<< . .

. 6
( : 16)



. . >>

you or the facilitator focuses on the specific elements that are a part of the project and those items that have
been excluded.
The meeting then proceeds to a discussion of the strategy for meeting project objectives. In each project, there
are a number of ways in which the objectives can be achieved. The facilitator elicits information relating to
the strategy from members of the project team.
A discussion of restrictions and risks associated with the project follows. Here the facilitator presents such
items as budgetary constraints, restrictions relating to conditions in the marketplace, and any other
circumstances that affect the manner in which the project work is to progress. If the project is to have a series
of go/no-go decision checkpoints, the facilitator discusses these points, with a complete description, if
feasible, of the factors and the criteria used to make each go/no-go decision. All of the assumptions that have
been made previously are presented and discussed with the project team. This is also the appropriate time to
initiate a discussion of the course of action that might be appropriate if a particular assumption proves to be
unfounded.
Finally, quality assurance, financial philosophy, priority of this project, and change control can be briefly
discussed. This effort concludes the positioning of the project and provides for a strong foundation upon
which the project plans can now be built.

Meeting 3: Develop Final Work Breakdown Structure and Team Organization
The third meeting addresses the scope definition and reconfirms the agreement on the end product. Any areas
of disagreement should be addressed immediately. Agreement on the project scope will facilitate the
development of the WBS. Since the scope and the first two levels of the WBS represent the conceptual plan,
they provide the direction for the balance of the WBS development.
The facilitator explains the top levels of the work breakdown structure with the team and then works with the
members to reach agreement on level 2, which is detailed tasks. Small subgroups are then created with two
assignments: to generate a level 3 subtask list and to determine the person (or department) who will become
the task owner.
The entire project team reconvenes and reviews each level 3 subtask list for clarity and appropriateness, buys
in to the responsibility assignment of the person (or group) accountable, expands the responsibility matrix to
incorporate those people (groups) who will support the task owner on each task, details the deliverable(s) with
a standard-of-performance criteria upon which it will be measured, and finally logs any assumptions,
constraints, or risks associated with each task.


Previous Table of Contents Next
Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Meeting 4: Develop Dependencies and Durations
Title

Each task activity in the work breakdown structure, except for those that start at a fixed time, depends on a
predecessor activity. We have found that the most stimulating and productive way to determine the sequence
of tasks based on their dependencies is to use pad notes attached to a wall. The team writes each task on a
----------- gummed slip, places the slips on a wall, and then moves them around in order to determine the paths of their
sequential and concurrent order from the start of the project to the finish.
The next team effort, time estimating, may be done in this meeting or as an assignment. If the team decides to
tackle this task now, the facilitator asks interested and knowledgeable team members how much time it will
take to complete each task. If the estimates are close and agreement can be reached, the estimate is recorded
on the task™s gummed slip. If there is a wide divergence and agreement cannot be reached, give the task
owner the assignment to break the task into further subtasks and rethink the estimate. Upon receiving this
more precise time estimate, go to the people supporting the task and obtain concurrence of the estimate before
proceeding further.
The meeting is completed by a discussion of what comes next. The facilitator reviews the actions generated
during the meeting, which include the sequence of dependency relationships and who is responsible for each
task, as well as a timetable for completion.

Meeting 5: Produce a Schedule
The team now has enough information to develop a schedule showing when tasks need to begin and end in
relation to one another on a calendar. Problems with the schedule plan should be identified and assigned to
individual members to resolve at this meeting. Those responsible for the critical path activities must evaluate
their assignments and create contingency plans for areas of high risk. There may be other deliverables created
as products of the planning process (for example, a resource loading chart or a budget). Any or all of these
items may be necessary to monitor and control the project. (We discuss them in more detail in the following
chapter.)
It is also important to facilitate an understanding of each deliverable with the team. We suggest that team
members keep a list of open items that must be resolved prior to the next meeting and then decide who will
resolve and complete each one. As a result of these types of actions, teams begin to see project progress and
develop positive feelings about the process and team relationship.
In this final meeting, the facilitator discusses what is next in the planning process”for example, how data
will be produced on schedule charts, if and how resource allocation will be performed, how status will be
tracked, and when status meetings will be held.

Effective Planning
The process of plan development is designed to produce documents that represent the true expectations of the
team. The plan represents commitments on their part, makes a statement of the team members™ ownership,
and represents time frames and budgets with a high probability of being achieved. There are seven
requirements for effective planning:
Requirements for Effective Planning
1. Parameters: Establish parameters of quality, time, resource allocations, and cost for every project.
Ensure that these parameters are realistic.
2. Plan: Develop a plan that will accommodate the parameters committed to.
3. Simplicity: Keep project plans, procedures, and reports direct, clear, and concise.
4. Approvals: Secure formal and informal approval of project plans.
5. Accuracy: Confirm that everything you disseminate is accurate.
6. Authority and responsibility: Place authority and responsibility in parity with what your
expectations are from the project team members.
7. Project team members: Remember that human factors are of overriding importance.

