FAQs - Bridging Business & IT
We help companies fix broken IT projects and show others how to avoid breaking projects in the first place.
There seems to be a difference between the project failure rates that you cite and those quoted by the Project Management Institute (“PMI”). Can you explain the difference?
Yes. At first glance, the failure rate estimates from PMI (who suggests a range of roughly 14% to 19%) appear to be lower than the failure rates we cite. There are three factors that explain this apparent discrepancy. First, PMI’s annual “Pulse of the Profession” is a global survey that focuses on much larger and more mature organizations with far greater resources than is representative of the general business population. In 2019 54% of the respondent companies (2,406 out of 4,455) were over $500 million in annual revenue with 45% being over $1 Billion. By comparison, there are less than 7,000 companies in the US with annual revenues over half a billion and they represent less than 5/100th of one percent of the total number of US companies. Second, PMI tends to survey its certified members who are more experienced and better trained than the project management population overall. That said, such certified professionals represent only about 5% of all the project managers in the US. Finally, PMI looks at all projects, not just IT projects. So, while PMI’s methodology makes perfect sense when attempting to gain an understanding of the project management profession overall, it is not necessarily reflective of the enterprise IT experience in the US. One would expect to find what PMI has found—better trained professionals in better equipped organizations achieve better results.
There are two component costs to IT project failures—the first is more visible, clear-cut and grabs the headlines. The second is less visible, but is far larger. The first type of costs are those related to IT projects which either fail outright or are otherwise abandoned. These require a total write-off. In 2012 the best estimates of these costs in the US were about $100 Billion per annum. In 2020 the Consortium for Information and Software Quality (“CISQ” a collaboration of Carnegie Mellon University’s School of Computer Science – one of the best in the world by the way) estimated this cost at $260 Billion.
The second type of failure costs is harder to both see and quantify, but research by ZDnet, the Institute of Electrical and Electronics Engineers (“IEEE”) and CISQ provides some great insights. This second type of IT project failure cost comes from rework on all the systems that eventually limp into production but never do what they were supposed to do—so they have to be continually patched throughout their service life. The IEEE notes that almost 50% of a software professionals time is spent on rework rather than on work than is done right the first time. They found that for every dollar avoided up front by short-cutting the business requirements and design processes a company ultimately spends $36-$50 pre-release or go-live to fix what could (should) have been caught earlier. If the error makes it into production, the cost to remediate the issue sky-rockets to as much as 100 times what would have been the up front cost to do it right. Over the service life of the system these remediation costs add up—a bad IT project is a thief that keeps on stealing. Using IT spending estimates from Gartner along with failure rate analysis from the IEEE yielded an estimate of roughly $400 Billion per annum which closely agrees with ZDNet’s separate estimate for these IT project failure costs in the US in 2012. In 2020 CISQ estimated these costs at $1.56 Trillion.
Taken together, project write-offs and unnecessary rework totaled $500 Billion in annual IT project failure costs in 2012 and $1.82 Trillion in 2022. About a 3.5 X increase. The percentage of projects that failed remained almost identical between 2012 and 2020. Inflation accounted for some of the increase, but the explosive growth of software in every area of our lives accounted for the rest. This problem isn’t going away on its own.
What are the scientific discoveries that you reference that explain why people often forget the critical details that are vital to the success of an IT project?
In the last 20 years neuroscience has made some remarkable advances. We’ve learned that our unconscious mind is playing a far larger role in decision making than we previously thought. It turns out that human beings are not logical, rational actors who consciously think through decisions based on the best available information—as economists have proclaimed and business schools continue to teach. Psychologists have now convincingly demonstrated that a great deal of human behavior is either driven or significantly influenced by our unconscious minds. Economists have had it all wrong, but the business community has yet to catch up with what the scientific community now knows.
If you’re really interested in hearing about the science behind our Solution, please download our white paper.
Is the Business Execution Lifecycle & Process Mining Roadmap ("Roadmap") limited to any specific project management methodology?
No. The Roadmap is project management model agnostic. It is a framework for articulating and defining the execution strategy of the business—for capturing what the business wants to do, so that all of the things the business needs to do to accomplish that mission (aka business requirements) can be identified. The Roadmap works as well with a Waterfall project as it does for an Agile project and anything in between.
We’re here to teach you how to fish. We’re not here to fish for you. We like to move quickly, but we can only move as fast as you do. We can usually tell in an hour or so whether we think we can help you. If we can’t, we’ll tell you and try to point you in the right direction of someone who can.
If we think we can help you, we’ll suggest that everyone on your IT project team (sponsors, key stakeholders, PMO, analysts, business and process SMEs, internal tech team and external vendors) sit through the first phase of our training (one day) so they understand what the problem is that we’re trying to solve, why it’s happening, and how we need to fix it.
From there the number of participants usually gets cut in half going into our second phase which is a two-day hands-on workshop. Only the project manager(s), analysts, key business and process owners, solution architects, internal and external tech team leads need to take part in the workshop. If possible (meaning that we’re working with one company and you have an existing project to work with), we’ll try to use your actual project as the basis for the workshop exercise. If not, we’ll work with a simulation that we’ve developed.
Where things go from here will vary depending upon your specific organization, project and the skills of your team. If your project leadership wants an on-going resource to answer questions or provide coaching, phase three of our training offers multi-month coaching that’s tailored specifically to your needs.
We don’t believe in endless engagements. We’ll always be available to provide coaching or answer questions if you need help, but we’re talking about your business, not ours. Only you and your team can execute your mission.
In a phrase, pattern recognition. We see things very quickly that others never do. We know where the landmines are buried. We know the tricks of the trade to get around them. We know from decades of experience what to do to address an issue once it’s been identified. And our mission in life is to pass that knowledge and those skills on to others in our profession.
Making a decision to work with us boils down to a decision about time and money. If you’ve got all the time in the world, and money is no object, then by all means—reinvent the wheel and learn things for yourself the hard way. If, however, time and money are tight, the stakes are high, and you’d like a shortcut to get to where you need to go faster, then you might want to consider talking to a guide who can show you the ropes.