Capabilities Assessment to Improve Project Success Rates
In May 2007, the Massachusetts Division of Unemployment Assistance (DUA) signed a contract with Bearing Point, Inc. to modernize the State’s unemployment processing system. The project was called the DUA Quality Unemployment System Transformation (QUEST) Project. Bearing Point filed for bankruptcy in February 2009 and Deloitte announced they would buy Bearing Point for $350MM in March of the same year.
"The government is incapable of running projects. Simply put, their miserably high failure rate proves that government should be out of the project management business." There are plenty of examples of this. We have heard this line, or ones similar to it, time and again and rarely hear how the projects failure reasons support the hypothesis. The reason? The prognosticators purporting this are part of the problem. Coming to that conclusion does not take any superior intellect—just listen to the nightly news. However, to try to get closer to the truth, I candidly and confidentially interviewed a number of government project managers and executives to gather their views. Following is a summary of those conversations.
In order to comply with the Affordable Care Act, the State of Oregon made the decision to build its own Health Insurance Exchange (ORHIX). An online portal to allow applicants was supposed to go live October 1, 2013. As of March 30, 2014 the site was not functional and all ORHIX applications must be processed from paper applications.
Experience with red projects has more value than recovering them—avoiding them is the real objective. This presentation focuses on a number of techniques learned while recovering projects that greatly improve the chances for success. It introduces the concept of a Guidance Team that gets involved with the project at the customer inception stage and follows the project and team through to the project completion.
From years of experience in recovering red projects, I estimate that only a third of all problems that affect red projects are actually on the project; the other two-thirds are in the surrounding organizations. Poor policies and procedures or lack of commitment by the customer, vendor, integrator, or organization overshadows problems on the project. Unfortunately, project managers do not have the authority, or even the influence, to address these issues. Their only course of action to complete the project successfully is to band-aid the problem. This must change if companies are going to quickly and accurately implement business initiatives.
Select any area to learn more:
Months ago, maybe over a year, now, I was blasted for talking about innovation in the context of information technology (IT) projects. The gist of the complaint was that all IT folks think they are building some new groundbreaking, revolutionary application that requires the latest in technology's tools. I agreed with his argument, qualifying that although this seems to be a pervasive theme, IT is a discipline that needs to keep one-foot in the pioneering frontier. Regardless, I had to concede that many innovative initiatives are more about a technician playing with some new toy. Jobs like implementing ERP interfaces to manufacturing execution systems (MES) only sound new. Unfortunately, I must say, "been there done that." Most IT is neither new of innovative. To avoid squandering funds, executives must understand and direct what needs to be innovative and permeate the company's culture with that knowledge. Otherwise, the wasted time and expense will suck a company dry.
"Project management is easy. We have been managing people for hundreds of years. Just take any manager, give them a project, and tell them to get it done." Experienced project managers will accurately predict the end of this story—there is a disproportionate chance this project will fail. Rather than "manager" being the key noun, a leader is required to deliver project value on time and within budget. To distinguish the project manager further—functional managers need only manage subordinates, while successful project managers lead extended project teams. This fundamental difference drastically increases the project manager's scope of the responsibility, since the project team includes an entire flock of stakeholders.
Friday brought news of another company outsourcing part of their IT. The details are sketchy, but it appears that all the COBOL programmers (many counting days until retirement) are going to have their jobs moved half way around the world. Soon after, it sounds like the IT infrastructure and operations will follow. Friends lamented about more jobs going overseas. I had to ask what other options management had. I did not hear any alternatives.
To the dismay of my cohorts and their potential pink slips, I am less concerned about outsourcing the administration of servers, networks, and base applications. For most companies, those are not the systems unique to their mission. These days, those functions are utilities. However, outsourcing customized systems that are at the heart of how a company does its business and distinguishes itself to its customer, is very risky. It may be the only option now; however, it could have been avoided.
The other day, while playing with my nine-month old Granddaughter, I counted the number of times she tried to do something and failed. If I had that much trouble, I would give up. Then I reflected on how many successes she has ever hour. Day by day, she changes—in a marked way. Making new sounds, crawling, climbing, signing, putting toys together, they are all big steps. She repeatedly tries until she gets it right, resulting in more successes in a day than I have in a week... maybe a month, even though she fails at more things in an hour than I do in a year. Maybe, if I were to increase my number of failures, successes would skyrocket.