The process of planning is critical to the success of project management. Frequently organizations have
produced the correct plan documents but have failed to execute a significant percentage of the projects
according to the plans. This happens when the process used to produce the plans is defective and the plans
cannot be achieved. The planning documents do not accurately reflect what the project team expects to
happen and do not represent commitments on the part of individuals who are motivated to realize the desired
results.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 5
Project Planning Techniques: Schedule, Cost, and
Resource Utilization
-----------

This is the second of two chapters that deal with the development of the project plan. The project objectives
have already been defined in the previous chapter. Detailed project planning is now required. In this chapter,
we focus on the following techniques used in planning: work breakdown structure, project network,
estimating, critical path analysis, and scheduling. We then discuss how these planning techniques can be used
in making important business decisions regarding mandatory target dates, resource leveling, project budget,
and risk assessment and contingency planning.

Work Breakdown Structure
The work breakdown structure (WBS) is a checklist of every activity that must be performed to create the end
product. This checklist becomes the foundation for the schedule, resource allocation, and budget plans.
Create a WBS using one or more of the following methods: questionnaire, one-on-one personal interviews, or
group sessions. We recommend the group sessions as the vehicle for developing the most comprehensive
work breakdown structure.
Figure 5-1 shows the basic framework for a WBS. Begin its construction by isolating the major work
assignments for your project. The key question the team needs to answer is, “What major work assignments
must be accomplished to complete this project?” The major work assignments should be the significant
chunks of work necessary to see the project through from start to finish. If you are using some type of systems
or product development life cycle, your major work assignments will follow directly from the phases or stages
of this life cycle.
Write each work assignment on a separate sheet of flipchart paper. (The flipcharts give everyone an
opportunity to see what has been discussed and what might have been omitted. They make returning to any
previously discussed section to make further recommendations much easier.) Figure 5-2 shows the beginning
of a sample work breakdown structure for a hypothetical project to install a new software package. In order to
install the new package, five major work assignments must be accomplished: assess requirements, design,
develop, test, and implement.
Next, for each sheet that has a major work assignment ask the question, “To accomplish this work
assignment, what tasks must be performed or delivered?” Begin each task with an active verb since you are
listing the action or performance that needs to be done. Figure 5-2 shows the breakdown of tasks for each of
the major work assignments in our hypothetical project. (At this point in the work breakdown process, do not
impose sequence into the work tasks.) Notice that there is only one task for each of the first two work
assignments (assess requirements and design). Depending on the nature of the project, sometimes you may
determine that the major work assignments sufficiently describe a process for developing a portion of the end
product or end service (e.g., an in-house product development or systems development life cycle). We have
used the first two work assignments to illustrate this occurrence.
Following are sample categories of major work assignments that can be used to construct a work breakdown
structure:
Sample Categories for Major Work Assignments
• Components of the product: internal, external, peripherals
• Functions: word processing, calculations, filing
• Organizational units: units, departments, branches
• Geographical areas: states, regions, cities
• Cost accounts: accounts assigned to parts of the project
• Time phases: initiation, design, development
• Phases: marketing, design, construction, training, financing

Break down the work efforts until you (or the person responsible for the area) can assign to them reliable
effort estimates (the amount of effort time needed to accomplish the work task).
When you define the lowest level of detail, assign a person or functional area to take responsibility for doing
the work and commit to a deliverable”the end product of the effort that comprises the work task. In other
words, the work task (verb) results in a deliverable (noun). This deliverable can be measured and quality
assured.




Figure 5-1. Work breakdown structure shell.
In order to determine if the WBS is complete and accurate, ask yourself the following questions:
• Is it broken down to the level of detail that guarantees control to the project manager?
• Do the work efforts at the lowest level begin with an active verb? (If they are phases, components of
the product, or areas of responsibility, the WBS is not decomposed completely.)
• Does each activity result in a deliverable and have someone accountable for completing the activity
on time, within budget, and of the quality acceptable?
If the answers to these questions are yes, the WBS is complete.

Project Network
The WBS defines the tasks logically; then the network organizes them sequentially. Every work task in the
WBS must also appear in the network. The network analyzes the sequence of task execution and portrays it in
a diagram to ensure that the team is in agreement about the sequence. The team must feel that the sequence
provides them with all prerequisites to their tasks. The objective of the network is to portray visually the
relationships of work activities to each other. A network demonstrates these relationships and communicates
them more clearly to project team members and to managers than any other technique.
There are two options for producing a network: (1) Draw the network free form (a right-brained, visual
approach) or (2) determine the immediate predecessor(s) for each activity (left-brained, analytical approach)
from which the network is generated.
Figure 5-2. Work breakdown structure tree chart for a sample project.

