Recognizing and Responding to the Needs of Project Stakeholders and Clients

Page content

This Isn’t What I Need

When trying to wade through the water to find out the true project stakeholder needs, you better bring along your hurricane gear. How often have you heard or been part of a conversation like the one below after finishing a project?

Project Manager: What do you think of the software?

Stakeholder: Well, it’s nice, but…..

Project Manager: But?

Stakeholder: I’m sure a lot of work went into it, but it’s not really what I need.

Project Manager: It has everything in it that you asked for.

Stakeholder: Yes, I know, but it’s still not quite what I need. I think we may need to start over.

Obstacles to Figuring Out the Real Needs

No matter how conscientious you are about communication and planning, there are always going to be gaps between the stakeholders’ vision of the final product of a project and your interpretation of that same vision. These misunderstandings are due to a variety of reasons – here are just a few.

In an effort to be all-inclusive, sometimes stakeholders will ask for everything, including the kitchen sink. When trying to determine what is really needed for the final product, the assignment of priorities can get confusing and result in flawed requirements.
At the opposite end of the spectrum, there are stakeholders who don’t ask for enough. This may be because they lack confidence in your ability to deliver, so they try to limit their own expectations and ask for something less than what they need. Even if they have full confidence in your abilities, they may just have trouble translating their ideas into words.
Although not as common, there are stakeholders who assume that you should already know what they want. After all, how could anyone want anything different?
It’s more common that certain stakeholders will assume that one aspect of a project is a natural extension of another that has already been requested. As a result, they feel it is unnecessary and repetitive to mention this second requirement.
For large projects with multiple stakeholders, all from different fields, the “that’s not my problem” syndrome may kick in. In this scenario, one group may assume that it is the responsibility of another to request a certain requirement, and vice versa. As a result, no one is willing to claim ownership of a particular project need.

What Can a Project Manager Do?

As we alluded to before, it’s a rare case when the final project deliverable meets 100% of all stakeholder expectations. However, there are a few things that you can do to make sure that you are addressing as many of the project stakeholders’ needs as possible.

Make sure that all stakeholders are involved in project scope decisions. In fact, make them write the scope document. When people have to actually write down what they need or want from a project, they will often start to think about it a little harder and give a clearer idea of their requirements.
Instead of just asking what is needed, also ask why. Ask about what is wrong with existing products or methods that make a new one necessary. By doing this, you may be able to catch some of the things that are missing, especially if you have a background in that field or industry.
In the case of software or IT projects, go to the people who will actually be using the finished product. In many organizations, the person or group requesting the software project could be removed, by several levels, from those that will actually use it. In this case, the requester may be trying to communicate needs that even he or she doesn’t fully understand or has misinterpreted. By going to the source of the original request, you can often get a lot more detailed information.
Create a solid communication plan and stay in touch with all stakeholders during the project’s life cycle. Don’t be afraid to modify the project’s scope or requirements if new information comes out in these meetings. However, if you do consider making a change, make sure to differentiate between scope discovery and scope creep first.