Project Health Checks and Audits

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.

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. 

The subpoena shows up at the front desk and you get the call to come and pick it up. You get that nauseating feeling that it is going to be a long day… no… a very long year. The subpoena asks for every contract, statement of work, 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 corners you cut for the sake of getting the project done and meeting the customer's incessant requests for more or different features and functions.

You wonder if along with bringing in the lawyers you should also bring in an expert to help you build your defense.  This keynote helps you understand what experts witnesses look for and how they prepare their case. 

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.

People routinely ask me the question, "What do you do when you find yourself on a project that is a hopeless failure?" It was raised again a few weeks ago in a Focus.com roundtable and then last week in an interview with Andy Kaufman. It only matters if the executives above the project are ignorant to how dire the situation is. It is tricky, trying to convince someone that they have a problem when they refuse to acknowledge the obvious—a tough and politically dangerous sell. The general consensus is "dust of the résumé." However, there is a logical approach to the problem—be logical.

Leadership is more than leading the people reporting to you. Too often, you need to lead people over which you lack any authority. The absence of hierarchical advantage adds a challenge, but is ideal training on how to deal with managers, customers, and difficult people. The key is making them feel the direction chosen is theirs. One of the best methods of doing this is storytelling.