Babok® task: Conducting Stakeholder Analysis
Continuing with our suggestions on how to integrate business analysis best practices into ITIL contexts, let us focus on the conduction of stakeholder analysis. Once again, we have to stress that BABOK is not prescriptive on when and how this task (or any of the other 31 BA tasks listed in BABOK) should be carried out by the business analyst during a project. BABOK only makes a point on the possibility of executing the task, whenever the inputs required to execute it are available.
In our practice, requirements managers normally conduct stakeholder analysis during Service Strategy. Their first effort, at a higher level, takes place to support the preparation of the business case. Then, after the new or changed service is approved, they conduct a more comprehensive analysis of all stakeholders, focusing also on IT and implementation subject matter experts.(*)
What is Stakeholder Analysis?
As soon as the business need is defined, the business analysis team needs to pause for a moment and identify who may be affected by a proposed change in services or who may have a stake on the business need being addressed. Similarly, once a project is approved (the service is chartered), business analysts need to move on to identifying who will be the relevant stakeholders during the project phase, and what would be their level of influence and authority regarding the approval of project deliverables.
Why is conducting stakeholder analysis important to the project?
As much as an AGILE approach would provide the delivery team with some extra room to react during Service Design and Service Transition, a late identification of a stakeholder usually translates into a revision of requirements, stakeholder concerns, and of business analysis deliverables in general. Having a formal process to analyse stakeholders before undertaking elicitation activities, provides business analysts and project managers with an opportunity to discuss openly the completeness of the business analyst’s stakeholders list, and to minimize the risk of reworks.
The diagram below provides a quick view on who can be involved in this business analysis activity:
Besides early identification, BABOK 2.0 points to three other key issues the business analyst should consider when conducting stakeholder analysis:
Complexity of stakeholder group How many end users are represented in a stakeholder group? would their representatives or advocates be able to communicate all end user concerns and needs accurately? Think of marketing analysts facing a critical change in customer service. Would they need to conduct surveys among clients before taking part in a requirements workshop?
Similarly, if the change initiative affects a large number of systems and if elicitation activities might need to be organized for cross-sectional teams, the project manager may have a lot to say on how that approach could fit into his overall project plan.
Stakeholders’ attitudes and influence: Attitudes are unlikely to change in the span of a single project and business analysts can anticipate stakeholder attitudes to expedite business analysis activities: Do stakeholders trust the IT project team to deliver a solution? How about the business analysis team? Do they see the value of business analysis activities? Has the business analyst built trusting relationships with project team members?
On the other hand, understanding the level of influence each stakeholder can exert on the project, and within the overall organization, makes the business analyst better at building trust and brokering agreements on requirements and project priorities.
Authority levels for business analysis work: Finally, the business analyst obtains, as output of this activity, a list of stakeholder responsibilities and accountability on requirements management. It is through stakeholder analysis that business analysts determine which stakeholders will have authority over business analysis activities and product deliverables, and what would be the overall workflows and approvals required when managing change in requirements?
In conclusion, “conducting stakeholder analysis” is another best practice from the Business Analysis Body of Knowledge that can help Service Portfolio Managers initiate new or changed services with a complete list of relevant stakeholders.
Inferior execution of this task before moving on to Service Design carries the risk of generating business requirements that do not capture all stakeholder concerns.
(1) Notes on BABOK® and ITIL®
(*) BABOK 2.0 refers to stakeholder analysis as an ongoing task:
“Stakeholder analysis is performed as soon as a business need is identified and will usually be an ongoing activity as long as business analysis continues”
p26, A Guide to the Business Analysis Body of Knowledge® Version 2.0 . International institute of Business Analysis
I agree with BABOK on the ongoing nature of the activity. What this article is suggesting is two clear instances when stakeholder analysis could be organized formally in an ITIL context, and included in project planning: during Definition and Analysis of New or Changed Services and during Approval of New or Changed Services (see diagram below).
Finally, another instance when conducting stakeholder analysis would be needed in an ITIL context would be when firming up authority levels on service validation, during Service Transition.
ITIL® is a registered trademark of the Cabinet Office in the United Kingdom and other countries. BABOK® is a registered trademark owned by International Institute of Business Analysis
By Larry Velarde, CBAP®
