A set of guidelines exists that can work to rescue foundering projects; the guidelines operate along the lines of people, process and product. We can combine the practices in this section in endless ways to create an endless number of recovery plans.The plan in this section is designed to rescue projects that are in deep trouble. Those are the projects that need the most help so I have described a thorough approach. If our project is not in that much trouble, we can use a less thorough approach. Adapt this project-recovery plan to the specific needs of your project.
One plan that virtually never works is cutting corners. Far from being a time to cut corners, project recovery is a time to return to basics. The plan described here is consistent with the four pillars of rapid development:
- Avoiding classic mistakes
- Applying fundamental development practices
- Managing risks
- Looking for ways to apply speed-oriented practices
(see Best Practices)
- First Steps
Before you launch a recovery plan, find out what kind of plan you need:
- Assess your situation
Determine how critical the deadline really is and what precisely is needed to meet it. You might find out that there isn’t really any hard deadline and you don’t need to worry about project recovery at all. Or you might find that our users are much more willing to negotiate the feature set to avoid a late project than they were at the beginning.
- Apply Theory-W analysis
What do you and your team need to succeed? What do our users need? What do you need to salvage the users relationship? Don’t focus on the past. Focus on the present. If you can’t find a way to make winners out of everyone by their own standards, scuttle the project.
- Prepare yourself to fix the project
If your project is in recovery mode and not merely a little behind, your project is broken. Realize that your project is broken. Realize you cannot fix it by doing same things that you have been doing. Mentally prepare yourself to make significant changes. Prepare both your team and management for the reality that significant changes will be needed if they want to rescue the project. If people are not willing to make significant changes, you have already lost the battle. Consider canceling the project.
- Ask your team what needs to be done
Ask everyone on your team to contribute at least five practical ideas about how to rescue the project. Evaluate the ideas, then implement as many of them as you can. Give people the credit.
- Be realistic
If you are in project-recovery mode, you are probably wearing a string of broken schedule promises around your neck. If you are in project-recovery mode, your team desperately needs a strong dose of clear-headed, realistic project leadership. When you start your project recovery, admit that you don’t know how long it will take to finish. Explain your plan for getting the project back on track and then give a date by which you can commit to a new deadline. Don’t commit to a deadline until you have good reasons to think you can meet it.
People are the most important point of leverage in rapid-development and you need to put that area of your rapid-development house in order before you proceed to the areas of process and product.
- Do whatever is needed to restore the group’s morale
During project-recovery, morale plays a critical role in your team’s productivity. If your group has been working hard, the question is not how to motivate them to the utmost but how to restore their morale so that they will be motivated at all. Be sure that you are providing for the team’s hygiene factors. Remove excessive schedule pressure, poor working conditions, management manipulation and other morale killers. For more see the 5 Motivation Factors.
- Clean up major personnel problems
If you think you have a problem person, face up to that fact and eliminate the problem. Replace uncooperative team members even if they are key contributors. They cost more in team morale than they contribute technically. You are regrouping anyway so this is a good time to cut your losses.
- Clean up major leadership problems
Look at how you have been providing leadership to the project and adapt different strategies and techniques to the project and the team. Don’t be scared to make 180 degree changes.
- Add people carefully, if at all
Remember Brooks’s law that adding people to a late project is like pouring petrol on a fire (Brooks 1975). Don’t add people to a late project nilly-willy. But remember the whole law. If you can partition work in such a way that an additional person can contribute without interacting with the other people on the project, it’s OK to add a person. Think about whether it makes sense to add someone who will spend 8 hours doing what an existing developer could do in one hour. If your project is that desperate go ahead and add a person. But stick to the plan.
- Focus people’s time
When you are in project recovery mode, you need to make the best possible use of the people who are already familiar with the project. Consider taking the money you would have spent adding people and use it instead to focus the efforts of your existing people. You will come out ahead.
- Allow team members to be different
Some people will rise to the challenge of project recovery and become heroes. Others will be too burned out and will refuse to give it their all. That is fine. Some people want to be heroes and others don’t. In the late stages of a project, you have room for quiet, steady contributors who don’t rise to heroic heights but who know their way around the product. What you don’t have room for are loud naysayers who chide their heroic teammates for being heroic. Morale during project recovery is fragile and you cannot tolerate people who bring the rest of the team down.
- See that developers pace themselves
Runners run at different speeds depending on the distance to the finish line. Runners run faster towards a nearby finish line than they do towards a finish line that is miles away. The best runners know how to pace themselves.
Although we will find our greatest leverage in the area of people, we must also clean up our process if we want to rescue a project that is in trouble.
Identify and fix classic mistakes
Survey your project to see whether you are falling victim to any of the classic mistakes. Here are the most important questions to ask:
- Is the product definition still changing?
- Is your project suffering from an inadequate design?
- Are there too few management controls in place to accurately track the project’s status?
- Have you shortchanged quality in the rush to meet your deadline?
- Do you have a realistic deadline? (If you have slipped your schedule two or more times, you probably don’t)
- Have people been working so hard that you risk losing them at the end of the project or earlier? (If you have already lost people, they are working too hard)
- Have you lost time by using new, unproved technology?
- Is a problem developer dragging the rest of the group down?
- Is team morale high enough to finish the project?
- Do you have accountability leaks? People or groups who might mean well but who have not been accountable for the results of their work?
Fix the parts of our development processes that are obviously broken
When a project is in trouble, everyone usually knows that a few parts of the process is broken. This is where back-to-basics really comes into play – the broken parts are often broken because the project has consciously or unconsciously been ignoring the software fundamentals. If the team is tripping over itself because we have not been using version control, set up version control.
If we are loosing track of the defects being reported, set up a defect tracking system. If end-users have been adding changes unconsciously or do not give correct requirements, set up a Change Board. If the team has not been able to concentrate because of a steady stream of interruptions, move them elsewhere.
Create miniature milestones
In rescuing a drowning project, it is absolutely essential that we set up a tracking mechanism that allows us to monitor progress accurately. This is our key to controlling the rest of the project. If the project is in trouble, we have all the justification we need to set up miniature milestones. Miniature milestones should be miniature, binary and exhaustive.
They are miniature because either they are done or they are not – in one or two days, no longer. They are binary because either they are done or they are not – they are not 90% done. They are exhaustive because when we check off the last milestone, we are done with the project. If we have tasks that are not on the milestone schedule, add them to the schedule. No work is done “off-schedule”.
Setting up and meeting even trivial milestones provides a morale to morale. It shows that we can make progress and that there is a possibility of regaining control.
One of the biggest problems with setting up mini-milestones at the beginning of a project is that we don’t know enough to identify all the work in detail. In project-recovery mode, the situation is different. At that stage in the project, developers have learned enough about the product to be able to say in detail what needs to be done. Thus mini-milestones are particularly appropriate for use in project recovery.
Set up a schedule linked to milestone completion
Plan completion dates for each mini-milestones. Don’t plan on massive overtime; that has not worked so far and it won’t work going forward. If we plan massive overtime into our schedule, developers cannot catch up by working more overtime when they get behind. Set the schedule so that if developers get behind on their mini-milestones, they can catch up by working overtime the same day. That allows them to stay on schedule on a day-to-day basis. If you stay on schedule day-by-day, you stay on schedule week-by-week and month-by-month, and that is the only way it’s possible to stay on schedule for a whole project.
Track schedule progress meticulously
If we don’t track progress after we set up mini-milestones, the schedule-creation progress will have been just an exercise in wasting time. Check with developers daily to assess their progress against the mini-milestones. Be sure that when a milestone is marked “done” it is truly 100% done.
Do not allow developers to get off-track on their mini-milestone schedules.
The easiest way to get off track is to miss one milestone and then stop keeping track. Once a schedule has been calibrated, do not take schedule slips lightly. If a developer falls behind a single milestone, expect him to work overtime to catch up (if a developer meets a single milestone early, it’s OK to allow him to leave early). Daily milestones must be met consistently or the schedule must be recalibrated so that they can be met consistently.
Record the reasons for missed milestones
Having a record of the reasons that each milestone was missed can help to detect the underlying causes. A record might point to an individual developer’s need for training or highlight organizational dynamics that make it hard for any developers to make good or their estimates. It can help to distinguish between estimate-related problems and other schedule-related problems.
Recalibrate after a short time – one or two weeks
If a developer misses milestones and falls more than a half day behind, it’s time to recalibrate that developer’s schedule. Recalibrate by increasing the current schedule by the percentage of the slip so far. If the developer has needed 7 days to do 4 days work, multiply the rest of the work by 7/4. Don’t play games by thinking that you will make the time later. If you are in project-recovery mode, that game has already been lost.
Don’t commit to a new schedule until you can create a meaningful one
Do not give a new schedule to upper management until after you have created a mini-milestone schedule, worked to it for at least a week or two, recalibrated and worked a week or two more to check your recalibration. Giving a new schedule to management any other way is tantamount to replacing one bad schedule with a different but equally bad schedule. If you follow these steps first, you will have a more solid basis for your future schedule commitments.
Manage risks painstakingly
Create a Top-10 Risk List and hold daily risk-monitoring meetings. We can expand the 4:00pm war-room meetings to review risks and address new issues that have arisen as well as to provide timely decisions.
It’s often not possible to recover a project until you rein in the product’s feature set.
Stabilise your requirements
If requirements have been changing throughout the project, you don’t need to look any further for the source of your problem. You must stabilise requirements before you can bring your project to a successful conclusion. A system with significantly changing requirements cannot be developed quickly and often cannot be developed at all.
It is not uncommon to need to do a nearly complete requirements specification at this stage. Some products change so much during their development that by the time the crisis hits, no one knows for sure what features the product is supposed to contain. Developers and testers are working on features that might or might not need to be in the product.
Some projects will resist the work involved with formalizing a statement of requirements this late in the project but keep in mind that the other approach is the one that is causing this problem. You have to do something different and you have to know what your feature set is before you can finish the product, before you can even be sure that the development team is working on the product you want and/or need.
If the project has been running for some time, formalizing requirements will be a painful step because it will involve eliminating some people’s pet features. That is too bad but it should have been done early on and it has to be done before you can complete the project. If you cannot get the parties involved to commit to a set of requirements when the project is hanging on by its fingernails in recovery-mode then you might as well give up. You are fighting a battle you cannot win.
After you get a set of requirements, set the bar for accepting changes very high. Require a full day even to consider a change. Require more than a day as the minimum time needed to implement a change (this is for feature changes not defect corrections).
Trim the feature set
Recovery mode presents an opportunity to reduce the requirements to the minimal acceptable set. Cut low-priority features ruthlessly. You don’t need to fix everything and you don’t need to implement every feature. Prioritize. Remember, the real problem at this stage is not developing the product in the shortest possible time or creating the best possible product: it’s completing the product at all. Worry about low-priority features on the next version.
People should be ready and willing to define a minimal feature set at this point. If they are not willing to sacrifice pet features when the project is in recovery-mode, they probably won’t ever be willing to.
Assess your political position
If people are not willing to freeze requirements or fall back to minimal requirements, this is a good time to take a step back and look at what is really happening on your project. Think about why the other parties are still not focused on the product. What are they focused on? What is more important to them than the product? Are they focused on a power struggle? Are they focused on making you or your boss look bad? As ugly as organizational politics can be, they do exist and an unwillingness to make crucial compromises when there is no other choice is a telltale sign.
If you are caught in the middle of a political skirmish rather than a product development, the project-recovery plan in this section won’t be of much help and you should choose your actions accordingly.
Take out the garbage
Find out if there are any parts of the product that everyone knows are extremely low quality. When you have found a lot of defects in a particular piece of code, it’s tempting to think that you have found the last one. But buggy modules tend to produce an amazing, continuing stream of defects.
Error-prone modules are responsible for a disproportionate amount of work on a project and it is better to throw them out and start over than to continue working with them. Throw them out. Go through a design cycle. Review the design. Implement the design. Review the implementation. This will seem like work that you cannot afford when you are in recovery mode but what will really kill you in recovery mode is getting nickel-and-dimed to death by an uncontrollable number of defects. Systematic redesign and implementation reduces your risk.
Reduce the number of defects and keep them reduced
Projects that are in schedule trouble often start to focus on schedule and expedient shortcuts to the exclusion of quality. Those compromises invariably return to haunt the developers before the product is released. If you have been 3-weeks-to-ship mode for a while, you have most certainly been making quality compromises and shortcuts during that time that will make your project take longer than shorter. Focusing on quality is one way to reduce development time and doing so is essential to project recovery.
Get to a known good state and build on that
Plot out the shortest possible course from wherever your product is now a state which you can build and test some subset of it. When you get the product to that point, use daily builds to keep the product in a buildable, testable state every day. Add code to the build and make sure that the code does not break the build. Make maintaining the build a top priority.
Surprisingly, the best time to launch a project-recovery plan might not be the first moment you notice your project is in trouble. You need to be sure that our management and the development team are ready to hear the message and ready to take the steps needed to truly recover the project. This is something that you need to do right the first time.
You have to walk a line between two considerations. If you launch your recovery plan too early, people won’t yet believe that there’s a need for it. It is not in your best interest to cry “Wolf!” before other people can see that the wolf is there. If you launch it too late, it will likely follow on the heels of a series of small corrections or mini-recovery attempts that did not completely work and you will have undermined your credibility in leading a more effective, larger-scale recovery effort. You will have cried “Wolf!” too many times.
I don’t recommend letting your project run into the weeds merely so that you can do a better job of rescuing it. However, if your project has already run into the weeds, I do recommend that you time the presentation of your recovery plan so that everyone else on the project will be receptive enough for it to succeed.