Skip to main content

Lean Stage Planning in the Face of an Incomplete Solution: Part 2 – The Requirements Breakdown Structure

Part 1 defined High-level Requirements. In Part 2 we discuss the decomposition of those requirements.

The issue has to do with separating the “WHAT” from the “HOW”. Current practice is to define all requirements as part of project initiation. That has proven impossible except in the simplest of project situations. To reach a so-called complete definition means guessing is allowed. This leads to problems and non-value added work. This is counter to the lean principles. Rather I have proposed a two-step approach. The first step is to identify the high-level requirements. These are the “WHAT” that every acceptable solution must include. They will not change. Part 1 discussed the “WHAT.” The second step is to identify “HOW” these requirements will be met. That is the topic of Part 2. As part of identifying the “HOW” additional lower-level requirements might be identified in order to facilitate identifying the “HOW.” This step is nothing more than the decomposition of the “WHAT”. But by assumption, much of the “HOW” is not known at the outset of the project and must be discovered and learned during iteration (PRINCE2 Stages).

REQUIREMENTS BREAKDOWN STRUCTURE

Requirements have always been a sticking point in the process of deciding how to manage a complex project. There will be those situations where the project has been done several times, and there is a documented history of those efforts. All requirements should be known. At the other extreme are projects that have never been done before or are significant departures from previous projects. These will be high-risk projects and most likely complex too. 

DEFINITION: Requirements Breakdown Structure

The requirements breakdown structure (RBS) is a hierarchical description of all ECPM requirements that must be present in the solution in order to deliver the business value expected. The RBS hierarchical structure may include any or all of the following:

  • Functions
  • Sub-functions
  • Processes
  • Activities
  • Features

Elicitation and Decomposition of ECPM Requirements

In the ECPM Framework, the elicitation of requirements is a two-step process: high-level requirements elicitation followed by requirements decomposition. The first step is to elicit a set of high-level requirements that forms the necessary set of requirements whose inclusion in the solution will assure deliverables that meet expected business value. Regardless of the complexity of the project, this high-level identification of requirements will be complete. These requirements capture what will be in the acceptable solution, but not how they will be developed or even if they can be developed. 

The second step is to decompose the high-level requirements for further description of what each requirement includes. This is done incrementally and is very different from PRINCE2 practices. Much of what is done as part of the initial PRINCE2 project plan is done as part of Stage Planning in the ECPM Framework. The benefit here is to deal with certainty up front and to relegate uncertainty to the Stages. That reduces risk, reduces changes that arise from having made bad guesses during initial planning and preserves the lean characteristics of project execution.  The results of the second step inform the team on how they might manage the project. At this point, however, the decomposed requirements definition is limited to what needs to be part of the acceptable solution, but not how those decomposed requirements will be built and integrated into the acceptable solution. That is delivered through an iterative Stage Planning strategy. There the process of learning and discovery takes place as the solution unfolds over the course of the Stages.

Representing Requirements: The Requirements Breakdown Structure

It is best to think of the Requirements Breakdown Structure (RBS) at two levels. At the highest level is a list of “WHAT” must be in an acceptable solution. At the next level is a hierarchical list of a more detailed description of each Requirement. If you add a third level of decomposition, then the RBS transitions into a Work Breakdown Structure (WBS).  So far, requirements were defined from the perspective of what those requirements have to do. Functions, processes, and activities offer us the details of that definition. Given that understanding, our requirements admit a structure like that shown in Figure 3.1, which was introduced in Part 1 of this article and not repeated here. For those of you familiar with the WBS, you will see that this is quite similar to a functional-based WBS (Wysocki, 2014a). And it is, so nothing is new here. However, what is new is what we are going to do with RBS. The RBS (used in the same way as the Product Breakdown Structure in a PRINCE2 project) will be the basis on which you decide how to structure the project management approach you will use for a project with this type of RBS.

As you gather and document requirements by whatever method you choose, place them in their appropriate level in the RBS. The graphical format used in Figure 3.1 works well. Alternatively, you could present the RBS in an indented outline format. It’s all a matter of preference. 

Here is a brief description of each level in the decomposition shown in Figure 3.1:

  • Solution—The solution is the output from the ECPM Framework STEP1: Develop the Business Case.
  • Requirement—Requirements 1 through n form the necessary and sufficient set that describes an acceptable solution. Usually, this set will contain 6-12 requirements. The “necessary and sufficient condition” statement means that all of the stated ECPM requirements are needed in order to achieve an acceptable solution and the expected success criteria. This is important because the project was justified based on the expected business value, as described through the success criteria. Linking the ECPM requirements to the success criteria provides a basis on which to prioritize not only the ECPM requirements, based on their contribution to expected business value, but also to the prioritization of the functions, sub-functions, processes, activities, and features that define the decomposed requirements.
  • Decomposition Levels – Decomposition of the requirements can occur on different levels: 

Function—At the discretion of the project manager, the highest level of decomposition may be at the function level. This level comprises the functions that must be performed in order for the parent requirement to be acceptable. It is important to understand that the RBS reflects what is known about the solution at the time the RBS is first defined. This initial list of functions may or may not be complete. Neither you nor the client can be expected to know if that list is complete. You might know that it is incomplete, but you would not know that it is complete. How could you? For the sake of generating the RBS, you have to proceed on the basis that the initial list will be complete. If it turns out that it is not, you will discover that as part of doing the project.

Sub-function—At the next level of decomposition are sub-functions. For more expansive functions, you may not have any idea of what those sub-functions might be, and that is okay. In any case, the project team should make every effort to identify the sub-functions that further define a function. Once these sub-functions have been developed, the function they define will now be complete. This is the same as the premise underlying the WBS architecture and is very intuitive. For many complex projects, additional sub-functions will be discovered as part of doing the project.