Visual Approach
In order to create a visual network, go back to the WBS and separately label each of the work tasks. You may
choose to produce labels on gummed slips (as we mentioned in Chapter 4, this is our favorite), 3 — 5 cards, or
magnetized labels for a magnetic board. The specific tool is not important. What is important is that your
labeling method allow team members to arrange and rearrange the network flow in as many ways as possible.
The basic sequential flow of the network usually follows the sequence of major work assignments from the
WBS”but not always, since the project team is analyzing how the work tasks can best fit together in a whole
project, not just the work assignment areas themselves. Once the labels of work activities have been arranged,
you can draw arrows between each work task (Figure 5-3), a useful way to show a network when team
members are visually oriented.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Analytical Approach
Title

In this approach, define the most immediate predecessor(s) for each work task on the work breakdown
structure, and then prepare a dependency analysis worksheet that can be translated to a network (Figure 5-4).
For each task, ask, “What task(s) produces the deliverable I need to begin this task?” Your answer will be the
----------- immediate predecessor(s). In Figure 5-4, Task A, assess requirements, must be completed before Task B,
design business system, can begin. Therefore, Task A is the immediate predecessor for Task B.
Another name for this technique is dependency analysis. The key purpose is to review the relationships
among work tasks within the project. Some tasks must be done in a sequential order; for example, the
electricity must be compatible before the equipment can be installed and tested. Other tasks can be going on
simultaneously”for example, preparing an implementation checklist while development continues.
In order to analyze dependencies and ultimately produce a network, isolate the lowest level of work tasks on
the WBS. Assign an identification number or letter to each work activity. (Keep the numbering scheme as
simple as possible so that it is not a burden later in the project.) Then determine the immediate predecessor(s)
using a dependency analysis worksheet (Figure 5-4). What is the first task that can begin this project? Put a
hyphen in the Immediate Predecessor column beside this task (or tasks if there are more than one) to indicate
that it has no predecessor.
What task could begin upon completion of the beginning activity? Write the identifiers for that
predecessor”in this case, beginning task(s)”on the line beside the corresponding task. What task could be
going on at the same time as this task? This task is now assigned the same predecessor as the previous one
discussed. When there are no other tasks that could be going on at the same time, ask, “What task could be
going on next?” Continue this process of chronologically walking through the project, but beware of
redundancy. Use only the most immediate predecessor or predecessors.




Figure 5-3. Network of interdependent tasks.
Figure 5-4. Task list with dependencies.
Next, validate the dependency analysis worksheet. All task identifiers must appear in the Immediate
Predecessor column unless the task is one of the last in the project. Look down the Immediate Predecessor
column and determine if every work task identifier (in your WBS) appears. If it does not, ask, “Is this one of
the final tasks of the project?” If the answer is yes, the WBS is validated. If the answer is no”that is, it isn™t
the last or one of the final tasks in the project”you have forgotten to make it a predecessor to something.
Check your logic.
Now plot the work tasks onto the network. Draw a Start box on a blank sheet of paper in the vertical center
toward the far left of the paper (the planning chart will branch to the right, top and bottom). At the Start box,
burst all of the starting work tasks. In our example, we have only one starting task, Task A. Draw a
dependency arrow from the Start box to each of the starting tasks (again, work tasks with no predecessor).
Build the chain by taking any task (or combination of tasks) now diagrammed on the network and searching
for them in the immediate predecessor column. When you find them, expand the network accordingly. Let the
immediate predecessor column drive the interpretation onto the network. You are developing a series of
chains; each activity that appears on the network is merely a link in that chain. Once the link is attached to the
chain, the Immediate Predecessor column tells which link or links must be attached next. Figure 5-3 shows
how to use multiple dependency arrows when two or more activities burst out or converge; Tasks C, D, and E
all share the same predecessor, Task B. Use the following guidelines when developing the network chart:
Guidelines for Developing a Network Chart
• Don™t worry about time estimates or drawing the network chart to scale. Concentrate on the
relationships. The chart aesthetics can be improved later.
• Make sure there is only one Start box and one End box.
• Do not allow any task to dangle. Every task must connect to another task or to the start or end of the
project. In other words, every task must be integrated into the framework of the network chart. If
several tasks are all ending tasks, tie them together to one End box.
• Indicate key go/no-go points in this network chart.
• Remember that this is a communication tool; it must be clear to all who use it.

