Do You Have the Key Business Stakeholders Involved in Your Project?

If customers are not receiving what they ask for in a project deliverable, what causes that? Where would everything fall apart to the point that requirements were not being carried out through implementation? Chances are the analyst may have had an incorrect or partially incorrect set of key stakeholders providing input to the requirements.

When regarding which stakeholders should participate in requirements discovery on a project, it’s easy to invite the masses to the meetings. However it’s more important to get the right stakeholders actively involved and the right time. Having more stakeholders than necessary can bog the meetings down in argumentation, conflicting dialog and detail. But overlooking an important stakeholder can result in missed requirements.

Who are the Right Stakeholders?

Deciding who should be involved, how, and when in doing stakeholder analyses[sic] is a key strategic choice. In general, people should be involved if they have information that cannot be gained otherwise, or if their participation is necessary to assure successful implementation of initiatives built on the analyses.

Thomas, J. C. (1993). Public Involvement and Governmental Effectiveness: A Decision-Making Model for Public Managers. Administration and Society, 24(4), 444 -469.

Getting the key stakeholders to participate in a project should not be anoff-the-cuff decision, but rather one that is a result of careful analysis and selection. Stakeholder Analysis is a much written about activity, but the general definition involves the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. (IIBA’s BABOK(R)  Guide, 2009)

This all sounds pretty simple in essence, but there is actually a lot that goes into identifying the correct participants. Also, skimming over the tasks related to this analysis can put the entire project at risk by not have the proper people involved or not having influencers associated with the project to help guide the project in moments of indecision.

Start with a Formal Stakeholder Analysis Exercise

There are many techniques for performing stakeholder analysis, but the overall goal is to determine who are the persons impacted by a proposed change and to assess their attitudes and influences on various project factors. These attitudes and influences are the drivers behind decision making and project progress in and of itself, as well as against the entire suite of active projects.

There is one critical element to stakeholder identification that often eludes a project’s members. Once formal stakeholder analysis is completed at the beginning of the project, it SHOULD continue throughout the life of the rest of the project. The identification of stakeholders early in the project will often result in the names or persons with manager and sponsorship powers, as well as line managers tied to the business units. These are definitively key stakeholders that have to make decisions about the project’s scope and direction.

Include Subject Matter Experts as the Project Unfolds

However, as the project team delves deeper into the requirement elicitation and modeling of the system, it is possible that the key stakeholder becomes someone more intimate with the inner workings of a department, system or team. Failure to identify additional stakeholder, often referred to as subject matter experts, as the drill-down continues can often lead to products or services that are not deemed usable by the very people that the project is designed to serve.

It’s important for the analyst to not replace the original key stakeholders with yet another set. Rather, the analyst is in a position to re-evaluate throughout the course of discussions whether the correct people are included. This doesn’t require another full stakeholder analysis exercise, because the analyst is not trying to, again, replace anyone. The goal is to get additional impacted persons to the table, perhaps through a subject matter expert interview. Where the focus of the original stakeholder analysis exercise was the entire project, a subsequent evaluation of proper stakeholder inclusion could focus on a granular sub-component of the project, such as an operational unit, system component or the like.

It’s also important to remember that as projects continue through to completion, the political aspects of the organization and its stakeholders are alive and well. Careful consideration to the inclusion of particular stakeholders must be given in relation to the attitudes of existing high-level key stakeholders.

Project failure has as its root cause many possible reasons. Delivery of a requirement set that has input from many potentially impacted stakeholders with thorough discussion and analysis helps to remove from consideration the possibility that the requirements didn’t meet the stated needs because the wrong people were involved in their definition.

>>Get a Quick Start on Stakeholder Analysis

Would you like a starting point for approaching common business analyst work scenarios, including building out a requirements development plan that includes a stakeholder analysis? Check out the Business Analyst Template Toolkit – all of the requirements templates are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.

