Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

Sometimes, trying to explain what’s within the scope of a business analysis by using just words becomes very difficult. That’s where a scope diagram can be helpful. Instead of just taking notes, you can actually structure your findings graphically in a scope diagram to help you make sense of everything. The scope diagram has three parts:

  • The rectangular boxes represent external agents (or actors). These agents are the people or the systems with which your project will interact. They’re external to your project, so you don’t study their internal processes. The only thing you can do is change the interface with the external agent.

  • The curved lines are the data flows into and out of your area of study that connect to the external agents. They represent interfaces.

  • The circle in the middle is your scope. You work on all the requirements inside the circle to be able to process information and send and receive it to your external agents.

The diagram below shows the area of study, the people or departments you interface with, and the interfaces themselves.

The beauty of this data flow diagram is that, when in place, it becomes an artifact you can share with stakeholders and project managers. When those people ask about new requirements, you have a scope you can return to in order to verify whether their requests fit within the boundaries of the original project or constitute a new request.

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

The diagram looks pretty simple, and you may be tempted to just jump right in and start drawing circles and lines. But those circles and lines represent aspects of your project, so be careful what you draw; it’s going to sign you up for what you work on! Here’s an easy five-step process to create a scope diagram:

  1. Identify parties and systems that will be impacted by the project.

  2. Identify information (data) flows among the parties or systems.

  3. Gain consensus on the scope for the project.

  4. Give the project a descriptive name.

  5. Finalize the scope diagram.

How to identify parties and systems that will be impacted by the business analysis

In this step, you want to list all the people, systems, and other external entities that your project impacts. Based on the project statement of purpose, come up with a list of these entities. These parties become your external agents.

Perform this activity with your project team. Having multiple people in the room helps bring in additional viewpoints that you may not have thought of on your own.

How to identify information flows among the parties or systems for business analysis

Next, you want to understand what information or data passes among these external agents. At this stage, you only want to understand the data at a high level; you can save the details for later.. As you identify them, add curved lines to your diagram.

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

Continue identifying all the data flows until you’ve completed the diagram. At this point, you have only rectangles and flow lines.

At this stage, you may find that some external agents don’t belong or don’t connect with any data flow lines to any other external agents. These stragglers are good candidates for specifically listing as “out of scope.”

How to gain consensus on the scope for the business analysis

Now you have a diagram with rectangles and curved lines, but still no indication of what is in scope. When you agree as a project team on what the scope is, you circle the rectangles you’re going to study as part of your solution.

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

At this stage, you can see that the only impacted party is the accounting department, so it becomes the group you analyze to determine a solution to the problem area. The circle now tells you a couple of additional items about the scope:

  • Any of the external agents who don’t share a data flow directly crossing the scope circle are out of scope for the project efforts.

    Any time you take something out of a project, list it as out of scope to avoid any confusion about its status later in the project.

  • The diagram shows you interfaces. Any data flow lines the circle crosses become user, system, or hardware interfaces. You may have to create these interfaces or modify existing ones.

All your requirements for changes or creation of new processes exist inside the circle. The external agents connected to the project scope interact with your project, but you have no control over them. For instance, legal is an external agent. Although it may be internal to your organization, it’s external to your project.

How to give the project a descriptive name

Make sure your project’s name is descriptive ensures that everyone understands what this project is undertaking. Consider the difference between Project Print Logo and Project Xf89K6-5. You can understand what the project is doing just by reading the name rather than a nondescript number.

In some organizations’ cultures, though, numeric names are just as descriptive as words. People in those organizations understand which project numbers related to which corporate initiatives. If that is indeed your organization’s culture, go with it.

How to finalize the business analysis scope diagram

For better clarity and readability by stakeholders, many business analysts list the high-level processes that will most likely be studied as part of your scope. You may study the software, hardware, manual or automated processes, and possibly the creation of new processes.

In this stage, you formally remove the items that aren’t in scope and document them as such. In addition, any flow lines connected from one external agent to another external agent outside the project circle are documented as out of scope for the project because your project has no control over communication between those external agents.

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.

This article can be found in the category: