CPR (Catastrophic Project Resuscitation)

If you're managing larger software development projects, bookmark this page immediately. I'm sure you'll refer to it at some point in your career.

Imagine the following scenario. For whatever reason, you suddenly find yourself managing a project that's already in progress. After meeting with the various stakeholders, you realize that the project is in trouble – serious trouble! I'm not talking about a slight schedule slip, or a few critical bugs that were discovered late in the development cycle. I'm talking about a project that's so out-of-control it's on the verge of being cancelled.

If you're a larger software development company, this means you've spent millions of dollars on a project that will never bring in revenue. If you're a start-up, it means you're going to run out of cash before your only product becomes available to the marketplace.

What now? You must take a strong corrective action and follow these 5 steps.

Step 1: Eliminate the Obvious Problems

There are always evident reasons why a project is running late. If you want to find out the true nature of the setback, don't ask senior executives; ask the people who are responsible for the schedule slip. Senior developers who have an excellent track record for being on time represent a great starting place for identifying problems. Other developers who tend to be consistently late and defensive about their tardiness do not.

Once you uncover the cause of the problem, eliminate it! This sounds so simple, yet is so frequently overlooked by IT managers. If the problem is linked to a feature creep late in the development cycle, don't try to solve it by switching from one incremental software development process to another. Freeze the requirements! If an identified person is consistently trying to squeeze in change requests that impact the schedule, assign this person to another project (preferably one that you're not managing).

Step 2: Set Up a Daily Build Process

Once you've eliminated the obstacles, you need to set up a daily build process. This will ensure you have a stable load as a starting point, and more importantly, will give senior management confidence that you are in control. Remember, it's not only about saving the project; it's about doing so before it gets cancelled.

Have someone run a series of automated tests on the daily build. If one fails, have the responsible developer fix it immediately, even if that requires him/her to stay late. Make it clear that breaking the daily build is not tolerable.

Step 3: Develop a Requirements Traceability Matrix

Now that you're confident the load is stable, you need to assess its overall status in relation to the requirements. You need to be clear on which features are complete, which ones are in progress, and which ones slipped through the cracks. The requirements traceability matrix (RTM) will give you an objective view of the release and, because it's well documented, will allow you to communicate your findings with Product Management and senior executives.

If you've followed the previous three steps, you have managed to eliminate the main problems, and now have a stable load and a clear understanding of the project's status. You are in control! Nonetheless, you're job is not done. You still haven't done anything to help the project meet its deadline.

Step 4: Reduce the Scope of the Project

The best way to squeeze the development schedule is to reduce the scope of the project by cutting features. For those of you who have already tried to eliminate committed features from a release, you'll agree that it's not as easy as it sounds.

Instead of asking the customer which features they want to cut, propose that features A, B and C be part of a subsequent dot release. Justify it by explaining that this will allow you to get the project back on track and give them more time to provide additional feedback. As long as this dot release is not too far away, the customer will most likely accept. Don't forget to update the RTM accordingly.

Step 5: Establish Project Milestones

Finally, plan all the features listed in the RTM to demonstrate how you will complete the project on time. Define miniature milestones according to these guidelines:

• Each developer should be responsible for at least one milestone per week. This will motivate them to work hard, and will allow you to discover a schedule slip before it's too late.
• Milestones should be binary. They are either complete, or incomplete. Measuring milestones using percentages (80% complete) is too subjective and doesn't give you a real feel as to whether the project is on track or not. As I keep telling my developers, once the first 90% of your feature is implemented, it's time to complete the second 90%.
• Milestones must be aggressive, yet realistic. Having aggressive milestones will motivate your developers to work hard. Having milestones that are impossible to meet will do just the opposite and will automatically result in a schedule slip.