Project Governance and Definition

The subpoena shows up at the front desk and the call comes to you to pick it up. That nauseating feeling in your gut is the prelude to a long day… no… a long year. The lawyers want every contract and statement of work, each change order, log, email, document, physical mail, specification, test document, picture, drawing, scratch note, etc. that ever existed on your project. You reflect back on the project and wonder how many times you cut corners in order to get the project done. Well as "done" as it is. After all, the customer never did really accept the final product. Maybe you should have had the project health check performed.

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.

Estimates for the annual cost of project failure are as high as two trillion dollars a year. The rates for projects being at risk are in the 60-70% range, and a quarter of all project's problems are so bad they are simply canceled prior completion. Preferably, all projects will run according to plan. However, moving from a 60% failure rate to 0% is unrealistic. To improve success rates, organizations must first understand what it is that makes their projects fail. Reasons range from methodology to human failure to lack of executive commitment. Taking a systems approach to analyzing projects uncovers all the factors that are contributing to the failure.

"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.

Executives build PMOs to ensure people follow a process. Companies require project management certification. Project managers have religious battles over agile and waterfall. Mistakes occur and managers implement more processes to prevent their reoccurrence.  Yet there is another philosophy that says this is the wrong direction completely. This ideology feels that people need more independence and less bureaucracy. The people who follow this think that people need more leadership training. People or Process, as the name implies, looks directly at these arguments and the role of people versus process in a project's or an organization’s success or failure. 

Decisions, deshmisions, what is the big deal? Anyone can make a decision! Hardly. After years of working with ineffective initiatives and consternated companies, I have a healthy respect for the D-word. It is all about the seven 'tudes—ineptitude, attitude, fortitude, altitude, aptitude, incertitude, and vicissitude. Some organizations obtrude the 'tude in which they are imbued, while others are denude of a common 'tude.

Projects build in technical debt and maintenance groups remove it—if your organization has a maintenance group. Technical debt accrues in any product, whether or not it has a technical component. It is the result of taking shortcuts when building the product. Sometimes it is the result of not having enough time, on other occasions it is due to not having the right tools. Anything from the implementation of the software component to light fixture can have technical debt. Promises are made to correct it later, but later never comes.

Project failure is rampant. In the US alone, the cost estimates for failure run as high as a trillion dollars annually. Regardless of the industry, executives seem powerless to alter this direction. The challenge for them is understanding where to focus their time and energy. All too often, they take the seemingly obvious move of zeroing in on the project manager, their teams, and technology. Other executives, reflect on their contributions to the failure. That self-reflection is time well spent as executives are essential in setting direction, aligning projects to corporate goals, implementing effective governance, and providing the needed resources. In other words, being effective leaders. This keynote explores the actions executives need to take to have the greatest impact on project success.

A few weeks ago, I posted an article on five of the ten stupidest decisions management had done on troubled projects, as promised, here are the other five. Although these may all bring a little light hearted laughter, the goal is to educate in order to avoid repeat performances. We all have seen, and made, dumb decisions; finger pointing and blame will not improve the result. So, read on, enjoy and then share your experiences so we all learn more.