Baselines and Freezes at Milestones 3 and 4
The standard against which design choices are evaluated and controlled is the
approved set of requirements: the scope baseline shown at milestone 3 on the life
cycle diagram. At this point in the life of the project, a feasibility study has
been conducted. A concept or a system has been chosen from among the alternatives
that could satisfy the need for change, originally expressed as a problem or an
opportunity. The requirements statement should make specific reference to a chosen
concept. For example, a bridge may be chosen as the preferred device for moving
vehicles across a river, instead of a tunnel, a causeway, or a fleet of ferryboats.
The requirements statement should set out the requisite characteristics of the
bridge. It should not attempt to be a generalized description of the functional
capabilities of all possible modes of conveyance.
In the architectural field, the preparation of requirements statements is a
specialized discipline called functional and space programming. An architectural
program provides a definitive statement of the requirements to be addressed by
the designer by specifying the spatial, functional, technical, and operational
capabilities of the facility. If properly done, the program is expressed in non-technical
terms that are clearly understood by the users, or beneficiaries, of the facility.
In his listing of the programming information required to establish a capital
cost estimate at this stage of a project, Parker calls for a description of the
client's need for the facility in relation to market or business strategy, the
business or operational objectives for the end product, and specific objectives
to be realized in the design itself.
Under each category, he lists illustrative items. Parker further identifies functional
space, occupancy, and special systems and features as three categories of information,
normally obtained from an architectural program, that are key determinants of
the project cost. He gives a useful checklist of items in each category.
Smythe provides a checklist of 37 items that can serve as a starting point
for developing a requirements statement for an industrial plant project. He groups
the items under the headings of process, services, environment, maintenance, security,
safety, and regulatory.
Webster's listing of the possible sub-dimensions of scope (technical performance)
is illustrated with examples from the automotive industry. His nine categories,
however, suggest a framework for developing a requirements statement for other
manufactured products, under the headings: physical criteria, performance, reliability,
unit cost of production, capital cost for production facilities, maintenance cost
in use, unit operating cost, aesthetic features, and esoteric criteria expectations
which exceed reasonable form and function requirements.
Once the requirements statement has been approved by the client or sponsor,
the project team develops a more elaborate conceptual design. The deliverable
at milestone 4 on Figure 2 assigns the agreed
requirements to major functional components or subsystems of the end product.
In the case of a building, Parker indicates the initial design decisions are concerned
with configuration (massing, number of floors, footprint, site plan) and design
parameters by system (structural, mechanical, electrical, plumbing).
In the terminology of defense materiel procurement, the system at this point has
been subdivided into configuration items, and a specification of functional performance,
design requirements, and interface requirements has been prepared for each item.
The deliverable, once reviewed and approved, constitutes the "functional baseline."
At milestone 4, the project outline or functional baseline, if it is compliant
with the statement of requirements, is formally "frozen." That is to say, the
design decisions taken to date must be respected in all subsequent design work.
The functional baseline is the fixed framework within which future design choices
must be made. The project outline document illustrated in Figure
2 shows a WBS consisting only of summary level scope elements. Each of the
chosen subsystems or components in the design is represented by a corresponding
D.E. Defining Project Scope for Effective Cost Control. Cost Engineer's Notebook
Index No. B 4.202, Rev. 1, 3/87. This item is contained in Cost Engineering 29.3,
March 1987, p3
71. Ibid, p6-9
72. Smythe, E.B. The Project Management Process Copies of overhead
transparencies used in a seminar, Vancouver, B.C.: Executive Programs, the University
of British Columbia, 1981, pp50-51
73. Webster, F.M., Jr. Micro Characteristics of an Activity and
its Performance. Proceedings of the 1979 Seminar Symposium Drexel Hill, PA: The
Project Management Institute, 1979, p360
74. Parker, D.E. Defining Project Scope for Effective Cost Control.
Cost Engineer's Notebook Index No. B 4.202, Rev. 1, 3/87. This item is contained
in Cost Engineering 29.3, March 1987, pp8-10