Skip to main content

A Collaborative Stakeholder Analysis

It can be said that a stakeholder is any individual or group with an interest in the success of an organization in delivering intended results and maintaining the viability of the organization’s products and services.

A stakeholder therefore can affect either project scope or product scope. It is our users, be they managers or clerical staff, that we depend on to determine the functionality of a system. I strongly believe in the business taking ownership for its own requirements.

Users tend to think of functionality in terms of needs. “I need the system to do this.” “Will the system ever be able to do that?” and the ever persistent “the system won’t do what I need it to do because of something.” Users drive change because they need ‘things’ to perform their duties and to make decisions.

The business analyst makes those things happen, and thus, leads the business to its own solution. This brings me to a technique which I have had much success with; a stakeholder analysis.

A stakeholder analysis can uncover so many interesting things, for example: who needs and does not need access to the system, who has overlapping responsibilities, whose goals do not align with the responsibilities assigned to them, which business processes are common and which are redundant. I could go on, but let me get right to it. I use the stakeholder analysis to determine who my users are, what needs they have, how they expect to have those needs met; ultimately, what they will do with the system.

A stakeholder analysis should be done at the very beginning of the project and feed directly into the initial vision and scope documents.

To achieve this I generally do the following:

  1. Determine who all the stakeholders are.
  2. Categorize them into people and non-people, users and non-users.
  3. Build descriptions, goals and responsibilities for each.
  4. Confirm that the goals and responsibilities are aligned.
  5. Work with the project group, staff, SMEs and general user community to determine everything that the user needs and might need from the system.
  6. I usually assign the above tasks to an SME or other lead. This gives me time to begin collecting business objects, rules or other requirements.
  7. In addition to the activities/business processes, I also ask for the stakeholder’s physical location and any other general characteristics that might be important.
  8. If there is a high volume of activities and users, I may create a matrix that associates the users to the activities. This is really helpful to see overlap, redundancies and common activities.
  9. Where the environment is very dependent on rules, or has a highly functional org-chart, I may use a legend in the activity/user association that looks something like this:

A. Basic and persistent association.
RA. Persistent association that is based on some to be determined rule.
TA. Non-persistent association that is transient in nature. The user’s association to this activity is dependant on a condition. Once the condition is met the association is only available temporarily.

  1. I then begin to abstract the stakeholders looking for those common activities that can be rolled up to an abstract user.
  2. This allows me to take advantage of inheritance and is the first step to creating system actors.
  3. Next I can begin to create an actor model, which includes inheritance between actors and associations back to the stakeholders (traceability!).
  4. I now have a very clear picture of who needs to do what, who has access to what and who might not need access at all.
  5. With my users associated with my business processes and my actors associated with my users, it is very easy to see which use cases I will need and how much usage those cases will have.
  6. I then begin to translate my activities into use cases and start to determine which scenarios I will need.
  7. If I were able to assign the stakeholder analysis to someone else, I may have an idea of which business objects and rules will fall into which use cases.
  8. I may also know something about the business events and pre/post-conditions.
  9. With a decent list of use cases, actors, users, business objects, triggers and invariants I am ready to begin an effective use case model.

Remember, I mentioned that a stakeholder analysis should be done at the beginning of the project.

Within a short period of time I have determined who is touching the system, how they will touch it and what their needs are. I also have an understanding of which business objects I will need, what rules will be employed and where the subject boundaries will fall.

If this exercise moved at a good pace, the project may not even be out of the inception or elaboration phase. Now that my project manager is super-impressed I can get to work on building models and the BRD. I don’t have to tell you how many artifacts can use this analysis – security models, training and process diagrams or workflow analysis, just to name a few.

I hope that this can help you in your next deliverable.

Don’t forget to leave your comments below

Perry McLeod, CBAP, PMP, EVP IIBA, is a Certified Business Analysis and Project Management Professional with over 15-years of experience in business systems analysis and project management. As a Senior Management Consultant, Perry has worked with many clients including, Thomson Reuters, Capital One and Fifth Third Bank. In addition to a strong history in business analysis, Perry is also an instructor and contributor to the IIBA’s Business Analysis Body of Knowledge. He is currently teaching Business Communication at Sheridan College and is a Technical Lead, Management Consultant for CGI. His ultimate goal is to help raise the level of maturity for his clients, building the roots for a Business Analysis Centre of Excellence (CoE). Effective planning and communication, established best practices and a well-defined risk plan are critical to Perry’s success and he stresses them for every project. As a member of the IIBA’s Toronto Chapter, Perry is committed to raising the chapter’s visibility across the GTA by helping companies understand that aligning themselves with the chapter is the first step in reaching higher levels of maturity and competence for their internal business analysis community.