Author: Robert Wysocki

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.

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.

Using the ECPM High-level Requirements Definition

PART 1: High-level Requirements Definition

Project management thought leaders are of like mind in that a complete description of requirements is unlikely during project initiation. Beyond the complexity and uncertainty the project is affected by the changing internal environment and external market dynamics. Managing a complex project using PRINCE2 is, of course, complex by definition, but the challenge is further increased due to incomplete requirements (similar to the PRINCE2 Project Product Description). The situation is not hopeless, and there are mitigation strategies that are available in the ECPM Framework during the Project IDEATION Phase and these are easily incorporated into the PRINCE2 Process.

This article puts forth a new definition of requirements (PRINCE2 uses the terms Project Product Description and Product Breakdown Structure) that eliminates the problem of incomplete requirements at Project Initiation. The definitional change is simple and paves the way for fully engaging the Client in Requirements Elicitation.

PRINCE2 recognizes requirements under the term specifications but does not provide any details. However the PRINCE2 Framework should include an understanding of how requirements are defined, elicited and implemented in the life span of a complex project. Having this understanding is a valuable addition to the PRINCE2 practitioner and professional as they accommodate the uncertainties and complexities of contemporary projects. 

DEFINITION OF ECPM REQUIREMENTS

An ECPM requirement is an end-state condition whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization.

The set of ECPM requirements is a necessary and sufficient set for the attainment of all project success criteria including the delivery of the expected business value.

This definition postpones the challenges associated with incomplete requirements and moves them to later in the project.

Requirements define the properties and characteristics of the product, process, or service that is the deliverable of the project. These requirements are the basis for analyzing the effect of any changes to a current situation that your client is seeking. A requirement exists either because the product, process, or service demands certain functions or qualities not present in the current solution. Project requirements start with what the customer really needs, and end when those needs are satisfied. (Note that I am saying “needs,” not “wants.”) This often leads to nonessential or over-specified requirements or some other anomaly. You are cautioned to be very careful about assuming who knows what and who understands what. Double check that the client understands every STEP of the way.

What your client wants may not be what your client needs. As project manager your job is to make sure that what they want is what they need and that you will deliver what they need.

This definition of an ECPM requirement is quite different from the IIBA definition of a requirement, but in its simplicity and uniqueness puts the connection between requirements and the project in a much more intuitive light. ECPM requirements will be the causal factors that drive the attainment of the success criteria, as stated in the POS. Every ECPM requirement should be directly related to one or more project success criteria. This definition results in a small number (8-12) of requirements at the beginning of the project, whereas the IIBA definition generates hundreds of requirements, which can never be considered a complete set at the beginning of the project. The mind could not grasp completeness, anyway.

Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM requirements definition can be considered complete at the beginning of the project. The decomposition of those requirements is not fully known at the beginning of the project, however. An ECPM requirement is a more business value-oriented definition than the IIBA definition.

The learning and discovery derived from completed project cycles will clarify the ECPM requirements through decomposition to the function, sub-function, process, activity, and feature levels. The first level decomposition of an ECPM requirement is to the functional level, and can be considered equivalent to IIBA requirements. So, while you can identify all ECPM requirements at the beginning of the project, you cannot describe the details of the requirements at the functional, sub-functional, process, activity, and feature levels. This detail is learned and discovered in the context of the cycles that make up the project. This two-STEP process for Requirements Elicitation is consistent with the Lean Principles (Poppendieck and Poppendieck, 2003), too.

The ECPM definition of requirements should be preferred to the IIBA definition because it ties requirements directly to the project success criteria, which is not the case with the IIBA definition. That makes it possible to prioritize ECPM requirements, whereas no similar case can be made for prioritizing IIBA requirements. In an IIBA, setting priorities is more of a technical assessment than a business assessment.

The choice of a single project to propose can be made based on the high-level requirements. Since the requirements describe an acceptable solution, the decision can be driven by the degree of fit between a proposed project and the effectiveness it will have in producing deliverables that satisfy the requirements. Reaching this decision is subjective—not objective.

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 world. These are widely used methods for generating requirements. It is usually the case where more than one method is chosen to generate the requirements on a project. Selection of the best methods to generate potential requirements for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation, reliability, client comfort level with the chosen process, and risks. 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.

It is important to realize that requirements identification and decomposition are critical to understanding the direction of the project. It is now that the framework for the project begins to take shape.

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 gathering 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

These are listed in the order of least formal to most formal. I single out these six methods because they work best when trying to translate business requirements into business deliverables. Across the entire history of the ECPM, I have had the most experience and success with these methods. These methods can also be used to decompose requirements and generate the RBS. Regardless of the method you use to generate the RBS, I strongly advise creating an RBS for every project for the following reasons:

