Work Scope and Product Scope: Why Both?

This second article in the series is a discussion of the necessity to separate work scope and product scope and be able to work on them in parallel. In future articles in this series we will look at how to discover and communicate the detailed requirements and how to trace them through the life of the product.

Scope and Requirements

Let’s suppose for the moment that you are a detective investigating a crime. At the start of your investigation you do not know precisely where you will need to go, or whom you will need to talk to, in order to come up with the right answers to your questions. So you spend a little time putting together all the information available at the time, and you make a plan to guide the remainder of the investigation. This making of a plan is very like what the requirements specialist does at the start of a requirements investigation.

The scope of the requirements investigation identifies the parts of the work/business/problem that need to be studied in order to discover the relevant requirements.  This scope of investigation is referred to as the scope of the work; it identifies where you might look, what you might look at and whom you will need to talk to in order to understand the real business/work problem, and from that discover and invent requirements for the solution.

As soon as you have a basic understanding of the business requirements then you can concern yourself with another scope, the scope of the product. The scope of the product identifies the boundaries of the solution (usually a software-hardware implementation) to support or improve the business.  The scope of the product is dependent on which of the business requirements can be met within the budget, time and technological constraints of your project.

A question we are often asked is: should I come up with a suggested product scope before I know the precise scope of the work? This is rather like asking: should the detective come up with ideas for who committed the crime before he has talked to all the witnesses. The detective keeps track of all ideas for the solution of the crime until he eventually knows enough to be able to solve it.

Similarly, a convenient approach for the business analyst is to develop the work scope and the product scope in parallel. You investigate the work scope in as much detail as is necessary for you to have ideas and eventually make concrete decisions about the scope of the product. You communicate the detailed scope of your product by defining and communicating those requirements that will be satisfied by your solution to the business problem.

Scope of Work

The scope of the work identifies the boundaries of the part of the world (usually a part of your client’s enterprise) that you need to investigate in order to understand the business problem. A banking project would likely include selected banking rules, bank customers, existing technology, the way that the bank is organised, and so on. A project to build a new phone network would likely include behaviour of phone users, existing networks, phone technology, etc. If you are working on requirements for a new way of selling train tickets then likely you would include train travellers, stations, station staff, current and proposed ticket prices and anything else that helps you to understand the work surrounding to the problem you are trying to understand.

However, in order to arrive at the requirements that are specific to your project, the scope of the work needs to be more precisely defined. A way of doing this is to build some kind of a model that identifies what is inside and what is outside the scope of your investigation.  The most convenient way we have found of doing this is to build a work context model.

Figure 1 is an example of a work context model for a project concerned with the work of managing loans of library books.

Figure 1: This work context model identifies the scope of the business analysis investigation by declaring the inputs and outputs. This is a high-level statement of the business requirements.  

The model identifies all the data and relevant material that is coming into the work and the all the data/material that is output by the work. The work boundary in this case is the circumference of the centre circle. Your investigation now covers the processing and stored data that is triggered by the input data flows arriving at the work boundary. The investigation also covers everything that the work does in order to produce its outputs. The squares around the outside identify adjacent systems (other pieces of work) that originate or receive data.

For example, in figure 1, we can see that the Borrower sends a Loan Extension Request to the work of managing library loans. If we looked inside the work we would find the details of what the librarian does and the business rules he carries out in order to respond to that request. So the work context model simply defines the edges of the investigation. When the analyst learns the precise details of each one of the inputs and outputs then he defines them in the dictionary of terms and definitions (see section 5 in the Volere template). This progressive definition of inputs and outputs is a nifty way of capturing many of the functional requirements.

For example:

When doing the detailed investigation of the work the analyst often discovers additional inputs and outputs or changes to the ones already declared on the work context diagram. When that happens (providing the change is judged relevant to the project’s goal) the analyst changes the work context diagram to reflect the scope of the work that is being investigated.

By studying the business inside the work context the analyst focuses on the business problem so that he can:

• Understand the business rules and business processes
• Identify which parts of the work need most investigation
• Identify potential improvements in the way the work is done
• Define the business requirements that could/should be carried out by the new/changed product.

The larger the scope of the work the more necessary it is to have traceable techniques for partitioning the investigation into pieces. We will cover these techniques in future articles in this series.

Now we will look at an example of the product scope for the library project

Scope of Product

The scope of the product identifies the boundaries of the solution. In most cases these boundaries are the interfaces between people and the software to be built or interfaces between other products and software.

The decision on the product scope is concerned with determining which of the business requirements (bearing in mind the constraints) could be carried out the by solution. In order to define the scope of the product the business analyst needs help from a number of other stakeholders. In particular technical stakeholders who understand the current technology, the technological constraints and the technological opportunities, have the knowledge necessary to come up with the best possible product scope. The business analyst also needs input from business stakeholders to make choices between possible product scopes.

Figure 2: This example of a product scope diagram for the library loan management product identifies the interfaces between the product that will be built and the people, organisations and other software systems. 

The product scope diagram in Figure 2 defines a possible product scope for the library loan management product. The business analyst and other stakeholders arrive at the product scope by allocating some of the business requirements, ideally those that will deliver the highest business benefit, to the product.  

Whose responsibility is it to define the product scope? The answer depends on how you have allocated responsibilities in your organisation. It helps to think about the determination of product scope as a design activity that brings together the business problem, the project goals, the constraints, and the technological possibilities. There is no one person who will have a detailed knowledge of all these things so it makes sense to involve different specialists when exploring and deciding on product scope.

Parallel thinking

The aim of any project is to arrive at a valuable solution, as fast as possible within the project’s constraints. Naturally everybody wants to identify the scope of the product and to build it as quickly as possible. But in order to build a suitable product one firstly has to understand the work it is intended to support.

How much time do we need to spend on investigating the work before we can set the product scope and go ahead with building the product? The answer to this question is it depends on how much is already known and defined about the work. The best way to avoid the extremes of over-investigation, or jumping straight to the solution before understanding the problem, is to consider work scope and product scope in parallel. For example you might decide to test your knowledge of the work scope by building a prototype of a possible product. This in turn helps you to decide which aspects of the business requirements need further investigation and which ones are already well enough understood to make product-related decisions.

Figure 3: Investigate work scope and product scope in parallel. Both are necessary in order to understand the problem and design the best solution. 

If you develop the skill of investigating work scope and product scope in parallel you:

• have a better understanding of the business problem
• quickly find alternative solutions
• discover the real requirements rather than solutions disguised as requirements
• are free to work in the order that is most suitable for your project

In future articles in this series we will look at how to discover and communicate the detailed requirements and how to trace them through the life of the product.