Your organization is undertaking a major new project that will have a significant impact across the board. If we know anything about project risk, we know the bigger they are the harder they fail. What can you do to improve your chances of success? Phase and stage your projects for a successful journey.
The September, 2006 issue of Baseline Magazine included an article on the Top 10 Project Pitfalls You Can Avoid. Number 1 on the list? A project’s scope is too monolithic and gargantuan. Here’s the example they used:
In 2001, McDonald’s planned to spend $1 billion over five years to tie all of its operations into a real-time digital network. Eventually, executives in company headquarters would have been able to see how soda dispensers and frying machines in every store were performing, at any moment. But after just two years, the fast-food giant threw in the towel.
There are, unfortunately, thousands of other recent examples of projects that were too big to succeed. There’s also lots of analysis to show us why jumbo projects don’t make sense. Two of my recent posts on Project Times, Start Your Project with PACE and The Great Canadian Payroll Debacle, show that things still haven’t changed all that much in ten plus years.
A study by the Standish Group revealed that projects costing less than $750,000 succeed 55 percent of the time, those in the $1 million to $2 million range have an 18 percent success rate, and those in the $5 million to $10 million range succeed only 7 percent of the time. So, we should be chunking our big projects into small pieces, right? Unfortunately, it’s still not happening across the board. Need more examples of massive failures by large organizations that should know better?
Ford Motor Co. lost an estimated $220 million on installing an electronic purchasing system. When Ford launched a procurement system dubbed Everest in 2000, the game plan was simple: exchange information on orders, accounts receivable and inventory status with suppliers electronically. The system was announced in 1999 and dismantled in August 2004. Ford pulled the plug when it realized more heavy investment was needed. The big issue: Ford’s suppliers were already tied to the automaker’s systems via electronic data interchange applications and didn’t see a benefit in changing to Everest.
The Internal Revenue Service’s failed $4 billion Tax Systems Modernization Program (TSM) of the 1990s is a glaring example of this tendency to bite off too much. TSM failed because it took a “big bang” approach in which the IRS tried to build a new and gigantic information system to integrate many disparate and out-of-date systems.
Having learned from this lesson, Arthur Gross, former CIO of the IRS, declared that the agency would from now on take “an evolutionary approach to modernization,” building on systems already in place.
One doesn’t have to work too hard to find lots of other recent examples. How do you solve this problem? Build the solution in pieces (phasing) and roll it out in pieces (staging).
Identifying phasing opportunities (how a solution will be built or assembled) from a business perspective is essential for creating change plans that optimize business value and manage risk. Because the risk of failure increases with size, stakeholders should consider phasing mandatory.
Phasing can be done by:
- customer or customer segments
- product lines or features
- process or function
- risks or exposures
One technique for establishing priorities and phasing options is to use the MuSCoW technique where each element of the change is assessed according to the following categorization:
Must – Minimum useful subset of business functional and structural requirements, features, locations and markets. Must be done in order to do business
Should – Workaround, but costly. Include as many of these in the first release as possible. Required by the business but there is a workaround that can be used temporarily.
Could – Great benefit but can manage without it for some time. Added benefit to the business but can be deferred.
Would – Wait until higher priority requirements are complete. Added benefit but needs to wait until higher priority requirements are done.
Staging relates to the options for managing the rollout or implementation of a solution. Avoiding the “big bang” implementation and staging smaller, targeted implementations can help gain experience, improve response times, manage risk and enhance value delivery. The options for staging are similar to the phasing options outlined above.
Phasing and staging decisions can seem challenging – too many and the costs, complexity and momentum may be negatively influenced, too few and responsiveness and return may be sacrificed and risks magnified. But avoid the big bang approach at all costs. It’s also important when establishing priorities to consider all of the elements that go together to make up an acceptable implementation package. Sometimes a few “coulds” or “woulds” can help add excitement to boost enthusiasm for and commitment to the change.
Given the risks of a project too big, ask the stakeholders how they would like to see the change phased and staged. Given the Standish findings mentioned above, “we need to do it all at once” is NOT an acceptable answer. And when pushed, you’d be surprised at the kinds of creative options stakeholders can come up with.
Drew Davison is the owner and principal consultant at Davison Consulting and a blogger on Project Times. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations to implement the empowered stakeholder groups critical to project success. Drew can be reached at firstname.lastname@example.org