allPM.com :: Requirements – Pandora’s Box for Project Managers By Frank P. Saladis PMP

Requirements – Pandora’s Box for Project Managers By Frank P. Saladis PMP

Published on Monday, April 09, 2007 - 03:57 PM

There are many versions and interpretations of the story but basically, according to the myth, Pandora opened a container that released all the evils of mankind - greed, slander, envy (maybe project management – just kidding). Only hope was left inside when she closed it again. Today, Pandora’s box is frequently used as a metaphor for the unanticipated consequences of technical and scientific development. It is basically used anytime people venture into unknown areas or start dabbling in areas that “should be left alone.” This sounds strangely similar to requirements management. For some reason, requirements are somehow related to the evils that project managers often face during the project life cycle. Things like: customer changes, incorrectly stated requirements, missing requirements, unnecessary requirements (unnecessary requirements?), too many requirements, unclear requirements and many more. These few examples provide a good basis for the reference to Pandora’s Box regarding requirements.

One of my favorite references to the requirements challenge is an example of the phases of a project found in Dr. Harold Kerzner’s book – Project Management: A Systems Approach to Planning, Scheduling, and Controlling, J. Wiley.

Initiation
Wild Enthusiasm
Disillusionment
Chaos
Search for the Guilty
Punishment of the Innocent
Praise and promotion of the Non-participant
Gather Requirements

I mention those phases in many classes that I teach and I always get pretty much the same reaction – first there is some laughter and then a few comments such as “ That’s the way it is around here, or “ Why change what works?” The frightening part is that the sequence of the phases is very close to reality, at least when it comes to requirements. Consider the following information prepared by Ralph R. Young, a leading author and subject matter expert in the area of Requirements Management:

53% of industry’s investment on application development projects is a casualty of cost overruns and failed projects
Major contributing factors include: lack of user input (13%), incomplete requirements ( 12%) and changing requirements
Reducing requirements errors is the single most effective action developers can take to improve project outcomes
There is as much as a 2000:1 cost savings from finding errors in the requirements stage vs. in the maintenance stage of the life cycle
The cost of rework is typically 45% of projects

Part of the problem, as observed by Mr. Young, is that the customer’s and the end user’s stated requirements are never the real requirements! What generally happens in the project is an attempt to obtain requirements by asking customers or users what they want. And that is what is provided, a list of “wants” instead of needs. There is no actual process for requirements or the process is limited due to time constraints, forcing the analyst to accelerate the interviews and information gathering sessions to capture the bare minimum information and then attempt to interpret what the user needs. In other cases, requirements gathering interviews take place well after development has begun. I recently saw a cartoon that provided an interesting perspective about projects and requirements. The cartoon showed several people sitting at computer desks and another person running out of the room shouting “You start coding and I’ll go and find out what we’re supposed to be working on.” This cartoon may not be too far from reality.Getting back to Pandora’s Box, it is possible that the requirements process is viewed as being so difficult and could generate so much extra work, not to mention conflicts among end users and decision making stakeholders, that a minimum amount of time is actually budgeted for requirements gathering and analysis. Eventually, this approach leads to cost overruns, delays in development, volumes of change requests, and an unhappy customer or sponsor.

The requirements process, if managed effectively, is actually not a Pandora’s Box but a secret weapon that, if used properly can reduce time to market, keep costs under control, reduce rework, increase quality, and accelerate the completion of the project. There certainly are challenges and obstacles to overcome in the requirements process but with some effective management and an enforcement of the process, many of the challenges can be effectively addressed and resolved.

Mr. Young offers some suggestions for successfully managing requirements:

There should be an organizational policy for requirements management
Senior management must visibly support the process
Investment of 8-14% of total project costs into the requirements process
An effective requirements tool to assist in managing data and tracking requirements
Effective communication between the project manager, the analysts, and the target audience (the end user or customer)

A key factor in the requirements process is for the project team to identify all of the stakeholders involved in the project. By definition, a stakeholder is any person or organization directly involved or in some way impacted either positively or negatively as a result of the project. This definition creates a very wide area to cover when it comes to stakeholders. By identifying the stakeholders the appropriate “net” can be tossed out to “trawl” for the requirements. You will bring in a lot of wants along with the needs but the requirements trawling process is designed to do just that. Find out what the target group wants and then work with them to help them to understand what they need. The items they need become the REAL requirements. It does take time do manage this process but the end result will, in most cases, be a happier customer and a project completed successfully.

Suggesting an 8-14% investment of total project costs for requirements may sound like a huge amount, but the benefits of taking the time to elicit, analyze, refine, and specify requirements will become clear during project reviews and especially when a satisfied client seeks your help on future projects. The requirements management component of a project is critical to overall success and the project manager and the team, actually the organization sponsoring the project, should invest the time needed to develop an effective requirements process, including the training needed by analysts, which will become a standard process for the organization. If you ask me I’d say its “required!”

About the Author

Frank P. Saladis (PMP) is Senior Consultant with International Institute for Learning, Inc. He has been involved in the development of standardized Project Management Guidelines (PMGs) for the AT&T Corporate Information Technology Services (Corporate ITS) organization and is the author of the Project Evaluation Review Process (PERP). He is the recipient of the 2006 PMI Linn Stuckenbruck person of the year award.

How well does management support newly assigned project managers?