Project Management Screw-Up 7 – We Didn’t Involve The Right People

Some years back I worked on a process re-engineering project at a large industrial manufacturer. The project went on for several months and it looked as if things were going quite well. Then, a person that I’ll call “Hack” showed up on the project who reported to one of the divisional VP’s. Hack came into the project with a negative view of the project and, after spending a couple of weeks on the project, was successful in convincing the divisional VP that the project should be shut down.

The project team packed up and was out of there that day. In looking at the situation, had we involved Hack earlier in the project we could have made some fundamental changes in the direction which would have put the project on a path more in line with management expectations and avoided wasting time & money on the project.

Chances are, there has been a Hack on one of your projects who showed up, disrupted everything and either slowed down or derailed your project completely. It could be that it was the wrong business decision to shut the project down, but it could also be that it was the right thing to do because the project wasn’t addressing the collective need of the customer. Regardless of right or wrong, it is very important to know who to involve in your project to better ensure success and avoid the waste and frustration of a stalled project.

So, let’s talk about the people, or stakeholders, who aren’t assigned to the project but can materially influence its outcome. In my experience, stakeholders generally fall into two groups: customer stakeholders, or those you help, and supplier stakeholders, or those who help you. Your customer stakeholders primarily are going to be your customer population and their associated management. At the end of the day, they are going to be the ultimate judge of your end product and will be your ultimate measure of success. Your supplier stakeholders can be quite varied. Technical support personnel, consultants, and third-party software providers are all examples of supplier stakeholders. As you design your project, you’ll need to think about the types of help that you will need and enlist support from your supplier stakeholders to help ensure success.

How it happens:

There is not clear definition on who the customer is – Getting your customer list right and making them aware of the project early on is super important in avoiding project stalls and fire drills because someone is bent out of shape because they weren’t included. Something that I’ve learned (again the hard way) is that you very well could be doing everything right on your project and that the project is being done for all the right reasons. However, if someone was not included (but should have been) in the project at the beginning and “finds out” that the project is going on, you have a situation on your hands. You not only need to orient them to the project and get their commitment, but also smooth ruffled feathers because you didn’t include them in the first place. Many times things work out OK, but you’ve taken time away from other activities to deal with a fire drill that could have been avoided had you better defined the customer list at project onset..

Others who could help with specific issues on the project weren’t utilized – On one project that I was the business owner, an employee relatively new to the company was working on a critical project to aggregate worldwide financial planning information and report it to senior finance management. He did an outstanding job of defining the information requirements, setting up the reporting infrastructure, and managing the team members assigned to him to complete the project. He came up against a project issue and was working hours on end trying to get the issue resolved among the project team. When he raised the issue to me, I asked him if he had contacted the group in the company that had expertise on the very issue he was trying to solve on his own. End of the story is that he solicited help from the group and they resolved the issue that afternoon. Knowing who can help you get through tough project issues can save you tons of time and frustration and avoid wasting precious project resources.

The people who can torpedo a project weren’t identified and managed – Just as in my “Hack” example above, it will help you immensely to know who is likely to create trouble for your project. When I was a consultant doing a project in a particularly political or contentious environment, we would review the customer’s organization chart with the customer project manager and identify friends and foes of the project. With project friends, we maintained the relationship with them by keeping them briefed on project progress to ensure that they remained friends. With the foes, we would take deliberate steps to meet with the foe, review the project with them, understand their reservations, and attempt to let them put their thumbprint on the project to make it more palatable to them. Sometimes this was successful where a foe became a friend of the project, but other times the foe remained a foe and we had to rely on the project sponsor to help us manage the foe. Either way, know who can hurt you and actively manage the relationship with them.

Warning Signs:

You’re getting a lot of questions from other stakeholder groups on what you’re doing – Sometimes this could simply be that stakeholder groups are curious about your project and find it interesting. This could also mean, though, that there are stakeholders that should have a voice in your project and are currently not being heard. Be aware of assessing the degree of involvement that other stakeholder group needs to have on your project and be open to involving them based on business need.

Uninvited stakeholders start showing up at project meetings – So you’re in a project status meeting and a stakeholder that has previously not been associated with the project shows up. It very well could be that the stakeholder has a need to know what’s going on and they just need to get up to speed on the project. It may be the right thing to involve the stakeholder, but avoid allowing the stakeholder to hijack your meeting and wasting time of other participants by getting a project briefing during a time where other project business was slated to be discussed.

Project issues are taking longer than expected to resolve — If team members appear to be spinning their wheels on a project issue, it could be that they are not involving the right subject matter experts and are attempting to wrestle the issue to the ground on their own. Take the time to work with them to make sure that resources available to them are being utilized appropriately.

Leave a Reply

Your email address will not be published. Required fields are marked *