10 Ways to Save a Slipping Project

November 19, 2008 by Peter Stevens

If anyone is looking for proof that agile and waterfall are from different planets, you just need to check out this article by Tom Mochal at TechRepublic, 10 ways to get a slipping project back on track. Overtime was top of this list, even if the deadline is months away! My first reaction was to roll my eyes. But this raises the question, what do you do to save a slipping project, especially if you are trapped in a waterfall?

Some of my "favorites" from TechRepublic's list were:

#6. Crash the schedule
#7. Fast track it
#8. Prevent all scope change
#10. Scale back the scope of work

"Crash the Schedule" and "Fast track it" — They sound like something Dilbert's manager would come up with. Actually they amounted to adding people. Brooks told us long ago in the Mythical Man Month that this is a sure recipe for making a late project even later. "Prevent Scope Change" — That's what the change management system has been trying to do all along. Why should it work now? "#10. Scale back the Scope" — you mean you are going to be honest about not being able to deliver every whim of the customer for the time and money he authorized? When all else fails, tell the truth! Better late than never!

Is there a better way to get (even) a non-agile project back on track? Absolutely. Even non-Agile projects can apply agile principles! Here is my list (and yes, this is how I approach challenged projects):

1. Be there for your team. Nothing is more demotivating than a project leader who finds subtle ways to remind his team how much more important he is than they are. So come to meetings on time and stay until the end. Answer requests for information quickly, uphold your commitments (i.e. promises you make to the team), and look for ways to make yourself useful to your team. Recognizing and removing impediments to their progress is a good place to start.
2. Ask the team. They know what problems they are having and can help identify solutions.
3. Focus. Get everybody to agree on the priority of getting a release out, especially people outside the project. These people may have other priorities, in which case you will have to stand up to them, refuse work and eliminate distractions which is not related to getting the project done.
4. Fix the target. What are the stories ("work flows" in waterfall-speak) which are really needed for the release? This is not quite the same as freezing the scope, because you might still eliminate features to make the deadline.
5. Hold a Daily Stand-Up Meeting. 15 Minutes, 3 Questions — What happened yesterday? What is your goal for today? What's getting in the way? Ask, don't tell. This helps your team focus on what they are doing and helps you recognize impediments to progress. Don't criticize people for their answers and don't tell them what to do. Otherwise it's micro-management and your team may not tell you the truth. Let them identify the need to communicate with each other. Identify impediments that need your attention. Don't discuss issues during the stand-up, but let people (including yourself) discuss things bilaterally afterwards as the need arises.
6. Manage Progress with a big, visible task board Forget the electronic stuff. Use cards and corkboard. Put the highest priority functions at the top of the board. Make a card for each task needed to complete the feature, including testing and customer sign-off. Track the progress of each task from "Waiting", to "In Progress", to "Task-Finished." When all the tasks are done, then the feature is "Really-Done." Update the board daily. This gives you and everyone else an immediate, obvious picture of the state of your project.
7. Prioritize. Decide what functionality is most important and get that finished first, then move on to lower priority features/issues/bugs.
8. Make features, not inventory. Demonstrate finished (really-done) functionality at least every two weeks. Finished means tested and production quality code. After each demo, plan the functionality to be delivered in the next iteration.
9. Leave the team alone. Once you have agreed with them what is to be delivered in the next two weeks, let them do their work. Don't disrupt them with unplanned work, requests for new estimates, changed priorities or other distractions.
10. Streamline decisions. Reduce the number of people empowered to make decisions about what should be in the product and what people should be working on. The closer to 1, the better.
11. Build quality in. Get every function *really* done before handing it off to QA for acceptance testing. QA should confirm that the program works, but finding actual bugs should be the exception rather than the expectation. This way you don't waste time fixing it later. The more time remaining until release, the more this one will pay off.

Well, that was eleven points. But making a project successful is not about satisfying the bean counters. It's about producing value for your customers and users. It's about producing a success for your company.

Bonus Points

Bonus point one: upgrade you engineering practices. XP offers an extensive tool box which can be applied to any software development project. Test Driven Design, Test Driven Development, Continuous Integration and Pair Programming head up a long list of engineering practices which you can use to build better software.

Bonus point two: upgrade your management practices. My experience has been that projects which start to adopt Scrum (even without changes in the overall project structure) see positive results almost immediately. These improvements become visible to the customers within two to three months.

What About Overtime?

Let us remember the Maxwell Curve: Peak productivity in a Waterfall project occurs at around 60 hrs/week. In an Agile project, the peak productivity is much higher and occurs around 35 hours/week. So I guess Waterfall project management really does live on another planet. But given that agilists can be substantially more productive, shouldn't you be trying to make your waterfall projects more agile?

Permalink