Lesson 2.2: Mapping stakeholders and who decides
Projects stall on people, not code. Learn to map sponsors, users, gatekeepers and blockers, and who decides what, in your first week with a customer.
By the end of this lesson you will be able to draw a stakeholder map for a customer project, name the six roles that most often decide whether a pilot succeeds, and write a decision map that says who approves what. You will learn a simple power-and-interest grid, a way to add attitude to it, and what to do about a blocker. You will see the method on three realistic projects and use a simulator to put a price on late approvals. This lesson follows Lesson 2.1, where you learned to find the real problem. Here you learn to find the real people, because a correct problem with the wrong people around it still fails. You need no technical background.
A surprising share of delays in customer projects have nothing to do with software. The code works, and the project waits: for a data extract that one team must approve, for a security review that sits in a queue, for a budget line that a finance manager must release, or for a user group that does not want the new tool. If you meet these people in the first week, you can plan around them. If you meet them in week eight, they become emergencies. Mapping stakeholders is the habit of meeting them early.
What a stakeholder is
A stakeholder is anyone who can affect your project or is affected by it. That includes the person who signed the contract, but also the person whose workday will change, the person who controls the data you need and the person who will be blamed if something goes wrong. A good map includes people who have never heard of your project yet, because they will hear of it eventually.
It helps to separate three words that are often mixed up.
Influence is the ability to change what happens through argument, reputation or relationships.
Authority is the formal right to decide, by position or by role.
Interest is how much the project matters to the person: how much they gain or lose.
A senior director may have authority and little interest. A junior analyst may have no authority, a lot of interest and, because everyone asks them which numbers to trust, considerable influence. A map that records only job titles misses the second kind of person, and projects often depend on them.
Six roles that decide most pilots
Every customer organisation is different, but the same six roles keep appearing. Look for each one in the first week and write a name next to it. A blank is a warning sign.
1. The sponsor. The person who wants the result and controls the budget or the priority. They can say yes to the project and, if it goes wrong, they carry the risk. Without an active sponsor, a pilot fades when something more urgent arrives.
2. The champion. Someone close to the work who believes in the project and will help you in daily ways: explaining how things are really done, introducing you to people, defending you in meetings. A champion is often below the sponsor in rank. You want both.
3. The users. The people whose work changes. They decide, by what they do every day, whether the solution is adopted. They rarely have formal power, and their opinion decides whether the project succeeds.
4. The gatekeepers. People who control something you need: data, systems, access, security approval, legal or compliance sign-off, procurement. They are often not part of the project team and may see you as extra work.
5. The economic buyer or approver. The person who releases the money, which is not always the sponsor. In large organisations a finance or procurement function applies its own rules.
6. The sceptic or blocker. Someone who doubts the project, fears it or loses something from it. They may be a user who fears for their job, a team that feels bypassed or an executive who backed a competing approach.
Notice that only one of the six is the person who asked for the project. If you meet only the sponsor, you have met one-sixth of the people who will decide your fate.
The power and interest grid
A simple tool for organising stakeholders is a grid with two axes: how much power a person has over the project, and how much interest they have in it. It is usually credited to Aubrey Mendelow, in a 1991 conference paper on stakeholder mapping, and it is widely used in project management. It gives four boxes.
· Low interest · High interestHigh power · Keep satisfied: they can stop you, so do not surprise them · Manage closely: involve them in decisions
Low power · Monitor: check in occasionally · Keep informed: share progress, learn from them
Place each person from your list in one of the boxes, and then decide how often and how you will talk to them. The sponsor and the head of security are probably in "manage closely" or "keep satisfied". The users are usually in "keep informed", but their influence on adoption means they deserve more than a newsletter.
The grid has a known weakness, which careful users note. It does not record attitude: whether the person supports you, opposes you or is neutral. Two people in the same box can need very different handling. Add a third mark to each name, a plus, a zero or a minus, and write one line on why. A high-power, high-interest person with a minus is the first person to visit.
A second weakness is that formal power is easy to see and informal power is not. The assistant who controls the calendar, the analyst whom everyone trusts and the long-serving engineer who knows where the data is buried can each decide your timeline. Ask people, "who else should I talk to?" at the end of every conversation. The names that come up repeatedly are the ones your first map missed.
Predict first: you are starting a pilot for a lender. The head of collections is the sponsor and is enthusiastic. Your project needs a nightly extract of loan data, which sits in a system run by the central IT team, and any use of customer data must be cleared by the compliance officer. Which person would you try to meet first this week, and why? Decide before you read on.
Most experienced engineers would go first to the owner of the data in central IT, with the compliance officer a close second. The sponsor is already on your side and cannot, on their own, give you what the project needs. The IT team controls how fast you can get data, and compliance controls whether you may use it. These people have little interest in your project and a lot of power over it, which is the "keep satisfied" box, and they are most likely to become blockers if they hear about the project late. A short, respectful meeting in week one, asking "what do you need from us to approve this, and how long does it usually take?", can save weeks.
Build the map in three passes
You do not have to produce a perfect map on day one. Build it in three passes.
Pass one: the org chart view. On the first day, ask your sponsor for names: who the users are, who owns the data and systems, who must approve security and legal matters, who holds the budget. Write them in a table with the six roles as rows. Mark blanks.
Pass two: the real-life view. In your first conversations with each person, ask three questions: "Who else will this affect?", "Who needs to agree before this can go live?" and "Is there anyone who might not like this idea?" The third question is awkward, and also the most useful. People answer it more honestly in person, one to one, than in a group.
Pass three: the living view. Update the map every week. People change roles, new approvers appear and attitudes change after demos. Treat the map as a working document, kept privately and not shared in full, because it contains opinions about people.
Keep the map private. It is a tool for you, and writing "blocker" next to a colleague's name in a document that circulates will damage trust. Share the roles and responsibilities, but not your judgements of attitude.
From stakeholders to decisions
A stakeholder map says who matters. A decision map says who decides what. Many projects stall because nobody is sure who can say yes. A decision map turns the question into a table.
List the decisions your pilot will need, and write one name next to each. A typical list:
Decision · Who decides · Who must be consulted · Typical timeApprove the pilot and its budget · Sponsor, with finance · Head of technology · 1 to 2 weeks
Release customer data for the pilot · Data owner, with compliance · Security · 2 to 4 weeks
Approve the design and security · Security team · Head of technology · 2 to 3 weeks
Agree the success metric · Sponsor · Users, finance · 1 week
Approve the go-live · Sponsor and head of operations · Users, compliance · 1 week
Decide whether to continue after the pilot · Sponsor and finance · Whole project group · 1 to 2 weeks
The times in the last column are illustrative. Ask the customer for real ones: "How long does a security review usually take here?" It is one of the most valuable questions in the first week. If the answer is "six weeks" and your pilot is eight weeks long, you have just found a schedule problem before it happened.
For each decision, it helps to have the answers to four short questions. Who decides? What do they need to see to say yes? How long does it take? What happens if they say no? Writing these answers down turns vague fear into a plan, and often shows that the first step is to start an approval that takes weeks, even before you have anything to show.
Some teams use a simple labelling of roles on each decision, such as who is responsible for doing it, who is accountable for the outcome, who is consulted and who is informed. If your customer uses such a scheme, adopt their words. If not, the table above is enough.
The times in the table are long compared with a ten-week pilot. The chart shows the upper end of each range, so you can see which decisions to start first.
Approvals can run side by side or one after another, and the difference decides your start date. Set the slow approvals and the share you can run in parallel and see what changes.
At the defaults the four approvals take eleven weeks in sequence and four if they all run together. With 60 per cent in parallel the wait is about 6.8 weeks.
Worked example 1: the lender and the compliance officer
A lender has approved a pilot for automated reminders to borrowers. The engineer builds the map in the first week and finds the following. The sponsor is the head of collections, a strong supporter. The champion is a team leader who has wanted this for years. The users are twenty-four callers. The data owner is in central IT. The compliance officer must approve any message sent to a borrower. The approver for budget is the finance controller.
The engineer asks the compliance officer how approval works. The answer is that every message template must be reviewed, which takes about two weeks, and no template may be used before approval. The engineer would have built the whole message system and then waited. Instead, they send the first template for review in week one, while building the rest. When the review comes back with changes in week three, the system is nearly ready, and the pilot starts on time.
Compare with the alternative. If the engineer had met compliance in week six, the pilot would have lost two weeks while ready to run. At a team cost of ₹4 lakh a week, that is ₹8 lakh of waiting. A short meeting, not a clever technical decision, saved that money.
Worked example 2: the hospital and the nurse managers
A hospital group wants a single screen that shows free beds across six hospitals. The sponsor is the chief operating officer. The engineer's first map lists the COO, the heads of IT and six hospital administrators. During pass two, a hospital administrator mentions that the nurse managers keep their own bed registers and do not like central dashboards, because they have been used in the past to compare wards unfairly.
This changes the map. The nurse managers are users with little formal power, high interest and a negative attitude, and they decide whether the data is entered correctly. If they do not trust the screen, they will stop updating the registers, and the screen will show wrong numbers. The engineer meets all six nurse managers in week one, explains that the screen shows availability and not performance, and agrees with them what will and will not be displayed. Two of them become champions. The screen works because the people whose data it relies on helped to design it.
The lesson is that a stakeholder with no formal power can still decide the result. When you find a person with high interest and a minus, go to them early, listen to the objection and find out whether you can address it.
Worked example 3: the logistics company and the dispatchers
A logistics company asks for a model that predicts delayed deliveries. The sponsor is the head of data science, who built the existing model. The engineer's map shows the data science team, the head of operations and the dispatch managers. The dispatchers are the users who will act on the predictions. The head of operations holds the authority to change when dispatch decisions are made.
In pass two, the engineer asks the dispatchers when they decide which trucks to send. The answer is 6 a.m., and the model's predictions arrive at 9 a.m. The sponsor did not know, because dispatch is not their area. The only person who can change the dispatch time or the pipeline's schedule is the head of operations, who is not part of the project. The engineer asks the sponsor to introduce them, and the head of operations agrees to a test in which predictions are ready by 5:30 a.m. in two depots.
In this case, the missing person was the decision-maker for the one change that mattered. The map showed a blank next to "who can change the process", and the engineer filled it in during the first week.
What a late approval costs
You can put a number on all this. The simulator below estimates the expected delay from approvals that arrive late, and what happens if you start them early with a short meeting.
Set the length of the pilot, the weekly cost of the team, the number of approvals the pilot needs, the chance that each is delayed, the length of a typical delay and how much early engagement reduces delays. The tool shows the expected delay without and with early meetings, and the cost of each. The numbers are illustrative and the calculation is a simplification, since it adds up expected delays and treats them as independent, but it shows the shape of the problem.
Try three experiments. First, raise the number of approvals from five to eight and see how fast the expected delay grows. Second, increase the effect of early engagement from 40 per cent to 70 and see what a well-run first week is worth. Third, lower the chance of delay to 10 per cent, which describes an organisation that approves things fast, and see how little the first week then matters.
With the defaults, five approvals, each with a 30 per cent chance of a three-week delay, give an expected delay of 4.5 weeks, which costs ₹18 lakh at ₹4 lakh a week. Meeting the approvers in week one cuts the expected delay to 2.7 weeks and saves ₹7.2 lakh. The figure is an estimate. The message is that the cost of waiting grows with every approval, and the cheapest time to deal with an approval is at the beginning.
Handling a blocker
Sooner or later you will meet someone who does not want the project, or who wants it in a different form. Blockers are rarely villains. They usually have a reason, and the reason is usually reasonable from where they stand.
Find the reason. Ask them what worries them. Common answers are workload ("this will add work for my team"), risk ("if it goes wrong, I will be blamed"), loss ("this changes my role") and history ("we tried something similar and it failed").
Treat the worry as information. A security officer who objects to data leaving the customer's cloud account is telling you a design requirement. A nurse manager who fears comparison is telling you what the screen must not show.
Offer a role. People oppose less what they help to shape. Ask the blocker to review the design, to set a condition or to be the first user.
Make the cost of no visible. If the blocker's concern is real but small, a concrete number, such as the weeks and money at stake, helps the sponsor decide whether to go on. Bring it to the sponsor calmly, with facts and without blame.
Escalate once, clearly. If nothing works, tell the sponsor what you need, from whom and by when. Do it in writing and without drama. Do not go around the blocker without telling them.
Keeping the champion and the sponsor
Two people deserve special care. The champion does favours you cannot ask of anyone else, and is easily overused. Thank them in public, give them credit and do not make them defend things you should defend yourself. The sponsor can change. People move jobs and priorities shift. If your sponsor leaves in the middle of the pilot, the project may lose its reason to exist. Keep a second senior person informed, so the project survives a change.
Common mistakes
Meeting only the sponsor. One of six roles is not a map. Find users, gatekeepers, the approver and sceptics.
Trusting the org chart. Real influence follows trust and history. Ask "who else should I talk to?" every time.
Leaving gatekeepers until later. Security, data and compliance have queues. Start their processes in the first week.
Ignoring users because they have no power. They decide adoption, which decides success.
Treating a blocker as an enemy. The objection is usually information. Ask for the reason.
Sharing your map. It contains opinions about people. Keep it private and share only roles.
Drawing the map once. People and attitudes change. Update it weekly.
Key takeaways
Projects stall on people far more often than on code. A map of stakeholders in the first week prevents most surprises.
Six roles decide most pilots: the sponsor, the champion, the users, the gatekeepers, the approver and the sceptic. Write a name next to each, and treat a blank as a warning.
The power and interest grid sorts people into four boxes. Add attitude, and ask "who else?" to find informal power.
A decision map says who decides what, what they need to see and how long it takes. Start the slow approvals first.
Late approvals have a price that grows with every approval, and meeting approvers in week one is the cheapest fix.
A blocker usually has a reason. Find it, treat it as a design input and offer a role.
Check yourself
1. Name the six roles that most often decide whether a pilot succeeds.
The sponsor, the champion, the users, the gatekeepers, the economic buyer or approver and the sceptic or blocker.
2. What does the power and interest grid miss, and how do you cover the gap?
It misses attitude and informal power. Add a plus, zero or minus to each name and ask "who else should I talk to?" in every conversation.
3. In the lender example, why did sending the first message template for review in week one matter?
The review takes about two weeks. Starting it early meant it finished while the system was still being built, so the pilot did not wait.
4. Five approvals, each with a 20 per cent chance of a four-week delay: what is the expected delay, and what does it cost at ₹3 lakh a week?
5 × 0.20 × 4 = 4 weeks, which costs ₹12 lakh.
5. A nurse manager group distrusts a new bed screen. Which box of the grid do they sit in, and what should you do?
Low power, high interest with a negative attitude. Meet them early, learn the objection and involve them in deciding what the screen shows.
Try this
This exercise takes about forty minutes. Use a real project from your own life or work, or a project you imagine for a company you know.
1. Write the project in one line. List the six roles in a table, and put a name next to each. Mark every blank.
2. Place each person on the power and interest grid, and add a plus, zero or minus for attitude with one line of reason.
3. List five decisions the project needs, with who decides, who is consulted and how long it usually takes. If you do not know the times, write down who you would ask.
4. Choose the approval that takes longest. Write down the first step to start it this week.
5. Choose the person with the most power and a minus. Write the three questions you would ask them in a first meeting, beginning with "What would you need to see for this to work for you?"
6. Use the simulator above with your own numbers, and write down what early meetings would save.
A good result is a one-page map with names, a decision table and a first-week meeting list. People who do this honestly often find a blank or two they had not noticed, and filling those blanks is the first week's real work.
Sources
[Stakeholder analysis](https://www.nngroup.com/articles/stakeholder-analysis/), Nielsen Norman Group. Used for the power and interest grid, its attribution to Aubrey Mendelow's 1991 conference paper on stakeholder mapping, and the point that the grid leaves out attitude. I read a summary of this page and did not check the original 1991 paper, so treat the attribution as secondary.
The three projects, the decision table, the delay figures and the simulator's defaults are the author's illustrations for teaching, not data from real companies.
Tags: Forward Deployed Engineer Stakeholders Discovery Customer relationships Beginner