Identifying Hidden Project Stakeholders by Connecting the Relationships

When beginning work on a project – whether joining an existing effort or helping to plan the kick-off – the competent BA looks around at the players to identify the Stakeholders in this initiative and what they care about.  After all, they’re the ones that will have to live with the outcome.  The obvious Stakeholders are the Business Area Sponsor who will make decisions and holds the purse-strings, the IT Division Heads who will provide the resources, the Operations Managers whose staff will implement the resulting changes.  But how do you figure out the ripple of impacts to others whose role is not so obvious?

Faced with the unknown parameters of your project’s “Business Domain” you might check the Organization Chart, but you’re not sure who to dub with the Stakeholder title.  Annual Objectives Statements provide some clue to motivators, but not really an understanding of organizational alliances and conflicts.  What’s needed is something that reveals more than reporting hierarchy and goals.

Identifying all the right stakeholders

Enterprise Analysis has provided the answer for me.   By this I mean building Domain Models – simple relational diagrams, focused on understanding  the ways in which elements of the business connect to each other, What and Why rather than How. I’ve used Domain Models to ferret out missing Stakeholders in a number of ways:

• A new spin on the organizational hierarchy– we expanded the org chart to visualize the invisible organizational lines and informal matrix reporting structures.
• A process decomposition – we grouped activities into their common process objectives to determine contradictions to the organizational structure.
• A goal decomposition– we categorized the hierarchy of business objectives and metrics that the organization used to measure success,  how they align with the project goals, and who was accountable.
• A context diagram – we created a wheel of Stakeholders with the new system as the central hub, labeling directional lines to indicate sources and destinations of different information, treating the system as a black box so as not to get tangled in functionality discussions.
• A stakeholder relationships diagram – we brainstormed stakeholders, labeling directional lines with the expectations key players have of each other, and then filtered out the irrelevant by removing those not impacted by project deliverables.
• A process interaction diagram – this time instead of Stakeholders we took the core processes (top level of a process decomposition) and looked at how they feed each other to determine if there were other impacts to consider.
• A business interaction diagram – we took the stakeholder relationships diagram one step further by slotting the roles and organizations into categories of supplier, customer, competitor, and process participants, allowing us to pinpoint resource inter-dependencies and competing interests that could cause issues for the project if not dealt with.
• A business object model – we identified the components and types of products included in the project scope to study the context of information needs.

The Business Areas that are your sources of domain information may give you some resistance initially, but going through this process of discovering relationships can be cathartic for your business counterparts, increasing their awareness of throughputs and influencing factors.  Documenting this sort of information helps the business areas to visualize what’s really going on, and organize a change plan where needed.

Anticipating the positive impact new stakeholders will have on your projects

To put the results in a project context consider these examples from my project history book where the representation expanded to include new stakeholder perspectives:

• Added key internal Customers and every IT department impacted by a planned Help Desk application with automated ticket routing & tracking.
• Included Underwriters that would be trying to sell the Managed Care partnership being evaluated by the Claims group.
• Added Facilities Management to a planned implementation of a Claim handling workflow and imaging system that had huge impacts on the mailroom, the de facto scanning center.
• Brought Data Warehouse participation into systems design sessions that were repeatedly identifying the warehouse as the best solution option for managing financial, regulatory and customer reporting.
• Internal Audit was added to a migration project and wound up taking responsibility for the process QA due to the complexity of properly mapping financial transactions to Insurance, SEC, Actuarial rules.

Think about being able to suggest to your Project Manager additional participants who will make decision-making easier, or identifying administrators of downstream systems that will become part of the test team.  This recent Project Times article on Detecting Stakeholder Misalignment describes the impact to Project Managers when Stakeholders are overlooked, and by proxy, the  impact to the Sponsors of the project.  By identifying potential conflicts early in the project you’ve saved them both from greater, potentially project-killing battles down the road.  All it takes is the brave Business Analyst standing up and saying so.  Your models could generate what the article calls a “stakeholder consensus audit”, a diplomatic disclosure of conflicting ideals.   The rewards include the Holy Grail – Informed Stakeholders.

Knowing the relationships can improve your own relationships

Through Enterprise Analysis you learn about the things that are important to your project’s Stakeholders and how your project will have an impact. By taking this broader view of business value you also gather some key pieces of information:

• expectations of Stakeholders and the risks of not meeting them;
• triggers that launch activity;
• deliverables between process participants;
• inter-dependencies like supply chain, competition for resources, regulatory constraints;
• work product destinations and Customer demands.

All of this information helps you – the wise new BA on the project – to elucidate the business need and start formulating solutions.  You are alert to project issues, know who you’re dealing with, what they’ll expect and more importantly, what they’ll find issue with.  Others will start to recognize that you are able to take on this type of senior level responsibilities.

Creating success by revealing relationships

Never looking beyond the obvious direct impacts can leave a dangerous gap in your project team’s sources of information and makers of decisions.  An important contribution from the project’s BA is to examine organizational, information, process, and customer/supplier relationships. By understanding your Client’s value chain the solutions to their business problems become more apparent.  Including upstream and downstream Stakeholders enables your Project Manager and Sponsor to take the next important step: ensuring that everyone understands and supports the project objectives.  The more you know about the business domain the more your Client will relax and be confident that you “get it”.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class