NASA Technical Reports Server (NTRS) 19930015493: Management issues in systems engineering

44 Pages·3.6 MB·English

by  NASA Technical Reports Server (NTRS)

MANAGEMENT ISSUES IN SYSTEMS ENGINEERING
N 9 3 8 2
MANAGEMENT ISSUES IN SYSTEMS ENGINEERING -
by Robert Shishko and Robert G. Chamberlain /p ,}_.
with contributions by
Robert Aster, Vincent Bilardo, Kevin Forsberg, Hal Mooz; Lou Polaski and Ron Wade
When applied to a system, the doctrine of "voice of the buyer" is heard. Determining
successive refinement is a divide-and- the right requirements -- that is, only those
conquer strategy. Complex systems are suc- that the informed buyer is willing to pay for
cessively divided into pieces that are less is an important part of the systems engi-
complex, until they are simple enough to be neer's job. Second, system requirements also
conquered. This decomposition results in communicate to the design engineers what to
several structures for describing the product design and build (or code). As these require-
system and the producing system ("the ments are allocated, they become inexorably
system that produces the system"). These linked to the system architecture and prod-
structures play important roles in systems uct breakdown, which consists of the hierar-
engineering and project management. Many chy of project, systems, segments, elements,
of the remaining sections in this chapter are subsystems, etc.
devoted to describing some of these key The work breakdown structure (WBS) is
structures. also a hierarchical structure that contains
Structures that describe the product sys- the pieces of work necessary to complete the
tem include, but are not limited to, the re- project. Each task in the WBS should be
quirements tree, system architecture and traceable to one or more of the system re-
certain symbolic information such as system quirements. Schedules, which are structured
drawings, schematics, and data bases. The as networks, describe the time-phased activi-
structures that describe the producing sys- ties that result in the product system in the
tem include the project's work breakdown, WBS The cost account structure needs to be
schedules, cost accounts and organization. directly linked to the work in WBS and the
These structures provide different perspec- schedules by which that work is done.
tives on their common raison d'etre: the The project's organizational structure
desired product system. Creating a funda- describes clusters of personnel assigned to
mental harmony among these structures is perform the work. These organizational
essential for successful systems engineering structures are usually trees. Sometimes they
and project management; this harmony are represented as a matrix of two interlaced
needs to be established in some cases by one- trees; one for line responsibilities, the other
to-one correspondence between two struc- for project responsibilities. In any case, the
tures, and in other cases, by traceable links structure should allow identification of re-
across several structures. It is useful, at this sponsibility for each WBS task.
point, to give some illustrations of this key Project documentation is the product of
principle. particular WBS tasks. There are two funda-
System requirements serve two purposes mental categories of project documentation:
in the systems engineering process. First, baselines and archives. Each category con-
they represent a hierarchical description of tains information about both the product
the buyer's desired product system as under- system and the producing system. The base-
stood by the systems engineer. The interac- line, once established, contains information
tion between the buyer and systems engineer describing the current state of the product
to develop these requirements is one way the system and producing system resulting from
35
READINGS INSYSTEMS ENGINEERING
all decisions that have been made. It is usu- priate concurrent engineering. Each one of
ally organized as a collection of hierarchical these systems engineering functions re-
tree structures, and should exhibit a signifi- quires application of technical analysis skills
cant amount of cross-linking. The archives and tools to achieve the optimum system
should contain all of the rest of the project's solution.
information that is worth keeping, even if The techniques used in systems engineer-
only temporarily. The archives should con- ing management include baseline manage-
tain all assumptions, data and supporting ment, requirements traceability, change
analyses that are relevant to past, present control, design reviews, audits, document
and future decisions. Inevitably, the struc- control, failure review boards, control gates
ture (and control) of the archives is much and performance certification.
looser than that of the baseline, though cross The Project Plan defines how the overall
references should be maintained where feasi- project will be managed to achieve the pre-
ble. established requirements within defined pro-
The structure of reviews (and their asso- grammatic constraints. The Systems Engi-
ciated control gates) reflect the time-phased neering Management Plan (SEMP) is the
activities associated with the realization of subordinate document that defines to all
the product system from its product break- project participants how the project will be
down. The status reporting and assessment technically managed within the constraints
structure provides information on the established by the Project Plan. The SEMP
progress of those same activities. On the fi- communicates to all participants how they
nancial side, the status reporting and assess- must respond to pre-established manage-
ment structure should be directly linked to ment practices. For instance, the SEMP
the WBS, schedules and cost accounts. On should describe the means for both internal
the technical side, it should be linked to the and external (to the project) interface con-
product breakdown and/or the requirements trol.
tree.
Role of the SEMP
MANAGING THE SYSTEMS ENGINEERING
PROCESS: THE SYSTEMS The SEMP is the rule book that describes to
ENGINEERING MANAGEMENT PLAN all participants how the project will be tech-
nically managed. The responsible NASA
Systems engineering management is a tech- Center should have a SEMP to describe ho_"
nical function and discipline that ensures it will conduct its technical management,
that systems engineering and all other tech- and each contractor should have a SEMP to
nical functions are properly applied. describe how it will manage in accordance
Each project should be managed in accor- with both its contract and NASA's technical
dance with a project cycle that is carefully management practices. Since the SEMP is
tailored to the project's risks. While the pro- project: and contract-unique, it must be up-
ject manager concentrates on managing the dated for each significant programmatic
overall project cycle, the project-level or lead change or it will become outmoded and un-
systems engineer concentrates on managing used, and the project could slide into an un-
its technical aspect. This requires that the controlled state. The NASA Center should
systems engineer perform (or cause to be per- have its SEMP developed before attempting
formed) the necessary multiple layers of to prepare a "should-cost" estimate, since ac-
decomposition, definition, integration, ver- tivities that incur cost, such as technical risk
ification and validation of the system, while reduction, need to be identified and described
orchestrating and incorporating the appro- first. The contractor should have its SEMP
36
MANAGEMENT ISSUES INSYSTEMS ENGINEERING
developed during the proposal process (prior • The role of systems engineering
to costing and pricing) because the SEMP de- • Therole of design engineering
scribes the technical content of the project, • The role of specialty engineering
the potentially costly risk management ac- • Applicable standards
tivities, and the verification and validation • Applicable procedures and training
techniques to be used, all of which must be • Baselinecontrolprocess
included in the preparation of project cost • Changecontrolprocess
estimates. • Interfacecontrolprocess
The project SEMP is the senior technical • Control of contracted (or subcontracted)
management document for the project; all engineering
other technical control documents, such as • Data control process
the Interface Control Plan, Change Control • Make-or-buy control process
Plan, Make-or-Buy Control Plan, Design • Parts, materials and process control
Review Plan, Technical Audit Plan, etc., de- • Quality control
pend on the SEMP and must comply with it. • Safety control
The SEMP should be comprehensive and • Contamination control
describe how a fully integrated engineering • EMI/EMC
effort will be managed and conducted. • Technical performance measurement
• Control gates
Contents of the SEMP • Internal technical reviews
• Integration control
Since the SEMP describes the project's tech- • Verification control
nical management approach, which is driven • Validation control.
by the type of project, the phase in the project
cycle, and the technical development risks, it Part II -- Systems Engineering Process.
must be specifically written for each project This section should contain a detailed de-
to address these situations and issues. While scription of the process to be used, including
the specific content of the SEMP is tailored the specific tailoring of the process to the re-
to the project, the recommended content is quirements of the system and project; the
listed below. procedures to be used in implementing the
process; in-house documentation; the trade
Part I -- Technical Program Planning study methodology; the types of mathemat-
and Control. This section should identify ical and/or simulation models to be used for
organizational responsibilities and authority system cost-effectiveness evaluations; and
for systems engineering management, in- the generation of specifications.
clude control of contracted engineering; lev- This section should describe the:
els of control established for performance
and design requirements, and the control • System decomposition process
method used; technical progress assurance • System decomposition format
methods; plans and schedules for design and • System definition process
technical program reviews; and control of • System analysis and design process
documentation. • Trade study process
This section should describe: • System integration process
• System verification process
• The role of the project office • System qualification process
• The role of the user • System acceptance process
• The role of the Contracting Office Techni- • System validation process
cal Representative (COTR) • Risk management process
37
READINGS INSYSTEMS ENGINEERING
. Life-cycle cost management process the project that ultimately determines the
• Use of mathematical models length and cost of the project. The develop-
• Use of simulations ment of the programmatic and technical
• Specification and drawing structure management approaches of the project re-
• Baseline management process quires that the key project personnel develop
• Baseline communication process an understanding of the work to be per-
• Change control process formed and the relationships among the var-
• Tools to be used. ious parts of that work. (See sections on work
breakdown structures and network sched-
Part III -- Engineering Specialty Inte- ules.)
gration. This section of the SEMP should de-
scribe tbe integration and coordination of the
SEMP Lessons Learned frorn DoD Experience
efforts of the specialty engineering disci-
plines into the systems engineering process • A well-managed project requires a
during each iteration of that process. Where coordinated SEMP that is used through
the project cycle.
there is potential for overlap of specialty ef-
• A SEMP is a living document that must be
forts, the SEMP should define the relative
updated as the project changes and kept
responsibilities and authorities of each.
consistent with the Project Plan.
This section should contain the project's
• A meaningful SEMP must be the product
approach to: of experts from all areas of the project.
• Projects with little or insufficient systems
engineering discipline generally have
• Concurrent engineering
major problems.
• The activity phasing of specialty disci-
• Weak systems engineering, or systems
plines
engineering placed too low in the
• The participation of specialty disciplines organization, cannot perform the functions
• The involvement of specialty disciplines as required.
• The role and responsibility of specialty • The systems engineering effort must be
skillfully managed and well
disciplines
communicated to all the individuals.
• The participation of specialty disciplines
• The systems engineering effort must be
in system decomposition and definition
responsive to both the customer and the
• The role of specialty disciplines in verifi- contractor interests.
cation and validation
• Reliability
• Producibility The SEMP's development requires contri-
• Human engineering butions from knowledgeable programmatic
• Maintainability and technical experts from all areas of the
• Safety project that can significantly influence the
• Survivability/vulnerability project's outcome. The involvement of recog-
• Integrated logistics nized experts is needed to establish a SEMP
• Quality assurance. that is credible to the project manager and to
secure the full commitment of the project
Development of the SEMP team.
The SEMP must be developed concurrently Managing the Systems Engineering
with the Project Plan. In developing the- Process: Summary
SEMP, the technical approach to the project,
and hence the technical aspect of the project Systems engineering organizations, and spe-
cycle, are developed. This becomes the keel of cifically project-level systems engineers, are
38
MANAGEMENT ISSUES IN SYSTEMS ENGINEERING
responsible for managing projects through WBS should be a product-based, hierarchical
the technical aspect of the project cycle. This division of deliverable items and associated
responsibility includes managing the decom- services. As such, it should contain the pro-
position and definition sequence, managing ject's product breakdown structure (PBS),
the integration, verification and validation with the specified prime product(s) at the
sequence and controlling the technical top, and the systems, segments, subsystems,
baselines of the project. Typically, these etc. at successive lower levels. At the lowest
baselines are the functional, "design-to," level are products such as hardware items,
"build-to" (or "code-to"), "as-built" (or "as- software items and information items (e.g.,
coded"), and "as-deployed." Systems engi- documents, databases, etc.) for which there
neering must ensure efficient and logical is a cognizant engineer or manager. Branch
progression through these baselines. points in the hierarchy should show how the
Systems engineering is responsible for PBS elements are to be integrated. The WBS
system decomposition and design until the is built from the PBS by adding, at each
design-to specifications of all lower level con- branch point of the PBS, any necessary ser-
figuration items have been produced. Design vice elements such as management, systems
engineering is then responsible for develop- engineering, integration and verification
ing the build-to and code-to documentation (I&V), and integrated logistics support (ILS).
that complies with the approved design-to If several WBS elements require similar
baseline. Systems engineering audits the equipment or software, then a higher level
design and coding process and the design en- WBS element might be defined to perform a
gineering solutions for compliance to all block buy or a development activity (e.g.,
higher level baselines. In performing this "System Support Equipment"). Figure 1
responsibility, systems engineering must shows the relationship between a system, a
ensure requirements traceability and docu- PBS and a WBS.
ment the results in a requirements traceabil- A project WBS should be carried down to
ity/verification matrix. the cost account level appropriate to the
Systems engineering is also responsible risks to be managed. The appropriate level of
for the overall management of the integra- detail for a cost account is determined by
tion, verification and validation process. In management's desire to have visibility into
this role, systems engineering conducts Test costs, balanced against the cost of planning
Readiness Reviews and ensures that only and reporting. Contractors may have a Con-
verified configuration items are integrated tract WBS (CWBS), which is appropriate to
into the next higher assembly for further the contractor's needs to control costs. A
verification. Verification is continued to the summary CWBS, consisting of the upper lev-
system level, after which system validation els of the full CWBS, is usually included in
is conducted to prove compliance with user the project WBS to report costs to the con-
requirements. tracting agency.
Systems engineering also ensures that WBS elements should be identified by ti-
concurrent engineering is properly applied tle and by a numbering system that performs
through the project cycle by involving the the following functions:
required specialty engineering. The SEMP is
the guiding document for these activities. • Identifies the level of the WBS element
• Identifies the higher level element into
THE WORK BREAKDOWN STRUCTURE which the WBS element will be integrat-
ed
A WBS is a hierarchical breakdown of the • Shows the cost account number of the
work necessary to complete a project. The element.
39
READINGS INSYSTEMS ENGINEERING
SystemComponents!subsystems) other interested parties. It fully describes
heldtogetherby"glue(integration)
the products and/or services expected from
each WBS element.
Subsystem
A This section provides some techniques for
The whole does
more than the developing a WBS, and points out some mis-
Subsystem sum ofitsparts takes to avoid.
Sub. C
system
B Subsystem Role of the WBS
D
A product-based WBS is the organizing
_Str BPr°duct structure for:
reakdown
ucture Shows \
thecomponents , Project and technical planning and sched-
from which the
uling
tern I systfeomrmedwas
• Cost estimation and budget formuIation
__J__
(In particular, costs collected in a
product-based WBS can be compared to
historical data. This is identified as a
Sub primary objective by DoD standards for
syste_
A WBSs.)
• Defining the scope of statements of work
Work
Breakdown and specifications for contract efforts
The individualsystem Structure (WBS)
components All work • Project status reporting, including sched-
components
ule, cost and work force, technical perfor-
necessary to
produce a mance, integrated cost(cid:0)schedule data
complete system
(such as earned value and estimated cost
_V__
at completion)
• Plans, such as the SEMP, and other docu-
mentation products, such as specifica-
Sub-
tions and drawings.
system Manage- Systems {&V II_
A meat Engin-
eering
Work to produce the It provides a logical outline and vocabulary
individual system that describes the entire project and inte-
components
Work tointegratethe
grates information in a consistent way. If
components intoa
system there is a schedule slip in one element of a
The whole takes WBS, an observer can determine which other
more work than the
sum ofitsparts WBS elements are most likely to be affected.
Cost impacts are more accurately estimated.
Figure 1 The Relationship between a System,
If there is a design change in one element of
a Product Breakdown Structure, and
the WBS, an observer can determine which
a Work Breakdown Structure
[
other WBS elements will most likely be af-
fected, and these elements can be consulted
A WBS should also have a companion WBS for potential adverse impacts. r
dictionary that contains each element's title,
z
identification number, objective, description, Techniques for Developing the WBS
and any dependencies (e.g., receivables) on
other WBS elements. This dictionary pro- Developing a successful project WBS is likely
vides a structured project description that is to require several iterations through the
valuable for orienting project members and project cycle since it is not always obvious at
4O
MANAGEMENT ISSUES INSYSTEMS ENGINEERING
the outset what the full extent of the work service products provided to external cus-
may be. Prior to developing a preliminary tomers. However, the general concept of a
WBS, there should be some development of hierarchical breakdown of products and/or
the system architecture to the point where a services would still apply.
preliminary PBS can be created. The rules that apply to a development
The PBS and associated WBS can then be WBS also apply to a WBS for an operational
developed level by level from the top down. facility. The techniques for developing a
In this approach, a project-level systems en- WBS for an operational facility are the same,
gineer finalizes the PBS at the project level, except that services such as maintenance
and provides a draft PBS for the next lower and user support are added to the PBS, and
level. The WBS is then derived by adding ap- services such as systems engineering, inte-
propriate services such as management and gration and verification may not be needed.
systems engineering to that lower level. This
recursive process is repeated until a WBS ex- Common Errors in Developing a WBS
ists down to the desired cost account level.
An alternative approach is to define all There are three common errors found in
levels of a complete PBS in one design activ- WBSs:
ity, and then develop the complete WBS.
When this approach is taken, it is necessary Error 1: The WBS describes functions,
to take great care to develop the PBS so that not products. This makes the project man-
all products are included, and all assembly/ ager the only one formally responsible for
integration and verification branches are products.
correct. The involvement of people who will Error 2: The WBS has branch points that
be responsible for the lower level WBS ele- are not consistent with how the WBS ele-
ments is recommended. ments will be integrated. For instance, in a
flight operations system with a distributed
A WBS for a Multiple Delivery Project. architecture, there is typically software asso-
Some of the terms for projects that provide ciated with hardware items that will be inte-
multiple deliveries, are "rapid develop- grated and verified at lower levels of a WBS.
ment," "rapid prototyping" and "incremental It would then be inappropriate to separate
delivery." Such projects should also have a hardware and software as if they were sepa-
product-based WBS, but there will be one ex- rate systems to be integrated at the system
tra level in the WBS hierarchy immediately level. This would make it difficult to assign
under the final prime product(s) that identi- accountability for integration and to identify
fies each delivery. At any point in time there the costs of integrating and testing compo-
will be both active and inactive elements in nents of a system.
the WBS. Error 3: The WBS is inconsistent with
the PBS. This makes it possible that the PBS
A WBS for an Operational Facility. A will not be fully implemented, and generally
WBS for managing an operational facility complicates the management process.
such as a flight operations center is analo- Some examples of these errors are shown
gous to a WBS for developing a system. The in Figure 2. Each one prevents the WBS from
difference is that the products in the PBS are successfully performing its roles in project
not necessarily completed once and then planning and organizing. These errors are
integrated, but are all produced on a routine avoided by using the WBS development tech-
basis. A PBS for an operational facility niques described above.
might consist of information products or
41
READINGS INSYSTEMS ENGINEERING
_ Error I I Functions without Products Error 2 Inappropriate Branches
This WBS describes only This WBS has branch points that are
functions, not the products not consistent with the way the WBS
elements will be integrated
I Error 3 ] Inconsistency with PBS
This WBS is inconsistent with the
Product Breakdown Structure :=
:_'_':--_•-_-_-_..i............_.-.>_......;×;........................... _:_._::.:'.'...:_.._.+:+_z:__,__._._ _._._.z._:_.:--_..:-.-_.:.:._:_._:_:._:y2_'_.:,':_: ...............................;-:.:.:_._:_,_-.:.:_:_:_..__×..-_:__::-:'-_._-_
:i_%,.'::::::i:i:::i:::i:i::>.'::.:_.:._:_:_j__2_,::">.':_.':':_:1;-_: [_,,.':_::_:5:'::':-::i:_:i(:-:_:>.__::!::_:_$:: :_:: :):..+.!8:-)_t>. _:_: _,>;.y_N_?_._ :_ N_K_ |i::: _:_:>.:__ _1::_): ::_:_:::_:: ::'_g::.S_._t_
:._ .................-._............................._........._.....-- . _i.......................-...................................................._.>.._,...._......_........×...._ Subsystem _i-..._-_.-,%/,',._...............
:_.:::.:>:__>:__¢c¢.:_:,.,::__;::__.:_-_;:_-.::-:.:-_:::-_ ::::::::::::::::::::::::::::::::::::::::::::::::::::::::_:.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
,.-__.:_.:...-:,><:_.:.__.v_×:_..=======================================i__:_::_:-_;_:_;_:;_._;_:_:_._:_:_._:_:_:_:_:_ -.;_.%'xXJL .u..v.v......-.u.u.v.v -.v.xLLx:Lv_. X.T.V::LU.: -:::?.=::?XT.:U._ ._A..J=...... :::::.'.-:_::>-
_f
i._:.":_:!:i[]tTransm,tter _*:_._._;_.i._;$:_i,i:;*_;l TWT Amphfier I:;:;:;:;:_:;:;:!:_:_:l H [4 [:I z_'rAmplin,, [
The Work Breakdown Structure The Product Breakdown Structure
Figure 2 Examples of WBS Development Errors
NETWORK SCHEDULING it will take, and how each element of the pro-
ject WBS might affect other elements. A
Products described in the WBS are the result complete network schedule can be used to
of activities that take time to complete. An calculate how long it will take to complete a
orderly and efficient systems engineering project, which activities determine that du-
process requires that these activities take ration (i.e., critical path activities), and how
place in a way that respects the underlying much spare time (i.e., float) exists for all the
time-precedence relationships among them. other activities of the project. An under-
This is accomplished by creating a network standing of the project's schedule is a
schedule, which explicitly takes into account prerequisite for accurate project budgeting.
the dependencies of each activity on other ac- Keeping track of schedule progress is an
tivities and receivables from outside sources. essential part of controlling the project, be-
This section discusses the role of scheduling cause cost and technical problems often show
and the techniques for building a complete up first as schedule problems. Because net-
network schedule. work schedules show how each activity af-
Scheduling is an essential component of fects other activities, they are essential for
planning and managing the activities of a predicting the consequences of schedule slips
project. The process of creating a network or accelerations of an activity on the entire
schedule can lead to a much better under- project. Network scheduling systems also
standing of what needs to be done, how long help managers accurately assess the impact
42
MANAGEMENT ISSUESINSYSTEMS ENGINEERING
A work flow diagram (WFD) is a graphi-
Critical Path and Float Calculation
cal display of the first three data items
above. A network schedule contains all four
The critical path is the sequence of activities
data items. When creating a network sched-
that will take the longest to accomplish. Activi-
ties that are not on the critical path have a cer- ule, graphical formats of these data are very
tain amount of time that they can be delayed un- useful. Two general types of graphical for-
til they, too are on a critical path. This time is mats, shown in Figure 3, are used. One has
called float. There are two types of float, path activities-on-arrows, with products and de-
float and free float. Path float is where a se-
pendencies at the beginning and end of the
quence of activities collectively have float. If
arrow. This is the typical format of the Pro-
there is a delay in an activity in this sequence,
then the path float for all subsequent activities gram Evaluation and Review Technique
is reduced by that amount. Free float exists (PERT) chart. The second called precedence
when a delay in an activity will have no effect on diagrams, has boxes that represent activi-
any other activity. For example, if activity A can
ties; dependencies are then shown by arrows.
be finished in 2 days, and activity B requires 5
Due to its simpler visual format and reduced
days, and activity C requires completion of both
requirements on computer resources, the
A and B, then A would have 3days of free float.
Float is valuable. Path float should be con- precedence diagram has become more com-
served where possible, so that a reserve exists mon in recent years.
for future activities. Conservation is much less
important for free float.
To determine the critical path, there is first Activity-on-Arrow Diagram
a "forward pass" where the earliest start time of Activity Ahas
been "artificially"
each activity is calculated. The time when the broken into two
last activity can be completed becomes the end "Y 5 "r! separate activities.
point for that schedule. Then there is a "back-
ward pass," where the latest possible start point Activity Description
of each activity is calculated, assuming that the Activity Duration
last activity ends at the end point previously cal- #e.g.,days)
culated. Float is the time difference between the
Precedence Diagram
earliest start time and the latest start time of an
Note: i
activity. Whenever this is zero, that activity is Each activity's
on a critical path. A Activity Description description
shouldcontain
an action and
the object of
]'_ ActivitDyuration
(e.gd.a,ys) that action.
!
of both technical and resource changes on the SS5 B
cost and schedule of a project.
ThismeansthatActivitBy
start5daysafter
cab
ActivitAystarts.
Network Schedule Data and Graphical
Formats Figure 3 Activity-on-Arrow and Precedence
Diagrams for Network Schedules
Network schedule data consist of:
The precedence diagram format allows
• Activities for simple depiction of the following logical
• Dependencies between activities (e.g., relationships:
where an activity depends upon another
activity for a receivable) • Activity B begins when Activity A begins
• Products or milestones that occur as a re- (Start-Start, or SS)
sult of one or more activities • Activity B begins only after Activity A
ends (Finish-Start, or FS)
• Duration of each activity.
43
READINGS IN SYSTEMS ENGINEERING
• Activity B ends when Activity A ends • Ensuring that the cost account WBS is
(Finish-Finish, or FF). extended downward to describe all sig-
nificant products, including documents,
Each of these three activity relationships reports, hardware and software items.
may be modified by attaching a lag ( ÷ or - ) • For each product, listing the steps re-
to the relationship, as shown in Figure 3. quired for its generation and drawing the
It is possible to summarize a number of process as a work flow diagram.
low-level activities in a precedence diagram • Indicating the dependencies among the
with a single activity. This is commonly products, and any integration and verifi-
referred to as hammocking. One takes the cation steps within the work package.
initial low-level activity and attaches a
summary activity to it using the first re- Step 2: Identify and negotiate external
lationship described above. The summary dependencies. External dependencies are
activity is then attached to the final low- any receivables from outside of the cost ac-
level activity using the third relationship count, and any deliverables that go outside
described above. Unless one is hammocking, of the cost account. Informal negotiations
the most common relationship used in prece- should occur to ensure that there is agree-
dence diagrams is the second one mentioned ment with respect to the content, format and
above. The activity-on-arrow format can labeling of products that move across cost
represent the identical time-precedence logic account boundaries. This step is designed to
as a precedence diagram by creating artifi- ensure that lower level schedules can be
cial events and activities as needed. integrated.
Step 3: Estimate durations of all activi-
Establishing a Network Schedule ties. Assumptions behind these estimates
(work force, availability of facilities, etc.)
Scheduling begins with project-level sched- should be written down for future reference.
ule objectives for delivering the products de- Step 4: Enter the schedule data for the
scribed in the upper levels of the WBS. To WBS element into a suitable computer pro-
develop network schedules that are consis- gram to obtain a network schedule and an
tent with the project's objectives, the follow- estimate of the critical path for that element.
ing six steps are applied to each cost account (There are many commercially available
at the lowest available level of the WBS. software packages for this function.) This
Step 1: Identify activities and dependen- step enables the cognizant engineer, team
cies needed to complete each WBS element. leader, and/or systems engineer to review
z
Enough activities should be identified to the schedule logic. It is not unusual at this
show exact schedule dependencies between point for some iteration of steps one to four to
activities and other WBS elements. It is not be required in order to obtain a satisfactory
uncommon to have about 100 activities iden- schedule. Reserve will also be added to criti-
tified for the first year of a WBS element cal path activities, often in the form of a
that will require 10 work-years per year. dummy activity, to ensure that schedule
Typically, there is more schedule detail for commitments can be met for this WBS ele-
the current year, and much less detail for ment.
subsequent years. Each year, schedules are Step 5: Integrate schedules of lower level
updated with additional detail for the cur- WBS elements, using suitable software, so
rent year. This first step is most easily ac- that all dependencies between WBS ele-
complished by: ments are correctly included in a project
=-
44 --