Project Health Checks and Audits

"Why is it that when you get hired you are no longer the expert?" A chuckle rippled through the audience; however, the woman asking the question was serious. I turned the question back to the audience of director level managers, "Why is this the case?" There was silence. Finally, I proffered that it was management's lack of understanding the skills of the people working for them. "Who in your organization can you implicitly trust?" More silence. It is sad that organizations know so little about the people that they hired—the people on which they stake their company's future.

In many years of recovering failing projects, I have found a few management actions whose rationale seem completely absurd. Regardless of my efforts, I am unable to understand or dissuade them from their decisions. These decisions either precipitate the failure or greatly exacerbate the project's dilemma. Regardless, due to management's level of shear desperation, they can only be classified as stupid decisions. If there were the Darwin awards for management, these would qualify.

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.

It is amazing how people on failing projects neglect to look at their own issues prior to blaming someone else. Yes, blame is easy and on red projects since no wants to be the source of the issues. The truth is, everyone is at blame, so before bringing in an auditor or recovery manager, tidy up your house first.

Red project recovery is a four-step process. One must, however, determine a short-term plan for the project. It takes time to get to a resolution and it is nonsensical to continue spending money at the current rate. Other than doing nothing, there are two remaining options:

The four steps to bring a project back from red. They are:

1. Project Audit;
2. Data Analysis;
3. Solution Negotiation;
4. Plan Execution.

Like any recovery, be it twelve-step or four-step, it goes nowhere without realization of the problem. Step zero is acknowledging the failure. Without this step, the problems and subsequent resolutions will not have full recognition and the project recovery will fail due to the lack of management support. With realization, the recovery process has meaning.

Reading an article the other day, the author was lamenting on how Project Managers were under educated and needed to know more about earned values analysis, risk probability determination, finite schedule development and other tools that make a Project Manager great. She was arguing that certifications, like PMI's PMP^® certification, needed to have more testing on those subjects.

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.

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.