Leadership for Project and Executive
Vision, honesty, and transparency: three key traits of an organization that can guarantee project success. This was summed up in last week's interview with Tom Cox, the host of Blog Talk Radio's Tom on Leadership program. His audience, primarily from the C-Suite, is keen to understand how troubled projects are a reflection of their organization's overall health. Projects are, after all, the proverbial canaries in our organization's coalmine. Projects stop performing because there is trouble in the organization.
"Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).
It happens hundreds of times a day around the world, the CIO calls an urgent IT Management Committee meeting. She has heard that one of the projects in the portfolio, a seemingly simple project doing a routine upgrade, is projecting a 20 percent cost overrun and will be three months late. How can a project go that far off track since the last week's executive team meeting? Managers scramble to get their stories straight, determine who to blame, form opinions and alibis, and pummel the project manager for failing to manage the project correctly, even though he has been saying the project is in trouble for months. The project has drifted from its initial intent and now the ultimate goal is to find someone to blame.
Loyalty. I have heard a lot about loyalty lately. It focuses on a company's loyalty to their employees. The current stormy economic condition means layoffs and employees on both sides of the pink slip are unsettled. Albeit, conditions today bare a stronger semblance to a hurricane stalled over the employment sector, while Wall Street seems to be holding its own, when the floodwaters subside both employees and employers will be on more fertile ground. As opposed to straining loyalty to its breaking point, it is only taking on a new form.
For years, project failure rates have been ridiculous. Various groups have published statistics showing troubled or failing project rates range from forty to eighty percent. People have asked time and again the primary reason for project failure and I repeat the same list so many have already stated—poor management, inadequate understanding of the goals, miserable communication, the list continues. However, I have discovered one problem common to every project I have recovered that I think is core to many of these generic observations.
In a meeting the other day, one exasperated participant exclaimed, "This isn't part of all the processes I just learned to get my PMP, how am I supposed to run this project?" I bit my tongue and refrained from looking over the top of my glasses and calmly telling him that running a project is a heck of a lot more than a series of check boxes. The poor guy was frustrated and lost. He was truly dumbfounded. His hard-earned certification failed to prepared him for his new assignment.
The project team has an obligation to tell leadership or the customer when they think the direction of the project is wrong. However, at some point the team must follow management. They have to trust management has the insight to know what needs to be done. I call this "Finding Religion." People must act on faith believing the direction is best for the company. This is often contrary to data that is in front of the team and indicates another direction.
Projects can be on-time, within budget, meet the specifications and still be a failure. Case in point, the new Dallas 160x72 foot mega screen. It seems the screen displays what it should, but is positioned a bit too low. So low, that on August 21st, the punter kicked a ball into it. Did someone forget the purpose of the stadium was playing football?
In daily talks and presentations, I am often asked what the most common reasons are for project failures. I usually turn the question around and ask people what they think. It is a fun exercise and people list a mixture of symptoms and sources. As mentioned in the previous blog, one must drill past the symptoms and get down to the problem itself. It is my firm belief that most project problems are rooted in the people, however people are creatures of habit.
It is common that when I am called into fix a red project to have management assign all of the projects ills to one problem. As of yet, I have to see such a project. There are multitudes of problems deeply embedded in the organization and the project team to make a project truly crimson. Managers look at how the problems manifest themselves, skip diagnoses and assign blame. Prior to getting to the point of calling an outside party, they have tried to fix the issues by attacking these symptoms. This only makes matters worse and the project becomes a deeper shade of red.