From the Sponsor’s Desk – You Can’t Always Get What You Want

In my last post, Fix the Business Process First, we looked at how a newly appointed VP went back to basics to understand the source of the problems being encountered and tackle the core issues. She solved critical client concerns and operating issues by fixing a broken business process.

In this post, we’ll look at how a tyrannical director’s excessive and unreasonable demands on a project team resulted in project failure and his own demise.

Thanks to reader T.G. for contributing the details on this project.

The Situation

This regulatory agency mandated a program to create central systems to share engineering data at each of the power generation plants under its oversight. The plant that is the subject of this case was an old plant. Their computer systems and processes were proprietary to each department making it difficult for engineers in other departments to see data that might give them clues about potential and real problems. As well, the plant had had a few low-level incidents and so was being closely monitored by the agency.

The Goal

A project was launched in response to the mandate from the agency to enable full sharing of operational and historical information across the organization, providing engineers with an overall view of plant operations and performance.

The Project

To help understand the desired end result that needed to be delivered, the project team developed and implemented a pilot in nine months. While it was not perfect, it did in fact work and was used on an interim basis to collect and disseminate the operational information. The regulatory agency was okay with the pilot as an interim solution but wanted the final version greatly improved (as did the engineers).
The pilot was barely finished when meetings for the next generation system started taking place. The project team wanted to move the pilot to a more advanced platform for managing the current and historical data and the associated charts, graphs, images and documents that were the core of the system. They considered a number of alternative solutions and presented their recommendations to IT management and the plant managers. The proposed solution was based on recently released technology and had a two year implementation target. The IT and plant managers liked the proposal but were somewhat concerned with target platform’s stability and reliability and the projected time frame. The team developed a plan to mitigate the risks. The IT and plant managers were satisfied. The project director was not.

The project director was a tyrant – an impossible man who had temper tantrums regularly and chewed people out throughout the day. He gave the team 6 months to put a new system in place with the new architecture. The project manager consulted with her team. They all agreed that 6 months would be utterly undoable. They proposed a number of options that would get them a phased in target solution over a two year period. The director insisted on the 6 month target. The project manager resigned. The regulatory agency was watching with great interest.

The Results

As predicted by the project manager, the deadline arrived and the system was not even close to complete. The replacement project manager was fired. The other plant managers looked the other way and had their engineers continue to use the original pilot. The project went on, but it was now too little, too late. The pilot stayed in use as the real system for another three years. Once again, a team was put under extraordinary pressure for little reason and nothing to show for it. The project director left the plant to pursue other interests. You can’t always get what you want!

How a Great Project Manager Tried and Failed

These are always tough situations to deal with. When the individual in charge tries to impose his or her will on others without considering and responding appropriately to the opposing views and feedback of knowledgeable professionals, chaos almost always ensues. The result: messed up lives (and sometimes careers), questionable quality, wasted opportunity, time and money.

In many ways, the original project manager did the right things:

• She focused on the objectives of the project to address the needs of the plant managers and the regulatory agency.
• She consulted fully with her team and accepted their counsel.
• She and her team developed alternative approaches that would phase the solution in over two years to accelerate the delivery of benefits and manage the risks associated with the new architecture.
• She said NO to an unreasonable demand.
• She escalated her concerns to her boss but, for a number of reasons including his own potential loss of job, he sided with the director.

What else could she have done? It’s not easy defying a tyrant but that’s exactly what was called for in this situation. Obviously the project director’s pursuit of an impossible 6 month solution was not only bad for the team, it was bad for the whole plant and the regulatory agency too. The director’s demands were exposing the plant to significant risk. The project manager needed to go around and/or over. And, that’s exactly what she did.

• She tapped into the other stakeholders to shift the director’s demands. The departments were protective of their data, but were told they had to comply (even though they hated this guy and did not want to see him succeed). Here was an opportunity for the other stakeholders to wield their influence. Unbelievably, they sided with the director.
• She escalated directly to the plant manager, admittedly very tough to do without the support of your own boss. He sided with the project director as well.
• Finally, she went directly to the regulatory agency for guidance. The agency’s representative on the project also supported the project director’s stance.

The project manager discovered that the director had sold a bill of goods to the stakeholders (behind her back) and by the time he presented his demands to her, it was too late to alter the opinions of the other stakeholders. They were all on board with the director, assuring the project manager that it would be all right. She watched the director’s enemies slap him on the back and congratulate him for being so smart. The project manager departed with her head held high.

The project manager had formed a stakeholder group at the outset of the pilot and they had been actively involved through the early stages. But, as so often happens over the course of a project, during the pilot development and implementation and the envisaging of the replacement solution, the project manager had focused much more of her attention on guiding her team to get the work done, much less on stakeholder engagement. That left her stakeholders ripe for the picking by the project director. Had she fully engaged the stakeholders throughout the pilot and into the development of the new architecture, they would have been much more aware of the issues and risks, more committed to the approach recommended by the project manager and much less likely to be swayed by a bullying director.

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project inception through completion. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. It is a great place to start your project and supplies a terrific framework for building an effective guiding coalition that will be there when conflicts and crises arise.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Drew Davison

Don’t forget to leave your comments below.