Project Governance and Definition

Projects build capabilities to met corporate goals. If you are a CEO, you need to make sure your employees and vendors know what those goals are and how they fit in to the plan. If you are a project manager, you need to know the bounds of you project. If you are anywhere in between, you need to understand how all the pieces fit together and keep it all aligned.

Most organizations consist of multiple business and support units, each populated by highly trained, experienced executives. But often the efforts of individual units are not coordinated, resulting in conflicts, lost opportunities, and diminished performance.

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.

Back from the brink... the first fail-safe recovery plan for turning around troubled projects and keeping the problems from reoccurring.

When budgets are dwindling, deadlines passing, and tempers flaring, the usual response is to browbeat the project team and point fingers of blame. Not helpful. For these situations, what is needed is an objective process for accurately assessing what is wrong and a clear plan of action for fixing the problem.

In Rescue the Problem Project Todd Williams, President of eCameron, describes how projects go wrong and what to do to fix them. It focuses on people first, then process , and finally technology. By doing this it helps you find the root cause of the failure and helps you prevent it from happening again.

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

Projects build capabilities to met corporate goals. If you are a CEO, you need to make sure your employees and vendors know what those goals are and how they fit in to the plan. If you are a project manager, you need to know the bounds of you project. If you are anywhere in-between, you need to understand how all the pieces fit together and keep it all aligned.

Most organizations consist of multiple business and support units, each populated by highly trained, experienced executives. But often the efforts of individual units are not coordinated, resulting in conflicts, lost opportunities, and diminished performance.

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.

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.