Estimating Techniques
Estimating is not your best guess. It is not trying to reach a challenge. It is not succumbing to somebody else™s
demands. Here are a few more examples of what estimating is not: an estimate is not what we estimated the
last time; not what we estimated the last time plus how much we slipped; not a conservative number with lots
of padding; not taking someone else™s estimate and then doubling it, and then increasing the units of time by
one; not providing the expected or “right” answer.
Remember, the word estimate is defined in Webster™s Tenth New Collegiate Dictionary as “an opinion or
judgment of the nature, character, or quality of a . . . thing” or “a rough or approximate calculation.” Many of
us think of an estimate in these terms. However, the dictionary also defines an estimate as “a numerical value
obtained from a statistical sample and assigned to a population parameter.” That means that an estimate can
and should be more than a guess, educated or otherwise. We will look at a technique that can make your
estimates more credible (with exertion and effort, though).
Estimating in project management is a forecasting technique for determining the amount of effort time and
elapsed time required to complete the work tasks of a project. We are attempting to forecast or predict how
long the actual effort or work will take, how many human resources will be required, and the elapsed time or
duration for completing the tasks.
Figure 5-5 shows a framework for developing a forecasting model. In order to determine the effort time and
elapsed time required to complete a project task, we need to consider the key variables that affect it. (Effort
time is defined as the amount of a person™s actual effort given to the task. Elapsed time is the duration
between when the task begins and ends.) For example, in the blank circles marked with directed forward
effort, we could write the key variables that affect our estimates of the time to complete some of the work
tasks in our sample project. Typical variables are the expertise or skill level necessary to perform the task(s);
the job knowledge required before a team member can become productive; the number of people working on
the task; or the number of tasks a single team member is working on simultaneously. In the blank circles
directed forward effort, we could write the key variables that affect our estimates of the elapsed time
necessary to complete some of these tasks. Typical variables are waiting for approvals, waiting for vendor
shipments, and dead time.


Previous Table of Contents Next




Products | Contact Us | About Us | Privacy | Ad Info | Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management
by Joan Knudson and Ira Bitz
AMACOM Books
ISBN: 0814450431 Pub Date: 01/01/91

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Critical Path Analysis
Title

The critical path is the longest sequential series of tasks leading from the start to the end of the project. It is
important to identify the critical path because a delay in any task on it could delay the entire project.
Moreover, should someone request a shorter time frame, you could use a backward planning approach to the
-----------
critical path and compress it, or during the project, you could manage by concentrating on critical path tasks.




Figure 5-5. Forecast method.
In order to determine the critical path, post the elapsed time estimate for each work task to the network
diagram. Figure 5-6 illustrates the network with an accompanying key. This key provides a useful and
efficient way to calculate the critical path as well as various start and finish times. The elapsed time estimate
for each task is written in the top left corner of the bottom quadrant (we will explain the remaining key
indicators shortly). Add the elapsed time estimate for tasks along every path to determine the longest path.
This path is the critical path and represents the estimated elapsed time of the project (symbolized by TE). In
the example (Figure 5-6), the critical path is A-B-E-H-I, and the total elapsed time for the project is 10.0
months. The noncritical paths in this network diagram include A-B-C-F-I (with an elapsed time of 8.5
months), A-B-D-G-I (with an elapsed time of 7.5 months), A-B-C-F-J (with an elapsed time of 7.5 months),
A-B-D-G-J (with an elapsed time of 6.5 months), and A-B-E-H-J (with an elapsed time of 9.0 months). Keep
in mind that tasks A, B, E, H, and I are also tasks on the critical path.
Now let™s look at the other key indicators on the critical path.




Figure 5-6. Task sequence and critical path.
Suppose you want to determine the earliest start and finish dates for the critical path. How would you
proceed? Look at the two boxes in the top row of the key on Figure 5-7. In the box on the left side, record the
early start times for each task, and in the box on the right side, record the early finish times for each task.
Early Start (ES) can be calculated by posting zero for the starting tasks (those with no predecessors) and using
the early finish times of the previous task. Early Finish (EF) can be calculated by adding together the early
start time for each task and the same task™s elapsed time estimate.
Let™s work through an example. Assume that the start is Day 0. This is the earliest you could start Task A. If
Task A takes one month, then the earliest that Task A could be completed would be one month from the start
of the project. In this case, Task B follows Task A. The earliest it can start is when the preceding Task A is
completed at 1. Therefore, Task B has an early start of 1, and because Task B takes 2.5 units of time, the
earliest Task B can be finished is 1 plus 2.5, which is 3.5. Keep in mind that the critical path™s early finish
always takes precedence over the other paths.

<< . .

. 6
( : 16)



. . >>