Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

As a business analyst, you must work with your stakeholders to create the appropriate scope. The more people you bring into your scoping sessions, the better. Involving all the people or representatives that are affected allows for a greater perspective on the project; you get different opinions from different people during the scoping process.

In addition, everyone understands and has input on the project boundaries (the scope) and is therefore in agreement moving forward.

A scope is like a contract on a house. All the aspects of the house purchase are outlined, and the expectations are set going in. The buyers and/or sellers can change the contract to affect the price or timeline, but both parties have to agree to any modifications. Similarly, expanding the project scope may affect the budget, timeline, and/or the specific requirements, so all parties need to agree to changes.

How to uncover stakeholders by asking project-specific questions

Suppose your manager comes to you and says a stakeholder initiated a request to have the company logo printed on the invoice. Pretty simple, right?

But this situation presents a lot of concerns you as a business analyst should have and express. Which invoices would the logo appear on — online? E-mail? Printed? What size is the logo? Is it registered or trademarked? Do different customers receive different logos from different company divisions? Who (or what department) owns the invoice printing process today?

And you haven’t even started to address getting permission from the legal department. The answers to these questions help you determine which stakeholders need to be involved. Here’s a sample list for the logo project:

image0.png
  • The legal department because the logo contains the mark, which comes with a set of restrictions and has to be approved

  • The company’s different divisions because they use different logos; certain customers purchase products from only one division

  • The billing department for invoices and manufacturing for products because these departments own the printing process

By knowing all the stakeholders, you can then form the basis of what you are (and aren’t) going to study.

Your various stakeholders will probably identify more parties, systems, and hardware than will actually be in the project scope when the project gets underway. That’s fine. You end up adding those extras to the “out of scope” section. Stakeholders must be clear and in agreement on any item’s placement, regardless of whether you identify the item as within scope or out of scope.

How to discover key stakeholders in different parts of the organization

Many organizations are arranged around functional-based or organizational-based segments (sometimes known as silos or stovepipes). People tend to think of these segments as vertical slices of the company, but many processes or projects go across those silos. For example, look at how a customer’s order goes through multiple silos.

[Credit: Illustration by Wiley, Composition Services Graphics]
Credit: Illustration by Wiley, Composition Services Graphics

The problem with this arrangement is that a project that one silo undertakes may make another silo’s process less efficient. When scoping, you have to consider all the parties you need to include and how changes may impact everyone.

The easiest way to make sure all stakeholders are on the same page is to bring in everyone who may be impacted by your project. If you’re trying to improve the customer order process, you bring in stakeholders from the marketing, sales, operations, and accounting departments. By having all these parties in the room, you make sure they all have a say in ways to make the process more efficient.

Some techniques you can use to identify who you need to have in the room are stakeholder analysis, brainstorming, swimlane process diagrams, data flow diagrams, and interface analysis.

About This Article

This article is from the book:

About the book authors:

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995. Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business. Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

https://www.b2ttraining.com/about-us

This article can be found in the category: