September 11th, 2007
In my previous article, 10 Ways To Insure Project Failure, I focused on project failures that resulted from management mistakes. Of course, failures can happen not only from poor management but from basic design mistakes, inadequate or improper programming tools and/or coding techniques, bad processes and/or procedures, or external forces. Once you’ve recognized that a project is in trouble, what should you do to help it recover or even determine if it can or should be recovered? Here are some steps you can take to turn things around.
1. Stop Work and Scrap the Current Schedule
When problems are mounting and it is obvious that a project is in trouble, many managers and team leads will continue the death spiral even further. They’ll often do this by forcing extra work and stress on the development team. Or they may take other failure prone tactics like bringing consultants or more programmers, believing a new tool is a panacea for all the problems, or other such things. The answer, however, is to stop the work on the project. If things are going wrong it should be obvious that continuing down the wrong course will only make things worse.
Scrapping the current schedule is another politically risky move. The company may have a lot riding on the work being done by such and such a date. You have to make sure everyone understands that the present schedule was irreversibly flawed and unrealistic. Such a schedule gives false expectations to upper management and users as well as demoralizing the developers. Emphasize that a new, realistic, schedule is the goal of this recovery process.
It does take some political courage to do this. Some organizations will turn on a manager or lead who stops a project cold and speaks the truth about the impending disaster. To sell it politically, emphasize the positive aspects, that it will save money and save the project while just continuing the status quo will result in failure.
2. Review and Reevaluate Everything
Go back to your original requirements and design and see if you can spot the flaws there. Perhaps the requirements are pie-in-sky and need to be cut back to something more realistic for the time frame. Maybe the design was too ambitious and needs to be scaled back or gradually phased in over several iterations.
Take the time to review each feature and rate it according to its importance to the project. Force everything to be rated at least with a ‘must-have’, negotiable, ‘nice to have’, or ‘can wait’. Just don’t let the pointy haired bosses say everything is a top priority.
Look at the programming tools you were using. Maybe that hot third party development framework or control wasn’t so hot after all and should be eliminated or cut back. Maybe making it a 100% web based app isn’t practical given the requirements you have. The objective is to discover if using the wrong tools is holding you back.
Review the code. Perhaps your team is new to OOP and is having trouble with developing classes. Perhaps they’re new to .NET or whatever language you’re using and they’re making coding or design errors. Having the team do review work is also helpful politically since some will complain that the programmers are ‘goofing off’ since the stop work order.
The goal of this part of the process is to identify problem areas so that corrections can be made.
3. Is the Project Feasible?
Now that everything has been reviewed and the causes of the problems should have been identified, it’s time to decide if work should continue or not. This is the moment of truth.
If the problems that have been identified in the previous step indicate that there is no way the project can be completed ‘as-is’ then it should be canceled. For example, if the reevaluation indicates that it will take a year to complete the project with a staff of 5 programmers but the budget only allows for 2 people and the schedule is for 3 months, it should be obvious to all that it won’t work.
It may be feasible to recover a portion of the project and do it within the needed time line. Don’t scrap the whole project but look for things that can be recovered and reused for a more reasonably scaled project.
It could be that one minor situation was causing the delays. For example, bugs in third party library might be the problem. In that case, the project might be put back on course quickly by replacing the offending component.
Now it’s time to negotiate the changes in the schedule and specifications with the project sponsors. This can be difficult if you’re dealing with a politically charged situation but, if the project is to be recovered, it’s a necessary step.
First, examine and review the specifications and requirements with the sponsors. If the flaws were found in this part of the project, work on negotiating on these first.
Next, take a look at the project features with them and tell them what can and can’t be done, what can’t wait and what should wait, and so forth. There will be some disagreement but the objective is to put together a realistic set of features that everyone can live with.
Lastly, negotiate the schedule. Don’t commit to anything firm yet. Explain that you will need to get with the development team to put together a realistic schedule based on the negotiated feature set. You can give a wide estimate but if you commit to a specific date or even a narrow time range you may very well be setting yourself up for a second failure.
5. Prioritize and Estimate the Remaining Tasks
Now that you have what should be a realistic feature set get with the development team and have them develop estimates for each of these features. Keep the granularity small by breaking down tasks into units of no more than a day or two. Any larger and you will risk being right back where you started.
Also make sure that you include estimates on tying up loose ends and stubbing out features to be added in a later release. And, lastly, make sure that you don’t shortchange any testing or documentation that will be needed as well in your estimates.
6. Build a New, Realistic, Schedule
Now that all of the tasks have been identified you can use them to build a realistic and accurate schedule. Once this new schedule is ready, take it back to the project sponsors. If it doesn’t meet with their approval then you’re back to step 4, negotiating. Determine what to drop to get the project to fit the needs and expectations of the sponsors while making sure that you keep it within the task estimates you’ve developed. The goal is to construct an accurate schedule that everyone can live with and that can achieve the desired outcome.
7. Get Back To Work
Now that the project is back on course, it’s time to begin work again. Make sure that you don’t repeat past mistakes. Beware of bad development habits creeping back in or project sponsors trying to use political muscle to get a dropped feature added back in. Keep a watchful eye out for existing problems recurring or for new ones cropping up. Remember that slips and problems usually happen very slowly and gradually so don’t let them grow by ignoring. Make sure that the feature ‘micro-stones’ are being met. If one isn’t quickly deal with the problem.
Using the Scrum methodology can work well in this phase to keep things on track although you should be wary of introducing new techniques into a failing, and now, hopefully, recovering, project. My advice would be to introduce ideas that help you meet the goal of completing the project but go slow with those that seem to cause problems. I’ve used some Scrum like methods but nothing formalized in some project recoveries. I’d like to hear from those of you who have used a formal Scrum methodology to recover a project.
Let me know if you have any questions or thoughts about this article by leaving me a comment or using the contact me button.
Entry Filed under: Project Management
Rate This Article: