Is “requirements” a project management process?

This is another post from the NewGrange listserve … I made a comment that I didn’t think “requirements” should be included as a project management process in “A Guide to the Project Management Body of Knowledge.” One person replied as follows:

Surely some level of requirements analysis is required in order to ensure that the objectives are stated in such a way that they can be met.

I argued that there were several weaknesses in this position … my post follows.

First and most significant weakness … it doesn’t comply with the definitions:

• Project management processes are concerned with describing and organizing the work of the project.
• Product-oriented processes are concerned with specifying and creating the project product.

Requirements does not fit the first. It does fit the second. There is an inconsistency that is neither explained nor justified.

Second and almost equally significant weakness … it [“A Guide to the Project Management Body of Knowledge”] says that each process repeats in each phase of the project life-cycle. So you now have “requirements” being repeated in the design phase, the development phase, the turnover phase, and in however many phases your project life-cycle has. Just how does that work?

You could argue that the requirements need to be reconfirmed or tested in each phase, but the same is true for many other aspects of the product of the project. To be sure, any construction team is going to spend time verifying the design before it begins work, and the fundamental purpose of many turnover/transition phases is to verify that the outputs of the development or construction phase are accurate and correct, so why limit the iteration to requirements?

Third weakness … if the link between the customer and the project manager is the requirements, how do they interface during the later phases such as design and development? The team’s understanding of what has to be done can change without the requirement changing. The whole idea behind the project life-cycle is to generate additional detail about what has to be done. That requires constant communication with the customer. Again, how and why are requirements special?

Fourth weakness … how do you handle something like a construction project? There are no requirements: there is a detailed specification. If you argue that those specifications are the requirements for that project, then your argument that requirements are an early version of the design with special status is no longer valid.

Fifth weakness … how are design and development “entirely part of the product world”? Are you saying that the project manager isn’t responsible for planning and managing the design work? Isn’t responsible for planning and managing the development work? Wow. How is the project manager’s responsibility for requirements any different than their responsibility for other product-oriented deliverables?

Sixth weakness … it would appear that there is no longer any need for a requirements phase in anyone’s project life-cycle since that work is now part of the project management process. So all of a sudden, there is a set of project management processes that is performed in the absence of any technical phase. This just wreaks havoc with pretty much everything else in the document.

The advocate for including requirements did not offer any counterarguments.

Once again on the Project Life-Cycle

This is from an exchange on the NewGrange listserve …

When phases are called “initiating, planning, executing, and closing,” how do you know where to do requirements, design, development, testing, and turnover? If you are going to do requirements as part of initiating, why not call it that? How can you possibly plan for the development activities when you don’t even have a design in place yet? Why have a planning phase when you know that most of the planning will not be done as part of that phas

These terms only work as “phase” names when you are actually dealing with a single phase. For example, they work fine for the construction phase of a real estate development project, or for the coding and testing phase of a software development project. But they don’t work when you try to use them for a development project that’s starts with a problem statemen

In my experience, IT project teams using these phase names are forced to commit to schedules and budgets that are mostly fantasy. Management doesn’t understand why they can’t accurately predict the cost of the project at the end of the planning phase, so they try to do requirements in the initiating phase … and don’t do any real planning to support requirements. Then they squeeze their design activities into the planning “phase,” and again, they try to develop an adequately detailed design document without any real planning.

Phase names need to be product-oriented.