Lean Stage Planning in the Face of an Incomplete Solution

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.