What Are Requirements — Really?

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:

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:

• The need to deliver business value — The more the better
• Complexity and uncertainty — All of the simple projects have been done

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.

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.

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.

• Reduces the number of requirements from dozens to six or eight. I think of requirements at a higher level than most professionals. Using the IIBA definition it is unlikely that requirements can be complete at the beginning of a project. In fact, most professionals would agree that a complete and documented set of requirements cannot possibly be generated 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). On the other hand, using my higher order definition I expect to generate a complete set of requirements at the beginning of a project. Through experience I have found that my higher order definition 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 definition of most requirements happens only through iteration. The requirements list will be complete using my higher order definition. The challenge arises in identifying the component parts of each requirement — the Requirements Breakdown Structure (RBS):

   

  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.

• Simplifies the search for a solution with acceptable business value. If you are emotionally attached to some component part of the solution and cannot demonstrate that it contributes to business value, don't expect to see it in the solution. That eliminates the expenditure of time, money, and resources on something that adds no business value to the solution.
• Choosing among alternative solution directions is simplified. Business value is the great tie breaker 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 definition of a requirement there is a return on investment from every part of the solution. The complex project is filled with uncertainty and risk and knowing that your approach uses available resources effectively and efficiently is reassuring to the client and your management.
• It is a working definition. 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, which is not possible with the IIBA definition.

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:

• Changing market conditions
• Actions of competitors
• Technology advances
• Client discovery
• Changing priorities

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.