Stakeholder Management and Negotiation

A fictional retail bank had three customer data platforms, one each for retail banking, cards, and wealth. Its new chief technology officer was asked to prepare and lead a consolidation. Under the bank’s delegation, she could manage approved delivery work, but selecting the surviving platform and reallocating budgets across units required the chief operating officer’s approval within his own mandate. He sponsored the program. A steering committee of the three business heads, the finance director, and the risk director advised him; it had no collective authority to make that selection. For two quarters, its members endorsed consolidation in principle without settling the trade-offs. Then the operating officer left. No successor or interim decision route was appointed, and the committee kept meeting. Wealth wanted to keep its platform, finance would not fund a fourth, and risk required accurate regulatory reports by the existing deadline. The case illustrates the part of technology leadership concerned with stakeholders, interests, expectations, sponsorship, and executable decisions. The public guidance discussed below comes from government standards, negotiation teaching, and company practices. The bank and its decisions are invented.

Who the stakeholders are, and what each one holds

GovS 002, the UK government project delivery standard, asks teams to understand stakeholders’ interests and expectations and revisit their engagement as circumstances change. It also requires outcomes to be validated against the needs they are meant to meet. Validation needs evidence from relevant users and operators and acceptance through the designated approval route. It does not give every stakeholder a veto over every preference. A program can meet its requirements and receive valid acceptance while a business head still prefers another option; an unmet mandatory reporting requirement is a different matter.

The entry on stakeholders distinguishes approval authority, relevant knowledge, and exposure to consequences. A participant can hold more than one. The bank had invited budget holders but had not asked the wealth operations staff how reconciliation and reporting would work during a migration. The following five-column map reconstructs the situation before the restart. Interests and expectations are the CTO’s initial hypotheses to confirm with each group, not evidence that consultation has already happened. Approval powers must be checked against the actual delegation.

Stakeholder (fictional bank)	Holds	Interest	Stated position	Expectation of the program
Chief operating officer (original sponsor)	Platform selection and cross-unit budget authority within his mandate; escalation route	Lower run cost before the next plan	Consolidate	A decision by quarter three; timely risk reporting
Head of wealth	Approval within her unit; exposure	Regulatory reporting continuity; her team’s standing	Keep the wealth platform	No reporting outage; a role for her people
Head of cards	Approval within his unit; knowledge of the largest data volume	Real-time fraud features he has been promised	Keep the cards platform, it is the biggest	Feature work continues during migration
Head of retail banking	Approval within her unit; exposure; customer-service knowledge	Continuity of branch and digital customer services	Not yet established	Service impact and staff requirements to be confirmed
Finance director	Spending controls within the finance delegation	No fourth platform; a defensible comparison	Whichever is cheapest	A total cost of ownership comparison, not a pitch
Risk director	Reporting-rule expertise; required compliance sign-off in this bank	Reports filed on time and correct	No migration that threatens the deadline	Evidence that the reporting path meets requirements
Wealth operations staff	Exposure; knowledge of reconciliation rules	Reliable reports and workable exception handling, to be confirmed	Unasked	Input, support, and training needs not yet confirmed

The Interest and Stated position columns answer different questions. The next section uses that distinction to develop alternatives. The operations row also shows an information gap: a broken report could expose a missed requirement or an unworkable transition, without implying that staff chose to obstruct the program. The article on leading across functions develops the mapping of functional interests and decision roles. At the executive level, the same work must account for budget mandates and required approvals.

Interests, not positions

Repeating a preferred solution can narrow a negotiation even when that position could change. Harvard’s Program on Negotiation summarizes principled negotiation through four practices: address relationship concerns as well as the substantive problem, investigate interests beneath stated demands, develop options that create mutual value, and agree fair criteria for comparing them. Interests explain why someone wants a platform retained. They do not establish that the platform is necessary, or that another option will satisfy the person.

Wealth wanted reliable reporting and a viable role for its team. Phasing migration around the deadline and retaining reconciliation responsibilities were proposals to investigate with its head and operators. Cards wanted fraud features; adding dates to a roadmap would still require delivery capacity and agreement about dependencies. Retail needed continuity of customer services. Finance needed comparable costs. The article on budgets and total cost explains common scope, workload, horizon, and uncertainty. Comparing all candidates on that basis reduces opportunities to manipulate the comparison, but does not eliminate biased assumptions. These proposals become credible only when the affected people confirm the requirements and the responsible owners establish that the work can be delivered.

PON’s guidance on Getting to Yes also recommends redirecting hostile exchanges toward joint problem solving and seeking agreements that participants can uphold. In the bank, that meant asking what each unit needed to protect, checking the evidence, and finding out which commitments its managers could actually make. Agreement was useful only if it could survive implementation.

Expectations, set on purpose

