A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by  

It is widely accepted that the elicitation of complete requirements during project ideation is very unlikely except in the simplest of projects. There are a number of internal and external factors that affect the solution and its clarity that often change during the project life span that accounts for this. The environment is dynamic. It doesn’t stand still just because you are managing a project! These factors create process challenges that can be mitigated by a simple change in the definition we use for a requirement. This simple change of definition simplifies many of the project management process problems and improves the likelihood of delivering the expected business value.


As part of the Ideation Phase of a complex project we can define 
“WHAT” an acceptable solution has to contain and the business 
value it is expected to generate.

At the start of a complex project we may “NOT KNOW HOW” to 
achieve an acceptable solution.

The resulting incompleteness is a logical consequence of the 
Plan-driven definition of a requirement. That incompleteness can 
be removed by using a Change-driven definition of a requirement.

Using a Change-driven definition of requirements implies that an
iterative project management approach will be required.

Most project management processes use a Plan-driven definition of requirements. That will not work in the contemporary complex project landscape. This article introduces a Change-driven definition of requirements. That simple change eliminates the obstacle.


To a certain extent we have become trapped by our own view of requirements and their elicitation. The IIBA definition may fulfill its objectives but at what price? The IIBA definition of requirement is a Plan-driven definition and it tries to define both the “what” and the “how”. In independent projects that works. But in complex projects that seldom works. The Effective Complex Project Management (ECPM) definition of requirements proposed below is a Change-driven definition. It focuses only on the “what”. The “how” is developed within the Work Breakdown Structure (WBS) and the project execution phase.


The IIBA definition is all well and good and I’m not going to challenge it. I assume it accomplishes what its creators envisioned. But let me offer a different perspective for your consideration. I believe we execute projects to solve critical problems or exploit untapped business opportunities with the ultimate goal of generating business value.

The need to deliver business value

Using cost, time and scope as the variables for measuring project success misses the point of doing a project. The success of a project is measured by the achievement of business value – the more the better. The total cost of the project is measured against the business value generated to calculate Return on Investment (ROI) and compare against other projects competing for the same resource pool.

Complexity and uncertainty

The IIBA definition of requirements is a one step Plan-driven definition. That gives rise to incomplete requirements except in the simplest of situations. The definition of an ECPM requirement given below is a two step Change-Driven definition. In the first step the requirements definition focuses on the “what”. At this level requirements are complete. Think of them as defining an ideal end state. With requirement defined the focus of the solution turns to the second step – the “how”.


An ECPM requirement defines a component of the desired
end state and when integrated into the solution meets one
or more business needs and delivers specific, measurable
and incremental business value to the client business unit.

The set of ECPM requirements forms the necessary and
sufficient set needed to establish the desired end state and
attain the planned business value.

Adapted from: Wysocki, Robert K, (September, 2014), “Effective Complex
Project Management: An Adaptive Agile Framework for
Delivering Business Value”, J. Ross Publishers

“How” is usually not known at the outset of the complex project. It can only be discovered through successive learning and discovery iterations that build upon a solution that is converging to the desired end state. So at the start of the complex project the definition of “how” is incomplete. Very little of the solution might be known at the outset or most of the solution known with only a few details missing but the solution is not completely known at the outset. So the “how” is the second step of the ECPM requirements definition and its discovery is imbedded in the Work Breakdown Structure (WBS).

The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the planned business value 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 in the Project Overview Statement (POS). Linking requirements to the success criteria provides a basis on which to prioritize requirements.

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 business value in a much more intuitive light. I have no particular issue with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use the ECPM definition throughout this article.

An example of an ECPM Requirement
from a project to establish a
Workforce and Business Development Center

A Business Incubation Center (BIC) (Figure 1) to support the needs of students, workers, entrepreneurs and local businesses for career and professional development and business growth.

rwysocki July30
Figure 1: The Business Incubation Center (BIC)

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 one or more project success criteria stated in the POS. This definition results in a small number (less than 12 for example) of high level 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 last time I applied the IIBA definition resulted in my client and team generating over 1400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made in that example is highly unlikely. 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. 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 requirements through decomposing them 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 but in ECPM parlance it is no longer a requirement. It is a function that must be present as a condition of achieving the requirement. So while you can identify all requirements at the beginning of the project you cannot describe the details of the requirements at the functional, process, activity and feature levels. This detail is learned and discovered in the context of the cycles that make up the project.


  • Framed in the language of the client
  • Relate directly to the generation of business value
  • Helps create and maintain client ownership and meaningful involvement
  • Integrates all of the steps that define effective complex project management
  • Reduces the number of requirements from hundreds to less than 12.
  • Become the basis for solution development
  • Related directly to project success criteria


Current definitions of requirements include both the “what” and the “how.” This leads to incomplete requirements specification for every project except the simplest. The result is confusion and problems associated with the execution of the chosen complex project management process. The ECPM Requirements definition focuses on the “what” and with few exceptions will be complete. Choosing the best fit complex project management process becomes a well-defined decision. The “how” is identified incrementally through a Work Breakdown Structure (WBS) derived from the set of requirements.

Deploying this ECPM Requirements definition across the project life span introduces changes to the project management process that have every reason to significantly improve project performance and reduce the risk of project failure. The discussion of those changes is beyond the scope of this article.

Bob has over 45 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author and public speaker. He has written 24 books on project management and business analysis. His materials are used in over 350 colleges and universities worldwide.

Article source: http://feedproxy.google.com/~r/BusinessAnalystTimes-BusinessAnalysisHome/~3/NrtBBnNFkaA/a-fresh-look-at-requirements-and-requirements-elicitation-in-complex-projects.html


Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *