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.

Turning it around:
Communicate, communicate, communicate - I've always found that, unless there is specific confidentiality constraints that forbid you from discussing the project outside of a small group, communication on what you're doing to different stakeholder groups is crucial. Have a standard pitch that you can give at a moments notice to a group of people which describes the project.

Know who to call - As I mentioned above, don't slog through issues on your own if you don't have to. Whenever I run up against a difficult issue on a project, my first thought is "Who can help me resolve this?" Be continually seeking out subject matter experts to help get you through problems. It not only makes your life easier, it better ensures a more successful project completion.

Right-size project involvement - Just because someone wants to be involved in a project (or shows up as an uninvited stakeholder) doesn't necessarily mean that there is a business need for them to be involved. You've got to make conscious decisions on who is involved in a project and to what degree they are involved. Their involvement could be as an interested party that gets a briefing on some periodic basis. Then again, their involvement could be as a decision maker because the product you are producing will have a direct impact on their business.

Let your project sponsor help you - When defining your stakeholders, use your project sponsor to help you with the identification. They will likely know the organization better than you and can help ensure that the right people get involved in the project. You may also need your project sponsor to help you with a foe that is creating problems for you.

Be open to adjusting the focus and scope of the project - If it turns out that you didn't include the right stakeholders at project onset, be open to refining your focus and scope to ensure your project is addressing your true stakeholder needs. Use your project sponsor to help you in this refinement and in working with the other stakeholders to decide on how business needs either are or aren't met.

Take Aways:


Know who your customer is and involve them up front

Know who can help you get things done; don't try to do everything yourself

Know who can torpedo your project and manage the relationship with them


Lonnie Pacelli is an accomplished author and autism advocate with over 30 years experience in leadership and project management at Accenture, Microsoft, and Consetta Group. See books, articles, keynotes, and self-study seminars at http://www.lonniepacelli.com


 By Lonnie Pacelli


Article Source: Project Management Screw-Up 7 - We Didn't Involve The Right People