Why do some complex IT projects succeed yet most fail? There is much research regarding why IT projects fail, and a great deal of understanding and wisdom has come from this. But there is a difference between identifying what to avoid as known pitfalls and knowing what to do to succeed.
Imagine trying to learn how to become a winning race car driver by polling the drivers that crashed about why and how they lost control of their car. You will definitely learn some important truths about avoiding oil spots and debris on the track that benefits any driver. But does that knowledge alone put you in the winner’s circle?
The great work being done analyzing outcomes of IT projects brings tremendous value and understanding. My assertion is that something more separates the great wins from the losses, and there are additional nuances lost when we roll data up for statistical purposes.
Large IT projects are not all the same, as deploying a packaged technology is very different than innovative or transformative projects. This seems self-evident, but when statistics are combined I believe it skews in favor of success, because deployment projects are more amendable to process and control management for success, and also have proven metrics for quality estimation. The area that I have most interest in is innovation and transformative large software development projects.
We also need to know the applied criteria typically used to determine “success”. Common practice is to define success as: on time, within budget, and deliver planned features. This is a rigid definition, and from a business perspective success and failure are more fluid in definition than a simple project management standpoint. I have seen projects within budget and on time with all planned features, yet brought little to no benefit to the business and were therefore a bad ROI. Conversely, I have seen projects run long and over budget, yet result in great value to the business. There can be a difference between business benefit success and project management success.
Based on the strict project success definition applied by most researchers, the majority of large software projects are not successful, when broken into three categories: “Failed”, “Challenged”, and “Successful”.
The Standish Group presents findings that between 2003 and 2012 only 6% of very large software projects were successful, with 42% being failed and 52% challenged. These statistics are staggering, but we must consider that challenged projects might still be successful from a business ROI standpoint. There are not clear statistics for ROI-based success and failure, and I respectfully disagree with the ROI projection statistics made in the Gartner blog linked below. But we are likely safe in accepting that the majority of large software projects are not a great success.
Typically in cases of a time and/or cost over-run, as well as a feature under-run (resulting in an un-planned phase 2), actually translates to a longer time to positive return from a business financial perspective. Sometimes this means writing off a loss, but in those cases there was usually bad decision making or lack of understanding potential benefit. Occasionally there are windows of opportunity that once missed mean the entire investment was a loss.
There is substantial research and evidence supporting the value of best practices and wisdom regarding the ingredients in a successful large project. For the sake of brevity the below list is not as detailed and nuanced as the planning for a complex project should be, but here are some key ingredients:
- Clear goals and longitudinal stakeholder involvement
- Quality architecture and design, technology stack, etc.
- Accurate estimation and planning of milestones and checkpoints
- Quality teams with appropriate expertise and competence
- Consistent communication and processes
- Experienced leadership and management of the project
- Appropriate focus and energy to maintain momentum
Much like successfully serving a gourmet seven course meal, having a list of recipes alone does not mean receiving a 5 star rating. There is much more to the execution of such a meal than simply following the processes of each recipe upon the ingredients required. Kitchen size, cooking time, preparation of sauces and stocks, conflict over appliances, so many opportunities for failure!
So what makes some large IT projects successful where most are not? I believe that the prescribed wisdom for planning and executing such projects are valuable and necessary, but I also believe there are two key elements that successful projects always have: Gurus and a lean philosophy.
This is a controversial assertion, but in my experience I have never seen a really large software project succeed without both of these. And I have seen many fail at the lack of one or both.
By “guru” I actually mean a visionary technologist that is gifted in business acumen and strong communication and interpersonal skills. These folks must have longitudinal involvement with the project from business needs and requirements analysis to executing the deployment, as well as latitudinal access and involvement through all the layers of teams involved (designers, developers, quality assurance, operations, business, etc.). Although not always authoritatively empowered they inevitably have significant influence leadership across teams. They must have a holistic grasp of the vision and execution of the project, and be able to move freely through the teams to ensure focus and understanding does not drift. They must be able to argue technical details as easily as business need.
Regarding “lean philosophy”, I am referring to controlling the geometric cost of complexity in large projects. Engineering modular technology and processes in a vacuum often results in over engineered and complex interfaces. Each component or process becomes more complex than required for its place in the architecture of the whole. This is a cumulative and geometric increase in complexity that can quickly overwhelm even the most genius of designers and architects. The lean philosophy is to ensure clear and limited requirements for each component, and ensure no inflation occurs. Too often it is during the integration phase of really large projects that excessive complexity and resulting instability leads to major re-factoring and time plus cost overruns. This is also the point at which features get cut to improve odds of meeting delivery timelines.
I have seen some folks achieve amazing successes in certain business segments where the competitors failed, and the primary distinguishing differences between the success and failures revolved around the two ingredients I am positing.
I have become a strong believer in “just enough” as the answer to questions about how much processes and controls should be followed, how much provision for future expansion should be included in the design, and how many teams to be thrown at a project. Lean philosophy applies in all areas.
One of the key scope planning steps is to break really large projects into multiple deliveries that each add value. This is another aspect of the lean philosophy.
Although in the postmortem of a failed project the reasons decompose into many smaller bits, in my experience the root cause of failure for large projects fall into these two categories:
- Lack of a visionary technologist leader
Please let me know if you are interested in hearing more details on implementing this approach to complex and large projects, or if there is interest in additional thoughts regarding the hidden costs of applying “patterns” and generic components and processes.