Requirements vs. specifications and other comparisons
by William R. Duncan, PMP, Contributing Editor
Q. What is the difference between a “requirement” and a “specification”?
The dictionary tells us that a requirement is something that is needed and that a specification is a precise description of an item. In the project management arena, the term requirement generally refers to a customer need while specification refers to a detailed, usually technical description of how that need will be met. For example, if an airline wants a plane that will fly 800 passengers from Los Angeles direct to Tokyo, that is a requirement; when the manufacturer designs an aircraft of certain dimensions powered by four engines of certain horsepower, that is a specification.
Comedian Steve Martin notes that the French “have a different word for everything.” Project management often suffers from the same language problem.
But both requirements and specifications can exist at many levels. Bob Youker has written a number of papers describing this “hierarchy of needs.” For example, the aircraft manufacturer will most likely view its engine needs as a requirement to be converted into a specification by a subcontractor.
Many application areas have developed modifiers for these two terms to describe different levels of detail. For example, I've seen marketing requirements used in new product development and functional requirements used in aerospace and defense. But there is no universally accepted terminology—I've even seen one company refer to requirements specifications as an intermediate step.
Q. What quality checks would you recommend to assess the adequacy and completeness of a work breakdown structure?
William R. Duncan, PMP, is with Project Management Partners, a project management consulting and training firm headquartered in Lexington, MA, USA. He is the former Director of Standards for PMI and was the primary author of the 1996 version of A Guide to the Project Management Body of Knowledge. Send comments on this column to [email protected].
Here's a list that I have adapted from material I wrote for A Guide to the Project Management Body of Knowledge:
Do the items at the lower (child) level completely define the item at the upper (parent) level? That is, are they both necessary and sufficient?
Does the lowest level of the WBS provide adequate detail to estimate effort, cost, and duration? Does it provide adequate detail to report progress once the project gets under way?
Can I assign explicit, single-point responsibility to an individual or organization for each item at the lowest level?
Are completion criteria for each item defined?
Are management activities (status reports, team meetings, and so forth) included?
Are integrative activities (getting elements of the product or service to work together) included where needed?
I issue a warning, however: While this checklist may help you to assess the adequacy and completeness of your WBS, you shouldn't rely on inspection to ensure the quality of your WBS; the best way to ensure the adequacy and completeness of your WBS is to develop it with your team.
Q. Developing a WBS seems like extra effort since you have to sequence the activities anyway. Why not just use the process of constructing a network logic diagram to identify the work?
In my experience, project teams that rely exclusively on a network logic diagram to define the work of the project often miss things that are part of the project scope but off the main flow. Support activities such as project management and the development of training materials are frequent omissions. In addition, the WBS provides a better mechanism for performance analysis (if the project is in trouble, what are the root causes?) as well as for organizing lessons-learned information.
To me, relying exclusively upon the network logic diagram is false economy.
Q. Can you point me to a good discussion of the role of a sponsor?
A Guide to the Project Management Body of Knowledge (Section 2.2) defines the sponsor as “the individual or group within the performing organization that provides the financial resources, in cash or in kind, for the project.” I think that defines the basic role of the sponsor—show me the money.
In many organizations the sponsor is also expected to be a “champion” for the project. The champion is usually a senior manager that influences the organization in order to help overcome barriers and obstacles when and as needed.
However, the champion does not have to be the sponsor. For example, one of my clients is involved in new product development: the senior vice president of the business unit is the sponsor and one of the project manager's primary roles is that of champion. Another client is the information systems department of a large utility: the sponsor is usually the head of the user department and the champion is usually the Chief Information Officer.
Q. What do I do when my client says, “ We don't want to pay for project management”? Why is project management as a service such a hard sell?
Reader Service Number 030
In my experience, there are two primary reasons:
Your client may not know the difference between project management and project controls. I recently had a prospect comment, “Why do we need a full-time project manager to complete a weekly status report?” If your client sees project management as nothing more than preparing a weekly status report, they won't see much benefit and they won't want to pay for it.
The cost of project management is often presented as a lump-sum amount and thus comes across as a “pad.” If you communicate the work of project management (status reports, yes, but also change management, plan maintenance, corrective action, risk management, and so on), you may have a better chance of selling it. I have one client who claims to have declined to manage the project when the client declined to pay for project management. The contractor's team (eight people strong) showed up on Monday morning and asked the client's project manager for their assignments. Needless to say, the client was a bit angry, but they also approved a contract modification to cover project management.
Q. We would like to define a standard project life cycle that can be used for all projects in our organization—new product development, information systems, quality improvement, and so forth. We're considering using the process group names in the Guide. What do you think?
Phases are defined to provide control. While the general sequence of initiation to closeout holds for all projects, those names won't always work. For example, where does “design” go in an information systems project? Where is the “fuzzy front end” of your new product development project? The process groups serve to organize project management processes, while phase names are used to organize product-oriented processes. Using one set of names to organize the other set of processes just isn't appropriate.
Using the process groups as phase names has some additional problems:
Planning as a phase name suggests that planning doesn't happen in the other phases.
The processes within each process group repeat within each phase of the project. To have administrative closure within both the planning and closeout phases is likely to cause confusion.
Q. How would you quantify activities in a research and development environment, and how would you measure progress?
In my experience, the issue here is to help the researchers understand that you are looking to quantify and measure their activity, not the results of their research. Once they understand that, they can quantify their efforts (and you can measure their progress) the same as anything else.
For example, one of my clients designs and manufacturers a product that involves sophisticated chemistry. The researchers must often run many tests and experiments to “discover” the process that works best. Sometimes, they'll even need to run tests to discover a process that works at all! When planning a project like this, we ask the researchers to answer these basic questions:
How much effort will be required for you to run one test or experiment?
How long (elapsed time) will it take you to run one test or experiment from start to finish?
How many tests or experiments do you think you'll have to run before you find one that works satisfactorily?
We also ask for three point estimates in response to these questions (optimistic, most likely, and pessimistic). Throughout, we make certain that the scientist(s) and/or engineer(s) involved understand that we are not asking for a guarantee of success, just for their best estimate.
It is now quite easy to measure progress. If more tests are needed, or if the tests take longer than expected, we have a negative variance. If fewer tests are needed, or if the tests take less time than expected, we have a positive variance. We can also use this information to analyze trends: are we consistently under- or overestimating any component?
There is other information that we need for planning—can any tests be run in parallel? is there special equipment needed?—but the questions above are key to progress measurement.
DO YOU HAVE A QUESTION about the practice of project management? Send it via e-mail to [email protected] or fax it to 781/862-9908.
JULY 1999 PM NETWORK