4 of the 13 questions we have for this objective, shown with the answer and the reasoning.
How to apply the stakeholder management technique
At Benham Telecom, the architect's stakeholder map for a network billing engagement lists each stakeholder group and its power/interest quadrant, and nothing else. When the team starts Phase B, nobody can say which catalogs, matrices or diagrams each group expects, and two weeks are lost producing artifacts no one asked for.
What should the architect add to the stakeholder map?
- AA RACI chart assigning each stakeholder to the project's delivery tasks.A RACI chart is a project management tool for tasks. It does not tell the architecture team what each stakeholder needs to see.
- BEach stakeholder's job grade and reporting line, to show their seniority.Seniority may inform power, but it does not describe concerns or deliverables, which is what the team was missing.
- CA list of the Architecture Contracts each stakeholder will sign.Architecture Contracts are Phase G agreements. They do not guide what architecture content to produce in Phases B to D.
- DFor each stakeholder group, its key concerns and the catalogs, matrices and diagrams that address them.The stakeholder map in the TOGAF Standard records, for each stakeholder group, its involvement and key concerns, its class and the artifacts relevant to it, so that the map drives the content produced.
Why: The stakeholder management technique ends by tailoring engagement deliverables: the stakeholder map records each group's concerns, class and the relevant catalogs, matrices and diagrams (TOGAF Standard, ADM Techniques, Stakeholder Management). A map with only quadrants tells the team how much to engage each group but not what to produce. The deciding fact is the wasted work on unrequested artifacts. The distractors add project or contractual information that does not connect stakeholders to architecture content.
How to apply the stakeholder management technique
Marlow Credit Union completed Phase A of a lending platform engagement with an approved Statement of Architecture Work, a stakeholder map and a Communications Plan. Midway through Phase B, the Chief Operating Officer who championed the work leaves and is replaced by an executive from a competitor who has publicly favoured buying a packaged lending suite rather than the planned integration approach.
What should the architect do next?
- ARevisit the stakeholder analysis for the new COO, update the stakeholder map and Communications Plan, and engage her early on her concerns and the options being considered.Stakeholder management is continuous. A new high-power stakeholder with different views must be analyzed and engaged before the architecture progresses further.
- BContinue with the existing Communications Plan, because it was approved in Phase A.Approval does not freeze the plan. Ignoring a change in a key stakeholder's position risks the architecture being rejected later.
- CRestart the engagement from the Preliminary Phase to re-establish the Architecture Capability.The Architecture Capability is unaffected by one executive change. Restarting the Preliminary Phase is out of proportion to the problem.
- DRaise a change request in Phase H to record the new COO's preference for a packaged suite.Phase H manages change to an implemented architecture baseline. A new stakeholder's preference during Phase B is a stakeholder engagement matter, and any resulting requirement goes through Requirements Management.
Why: The TOGAF Standard treats stakeholder analysis as starting in Phase A and being revisited throughout the ADM as stakeholders and their positions change (TOGAF Standard, ADM Techniques, Stakeholder Management). A replacement COO is a high-power stakeholder whose position has moved, so the map and the Communications Plan must be updated and engagement planned to address her concerns. The distractors either treat the plan as fixed or reach for heavyweight mechanisms such as restarting the capability or Phase H.
How to apply the stakeholder management technique
Kinross Airports is in Phase D of an architecture for a new passenger check-in platform. The operations director's main concern is what happens to check-in if one of the two data centres fails. The architect has produced structural diagrams of the platform's components, but none of the viewpoints the team normally uses shows failure behaviour or recovery. The Architecture Repository holds a library of viewpoints that other teams have defined.
What should the architect do?
- ARecord the concern as out of scope, because the standard viewpoints the team uses do not cover it.Concerns of key stakeholders must be addressed. A gap in the team's usual viewpoints is a reason to find or define one, not to drop the concern.
- BAdd availability notes to every existing structural diagram and send the full set to the operations director.A structural viewpoint is not designed to show failure and recovery behaviour. Annotating many diagrams leaves the director to assemble the answer.
- CSend the operations director the Technology Standards catalog showing the approved data centre products.The catalog lists approved technology. It does not show how check-in behaves when a data centre fails.
- DLook for a suitable viewpoint in the repository's viewpoint library and, if none fits, define one for resilience and recovery, produce the view, and add the viewpoint to the library for reuse.Viewpoints are reusable and stored in the Architecture Repository. When none addresses a concern, the architect defines one, which then serves future engagements.
Why: The TOGAF Standard holds that each view must conform to a viewpoint that frames the concerns of its stakeholders, and that viewpoints can be reused from a library or newly defined when the concerns require it (TOGAF Standard, Architecture Content, Architectural Artifacts). The deciding fact is that the team's usual viewpoints are structural, while the director's concern is behaviour under failure. Defining or reusing an appropriate viewpoint, and storing it in the repository, addresses the concern and builds the capability. The distractors drop the concern, overload the stakeholder, or answer a different question.
How to apply the stakeholder management technique
Aldermoor Chemicals is in Phase A of a global procurement architecture. Stakeholders include plant managers in nine countries, the group procurement board, IT application owners and an external auditor. The architect is writing the Communications Plan and a colleague suggests keeping it simple.
What should the Communications Plan specify?
- AA single monthly newsletter sent to every stakeholder so that all groups receive the same message.Different stakeholder groups have different concerns and needs. One message for all ignores the stakeholder analysis that the plan is built on.
- BCommunication with the Key Players only, since other groups cannot affect the outcome.Keep Satisfied, Keep Informed and even Minimal Effort stakeholders still need planned treatment. The external auditor and plant managers would be left out.
- CFor each stakeholder group, the information they need, the communication mechanisms to use, and the timing of communications aligned to engagement milestones.A Communications Plan identifies stakeholders, their communication needs, mechanisms such as meetings, newsletters and repositories, and a timetable tied to the engagement.
- DThat all architecture content will be published in the Architecture Repository, where stakeholders can find what they need.The repository is a useful mechanism, but publishing alone is not planned communication. Stakeholders who do not know what to look for will miss what matters to them.
Why: The Communications Plan, an output of Phase A, sets out how the architecture team will communicate with stakeholders: who receives what, through which mechanisms and when (TOGAF Standard, ADM, Phase A; ADM Techniques, Stakeholder Management). It is built from the stakeholder analysis, so it differs by stakeholder group. The distractors simplify the plan in ways that ignore the classification of stakeholders.