The term ‘stakeholder’ was originally coined in 1963 by the Stanford Research Institute, who defined stakeholders as ‘those groups without whose support the organization would cease to exist’. Today, the term is more commonly used to include anyone who has an interest.
In the context of problem solving, there are two groups of stakeholders;
- Primary Stakeholders – people who are affected by the problem but are also able to participate in finding and implementing a solution.
- Secondary Stakeholders – people who are affected by the problem.
You will also find a more detailed discussion on the management of stakeholders in the Relationships article.
In order to gain as complete an understanding of the problem as possible, you will have to talk to a representative cross section of primary stakeholders to discover:
- What do they think about the problem?
- What do they think the real cause of the problem is?
- Is anything making the problem worse?
- What happens if it is not solved?
- How does it affect them, their colleagues, customers and department?
- How is the problem being managed?
- How would they solve it?
In addition to gathering vital information, you are also communicating something important to the primary stakeholders; “I recognise that this problem affects you and I want to hear your opinions”.
Engaging with the secondary stakeholders must be done with care, because a consequence of involving them in your project at this early stage is that they will expect something to happen as a result, and if you directly solicit their opinions, they will expect you to incorporate them. After all, it is human nature that if someone asks you for your advice, it’s because they want it.
All too often, I hear secondary stakeholders complaining that they offered their opinions, and ‘management’ haven’t paid attention to them.
It is vital that you make your intentions clear when consulting with secondary stakeholders, being careful to reassure, engage and involve them without leading them to believe that their views will determine the outcome.
There is no doubt that you will need the secondary stakeholders’ buy-in at some point in the future, because they will be affected by the implementation of any solution and you need to make sure that you have their participation at the right time.
Clearly, this is a delicate balance, and I would advise you to engage closely with the managers,leaders or representatives of secondary stakeholder groups so that they can manage their expectations.
Drawing battle lines at the first meeting
Before your initial stakeholder meeting, you need to determine who the problem affects and invite the most appropriate and perhaps senior representatives of the affected business areas as stakeholders for the project.
Projects that have a positive business impact can tend to attract ‘hangers-on’ who are happy to attend meetings but contribute no material benefit, the pay-off for them being a legitimate reason to skip their regular duties.
Remember too that business problems don’t affect every area of the business equally. One department might have a great incentive to solve a problem because it hinders their ability to deliver against their targets. Another department may be equally affected, but the problem actually conceals another, internal problem such as weak management. Therefore, even though the department is affected by the problem, its manager is inexplicably reluctant to cooperate. In this instance, the manager’s attitude reveals a much bigger problem which is not yours to solve. All that you can legitimately and authentically do is report back to the project sponsor or your manager and decline the project management role until this potentially political issue can be more effectively dealt with.
Preventing Run-Away Meetings
In your initial stakeholder meeting, you need to allocate time according to the following guide. If your experience is that initial stakeholder meetings turn into a ‘free for all’ then just follow these five simple rules:
- Have a clear agenda.
- Publish the agenda well in advance.
- Allow enough time to add ‘Any Other Business’ items.
- Drive the meeting by asking all the questions.
- Handle attempts to hijack the meeting by adding them to the agenda for the next meeting.
Understand the Stakeholders Perception of the Problem
The first third of the meeting should focus only on the technical or business problem.
State clearly and simply what your understanding of the problem is. In order to clarify the stakeholders’ understanding of the problem, make a clear distinction between the problem and the effects of the problem. One way to do this is to understand that the effects of the problem will change over time and with different stakeholders, whereas the problem itself will not. For example, if the coffee machine is out of order, it will affect different people at different times and for different reasons, while the underlying problem will not change.
This is a time of active listening. Put differences aside for a while and listen to each other with the intention to understand. Active listening involves both impartially hearing all comments and opinions whilst also working to test your own understanding.
A very simple way to prevent the meeting from breaking down into an argument is to recognise that every contributor is right, from their point of view, and they are not talking about the problem or the business as an objective reality but instead as an aspect of their own personal experience.
For example, “The sales order processing system never works” is highly likely to lead to defensive behaviour, including blaming, avoiding, distracting and attacking. When the meeting’s participants get drawn into the defence, you might as well end the meeting because you’ll make no further progress.
It is more accurate to say, “I feel that the sales order processing system never works for me”. Other people can argue that their experience is different, but they cannot dispute the statement itself, and what then arises is a comparison of different stakeholders’ subjective experiences rather than an argument over who is right about the objective reality.
Human nature is to project our subjective experience onto everything and everyone around us, so when someone inevitably says, “The sales order processing system never works”, you need to step in immediately, before anyone else has a chance to attack the statement, and rephrase it with a question, such as, “Are you saying that you feel it never works for you, or do you feel there is a problem that affects other people too?”
By getting the person who raises the objection to be more specific, they have to speak more personally. The owners or creators of the system in question will feel that they have done their best in delivering against user requirements, and they will also perhaps feel frustrated that complaints are being aired for the first time at what they consider to be a very late stage in the service delivery process.
At a later stage in the project, the project team will need to determine these other facets of the problem:
- How the problem is managed (often a large contributor to the problem) and,
- The actual root cause of the problem.
The next two thirds of the meeting should focus on managing the stakeholders by clarifying expectations, gaining commitments and access to resources and understanding any hidden agendas.
The first thing to do in this stage of the meeting is to determine if the stakeholders present are the right people to be involved. It may seem that this should have been done at the start of the meeting, but remember that people who are best placed to define the problem may or may not be the people most affected by it. That’s one reason why we separate the two stages of the meeting.
If the stakeholders present aren’t the right people then you can allow the inappropriate ones to step down at this point. The danger is that if you now need to invite other stakeholders, you also need to go through the definition stage again. Because of the subjective way that people will describe the problem it is very important that all stakeholders are able to share their experience, otherwise they can feel detached from the problem solving process, as if they have been landed with someone else’s problem. Being able to share their own experience and understand the experiences of the other stakeholders is a vital stage in gaining commitment, so don’t be tempted to skip that stage, just because you’re happy that the problem has been defined to your satisfaction.
Determine the stakeholders expectations of the project. Prioritise these into must-have and nice-to-have, e.g. improved margins, reduced costs, increased uptimes, improved staff morale, more responsive reporting system, financial evaluations etc.
The more direct the business benefit, the higher its priority, but the more benefits the project has, the more buy in you can expect from stakeholders.
To what degree should the problem be solved? Is it acceptable to stop, prevent, eliminate, reduce, mop, treat or redirect the problem? (See Step 3: Deciding to Act for an explanation of each of these alternatives)
Determine the stakeholders’ expectations of, and constraints upon, the project manager and the project team. Prioritise these into must-have and nice-to-have. An expectation could be to complete a 14 month project in 9 months, or to deliver an outcome that results in performance bonuses being paid. A constraint could be the project’s budget in money, time and resources. The project manager could even be constrained by expectation not to interview any line staff or suppliers in order to contain information about the problem.
Be very clear what you as the project manager can offer. You can typically provide a clear view of the project and steps necessary to resolve it. However without the stakeholders’ direct involvement, it is highly unlikely that you can resolve the problem as it is not under your control.
Unless you truly understand the problem and have solved many similar cases before, be cautious and tread carefully when committing to what you will deliver. The best situation of all is to deliver exactly what you commit to.
If you are unsure of a deliverable, be sure to state this clearly with reasons for your uncertainty. Also beware of the ‘Paradox of Please’; in trying to please your stakeholders, your boss and yourself, you may end up pleasing no-one.
If you under-deliver, you fail to meet stakeholder expectations, which is clearly not a good situation to be in. However, if you under promise and over deliver then you can easily gain a reputation as someone who goes the extra mile and delivers more than was expected. The problem with this is that next time, more is expected of you… and more… and more.
Project confidentiality is often an important consideration, especially when problems affect business performance or product sales. The project manager must clearly define communication boundaries for the problem and ensure that they are always respected.
As simply as possible, advise the stakeholders what resources you need to successfully resolve this problem, including their and their teams’ contributions. Prioritise these into must-have and nice-to-have.
Here are some suggestions for the resources that you’ll need:
- Access to key staff and information.
- Time with key staff.
- Access to external resources such as contract staff, suppliers or materials.
- Support in trying innovative approaches.
- Involvement in the decision making process.
- Sufficient time to do a good job.
- Senior management’s personal involvement.
- Stakeholder support when encountering resistance.
If the meeting is not going well, or there is opposition to the project, articulate your feelings to the stakeholders and explore their reservations.
Opposition usually arises because of:
- Lack of respect or trust for the project manager and project team.
- Previous bad experience with the project manager and their team or a similar project initiative that turned out badly.
- Loss of control and increased vulnerability.
- Perceived unimportance or irrelevance of the problem.
It’s worth remembering that if someone perceives the problem as unimportant then they’re probably not the right stakeholder for the project. For example, if the sales order processing system delays orders and prevents sales people from receiving commission statements on time, how is that a problem for a manufacturing manager? Aside from the lack of impact of the problem, the manager might also resent the sales team, and may even stand to gain from the delayed processing of orders. Therefore, the manufacturing manager is not the right person to have in the group of stakeholders for this problem.
Uncover Hidden Agendas
Probe stakeholders to determine if they have any of the following underlying issues that would manifest if the project went ahead:
- Perceived ‘loss of control’
- Probabilities of project success
- Stakeholders’ motivation to proceed
The above issues can be brought to the table by addressing them directly or taking a more subtle approach like “How do you feel the meeting is going so far?”, or, “How do you feel about what we have agreed?”
Another method to flush out issues is to probe for information and request commitment from the stakeholders and/or their team. If you don’t get straight answers, you may have a problem.. An objection about workload has no real substance to back it up, so when you challenge an objection about added pressure, you get an overly emotional reply of, “I can’t possibly do that, I’m far too busy doing other things, which are a far better use of my time, and if I wasn’t so busy I might be able to get some of my own jobs done instead of having to waste my time sorting other peoples’ mess out!”
This response is confusingly over-emotional, defensive and seeks to confuse or misdirect the project manager.
Avoid Getting Eaten Alive
Where these issues are present, you need to address them upfront, since they are powerful motivators to derail a project. Putting them aside by saying ‘we will deal with these as they arise’ will cause them to come back and haunt you.
It’s not a good idea to deal with these issues head-on, because a confrontational approach, whilst honest, will rarely be met with a similar level of honesty from the person raising the issue. On the other hand, you can’t take these people aside and have private conversations to mitigate their concerns because this is a hallmark of a political, manipulative approach that will harm your credibility and give the people concerned an excellent opportunity to manipulate the project to their own ends.
Ways to overcome these issues include:
- Introducing points throughout the project where the stakeholders can decide to proceed or otherwise.
- Break the project up into a series of mini projects and proceed one step at a time until the stakeholders are comfortable with your methodology and approach.
- Ask the stakeholders how to restructure the project so that their issues can be reduced or overcome.
The danger in putting the ball back in the stakeholders’ court is that their resistance is likely born out of personal motivations which they will never openly admit to, so giving them back control will almost certainly give them the means to derail it before you have made any progress. Of course, you’ll get the blame, because you didn’t maintain control of the project. Manipulative people will easily portray your approach as ‘passing the buck’.
Go – No Go Decision Point
Based on stakeholder feedback, you may discover that the low hanging fruit that your boss asked you to pick, is neither low nor hanging. In many cases, it’s even poisonous. If your feeling is that you have a less than 50% chance of success, delay going ahead until you have such time to discuss the matter with your manager or the person who allocated you the project in the first instance. If stakeholders are not aligned to your thinking, and they outrank you in seniority, then the probability of project success is low. However, this can also be a sign that it’s your thinking that is out of alignment with the direction of the business, and you can take this as an opportunity to step back and critically analyse what you are trying to achieve.
Ultimately, if the project is a failure waiting to happen and your manager won’t allow you to officially cancel it, just treat it in the same way that the stakeholders are – as a low priority. Some companies have change projects running for years in this way. No-one wants to move them forward, but no-one wants to kill them either.
Your Time of Maximum Leverage Is Now
Remember that your maximum leverage with your stakeholders is going to occur in the initial meeting, as it is much easier to negotiate a new contract than to renegotiate an existing one. The expectations that you set at the start of the project will stay with you. In addition, the way you behave in this meeting will set the tone for the rest of the project, so if you behave in a weak and indecisive way, you will be treated as weak and indecisive.
Cover Your Butt
After you initial stakeholder meeting, on the assumption that you as project manager believe the project has potential, confirm the project outline to the stakeholders, your manager and the project sponsors. This is not intended to be an enforceable contract but more of a working agreement, a clear communication of what is going to happen.
Include in your communication a request for stakeholders to contact you immediately if you have misinterpreted their requirements. Avoid circulating this document to people who are not directly interested or involved in the project. Remember the greater the number of participants, the greater the interference potential and the lower the chance of achieving alignment.
In your document, ensure you detail the following as simply and directly as possible:
- The problem, or your best current understanding of the problem.
- Project objectives, including the benefits your stakeholders are hoping to achieve from the project. Where ever possible, focus on quantifiable benefits instead of the more intangible ones. Unquantifiable benefits leads to ambiguity which leads to stakeholder dissatisfaction. If you can’t quantify a benefit then you can’t measure your progress towards achieving it.
- Specific project deliverables; what you and your team will deliver, such as a report, a negotiated contract, or a specific list of recommendations,
- Project boundaries. Some projects are like chasing a rabbit down a burrow. The deeper you get, the more burrows you find. Ring fence the project or you may find yourself hunting forever.
- Project confidentiality. What information can be shared with who? Who should the final project report be distributed to?
- Resources required for the project including any commitments from stakeholders, support from senior managers or involvement from other parties. Include details on staff to be contacted, type of information to be made available etc.
- Details of the project management team, including roles and contact details.
- Project schedule or Gantt chart showing starting date, milestones and proposed end date. Include key meetings and other shared events such as deadlines for the supply of information. If you do draw up a Gantt chart, it’s also useful to translate it into a simple list of milestones for non-technical readers.
- Cost Benefit Analysis. As clearly and as simply as possible, articulate the project’s envisaged benefits and estimated costs. Depending on your company policy, you may be required to conduct a Return On Investment (ROI) analysis and compare this to project benchmarks or capital costs. Other types of analysis may also be required. Talk to your corporate financial team, determine their requirements and preferably obtain a project evaluation template. Remember to state your assumptions clearly and include copies of your calculations.
If you decide not to go ahead, after discussing this with your boss, personally contact stakeholders and let them know your reasons. Be polite, be authentic and once again, circulate only to those with a direct interest or involvement in the project.
Repeat Steps 2 to 4 if required
Having come to the end of Step 4, it may now be apparent that the definition of the problem (Step 2), degree to which the problem needs to be solved (Step 3) or everybody’s interests (this step) may be out of alignment or in conflict to one another. In this case, you need to repeat the Step 2 to Step 4 cycle until such time that all the components are bought into line.