Abstract
Most scope creep occurs because of lack of agreement among stakeholders, an inconsistent understanding, or lack of sufficient analysis in development of the product or solution scope. Business analysts facilitate discussions using visual analysis techniques to clarify the scope of the product or solution. Without clear boundaries, the project can sometimes get outside of scope, trying to solve additional business problems. A well-defined and documented scope allows accurate project planning and keeps the team on track.
Business analysis scope modeling techniques focus on collaboration with business stakeholders and on the technical team to define a clear scope definition and to mitigate the risk of scope creep. This paper describes three popular business analysis techniques for getting your stakeholders to agree on scope and to stick to it! The techniques include the context diagram, the use case diagram, and the product backlog.
Introduction
What Is Scope Creep? Why Does It Occur So Frequently?
Scope creep refers to the problem experienced on many projects when the size or complexity of the original product description grows. Let's look at an example: A businessperson asked for a new website to advertise a product. The project team starts by creating a design and developing a plan to build the website. After the plan is complete, the business person realizes that he or she would also like to be able to sell the products on the website, not just advertise. This is additional work for the project team which will jeopardize the project plan, time, cost, and quality.
Scope creep is pervasive on our projects for a couple of reasons: 1) We often do not have a clear, agreed upon scope before we start, so everyone has a different idea about what is in and out of scope, and 2) As stakeholders see the requested product being created, they get additional ideas for what it might do!
Scope creep continues to be a big problem for most organizations because of the complexity and size of the products and solutions that are being built. The more complex the result, the more difficult it is at the beginning to anticipate every feature that may be needed/desired. In addition, the interfaces with related systems and parties may be more time-consuming to build than building the product itself. It is difficult to create a project plan without a complete picture of the product. This is one of the reasons many teams are moving to change-driven, agile development approaches. With agile, changes are welcomed, within the confines of a product vision or roadmap (scope). Regardless of the development approach used, scope modeling and agreement about solution boundaries increases the likelihood of stakeholder satisfaction and project success.
Differentiate Between Product, Solution, and Project Scopes
The word scope is used in different ways and is difficult to define.. Webster's New World College Dictionary says scope is “the extent of the mind's grasp; range of perception or understanding” (1996, p. 1203). Roget's Thesauraus lists “field of view, range, size, meaning” as synonyms. (2001, p. 1149). To help clarify our use of the word “scope,” I recommend using another word as a modifier for scope, such as “product scope,” “solution scope,” or “project scope.” In this paper, I will use the definitions of these terms from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide).
Product Scope: The features and functions that characterize a product, service or result (PMI, 2013a, p 105)
Project Scope: The work performed to deliver a product, service, or result with the specified features and functions (PMI, 2013b, p. 105);
Solution: A set of changes to the current state of the organization that are made in order to enable the organization to meet a business need, solve a problem, or take advantage of an opportunity. (IIBA, 2009, p. 4).
Business Analysis Techniques Can Help with Scoping
Business analysis has many techniques for scoping and analyzing business needs. It involves critical thinking about the current business processes, information, policies, and people involved with the business. When a business analyst is assigned to a new project or initiative, he or she first needs to understand the current environment or “context” within which the business operates and how work is being done. He or she analyzes the stakeholder request, talking with the stakeholders to determine if the requesting stakeholder has identified the root cause of the problem. The business analyst also attempts to assess the cost/benefit analysis of the request quickly. Will the request bring enough value to the business to outweigh the cost of getting it done? When the change seems to be cost justified, the business analyst gets to work identifying solution options and helping the team assess each option and choose the best one. The business analyst considers a number of factors to assess the work, to begin to define a solution scope, and to decide on the best business analysis process to use. Factors such as the number of stakeholders impacted, the complexity of the solution, the number of interfacing organizations and systems, and the involvement of outside organizations all help the business analyst decide how to approach the work and how formally to define deliverables.
The Project Charter
The PMBOK® Guide describes the project charter as the authorizing document for the project. This document is developed by the sponsor or other initiating stakeholder and is often created with the assistance of a business analyst. In some organizations, business analysts work directly for the business area and help identify new projects and develop the business case and charter to get approval. When a business analyst is involved in the development of a charter, he or she may already have started the scoping process as part of the business case and cost justification. If a business analyst has not been involved, the charter's description of the product or solution scope may not have enough detail to define boundaries clearly. Some projects use a scope statement to describe the product scope further. However, a textual description is often not at the right level of detail to prevent scope creep, so many business analysis techniques also inclue a visual component.
Context Diagram
The context diagram is a well-established technique used to develop a clear understanding of a solution or product scope. The context diagram and its associated analysis provide a very structured approach to asking questions that help stakeholders determine the boundaries of their request. The context diagram shows the solution or product as a circle in the center of the diagram. It does not show any detail inside the solution, because these details are not yet known. Instead, it shows the outside forces which will be important for the solution, resting on the idea that if you understand everything that is outside the scope but has an impact on the scope, you, by definition have defined the scope. This is similar to the drawing technique of creating the negative space around the object of focus. By sketching what is not the object, by default you are outlining the object itself.
Exhibit 1 – Drawing the negative space (Devsim, 2008)
Notice how the small xs in Exhibit 1 do not define the plant, yet the plant is clearly seen. By showing the space where the plant is not (the negative space near the plant), you reveal the plant very clearly. The context diagram uses the same principle.
Exhibit 2 – Context diagram
Exhibit 2 shows a context diagram for a new product: mobile app to help home buyers. A home buyer must complete many tasks (and lots of paperwork!) to purchase a home. The goal of this app is to help the buyer navigate all of this work by providing a checklist of items to be done and allowing for alerts and timestamps. As you can see in Exhibit 2, the circle in the center of the diagram is the mobile app, our solution, and there are boxes and arrows on the outside. These boxes or rectangles represent the parties, organizations, or systems with which the new app will interact but which are outside the scope (the negative space). The arrows represent data flows showing information that will flow to and from the app. For example, the app will send information to the buying agent (e.g., the offer), and the buying agent will send information to the app (e.g., response to the offer). As you can see, this is a very simple view of the product scope which quickly reveals important information about the complexity and boundaries of the product.
The Context Diagram Shows Interfaces
The rectangles on the context diagram effectively represent interfaces. An interface is a connection from the product or solution to another party. The interface can be with a person, like the buying agent, or with another system. For example, the app could send information to the buying agent via a text message or an email message. An interface can be automated between two software or with a hardware systems. For example, the mobile app could interface with a home marketing system (e.g., in the US there is a system called MLS, or Multiple Listing Services) so the buyer could view details about the home. This would be an automated interface where the buyer could seamlessly search homes for sale.
Interfaces should be identified during the planning stage of a project to help determine the time and resources needed to complete the project. From a business analysis persective, every interface indicates at least one stakeholder who must be involved (the business analyst will need to plan elicitation sessions), and every data flow represents needed requirements. The requirements may be user interface requirements (e.g., screen design) or data transmission requirements (e.g., sending information to the buying agent). The number of interfaces is an important factor in determing the size and complexity of the project.
The Context Diagram Helps Identify Stakeholders
Making sure you have identified all of the stakeholders for the project is also an important aspect of scoping. Even on a small project, there can be a large number of stakeholders. If you don't know who they are and how many there are, your planning will not be accurate. Stakeholders are people who have a vested interest in the requirements for the solution; for example, end users of the solution, their managers, outside people who govern the solution (e.g., regulators, government agencies), external customers, business partners who are affected by the solution, the entire implementation team (people who will be building, testing and implementing the solution), and with the people who will run and maintain the solution after it is deployed. Missing a stakeholder often means you have missed their requirements, which will appear as scope creep later. In addition, analyzing stakeholders facilitates communication planning. Each stakeholder on your project will require different communications, so you need to plan for each individual uniquely.
Use Case Diagram
Another tool that is very useful for scoping a solution or new product is the use case diagram. This diagram and associated model were invented to support software design and development using an object-oriented approach. Ivar Jacobson is credited with inventing this technique, along with Grady Booch and James Rumbaugh (the “Three Amigos”). Jacobson used the English phrase “use case” from “usage case”—a direct translation of his Swedish term användningsfall. A use case is a goal an actor (user) wants to achieve from software. The use case diagram shows the main use cases within the scope of a project and shows the actors who will interact with these use cases.
Exhibit 3 – Use case diagram
Using the same product example (the mobile app for home buyers), the use case diagram in Exhibit 3 shows the actors as stick figures outside of the main rectangle, which represents the automation boundary of the software. The actors are outside the software but interact with it as indicated by the lines connecting them to the ovals inside. Each oval is a use case which represents a goal of an actor. For example, the buyer wants to review homes for sale from the MLS system so the use case titled, “Review home characteristics” will get information from MLS and present it to the buyer. In this scenario, the primary user is the buyer, so the goals are stated from his or her perspective. The other actors are involved because they need to provide information to the software. Actors can also be used to represent systems or other software with which this software should interface. For example, the app will interface with the MLS system to show the buyer details about homes for sale. Again, the visual is very simple and yet communicates a lot of information about the desired solution and its boundaries.
Deciding on which use cases to be included is a scoping activity. Key stakeholders should work with the business analysts and technical team to discuss the functions they would like to have available. The analysts and technical designers can discuss feasibility and give the users creative ideas for how the software might best meet their needs. This collaborative design allows the technical team to gain insight into the business needs and concerns and allows the business stakeholders to understand which of their requests are difficult and expensive and which are quick and easy. This can help with prioritization and the decisions about moving some items out of scope before the project teams begin planning.
The Use Case Diagram Shows Interfaces
Like the context diagram, the use case diagram shows interfaces with the new software, allowing the business analyst and designer to plan their detailed project work. At every place on the diagram where an association line crosses the automation boundary, an interface is highlighted and detailed requirements need to be created. For example, when the buyer wants to check the status of an offer, what will the screen look like? What buttons will be available? What information will be displayed? This is a user interface. How will the app get information from the MLS system? This is an automated interface which will require technical specifications.
The Use Case Diagram Facilitates Agreements on Role Changes
Another great benefit from using a use case diagram is that it helps the business stakeholders think about how they might change the roles of the people in their organizations. The diagram facilitates this discussion because each actor is shown involved with use cases. If this involvement means a new job function, the people who hold the role of that actor will need to be notified of their job change and possibly trained on the new function. Changing people's jobs can be a significant event and requires good communications and planning. When the team realizes the new solution will change someone's job early in the project, it gives the stakeholders time to think about how they will communicate the change and roll out new job descriptions or employee procedures to coincide with the solution implementation.
In our example, the buyer's agent traditionally phones the buyer to let him or her know whether the offer has been accepted by the seller. Rather than phoning, the new app will require the buyer's agent to input the offer response into the system so the buyer can see it in their app. For some agents, this may be a daunting change. Agents may not feel comfortable with technology and may be fearful about entering important information on their phone. This will probably point out the need for management to make sure that each agent has a mobile device that will work with the new system and provide training and support to the agents as they begin to use the new system. Many questions will need to be answered to make sure the agents are comfortable with this new process: How will I know the buyer got the response? Should I still call the buyer to confirm? What if I don't enter the response correctly? What if the buyer doesn't look at their phone within the acceptance timeframe? These concerns are valid and will be addressed with the agent as the solution is created. These concerns may also lead to improvements in the design of the app as the business analyst and designer better understand the potential issues this change will create. These are very good things to know about during scoping, since the more stakeholder concerns there are, the more time which will be needed to address them.
Product Backlog
A “Wish List” Approach to Scoping
The third scoping technique I want to cover in this article is product backlog. The product backlog is a list of stakeholder requests that are used to scope the product and develop a release plan. Each request is briefly analyzed and estimated at a high level. With this information, the team collaborates to determine the value of each request, along with its impacts and dependencies on other requests. These requests are then prioritized into a development sequence.
Exhibit 4 – Product backlog
The Product Backlog Facilitates Prioritization
The product backlog technique is popular in change-driven approaches to software development because it allows stakeholders to ask for any features they want and to see that their requests are being considered. When the team collaborates to set priorities, each stakeholder learns about other requests and begins to see how his or her request compares to others. When the team estimates the time and cost for each request, it becomes a little easier to agree on priorities. For example, in Exhibit 4, the team has identified the third request as the lowest priority. This list generates conversations with stakeholders about the business value of each request. It effectively facilitates a cost-benefit analysis of each request, allowing them to be compared and prioritized in a very rational, objective way. This technique works well with change-driven projects because the focus is on quick delivery of business value. As high-priority items are completed and delivered, stakeholders are confident their needs will be met as promised. The product backlog also allows for priorities to be changed as the product is developed and the team learns more about how well the solution is supporting the business needs. New requests can be added at any time and are prioritized at the next release planning session. Requests that consistently earn low priority are often dropped by the requesting stakeholder, as he or she sees the request is not as important as the others.
Conclusion
There are many techniques to facilitate a team to agreement about solution scope. These techniques help the business analyst develop specific questions for stakeholders, helping them think about the true business need and best solution for it. Each technique involves a simple, visual representation of the solution scope which can be used throughout the project to prevent scope creep. Spending a little more time getting clear agreement about the solution scope upfront makes project planning much easier and more accurate. It also helps to decrease scope creep and delays during the project execution. Project managers who are not experienced in using these techniques should request the addition of a business analyst to their teams as early as possible. The business analyst can be a strong partner for the project manager during project initiating and planning, and will be a great addition to the team through completion of the project.