The initial map left several expectations untested. GovS 002 connects communication to the audience, timing, and accessibility of the message; the UK digital leadership framework also asks senior leaders to manage expectations against organizational capacity. The CTO needed to ask what each group understood the program to promise and correct material mismatches. Silence can allow a mistaken expectation to persist, but it does not automatically establish a promise or agreement.

Start by explaining what the program will decide and the intended timing, what is outside its scope, and what input or approval is needed from each participant. Ask them to confirm their understanding, record unresolved concerns, and notify them when commitments change. GitLab’s communication guidance distinguishes a proposal seeking input from an explanation of a decision already made. The bank needed that distinction and a valid route from proposal to decision. After the sponsor left, further discussion could gather evidence, but the committee could not authorize the platform selection under its existing mandate.

Conflict between stakeholders

By the third quarter, wealth and cards were in open conflict. GitLab’s conflict guidance identifies perceived inequity as a possible cause and asks participants in collaborative resolution to support their positions with data. The CTO could investigate migration effort, reporting risks, and feature dependencies while also hearing concerns about team standing and fairness. Agreed criteria organize a comparison; they do not necessarily settle conflicting values or remove uncertainty. If new evidence reveals a missing requirement or a biased assumption, reopen the affected criteria, record the reason and approval, and reassess every candidate consistently. A disappointing score alone is not a reason to change the rules.

The CTO also had a platform preference and a budget. She could facilitate the discussion while disclosing those interests, but should not present herself as an independent mediator. A neutral facilitator could help where trust had broken down. Amazon’s public principles encourage attentive listening, candid discussion, and respectful treatment. For this case, that meant explaining the evidence behind a recommendation and acknowledging unresolved concerns rather than treating disagreement as disloyalty.

What a sponsor is for, and what happens without one

GovS 002 distinguishes a sponsoring body, a senior responsible owner, and a program or project manager. The sponsoring body endorses the purpose, directs and supports the accountable owner, and makes or refers decisions beyond that owner’s authority. It can be a person or a group. The senior responsible owner owns the business case and answers for outcomes and benefits, while the manager handles day-to-day delivery. Companies may arrange these duties differently. The executive sponsor entry explains the functions and the need to check their local assignment. In this bank, the COO had provided sponsorship and a defined selection authority; his departure left those functions uncovered.

The selection was outside the CTO’s authority because the bank’s delegation said so, not simply because it crossed units. Repeatedly unanswered escalations and a business case with no active oversight were reasons to inspect the gap. The CEO needed to restore sponsorship and an authorized decision route, through a successor or a properly empowered interim arrangement. A committee could fill a decision role if it received the relevant authority and rules for reaching a decision. The existing advisory committee had neither.

Decision rights, tolerances, and escalation

Write down the owner’s authority, the sponsor’s limits, and the route for decisions that exceed either mandate. A sponsor may need to refer a funding or risk question to another executive or governing body. This is the practical content of a decision right. The entry on responsibility and accountability distinguishes carrying out work from answering for a decision. Naming either role does not supply someone else’s budget, staff, or required approval.

Tolerances let an owner handle permitted variation in cost, benefits, schedule, quality, scope, performance, or risk without asking for a fresh decision each time. Define what happens when a breach is forecast or an unresolved issue exceeds the owner’s authority. Routine reporting, assurance, and mandatory approvals still apply inside those limits. The sponsor continues to review business justification and risk; oversight is broader than deciding exceptions.

The delegation level vocabulary describes who participates in a particular decision: the manager, the team, or both. It complements authority limits rather than replacing them. When using DACI, assign one authorized Approver for that decision and identify who contributes evidence. That framework’s single-Approver rule does not invalidate collective decisions under another governance arrangement. An advice process adds a distinct requirement to consult affected people and experts when adopted. A DACI Contributor label alone does not establish that process or replace a separate approval.

Agreement is not commitment

The committee’s initial support for consolidation did not commit named staff or settle which unit would bear the transition work. GovS 002 calls for operational responsibilities to be agreed and accepted during transition. Amazon’s disagree-and-commit principle offers a company example of supporting execution after candid challenge. Applied here, the norm concerns a valid decision with confirmed resources and obligations. A new reporting risk or a failed prerequisite still needs escalation and may justify changing the plan; carrying on regardless would not demonstrate useful commitment.

A decision record preserves the authorization, reasons, dissent, accepted responsibilities, dates, concessions, and review conditions. It should link the resource owners’ approvals and identify dependencies that remain open. The document does not itself create capacity or consent. Meeting minutes can serve this purpose if they contain the necessary information; a bare statement that the committee agreed cannot show who is authorized and ready to act.

Before accepting a proposal, compare it with the best feasible course if there is no deal: the BATNA. PON recommends realistic alternatives and comparable terms. For the bank, possible fallbacks included a funded period of continued operation and a narrower migration. The CTO could propose these but could not impose a cross-unit investment freeze. She obtained authorization for continued operation through the next reporting cycle, with required reporting, security, maintenance, and contractual spending preserved and a dated review. The sponsor and finance confirmed the funding; other discretionary work would require its own approvals. That made the fallback executable. The narrower migration still needed reporting specialists who were unavailable before the deadline, so continued operation was the best feasible alternative for that cycle. Its cost, risks, and foregone benefits could then be compared with the consolidation proposal. Estimates of each business head’s alternatives helped frame questions, but did not prove what that person would accept.

The program, restarted

In the fourth quarter, the CTO took the authority gap to the CEO. The CFO was appointed sponsor with written authority for the platform selection and the proposed budget envelope, an onward route for decisions exceeding it, and a reporting and assurance schedule. The CTO’s delivery limits were recorded separately. The steering committee remained advisory. She then confirmed the map with all three business heads, finance, risk, and operations representatives. Retail added service-continuity requirements; operations supplied reconciliation rules and exception cases. Each group could distinguish a proposed arrangement from an accepted commitment.

The groups first separated mandatory conditions from comparative criteria. Accurate and timely regulatory reporting and the required service continuity had to be demonstrated before a candidate could be approved for transition. The risk director could assess evidence and require corrections, but could not waive an external obligation. Among feasible candidates, the bank compared total cost on a common scope and horizon, residual migration risk, and time to fraud features. A low cost could not offset a failed mandatory condition. If no candidate could meet it, the team would revise the scope, timing, or reporting approach. Preferences were already known; agreeing the evaluation method made them open to scrutiny. New evidence could trigger a documented revision and consistent reassessment.

The CTO developed the phased options with each business head and the delivery teams. Resource owners confirmed staffing, funding, dependencies, and achievable feature dates before those items became commitments. The sponsor received a proposal with feasible alternatives, comparison assumptions, dissent, and the authorized fallback. Within the stated mandate, she selected the consolidation approach and recorded the approvals and conditions for release. Wealth’s head still preferred her own platform, but accepted the supported staffing commitment and released engineers accordingly. That preference did not waive the later readiness checks, and the selection did not authorize a cutover before those checks passed.

Before migration, operations staff rehearsed reconciliation and report production with representative data, including exception cases, and checked results against the agreed requirements. Defects were corrected or the affected transition deferred. The designated business, risk, and operational owners recorded the required acceptance evidence; the release authority confirmed readiness, continuity arrangements, and the response if the new path failed. Training and support were funded alongside this work. The first reporting day after migration provided operational confirmation and new evidence to monitor, following the earlier validation. Problems would trigger investigation and the agreed response, not an assumption that staff had refused the decision.

What a reviewer should ask

A program’s stakeholder situation, or a leader’s handling of it, can be reviewed with a short list, each item tracing to something above.

• Does the stakeholder map distinguish confirmed authority, relevant knowledge, and exposure? Have the affected groups checked it?
• Have the interests behind stated positions been confirmed, and have proposed options been checked for feasibility and acceptance?
• Are mandatory conditions separated from comparative criteria? Are assumptions, revisions, and consistent reassessment recorded?
• Have participants confirmed scope, expected input, and timing? Are proposals, decisions, open conditions, and subsequent changes clear?
• Who provides sponsorship, within what mandate, and who takes over if that role becomes vacant?
• Are owner and sponsor limits, reporting, assurance, and escalation routes explicit, including forecast breaches?
• What is the authorized decision route: a DACI Approver or a collective body with defined authority and decision rules? Which separate approvals remain necessary?
• Does the record preserve resource owners’ commitments, dissent, responsibilities, concessions, dependencies, and review triggers?
• Which fallback is feasible and authorized if there is no agreement, what obligations does it preserve, and how does its value compare with the proposal?

The bank restarted when it restored an authorized decision route and connected it to stakeholder evidence, feasible options, and accepted delivery responsibilities. Meetings and records supported that work. Progress still depended on listening to the people affected, testing assumptions, and changing course when the evidence required it.

References

• UK Government Functional Standard GovS 002: Project delivery, version 2.1, issued 1 September 2025 (Open Government Licence v3.0): principles 2, 4, and 8; clauses 4.4.7 to 4.4.9; 6.4.3–6.4.4; 7.12–7.13; 8.6–8.8; and the planning and control clauses on tolerances and escalation.
• Katie Shonk, Principled Negotiation: Focus on Interests to Create Value, Program on Negotiation, Harvard Law School, 30 June 2026 (a summary of Fisher, Ury, and Patton, Getting to Yes).
• Katie Shonk, Six Guidelines for Getting to Yes, Program on Negotiation, 18 June 2026.
• Guhan Subramanian, What is BATNA? How to Find Your Best Alternative to a Negotiated Agreement, Program on Negotiation, 27 May 2026.
• Amazon, Leadership Principles.
• GitLab Handbook, Managing Conflict.
• GitLab Handbook, Communication.
• Atlassian Team Playbook, DACI Decision-Making Framework.
• UK Government Digital and Data Profession Capability Framework, Chief digital and information officer, published 29 August 2025.