Process—Complex functions and sub-functions can be further described with the business processes that comprise them. These are the business processes that are commonly used in today’s organizations. 

Activity—Activities define work to be done to deliver a function or sub-function.

Feature—At the lowest level of decomposition are features. These are the visible enhancements and characteristics of the entity that they describe. Think of them as cosmetic (i.e., authentication screen background color) and you won’t be far off.

Note that not all decomposition levels are necessary for every requirement. Some requirements will be more comprehensive than others, and utilize all levels. The simplest requirement might be best described using only a Features list. The decomposition is subjective. There can be more than one valid decomposition. In the final analysis, all that is needed is a decomposition that completely describes each requirement.

The RBS will be useful as an aid in helping decide which strategy is best for the PMLC Model to be followed, in other words, the nature of the project as viewed through its RBS. It is the best guide you will have to choosing the best strategy for managing the project. Furthermore, the RBS is a tool that can be used to make sure the project team members have the same understanding of the solution to be delivered. The client is in their comfort zone, and they can participate in assuring that common understanding too.

If you get the RBS right, you are halfway home. That means we should pay particular attention to what is put into the RBS, and make sure you are not victims of scope creep. We will have enough outside influences to add to scope. We do not need to be party to that now.

Approaches to Requirements Elicitation and Decomposition

Requirements have to be defined through a carefully planned engagement with the client. Of all the requirement gathering approaches, I recommend six that work particularly well within the ECPM Framework world. These are widely used methods for generating requirements. Selection of the best method to generate potential requirements for the project is the responsibility of the project manager. Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. Certain methods have been proven effective for specific industries and products. An example of this would be using physical, three-dimensional wireframe models in product design or solid models in bridge construction.

Requirements elicitation is the first and challenging task that the project manager and client will face in the life of a complex project. To do this effectively is as much an art as it is a science. On the art side of the equation, the project manager will have to prepare the client to engage in the elicitation, decomposition, and documentation process. The attitude, commitment, willingness of the client to be meaningfully involved, and preparation of the client are major determinants in the choice of approach. This preparation will include the choice of approach to be used and perhaps some preliminary training of the client and the core team. Some clients will be open and proactive in participating; others will not. Some will be sure of their needs; others will not. Some will be expressing their wants, which may be very different from their needs.

On the scientific side are the many techniques that have been used successfully to decompose and document requirements. I have had good success using brainstorming, user stories, interviews, facilitated group sessions, prototyping, and requirements workshops. All of these should be in your ECPM/kit (Described in a forthcoming article).

The steps to generate requirements begin by looking at the business function as a whole. This is followed by the selection of a method or methods for eliciting requirements. This effort must be planned. A few of the several approaches to requirements elicitation are listed below. These are ordered from least formal to most formal. These are usually understood or easily adopted in less sophisticated environments. (A good reference on methods for gathering requirements is Robertson and Robertson, 2012.). I have personally used and can recommend the following approaches to Requirements Elicitation:

  • Brainstorming
  • User Stories
  • Interviews
  • Facilitated Group Sessions
  • Prototyping
  • Requirements Workshop
  • Using Iterations to Construct the RBS

At the highest level of abstraction, we will have defined the high-level requirements that form the necessary and sufficient set of requirements that every acceptable solution must contain. We formed that set without regard for how or if we could deliver on those requirements. That is a journey of learning and discovery that occurs during project execution. A future article will discuss the Probative and Integrative Swim Lanes that drive that execution effort. For now our focus is on “HOW” those requirements will be met. That will often involve a more definitive understanding of the “WHAT” that defines that solution. That involves the elicitation and decomposition process discussed above and the six approaches listed to do that. Discovering and documenting the “HOW” is equivalent to experimentation with feasible alternatives. The results of those experiments lead to other experiments and finally convergence on solution components and the Integrative Swim Lanes to integrate those components.

When these iterations are complete, we will have converged on a complete requirements elicitation and documentation. The difference here is that it didn’t happen at the beginning of the project but over the course of executing the project. A learn by doing effort!    

The RBS is the foundation of the Work Breakdown Structure

The transition from the RBS to the Work Breakdown Structure (WBS) is straightforward as shown in Figure 3.2.

 fig 3.2 WBS from RBS

Figure 3.2: From the RBS to the WBS

The lowest level of decomposition in the RBS is the highest level in each part of the WBS. As shown in Figure 3.2 that lowest level in the RBS could be any one of function, sub-function, process, activity or feature.

Just as the RBS evolves through a sequence of Stages so also does the WBS evolve through a sequence of Stages. Underlying this evolution are the Probative and Integrative Swim Lanes discussed in a future article in this series.

PUTTING IT TOGETHER

Requirements elicitation and documentation has been the bane of many complex project teams because either the goal, the solution, or both are not clearly known at the beginning of the project. In the absence of methodologies to handle this lack of clarity, guessing has prevailed, and project success has suffered. The two-level requirements elicitation approach suggested in this article solves that problem, but it doesn’t come without a price. Stage Planning is changed to accommodate both Probative and Integrative Swim Lanes. The Change Management Process is also changed. Changes are bundled, and decisions on their acceptance and integration are handled as a group during the Client Checkpoint. The Bundled Change Management Process is discussed in a future article.  

REFERENCES

International Institute of Business Analysis, (2015). The Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3.0, IIBA.

Robertson, Suzanne and James Robertson. (2012). Mastering the Requirements Process, 3rd Edition, Boston, MA: Addison-Wesley Professional.

Wysocki, Robert K. (2014). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.

Comments (4)