By Laura Bamberg – Global Sales Administrator
After recent conversations with a friend about waffling company policies on projects, my head was whirling. I wondered how you manage a project without the stakeholders’ approval or buy-in.
As a short side note, the project sponsor can sometimes be the customer, but ostensibly, it’s the person paying for the project. The stakeholders include anyone affected by your project. The project team, the sponsor(s), the end-user – these people are all a part of the project.
In my friend’s company, the sales representatives sometimes create quotes based in large part on what the customers want, and not always on what their products can do. The next step in the process is a layer of approval from several colleagues, and in many cases, the sales representative in question has to go back to the customer and renegotiate. You can imagine how the customer feels.
What’s worse, at times, the deal is so tightly made already that the company is compelled to almost entirely re-do their own products or services to customize the needs of one client. All you project managers out there are cringing, aren't you?
Either way, a lot of people in this company are frustrated most of the time. Rarely can the project manager actually close a project on time, because there are too many changes and delays along the way. The project team is constantly being shifted about, forced to sacrifice the product’s quality at times.
Hopefully, this doesn't hit close to home for you. This blog could accommodate a lot of project management verbiage, but for today I’d like to focus on stakeholders. What are their expectations, and how in the world could a company that operates at this level of mayhem meet them?
Many projects begin with the stakeholders’ expectations making you feel frustrated and overwhelmed. How can you ensure they’re all completed? The short answer is – many times you can’t. At some point, a line has to be drawn, and on it are written the words – this is as far as we’re willing to go. We don’t have the resources to do everything you want. But we’re glad to have your suggestions – we can definitely keep this in mind for future projects. I bet that graphics idea (which would take about a year to implement) could be used in part on our next version.
Be up-front with your stakeholders. Let them know that before the project plan is implemented, you need to know what they want, but you also need them to know that you can't promise them everything.
Not only do you need to collect your stakeholder requirements – you need to be able to turn them into project management metrics. Here at Steelray, we’re very focused on metrics for our own business needs. They can be pretty useful if they’re truly measurable.
As an example, suppose your project involves developing a new industrial pressure treatment for wood. Stakeholder requirements could sound something like this: Does it look good? Is it easy to use? Over the course of the project, many more could be added.
You definitely don’t want customers to think your pressure treatment damages the wood it’s used on, or changes a beautiful color into an ugly one. But how measurable are these requirements?
What if the stakeholder requirements encompassed some of the following:
- Does it change the color of the wood?
- How long does it last?
- Are there environmental regulations that would be broken during disposal?
Not only does this encapsulate what the stakeholders asked for – it also provides them with metrics they can use during the course of the project, and especially at the end. I think it’s a given that you’re actually expected to follow through with them. Be sure to add this to Lessons Learned post-project if it's the first time metrics have been used!