• The RBS is most meaningful to the client.
• The RBS is a deliverables-based approach.
• The RBS is consistent with the PMBOK.
• The RBS remains client-facing as long as possible.
• The RBS is the higher order part of the WBS.

Choosing a Requirements Elicitation Approach

There are several things to take into consideration when deciding which approach to take:

• The experience of the client team—If the client team has memorable and effective experience with any of the requirements gathering approaches, try to select from among them. To the most extent possible, you should put the client in their comfort zone so that they can focus on the work of defining requirements.
• The experience of the development team—If the development team has memorable and effective experience with any of the requirements gathering approaches, try to select from among them. Given the choice of two or more approaches, choose the one that favors the client.
• The complexity and nature of the project—The more complex the project, the more you would want to use approaches that give detailed information and are less likely to overlook anything. A formal process should be preferred to an informal process.
• The experience of the session facilitator—First of all, the session facilitator should not be a member of the client team or the development team. This may come as a surprise, but there are good reasons to back it up. The facilitator’s job is so critical that you need someone with experience and with no bias toward the project. Their job is to facilitate, not politic. The client team leader and the development team leader need to focus their attention on the deliverables from the requirements gathering exercise, not on the process of getting them, and so they are not good choices. If there is no one internal to the organization that meets the criteria, hire an outside consultant. This is no place to cut expenses. The more critical and complex the project, the more you should favor the use of an outside facilitator.

Elicitation and Document Requirements

Complete and clear document requirements at the beginning of a project have never really happened. It just isn’t possible, except in the simplest of projects. (Infrastructure projects are an example because they tend to be isolated from the outside world.) A few “cowboys” would claim to have done so, and launched into project planning under the assumption of having a complete requirements document. Later, to their dismay, they are deluged with scope change requests from the client: “What happened? I thought we had all of this nailed. You told us you were satisfied and that we had done an exemplary job of gathering and documenting your requirements.” The problem is not with the process. The problem is not with the initial documentation. The problem is that the world is not a static place. It never has been and never will be. So, why should you expect your requirements document to stand still while you do the project? Change is inevitable, regardless of how well we did at the outset. There must be better ways. And there are!

The RBS is the major input to help you make the decision as to which category of project you have, and which PMLC model would be most appropriate for managing the project. I will show how the RBS can be used to help the project team decide which strategy, among the five major project management categories, should be chosen and under what circumstances you should use each one. The strategy that you choose then becomes the infrastructure on which you will choose a project management model and build your project plan. The status of the RBS relative to its completeness can be used as the measure of progress towards the solution.

The completeness and clarity of the RBS present you with two critical decisions as to which of five major directions to go (linear, incremental, iterative, adaptive, or extreme). Within that choice is which specific PMLC model will be used. In this book, the chosen direction is down the adaptive road, the ECPM road. As you will see, these decisions are not obvious. While there is some objectivity involved, the decision process leans heavily towards the subjective side.

I advise creating an RBS for every project because:

• The RBS is most meaningful to the customer.
• The RBS promotes customer ownership and eventual buy-in of the solution.
• The RBS is a deliverables-based approach and in the customer’s comfort zone.  The RBS can be used to measure progress towards solution definition.
• The RBS can be used to measure project status.
• The RBS is consistent with the PMI® PMBOK.
• The RBS remains customer-facing as long as possible into the planning exercise.

If you happen to know the complete RBS, you are in good shape but if you don’t, you have a problem. In complex projects, an incomplete RBS is the rule rather than the exception. It would be unusual to have a complete RBS at the start of a complex project. Some functions and features may not be known, and their absence may not be known at this early stage, either. Being able to say that the RBS is complete is based more on a feeling than on hard fact. The ECPM is designed to learn and discover the complete RBS, and hence the solution, through iteration.

Conventional wisdom says that a complete Requirements Breakdown Structure is not possible at the start of a complex project, but can only be defined through an iterative process. There may be exceptions for projects that are often repeated.

So far, we have defined requirements from the perspective of what those requirements have to do. Functions and features offer us the details of that definition. Given that understanding, our requirements admit a structure much like that shown in Figure 3.1. For those of you familiar with the WBS, you will see that this is quite similar to a functional-based WBS. It 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 (the reference here is to complexity, completeness, and uncertainty of the RBS for the project at hand).

Figure 3.1 Requirements Breakdown Structure

PUTTING IT TOGETHER

Requirements Elicitation is the heart of any effective complex project management approach. Change is inevitable and the project environment dynamic. It can change at any time and in unexpected ways and it directly impacts requirements. The only steady state in all of this change is the Business Case that initially was the justification for authorizing the project. The alignment to that and the expectation of the validating business value being realized is the justification for continuing or modifying the project.

To the extent possible the requirements infrastructure must be such that it brings as much stability to the project as is possible. The definition of requirements as provided by the ECPM Framework delivers that stability. The iterative definition of the RBS is the enabling tool.

REFERENCES

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

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