In this KnowledgeKnugget™ you will learn several different methods for identifying stakeholders. This is a critical step in your requirements discovery. Missing a single stakeholder might endanger the entire project. Discovering missed stakeholders late in the project is a major contributing factor to scope creep.

Missing Stakeholders Can Endanger Your Project

Imagine planning a “surprise” wedding without proposing to your bride-to-be. Imagine starting a project to remodel your house without consulting with your spouse. Imagine adding an additional floor to your house without consulting the local zoning authorities. These three are but a few of the wonderful hypothetical scenarios that describe the real-life situations in which some organizations initiate information technology (IT) projects without including all relevant stakeholders.

Involving the right decision makers is one of the critical success factors for any project, IT or otherwise. To involve them, you have to first figure out who they are. Identifying Stakeholders is one of the most important steps in the early phases of any project. Missing a single stakeholder might endanger the entire project. At the very least, discovering missed stakeholders late in the project is a major contributing factor to scope creep. How can you avoid this pitfall?

How to Start Stakeholder Identification

The best (and most obvious) place to start is with the project sponsor, aka the person with the idea. The first stakeholder on any project is that sponsor who, in a perfect world, is also the individual who has:

• the funding necessary to pay for the project;
• the savvy to know what the project will ultimately deliver; and
• the political clout needed to get the project staffed (i.e., getting you assigned to define the solution).

The project sponsor is the perfect first candidate to help you identify additional stakeholders, provided you ask the right questions.

Early in the project, the sponsor’s idea is usually vague. It is more of a vision of what the solution should be as opposed to a detailed description of the outcome, let alone a specific, step-by-step set of instructions for building the thing. That is fine, that is the sponsor’s role, ergo we say that he/she ‘envisions’ the solution. Your challenge, then, is to figure out how to identify who all of the stakeholders might be based on this vague vision. Where to start?

A good starting point is a plain, old, simple org chart. Remember those? They used to tell you who were responsible for what within your organization. Unfortunately, they are notoriously susceptible to getting out-of-date. As a result, organizations seldom maintain them. The good news is that they are very easy to create, so if your organization does not have one that is current, whip out your trusty org chart tool (i.e., a flipchart, white board, or any drawing software you might prefer) and throw one together. This is Agile Analysis at its best.

Once you have a reasonable facsimile of a current org chart, chat with your project sponsor (and perhaps your manager and peers) about whom on the org chart the project will affect. For starters, simply note on the chart which departments or units are “involved parties”. Later, you will have to decide whom in that unit you should interview to identify their needs and wants relative to your project.

One group you might identify is a potentially large pool of participants who will be involved in creating the solution. Call this group of folks “Creators”. This group might include analysts (i.e., yourself), designers, developers, testers (aka “software quality guardians”), managers, network administrators, system administrators, data base folks, and a whole slew of like-titled people who have a stake in your project. Ultimately, each of them might have a set of requirements that they would like to ensure that you follow.

… [end of excerpt]