Click here to learn more about the BA Template Toolkit

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. well put sir!

  2. Nathan Caswell says

    I’d second everything Doug has said while encouraging some ‘brutal reality’ assessment.

    The key is to be professional. “Nothing personal, just business” can be unpleasant, but getting in the middle is more so. Being professional means a clear idea what service you are providing, who you are providing it to, what their needs are, where your boundaries are, and who is the ‘least common manager’, i.e. the lowest management level with shared influence if there is conflict. BA boundaries are of a different nature than other service boundaries because they perform a liaison, bridging, or coordinating role. But there still are boundaries.

    There are a lot of situations, but I gather you are an employee (not consultant) with a management chain separate from the stakeholders.
    * Is the us-them IT and Business? If so, you can’t fix it in one project as in Doug’s interaction process example shows.
    * Who is the sponsor? Is the champion accountable for the results?
    * Who is your customer? may be the sponsor, or current project may be just one of a larger, business as customer, engagement. IT is probably a major consumer, are they the customer?
    * Is there a project charter with business goals and measurements?

    The underlying ‘brutal reality’ is if it is in your scope to bring the parties together, and if so is it in their interest?

    If there is a win-win, go for it. Recognize that it may take a large amount of progressively visible prep work. The BA role as liaison take on a mediator character here. Most mediations start with separate discussions where the mediator is able to build some common language and conceptual framework before direct negotiations. It works. (2 war stories for a beer, 4 for 2, 8 for 3, … 🙂

    If there is the “if this works, I lose my job” fear or reality it’s important to distinguish fear from reality. Fear may require additional management cooperation to work with. Reality may be a “be professional” situation.

    In some cases people manage to encapsulate resources or build fiefdoms. For example, preventing raw access to a data base. You may be in a position of either breaking them or letting the project work around to a middling result. A good situation to be very confident you have done your homework are right before initiating a breach.

    There are also the rest of the situations, including the one you actually have not addressed by any of these.

    To net it out: The BA needs to move beyond the IT mind set into the liaison role. This requires a particular attention to maintaining a professional approach to include, and exclude, stakeholders.

  3. ….and another thing….
    The them and us environment comment you made is reminiscent of where I work… until recently. It still exists but is getting better. You’re in a tough situation, but here’s what I did…and I did it on my own after trying to go through IT mgmt with no results.

    I started pinging my primary stakeholders and sending them emails or calling them to see how they were. Just a little relationship building. That led conversations that were mostly about nothing, but led to conversations where they opened up about issues. Whether the issue was with IT or the issue was amongst their own team, I always ask how I could help. Usually, they just wanted to gripe, but slowly they realized that I had some decent ideas and I WAS willing to help.

    Make yourself an advocate to the customer; they need one. Stand up for them! As Laura’s site suggests, start bridging the gap that can be very divisive between the two units. Start thinking of things that IT can do that will help the customers help IT. For instance, I recently rewrote a process that spanned from business over to IT. The trigger to start doing it was that IT was spending huge amounts of customer dollars sitting in meetings to review incoming requests for change when the customers hadn’t even communicated. So the short version is, I built a shell and then contacted my favorite customer and asked her to partner up. We delivered a solution together to our senior managers and are both responsible for ensuring the adoption of the changes…her on the business side, me on IT. Together we succeed or fail.

    Identify things that can better both areas, but DON’T fix it yourself, even if you can. Your business partner will rebel if he or she feels like IT is jamming something down his or her throat.

    Again, hope this helps.


  4. Good advice Doug. Thanks. You’re right in that pressure is coming from both sides. When you’re not getting support from you’re own management team it really feels like you’ve been hung out to dry though and when things descend into creating a paper trail to “cover your a**” then it feels like it might be time to move on.

  5. Hi Russ:
    There are a couple of things that you can do, any better put…have an obligation to do as an analyst. The first is to escalate the situation to your mgmt and/or the project sponsor. I’m going to assume that one or both may be the ones that are pressuring you to avoid stakeholders. This levels the playing field to a certain degree. They know that you understand not to talk to said stakeholder, and they also know that you are informing them of the risks involved of not doing so. You must do this at minimum. Following that, you need to document the risk in explicit verbiage in the project documentation and include what you foresee the results of the risk. The more detail you can provide in your foresight, the better.

    Then, there are a couple of other things that you can do to help yourself. Are you prevented from talking to only specific stakeholders? Are there others that you could get to with similar knowledge? Has the project undergone implementations in the past that may have captured some of the knowledge that you need or produced relationships that you could leverage without getting directly involved in the conversation? You’re going to need to think creatively in order to accomplish your goal…..which you probably need to define for yourself to keep your head straight. Exactly what is your personal goal here? Service the customer? Be an IT automaton doing what you’re told? Be an analyst? Your goal will clear the path and show you the correct direction…which will guide you around these obstacles. That’s sounds a bit corny, I know, but it really is important.

    Hope this helps

  6. So how would you guys deal with it if you’re actively discouraged from speaking to people you consider to be stakeholders? When there’s a pervasive “them and us” attitude that is perpetuated by the project management team and even to a certain extend by the project champion from the business? This is a situation I’ve found myself in recently and unfortunately have been unable to dig my way out of. I think it will lead to, if not the downfall of the project, then at least missing its target by quite a long way and ultimately being a disappointment to business sponsors further up the chain.

  7. Thanks Nathan!
    You’re surely correct about the silent killer, but I’m not so sure I agree with it being the result of a failure of addressing the original problem only.

    I wroye this article after reading several posts about project failures. The authors couldn’t figure why, but in reading what they said, each time it appeared that the project protocol was followed. That got me to thinking about what falls apart in a project. It also made me think about stakeholders, and I’m certainly guilty of going through the stakeholder analysis exercise as a matter of checking the checkbox and forgetting about how important the information is from it.

  8. Nathan Caswell says

    Good post! particularly the emphasis on doing it first and keeping a constant focus through the project.

    Stakeholder analysis is one area where the BABOK lumps a little broadly, in my opinion. The project interacts in different ways with those who have decision/approval power, those who contribute directly to the project, and those impacted by the project deliverables. One of the hardest to identify are the influencers of the decision makers.

    Stakeholder (BABOK definition) analysis is also a good place to apply some system thinking. Rather than a top down “who is involved” a bottom up search from “what is to be delivered” is suggested. The idea is to look beyond direct dependencies to find relationships between the stakeholders.

    There are really two, or three systems involved: the IT system and related owners and users; the business operation that will derive value from the project deliverables; and the management/organizational units that are responsible for the operation and have decision making power around the project.

    In my experience, the first can create more drama than actual problem. Missing a connection in the decision makers can be fatal, with little warning and recovery potential. The operational layer, how the app or process interacts in operation, is a silent killer that shows up after successful deployment through symptoms like not making the improvement targets in production, hearing same old complaints, or initiating a similar project. It is a failure to solve the original problem.

  9. A key stakeholder for writing content that is published to the world is a good proofreader, which I have failed to utilize. Apologies for a few typos. Lesson learned.


Leave a Reply to DougGtheBA Cancel reply


Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.