Author Archives: David

R&D vs. Project

Posted on by David

From McGee’s Musings:

The superficial resemblance between software development and construction in the physical world obscures the fact that often what we are doing in software development is more R&D than it is general contracting. Knowing which parts of the project are routine and which might be pushing the envelope requires a more sophisticated form of estimating and budgeting than vanilla project management techniques.

That makes a lot of sense to me.

LinkedIn

Posted on by David

After reading about LinkedIn over on rc3.org and a few other places I decided to try it out. It is basically a professional networking service that creates linkages among invitation-only networks while protecting the privacy of the participants. After making 4 invitation links I now have access to a network of over 1200 very interesting people. Pretty amazing.

I think this type of service is the kind of thing that professional associations should be focusing on: fostering quality connections among their members. That’s what they are all about and LinkedIn shows how you can facilitate that need in unique and valuable ways via the Web.

Sports Virtual Communities

Posted on by David

If you follow virtual community news, you may want to check out the May 16, 2003 issue of Sports Illustrated which has an article about the impact of sports community sites on the lives of coaches and atheletes. The article interprets that impact as largely negative. “Caught in the Net”, p46. Unfortunately SI doesn’t post their print articles online as far as I can tell.

On Killing Projects

Posted on by David

Sometimes projects cannot succeed in their current incarnation. I have been involved in a couple of projects that were initially disasters and had to be stopped, completely re-thought and then begun again. While it won’t happen often (hopefully!) being able to correctly identify a terminal project and deal with it can save time, money and finally generate a successful outcome. I’ve outlined a few factors to look for as well as some tips on how to kill a bad project.

When to Kill a Project

  • Over budget.
  • Over time.
  • Nowhere near completion.
  • Thinking about the project keeps you up at night and makes you nauseous at work.

The above are a deadly combination. Budget, time and completion milestones should all roughly keep pace with each other. Being over budget, over time and under completed is about the worst possible configuration and represents catastrophic failure for that project. Feeling sick to your stomach is your subconcious project manager telling you that you are doomed unless something is done. Listen to your body. The secret to excellent project management is recognizing tendencies toward the above early in the project rather than when you run out of money and/or time.

How to Kill a Project

  • Build a case including alternate options to meet original needs.
  • Gain support of stakeholders and a champion.
  • Present recommendations to leadership.
  • Do not play the blame game.
  • Learn!

Don’t just go to your supervisor and say this project needs to be killed. You have to address how the need that generated the project in the first place will still be met or debunk the necessity of meeting it at all. You won’t get anywhere unless you can confidently answer that one. You also need to sell all the stakeholders on the idea as well. Stopping a project is incredibly hard to do once momentum is established and you will need all the help you can get. Finally, don’t get into assigning blame for who screwed up what. That will just take energy away from killing the project. Fix the problems and learn what went wrong and why and how to do it better next time.

This is not to say that all poorly run projects must be killed. Usually you can make some adjustments to an existing project that will bring it back into shape. Killing should be reserved for those few that cannot be salvaged in their current form.