Plan a Better Project
As project budgets grow larger, the historical statistics become even more dismal — projects of $3 million to $6 million are successful only 15 percent of the time, while projects of $6 million to $10 million prevail only 8 percent of the time. And what of projects with budgets greater than $10 million? They almost never deliver, according to The Standish Group. Hardly 1 percent of these projects achieve their goals.
What can you do, as the manager of a large project, to avoid becoming another ugly statistic? Is it possible to buck the odds and implement your large project successfully, in spite of the overwhelming risk of flopping?
All of us know the old saying that an ounce of prevention is worth a pound of cure. This is just as true of large IT projects as it is of dental hygiene or automotive maintenance. It’s a lot easier to keep a large project out of trouble than it is to salvage one that has gone astray. Here are a few best practices you can use to keep your large project out of the weeds:
Replace phases with features
In her award-winning project management book, Manage It, Johanna Rothman talks about the problems that occur when project managers plan the entire project in the early stages and break it up into a series of phases such as planning, requirements, design, implementation, and testing. “But projects are full of risk,” Rothman writes. “Your carefully crafted schedule falls apart as soon as people start to work on the project.”
You can avoid this trap by planning the project in terms of features instead of phases. Create a prioritized list of business features and let this be the basis of all your planning. You can even use this list to create a Gantt chart, so long as each line in the chart represents the feature you will be implementing along with its proposed schedule.
Build your product incrementally
The Standish Group study delivers some good news: Smaller projects are more likely to succeed. Projects of $750,000 and less, which is the smallest group of projects studied, are winners approximately 55 percent of the time. These are much better odds than any of the larger projects. Although the study didn’t break this group into smaller divisions, experience shows that even within this project range the likelihood of success increases as the project budget gets smaller.
If you have created a project schedule based on features instead of phases, you have already set the stage to break your high-risk large project into a series of low-risk small ones. Starting with the highest prioritized feature, work with your business partner and project team to identify a set of capabilities that can be implemented in a short period of time — one or two months at the most. Then start building those capabilities.
This approach produces many valuable advantages for project managers. Jason Fried, founder of 37Signals, a web application company in Chicago, believes short projects help the project team work at a higher energy level. He says splitting a project into smaller chunks will excite and motivate people because they will more frequently be starting something new.
Stabilize the project team
Project teams go through five phases any time they are created: forming, storming, norming, performing and adjourning. Every time a project member is added or removed, the team is forced to go through the reduced productivity of the forming and storming phases. Don’t add and remove people impulsively — the resulting disruption could derail the team’s progress.
Norming and performing are the most productive phases a project team goes through. Once your project team has reached the norming phase, do everything you can to keep it there. Sometimes this means you have to run interference for them by taking care of small problems that could distract them from pursuing their goal.
Agile project management methodologies refer to this behavior as removing roadblocks. Whether you follow an agile lifecycle or not, your ability to remove roadblocks and distractions will make a big difference on the ability of your project team to focus on making progress.
Re-plan after every feature
Two of the most commonly cited reasons for why large projects fail are changing requirements and priorities. It’s hard for phase-based projects to keep requirements and priorities static as they march through requirements, design and so on, but projects that are structured around features don’t have these problems.
By only focusing on the requirements and design for the feature being implemented, you reduce the impact of changes in requirements and priorities. It’s not unusual for a business partner’s opinion of what is most important and of what he hopes to accomplish to evolve as he sees the results of the project. By building your plan around features, it is easy to re-prioritize them periodically as the project evolves. Your business partners will appreciate this flexibility, and you will dramatically reduce the risk of your project by anticipating change and creating a project structure that can adapt easily to your business’s needs.
Measure progress to predict the future
Long or unrealistic timeframes are another reason so many IT projects fail, particularly large ones. You can avoid this risk partly by using a feature-based approach to scheduling, but what if your estimates are not accurate? Your project could still fail if estimates and reality don’t come together.
The best measure of future performance for a project team is past performance. When you complete your first feature, compare your original estimate with the actual effort required. How close were you? Do you need to adjust your estimate for the next feature based on its similarity to the one you just finished?
Take advantage of the frequent opportunities to re-plan your schedule by adjusting estimates for remaining features based on the ones you’ve already implemented. As you continually fine-tune this assessment, your estimating capabilities will improve and your schedule risk will decrease as the project progresses.
Involve the user in interface design
Many projects falter because the end product simply doesn’t fulfill the needs of the users. Post-mortem analysis of these failures often indicates that the project teams either misinterpreted the original requirements or were not aware of assumptions about the product that were not captured by requirements.
You can avoid this problem by exposing real users to the product interface as soon as it is available. Build a working template of the interface as soon as you have an inkling of what you are supposed to do — don’t wait for a requirements document — and use it to test the assumptions the users bring to the product. Even if the interface is populated with fictitious data or isn’t connected to any sort of back-office system at all, the interaction of the user with the interface will quickly let you determine whether you are on the right track or not. If you have scheduled the demo early enough, you will be able to accept even major changes in direction without wrecking your project schedule.
Make your large project small
Large projects don’t have to fail. Project managers who are able to turn their high-risk big project into a series of smaller projects have a striking advantage over project managers who choose a phase-based, large-scale effort. By leveraging the reduced risk of smaller project efforts, project managers can make even the largest of projects succeed.
