© 2014 by Ed Holmes, may be copied and distributed for research and education if referenced – all other rights reserved
After decades of concern about the failure rate of software projects, veteran project managers can point to a steady increase in the quality of development projects. Great progress has been made in software development methodologies and the ability to assess the quality of development organization processes. Most large organizations have invested heavily in implementing process standards developed by ISO and IEEE, and they continuously improve performance by measuring themselves against the corresponding ISO or CMMI© process assessment criteria.
Despite the negative media hype generated by large project failures like the ObamaCare fiasco, life is getting better. The improvements are certainly a cause for celebration, but we are far from total victory. Recent surveys show that outright project failures have fallen to a range of 20 to 30 percent, but that large projects fail at a significantly higher rate than small ones. Unfortunately, half of projects that don’t fail still experience serious issues with cost, schedule, and functionality.
Software systems require a great deal of cooperation and coordination. Large, complex organizations create serious challenges for an IT department. Dealing with multiple geographic locations and business divisions, navigating complex organization structures and sorting through inter-organization politics can create challenges that make the technical issues seem almost easy.
Based on several decades of managing software systems projects in a very large corporation, these are the seven most critical factors for success:
Each factor is described in more detail along with a set of probing questions that can be used during project reviews to drive out issues.
Strong Project Ownership | Trusted Technical Leader with Deep Business Knowledge | Clear and Open Decision Making | Proper Business Alignment | Classifying Research as Research | Realistic Scope and Project Plan | Proper Risk Management
Launching a project in a large business or organization without a strong business owner is like leading an army into battle without a general. The owner must be an enthusiastic but realistic project advocate and must be able to communicate its importance up, down, and across the organization chart. There must be only one project owner and they must be at a management position and level appropriate to the scope, cost and importance of the project. Perhaps more importantly, they must exercise a level of control commensurate with the personal consequences of project failure. Lack of involvement by Kathleen Sebelius (former Secretary of Health and Human Services) in ObamaCare was a major contributor to project failure. But, as she replied to a congressional hearing when asked to call out one of her subordinates as the chief culprit, "Excuse me, congresswoman. Hold me accountable for the debacle. I’m responsible." (New York Daily News, October 31, 2013)
Most projects have a technical leader who deeply understands the technology. Successful projects have a technical leader who also understands the major components of the business process. Experience actually working in the supported business process is highly recommended.
Successful projects have frequent, open, and honest communication in determining and communicating direction, and the people responsible for the success of the project are continuously involved.
Successful modern organizations innovate and adapt quickly, and execute multiple improvement initiatives in parallel. It is critical that large (and long) IT projects maintain alignment with the ever-changing organization. Does it make sense to continue with a warehouse parts tracking project if the company direction is to move to a just-in-time inventory approach? Should work continue on automating an existing business process if a recently acquired subsidiary has a superior and already automated process that will likely become the company standard?
There is a big difference between the “R” and the “D” of “R&D.” A sure path to failure is to treat a research project as a development project. Vendors or internal IT “experts” can easily mislead the business about the maturity level of the technology they promote. All too often the level of risk created is not recognized or accounted for in the project plan. A research project can be a great idea, but not if executive expectations are based on typical results for a development project.
It’s not just the IT component of the project that can create this issue. Throwing new technology at a poorly understood business process can’t even be called research, let alone development. It can best be labeled as reckless experimentation. The outcome will be wasted money and project cancellation – followed by painful punishment for IT leaders. The only benefit will be a slightly improved understanding of the current business process. Look for the phrase, “constantly changing requirements”, one of the most common symptoms of a poorly understood business process. For example, the Los Angeles School System just finished spending $130 million and more than a decade trying to centralize and automate their student records process. Years of frustration led the district to sue the software subcontractor. Unfortunately, the courts agreed with the contractor’s assertion that internal dysfunction in the district led to “constantly changing requirements” and faulted the district for much of the problem. (LA Times, 10/14/2014). The district fired the contractor and created an internally coded solution. As might be expected, this version is also plagued with major issues. For the sake of California taxpayers let’s hope this $130 million research project is complete and that the district now understands enough about its requirements to proceed with an actual development project.
This may the most difficult area for software engineers and IT project managers to maintain objectivity. Exciting new projects are difficult for them to resist, especially if they have been involved in developing the concepts and promoting the benefits. It can be tempting to ignore potential risk and complexity – but it can be very dangerous.
Although risk management has traditionally been a strong component of project planning in other industries, recognition of its importance has been slow to materialize in the software development discipline. Current standard methodologies now have well defined elements to identify, control, and track risk. Projects that regard risk management as a lower priority are bound to fail. Large and complex software projects may have important risks that go unrecognized or are improperly labeled as "assumptions."
I recommend that project managers hold a special project review quarterly to address these success factors. Most questions will be appropriate regardless of the project stage. Please have the courage to recommend major changes or outright cancellation of a project if it continuously fails this review.
Please send questions or comments to Ed Holmes, email@example.com