From the Sponsor’s Desk – Managing Project Interlopers

In my last post, Projects Done Well, a Recap – Part 2, we concluded the review of lessons learned from the 22 case studies covered in this blog over the last two years. We discovered nine top contributors to project outcomes, all effecting more than half the cases studied. We also found that other studies and commentators agreed with our conclusions. If you haven’t reviewed those findings, please do so and apply the lessons learned to all your projects from now on. You’ll be glad you did. Your stakeholders will thank you.

Before getting back to our case study reviews, I’d like to address a situation that has often been a contributing factor to project difficulties and project management migraines – Project Interlopers. I’ll describe how they can negatively influence project outcomes and suggest how you can counter their impact to improve the performance of your own projects.

Effective stakeholder management is a key project success factor. Keeping the stakeholder group pure and focused is an absolutely essential part of that task. To use a culinary analogy, at least in Project Pre-Check, the process is the recipe, the decision areas are the ingredients and the stakeholders are the chefs! And we all know that too many chefs spoil the soup.

Project Interlopers (I’ll call them PI’s from now on) are influential and usually opinionated executives, managers and senior staff members who have no formal project decision making role yet insist on imposing their opinions and beliefs on project stakeholders and staff. Their unnecessary and unwanted involvement can create dissent among the real project stakeholders, launch wild goose chases, blow schedules, increase costs, negatively affect quality, diminish the value delivered and, in some unfortunate cases, directly contribute to project failure.

Let’s look at an example. In a previous post, You Can’t Always Get What You Want, we looked at how a tyrannical director’s excessive and unreasonable demands on a project team resulted in project failure and his own demise. What I didn’t mention in the post was the fact that the project director was a PI. His day job was the director of IT. He unilaterally took on the sponsor and the project director mantle. The actual sponsor, the plant manager, backed off and allowed the IT director to play his game. The actual PM ran the project until the boss’s interference drove her to depart. You know the rest of the story. The project failed.

Another example: a colleague of mine recently joined a project as a contract project manager. It involved the launch of a new financial product with a boat load of web development. She jumped into the project with both feet in response to some critical target dates. And then she ran into a number of conflicts. The VP of System Development, her boss and, unfortunately, a PI, explained that he was the project sponsor and proceeded to dictate direction, which was at odds with business expectations. The resource manager with whom she dealt to obtain project staff,  another PI, issued orders regarding the functionality, look and feel of the application, again at odds with the business direction.

The project manager took a deep breath and stepped back. She asked the individuals involved who they thought the stakeholders were and what roles they were playing. She found considerable disagreement and pursued the issues until there was unanimity. As a result of her questioning, a number of changes were made to the makeup of the stakeholder group. The business VP responsible for the product launch became the sponsor. The System Development VP had no formal stakeholder role, nor did the resource manager. Two organizations affected by the project were not initially represented in the stakeholder group. Senior managers were appointed to fulfill their target roles. According to the project manager, once the stakeholder group was reformed, the PI’s were removed and the real stakeholders engaged, the difference in clarity on goals and directions, in the speed of decision making and the level of stakeholder commitment was palpable. The project was a terrific success.

In the post The Offshoring Challenge, Part 2, the designated sponsor wasn’t really the sponsor after all. He didn’t initiate the change. He didn’t have the economic, logistical or political power to make the change happen. In fact, he had no organizational role other than the project role. He could have acted as the project executive but instead tried to be the sponsor. He was a PI of the imposter kind, playing a role he shouldn’t have been playing and not doing the job he could have done. Chaos reigned. As well, the designated PM turned out to be a consultant to the business and spent most of her time developing business specifications. Another PI imposter!

Ultimately, the sponsor imposter was removed from the project and sponsorship accountability was placed in the hands of the CEO, where it should have been all along. A senior executive with in depth knowledge of the business and recent experience in a similar project was brought in to provide overall guidance as project director. The project was finally delivered successfully, a year later and over 50% more than originally budgeted. Much of that overrun can be traced back to the PI’s and the absence of the right stakeholders.

Another colleague of mine joined a project as a contract project manager and ran into an aggressive and dictatorial PMO manager. She was a PI of the first order. She had no formal stakeholder role. She wasn’t the sponsor. She wasn’t a target. She certainly wasn’t the PM. She wasn’t a champion. Yet she ran all the stakeholder meetings and she dominated all the project team meetings. She harassed and bullied the contract PM from his first day on the job, in private and in public.

The PM tried to get the situation rectified by approaching the PMO manager directly. After that failed, he asked the sponsor, a business VP, for help. The business VP was a nice guy but not terribly decisive and he urged the PM not to worry about the PMO manager and just carry on. The PM approached the CIO and received the same advice. It seemed no one wanted to take on the PMO manager. The other stakeholders and his team members all sympathized with him, patted him on the back and told him he was doing a great job. And urged him to just carry on.

So he just carried on. The project turned out to be very successful and all the stakeholders were thrilled with the results. But the PM’s life was miserable. He claimed those nine months were the worst of his entire professional career.

So what can you do to deal with PI’s on your projects? First, you need to know who the real project decision makers are and what roles they’re playing – sponsor, target, change agent and champion. That it! The easiest way to find out is to ask the other participants. You want to see consistency in the responses. Who was responsible for launching the project? Who does the organization look to to deliver the change successfully? Which departments and which staff will be affected by the change? Which managers will have the final say on how a change will be implemented in each affected organization? Are those groups and individuals represented in the stakeholder group?

What about all those other folks who are usually involved in overseeing, supporting, contributing and commenting on a project’s makeup and performance? If they are not filling one of the four stakeholder roles and making explicit decisions on the conduct of the project, they’re not stakeholders, nor are they members of the stakeholder group. If they can’t logically fill one of the four stakeholder roles, they have no place at the stakeholder table.

The stakeholder group will be self-sufficient as long as all players have the authority and capability to make decisions on behalf of the organizations they represent, all the necessary organizations are represented and the consensus process works. Where conflicts arise that cannot be resolved within the group, the issues should be quickly escalated up the organization until a decision can be reached. Escalation should never be construed as a sign of failure. Rather, it should always be positioned as an available and appropriate measure for resolving a deadlock.

How does the stakeholder group relate to traditional project steering committees? If the rationale for and participation in the two groups is similar, perhaps only one group is required. However, in many cases, a steering committee is formed to provide an oversight function rather than a decision-making role. In those cases, a steering committee may still be appropriate. It can also be an effective forum for real or want-to-be PI’s to get information and air their thoughts and suggestions.

Stakeholders in any role can be tough to identify and even more difficult to replace. The time and effort that’s usually required to manage the replacement of a PI can distract everyone from the job that matters, delivering a project successfully. It’s best to assess stakeholder roles and capabilities right up front and address any apparent gaps. And to keep the stakeholders engaged, monitor stakeholders’ level of agreement on the decision areas critical to project success on an ongoing basis.

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 present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.