The fi rst substantive part of the project life cycle is the identifi cation of what is needed. That is initiated by the sponsor or the client, and with the help of the client, needs are further described through elicitation of requirements. Requirements defi ne things that a product or service is supposed to do to satisfy the needs of the sponsor or the client and deliver expected business value. A more formal defi nition is given by the International Institute of Business Analysis (IIBA) in “The Guide to the Business Analysis Body of Knowledge”:
“A requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specifi cation, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).”2 That is all well and good and I’m not going to challenge the defi nition. I assume it does what it is supposed to do. But let me offer a different perspective for your consideration and practical application. I believe we execute a complex project to solve a critical problem heretofore unsolved or take advantage of an untapped business opportunity. Two things link the deliverables to the requirements:
■ The need to deliver business value—The more the better
■ Complexity and uncertainty—All of the simple projects have been done Generating acceptable business value is really the only measure of project success. I’ve long felt that the criterion for defi ning project success as meeting a specifi cation within the constraints of time and cost is misdirected. It really ignores the business, the client, and organizational satisfaction. My criterion is that project success is measured by delivering expected business value. Nothing more. After all, isn’t it expected business value that justifi ed the need to do the project in the fi rst place? There are of course some exceptions in the case of mandated and otherwise required projects regardless of whether or not they deliver business value. Here is a working defi nition of a requirement:
2 International Institute of Business Analysis (IIBA). (2009). “The Guide to the Business Analysis
R E Q U I R E M E N T A requirement is a desired end-state whose successful integra- tion into the solution meets one or more needs and delivers specifi c, measurable, and incremental business value to the organization.
Furthermore the set of high-level requirements forms a necessary and suffi cient set for the attainment of incremental business value.
In other words, a requirement describes what a solution must do but not how it must do it. So the requirement is solution independent. Even if a solution is not known, the requirements of that solution can be established. That is criti- cal to complex projects because we may know the requirements but not how to achieve them.
The necessary and suffi cient conditions statement means that all requirements are needed in order to achieve the success criteria and none of the requirements are superfl uous. This is important because the project was justifi ed based on the expected business value as described through the success criteria. Linking requirements to the success criteria provides a basis on which to prioritize requirements.
This defi nition of a requirement is quite different than the IIBA defi nition but in its simplicity and uniqueness it puts the connection between requirements and the project in a much more intuitive light. I have no particular issue with the IIBA defi nition but I believe that a working defi nition linked to business value is a better choice. I will use my defi nition throughout this book.
Requirements will be the causal factors that drive the attainment of the suc- cess criteria as stated in the POS. Every requirement must be directly related to a project success statement. This defi nition results in a small number (8–12, for example) of high-level requirements at the beginning of the project, whereas the IIBA defi nition generates hundreds and even thousands of requirements that can never be considered complete at the beginning of the project. The last time I applied the IIBA defi nition, the client and my team generated over 1,400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made is highly unlikely. Subject to the learning and discovery that may uncover other requirements, the list generated using my high-level requirements defi nition can be considered complete at the beginning of the project. The decomposition of those high-level requirements may not be fully known at the beginning of the project, however. My requirement is a more business-value-oriented defi nition than the IIBA defi nition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposing them to the function, sub-function, process, activity, and feature levels. The fi rst-level decomposition of a requirement is to the functional level and can be considered equivalent to IIBA requirements. So while you can identify all 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.
I’ll have much more to say about requirements elicitation, gathering, decom- position, and completeness in Chapter 4 and in Part III, where you will learn how requirements completeness relates to the choice of the best-fi t PMLC model.
W A R N I N G Linking a single requirement to measurable business value can be diffi cult because the entire set of requirements is necessary and suffi cient to attain the expected business value. They form a dependent set and it may not be possible to ascribe a certain business value to a single requirement. In that case, a prioritization of requirements will be suffi cient.
So you are probably wondering if my defi nition is better than the IIBA defi - nition and whether using it in your organization makes business sense. Here are fi ve reasons that I put forth for you to think and talk about with your team members.
■ Reduces the number of requirements from hundreds to 8–12. I think of requirements at a higher level than most professionals. Using the IIBA defi nition it is unlikely that requirements can be listed completely at the beginning of a project. In fact, most professionals would agree that a complete and documented set of requirements cannot possibly be gener- ated at the beginning of a project. They can only be learned or discovered as part of project execution. That is the approach I take in my Adaptive Project Framework (APF) (See Chapter 12.) On the other hand, using my higher-order defi nition I expect to generate a complete set of require- ments at the beginning of a project. Through experience I have found that my higher-order defi nition gives the client and the project team a more holistic view of the project and enables much better business decisions that impact the solution.
■ Identifying the complete defi nition of most requirements happens only through iteration. The requirements list will be complete using my higher-order defi nition. The challenge arises in identifying the component parts of each requirement—the Requirements Breakdown Structure (RBS): Requirement Functions Sub-functions Processes Activities Features
A simple way of explaining the RBS is that it is a hierarchical list of what must be developed to meet requirements. Many of these details can only be documented during project execution. Chapter 4 discusses the RBS in more detail. Chapter 5 establishes the link between the RBS and the Work Breakdown Structure (WBS).
■ Choosing among alternative solution directions is simplifi ed. Business value is the great tiebreaker when faced with competing alternatives from which choices must be made. I have had experiences where a component part didn’t seem to generate business value early on and so wasn’t included, but at some later iteration the team or client learned that it did and so was included. So “when in doubt, leave it out” is a good practice as you build out the details of a solution. If a component part can contribute business value it will be discovered later in the project.
■ Provides for better use of scarce resources (money, time, and people). Using this higher order defi nition of a requirement there is a return on investment from every part of the solution. The complex project is fi lled with uncertainty and risk and knowing that your approach uses available resources effectively and effi ciently is reassuring to the client and your management.
■ It is a working defi nition. It is directly related to the expected business value that will result from a successful project. These requirements can be prioritized with respect to that business value.
I have always strived for simplicity and intuitiveness in all the tools, templates, and processes that I use. I fi nd that my higher-order defi nition of a requirement meets that goal for me and makes sense too. My clients have validated that for me.
The RBS is the key input to choosing the best-fi t PMLC model. This decision- making process is really quite simple. By working through the process of gen- erating the RBS, you and the client will be able to assess the completeness and confi dence you have in the resulting RBS. If the project is one that you have done several times, you should have a high degree of confi dence that the RBS is complete. This might be the case with repetitive infrastructure projects.
However, don’t be lulled to sleep thinking that the RBS can’t change. Remember, the world doesn’t stand still just because you are managing a project. Change is inevitable during any project, especially complex projects. That change can be internal to the organization and come from the client or even from the team, and it is unpredictable except for the fact that it can happen and you must be able to respond appropriately. Change can also come from some external source such as the market, the competition, or the arrival of some new technological breakthrough. These changes could have no effect, a minimal effect, or a major effect on your project. Again, you must be able to respond appropriately.
Traditional practices require client requirements to be clearly and completely defi ned before any planning can take place. Most contemporary thinkers on the topic would suggest that it is impossible to completely and clearly document requirements at the beginning of any project. Whether you agree or not, that condition is likely to exist in most contemporary projects, and there are many reasons for that:
■ Changing market conditions ■ Actions of competitors ■ Technology advances ■ Client discovery ■ Changing priorities
That is the motivation that resulted in my defi ning requirements as given earlier. In Part III you will consider these situations as well as how the scope change process is handled and its impact on project management processes. In doing that, you will learn alternative project management approaches to handle these diffi cult situations while maintaining a client focus throughout the entire project life cycle.
W A R N I N G You can never know for sure that the RBS is complete. When in doubt, err on the side of concluding that it is not complete. In any case, suppose that a TPM approach seems to be the best-fi t approach initially. If at some point in the project you come to the conclusion that your original choice was not correct and that parts of the solution are indeed not represented in the RBS, you should consider changing your choice to one of the Iterative or Adaptive approaches. Finally, when not even the goal is clearly specifi ed, an Extreme approach will be appropriate. In Part III, you will explore how these decisions are made in much more detail.