Requirements define things that a product or service is supposed to do to satisfy the needs of the client and deliver expected business value. A more formal definition is given by the International Institute of Business Analysis (IIBA) in “A 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, specification, or other formally imposed documents.
A documented representation of a condition or capability as in (1) or (2).”
That is all well and good and I'm not going to challenge the definition. 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:
Generating business value is really the only measure of project success. I've long felt that the criterion for defining project success as meeting a specification 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 justified the need to do the project in the first 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.
A requirement is a desired end-state whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization.
Furthermore the set of requirements forms a necessary and sufficient set for the attainment of incremental business value.
The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the success criteria and none of the requirements are superfluous. This is important because the project was justified 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 not only the 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 requirements decomposition.
This definition of a requirement is quite different than the IIBA definition 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 concern with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use my definition throughout this book.
Requirements will be the causal factors that drive the attainment of the success criteria as stated in the POS. Every requirement must be directly related to a project success statement. This definition results in a small number (8–12) of requirements at the beginning of the project, whereas the IIBA definition generates hundreds and even thousands of requirements which can never be considered complete at the beginning of the project. 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 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. My requirement is a more business-value-oriented definition than the IIBA definition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposition to the function, sub-function, process, activity, and feature levels. The first-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 believe that this 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 requirements where no similar case can be made for prioritizing IIBA requirements. I'll have much more to say about requirements elicitation, gathering, decomposition, and completeness in Chapter 4 and in Part II where you will learn how requirements completeness relates to the choice of best-fit PMLC model.
Linking requirements to measurable business value can be difficult because the entire set of requirements is necessary and sufficient to attain 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 sufficient.
So you are probably wondering if my definition is better than the IIBA definition and whether using it in your organization makes business sense. Here are six reasons that I put forth for you to think and talk about with your team.
These details can only be documented as part of project execution. The criterion for inclusion in the solution is that the component part must either directly contribute business value or support a higher order component part that does contribute business value. This tends to eliminate frivolous additions to the solution that have no obvious business value. Chapter 4 discusses the RBS in more detail. Chapter 5 establishes the link between the RBS and the Work Breakdown Structure (WBS). Basically the RBS documents what must be done to deliver a complete solution and the WBS documents how it will be done, so that using my definition of requirements we establish a strong connection between the work of the project and the delivery of business value.
I have always strived for simplicity and intuitiveness in all the tools, templates, and processes that I use. I find that my higher order definition of a requirement meets that goal for me and makes sense too.
The RBS is the key input to choosing the best-fit PMLC model. This decision-making process is really quite simple. By working through the process of generating the RBS, you and the client will be able to assess the completeness and confidence you have in the resulting RBS. If the project is one that you have done several times, you should have a high degree of confidence 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. 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 defined 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:
That is the motivation that resulted in my defining requirements as given earlier. In Part II 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 difficult situations while maintaining a client focus throughout the entire project life cycle.
The market is different today than it was 30 years ago. The PC is about 30 years old, and look at the impact it has had. Social networking is very new and its impact yet to be defined. Technology has been the prime mover to these market changes. Leveraging technology to get to market as fast as possible must now be the strategy. Leveraging technology to get the most innovative product or service to market before the competition gets there must also be the strategy. Leveraging technology to create barriers to entry is critical to every successful strategy. Project management is the only enabler of those strategies. It must provide approaches that support high change, speed, and increasing complexity. The old ways had to strain to keep up with the realities of projects such as these. It's no wonder that a reported 70+ percent of projects fail. That has to stop. Project managers need approaches that are built around the expectation of change — ones that embrace learning and discovery throughout all of the project life cycle. These approaches must have built-in processes to integrate the changes that result from this learning and discovery.
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-fit 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 specified, an Extreme approach will be appropriate. In Part II, I explore how these decisions are made in much more detail.
18.223.205.163