SPONSORS

SPONSORS

Requirements Management and Project Lifecycle

 

FEATURED PAPER

By Pascal Bohulu Mabelo

South Africa


Abstract

It is widely accepted that “Project Management is the application of knowledge, skills, [attitudes,] tools, and techniques to project activities in order to meet project requirements” (PMBoK, 2013).  The ‘application’ is not merely in doing project works, but aims to “meet project requirements.”
This simple definition suggests that no project delivery would make sense until requirements are defined, documented, and agreed upon—and effectively implemented, especially in megaprojects.

A recurring challenge is that many experienced project managers caution against mentioning the term ‘requirements’ to clients, fearing it might complicate the project from the outset. This concern is compounded by the fact that project lifecycle methodologies typically expect the client to furnish a project brief in the form of ‘Owner’s Requirements Specifications’ or ‘Project Requirements.’ However, some organisations may lack the capability or willingness to define and take ownership of such requirements. It soon turns into, “Tell us what requirements must be—for you are the experts!” The danger with this scenario is quite pernicious. Not only could the owner be handing out a blank cheque to the appointed team, but they are also being set up to deliver something the client will be quick to denounce and reject, saying, “This is not what we asked for; you have done your own thing!”

In the rare instances where clients provide ‘copy-and-paste’ requirements—adapted from previous projects—these may introduce confusion rather than clarity. Such inherited requirements frequently fail to align with the project’s unique context, diverging unpredictably at the client’s discretion instead of honing in on a coherent and elaborate baseline as the project evolves—from generic, high-level to detailed requirements. Still, successful projects must meet requirements and client’s needs!

Necessity of Project Requirements

Many project managers tend to approach delivery linearly: (1) collect requirements, (2) define the scope, and (3) develop the Work Breakdown Structure (WBS), assuming the subsequent steps will naturally follow. However, understanding the essence of ‘requirements,’ including their sources, timing, and relevance (i.e., the why, what, who, where, when, and how of project requirements), is far from straightforward and calls for a more nuanced approach. Any missteps in identifying and managing requirements will trigger a ripple effect and compromise the system development process.

Systems Engineering (SE) is “[…] an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining Acquirer needs and required functionality early in the development cycle, documenting requirements, and then proceeding […]” (INCOSE, 2015) [Underlining added for emphasis]. In short, project management relies on elicited and documented requirements for the “realisation of successful systems.” Indeed, as the PMBoK equally maintains:

“Project Management is the application of knowledge, skills, [attitudes,] tools, and techniques to project activities in order to meet project requirements.” (PMBoK, 2013) [Underlining added]

Therefore, a project is “successful” only if the stakeholders’ requirements are met and attained within the stated cost, time, and quality constraints—it is about meeting project requirements! Robert Buttrick eloquently captures the significance of requirements in his definition of a project:

“An endeavour in which human, material and financial resources are organised, in a novel way, to undertake a unique scope of work, of a given specification [i.e., set of requirements], within the constraints of cost and time, so as to achieve a beneficial change defined by quantitative and qualitative objectives.” (Buttrick, 2003) [Underlining added for emphasis]

Consequently, if a team fails to manage requirements, their project will fail to meet requirements
—it will flounder and fail. The author has compared the causes of project failure per the Chaos Report. Not only do these causes remain almost the same during the 1994 to 2009 period, but at least half of those reasons (in numbers and percentages) pertain to project requirements as follows:

More…

To read entire paper, click here

How to cite this paper: Mabelo, P. B. (2025). Requirements Management and Project Lifecycle; featured paper, PM World Journal, Vol. XIV, Issue II, February. Available online at https://pmworldlibrary.net/wp-content/uploads/2025/01/pmwj149-Feb2025-Mabelo-Requirement-Management-and-Project-Lifecycle.pdf


About the Author


Pascal Bohulu Mabelo

Johannesburg, South Africa

 

Pascal Bohulu Mabelo (MBA, MSc Industrial, BSc Civil, Pr. Eng, Pr. CPM, Pr. PMSA, PMP), has more than 25 years of professional experience and possesses a wide range of technical and managerial skills in large and complex infrastructure projects. He has worked on large infrastructure projects as a design engineer, project/programme manager, project consultant and project management executive. Pascal was honoured to serve as the national chairman of Project Management South Africa (PMSA), the leading Project Management professional association in Southern Africa.

Pascal has published the book: “Managing Engineering Processes in Large Infrastructure Projects” (Cambridge, 2021); he has also published, “How to Manage Project Stakeholders—Effective Strategies for Large Infrastructure Projects” (Routledge, 2020) and “Operational Readiness—How to Achieve Successful System Deployment” (Routledge, 2020). Through various publications, journal articles, and conference presentations, he assiduously promotes the application of Systems Thinking and/or Systems Engineering principles, concepts, and practices to unravel complexity in Large Infrastructure Projects (LIPs) to address their persistent risks of failure and their massive, even pernicious, cost and schedule overruns.

Pascal is currently a Director and Principal Consultant at E 6 Project Consulting or E6PC; for comments, further information, and clarifications he may be contacted at Consult@e6pc.com.

His other papers can be viewed at https://pmworldlibrary.net/authors/pascal-bohulu-mabelo/