On Late Projects

As a followup to my earlier posts on Project Management: Art or Science?, I thought I should share the second major point to come out of that conversation: “How do you fix a late project?”

I know about half of you just thought “That's easy, you just…” and a myriad of answers followed. Let me respond to that: You're dead wrong and your project is going to crash and burn.

Now, take a deep breath and keep reading.

If you went to the doctor and said that you foot hurts, would she prescribe morphine to ease the pain? Of course not, she'd try to figure out the cause and address that. It could be that you stubbed your toe and broke it. It could also be that you've had a stroke. Each call for radically different treatments. You can't suggest a remedy until you've diagnosed the problem!

So I laid out what I – and a few others (Peopleware, Rapid Development, and The Mythical Man Month) – see as the primary causes and then potential fixes.

The single biggest reason is changing requirements.

Whether the requirements are in a formalized Requirements Tracibility Matrix or simple a list of “I want it to do X”, the problem is the same. A Priority and Impact must be assigned to every item. I use a simple 1-10 scale for each described as: Priority 1 = do this if there is time to 10 = do this tomorrow and Impact 1 = few will notice if this doesn't ever happen to 10 = the project is a failure without this. By multiplying these together and ordering them descending, it is quite simple to figure out which are the most imporant and critical for the project. By classifying all items in this way, you can make it clear to the customer where progress stands and where an particular item falls in the queue. More importantly, as a Project Manager, you can involved the development team, evaluate the new requirements, and respond to the customer with a new projected completion date or a suggested list of items to drop. Of course, at certain times in the project, any changes could be catastrophic. Make this clear to the customer by stating the delay required to simply evaluate the changes without even doing them. When faced with this sort of choice, most customers will attempt to work with you. More than anything, keep a complete record of all requirements, who submitting them, when they were submitted, and who – if anyone – provided comment, changes, or clarification.

The next reason is poor communication.

This can be poor communication of requirements, poor communication of division of labor, responsibilities and a variety of other aspects. The best way to make this worse is to add more people. As described as far back as The Mythical Man Month, adding more people simply increases the number of communication paths and lowers the average knowledge of the project. Throw in the fact that it also escalates the price of a late project and there are three strikes. The best way to address a situation like this is to improve communication. It means bringing the functional groups of the team together and evaluating everything. This may take a day… or three… or five to sort out, but the impact of diverging efforts are magnitudes worse.

The final of the top three reasons involves deployment/integration.

“It works fine on my machine!” You've heard and said this dozens if not hundreds of times. You spend the day writing code, check it into the main system, and then go home for then weekend. As soon as someone updates their codebase, it breaks. You didn't include all your files or you made a configuration change or you changed a method's signature. With the level of tools now available, there is little excuse for this anymore. Tools such as Ant: Cross Platform Java Build Tool, jUnit: Java Unit Testing Tool, Eclipse: The Java IDE, and their equivalents in other languages, this is steadily dwindling. It's stunning that by some estimates, nearly half of all development groups don't use source control. Then there are groups who have it and use it, but do so only rarely. This is the best way to ensure that projects don't work over the long term.

Now, will fixing these things or addressing them on Day 1 won't nessecarily give you a successful project. Unfortunately No. There are more ways for a project to fail than I have time to address here. Following these suggestions and fine-tuning your style will let you discover new and different ways to fail. This is why sharing information, building connects, and constantly learning should be a focus of the project manager both within and outside the organization.

Tomorrow, I'll address an interesting parallel between Lando Calrissian and Negotiating Deals that I noticed while watching The Empire Strikes Back last night.