<<

. 2
( 5)



>>

model produces two deliverables: the work breakdown structure (WBS), which determines all the work
efforts required to bring the project to a successful completion, and the network, a sequence in which the tasks
should be performed.
The WBS is a framework in which to define the work tasks for the project. The work tasks are arranged in a
hierarchy of major categories (or phases) of work. Each category is then broken down into lower levels of
detail that describe the specific tasks necessary to complete the major categories of work. (We discuss the
details for developing these categories and work tasks in Chapter 5.)
Developing a WBS requires the contributions of the project team members. An effective method for
developing a WBS is to hold a group session where team members can freely brainstorm and discuss their
ideas. If a meeting is not feasible, interview team members one at a time or send out questionnaires. Keep in
mind, however, that a group session will always produce the best results. (At the end of this chapter, we
discuss in more detail how to set up and facilitate team meetings.)
Once the WBS has been completed, the team can develop a network showing the interrelationships among the
tasks. These interrelationships, or dependencies that the tasks have with one another, are typically referred to
as the relationship a predecessor task(s) has to a successor task(s). The relationship is determined by the
necessity of a predecessor task to be complete (or partially complete) before the successor task can begin; that
is, the start of the successor task is dependent on (or constrained by) the predecessor task. (We cover the
mechanics of developing a network in the next chapter.)

Step 3: Estimate and Schedule the Project
Estimating and scheduling focus on determining the duration, required level of funding, and required level of
resources for the project. Approaches to estimating are personal. Each individual has his or her own
techniques for developing an estimate of the effort required to perform a task and duration to complete the
task. Some organizations have estimating procedures for use by the team, but most do not, so teams typically
are left to their own devices to develop the task estimates, and the project manager is provided with minimal
guidance for review and confirmation of estimates.
Most estimators begin by estimating the person-hours required to perform a task. This number becomes the
basis for an estimate of elapsed time. Next is the determination of direct costs; these are the person-hours
multiplied by the charge-out rate of that grade of personnel. Finally, when capital assets are required to
perform the task, the type and cost to the project are determined. Estimating is a seven-step process:
Estimating Steps
A. Develop the task estimates.
B. Process the data into a preliminary plan.
C. Compare the preliminary plan to objectives.
D. Negotiate revisions to the estimates.
E. Negotiate revisions to the project objectives.
F. Make a go/no-go decision.
G. Prepare schedules and budget.

Step A: Develop the Task Estimates
The estimating data must be developed by the team members who are responsible for performing the work.
This ensures that estimates are realistic, that there is a commitment to the estimates by the team members, and
that the team will be motivated to meet the estimates. All estimates must first be processed into a preliminary
plan in which each task has a planned starting date and a planned duration. The team members furnish the
following data to you as project manager: the amount of time necessary to perform the work or effort of a
task; the amount of calendar time or elapsed workdays necessary to complete the work tasks; capital assets by
unit of measure to perform the task (e.g., purchase of equipment, special construction of facilities); and direct
costs by category to perform the task (e.g., labor and materials).
The most accurate estimates result when small increments of work are being estimated. A large or complex
task should be divided into subtasks for estimating, which can then be summed to the task estimate. Tasks can
be performed by varying numbers of persons, depending on the nature of the work and the manner in which it
is divided among the people involved. The team member should estimate each task based on the most
efficient number of persons needed to execute the effort. Later the estimate can be modified to deal with the
schedule or resource problems.
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



In preparing estimates, team members should take into account nonproductive time. This downtime factor can
Title
be based on the judgment of the estimator or can be a guideline from the functional manager. Given the nature
of their work, downtime varies from unit to unit. Since projects do not constitute the entire workload of most
functional units, persons assigned to a project must be expected to be diverted from time to time to deal with
functional work. This nonproject loss factor should be used in developing estimates for elapsed time. These
----------- diversions do not affect the project budget, since time spent on other activities is not charged to the project.
The impact on the schedule, however, must be accounted for in the estimates.

Step B: Process the Data Into a Preliminary Plan
The preliminary project plan consists of a schedule derived from the dependency relationships and the task
estimates. This schedule is prepared on a time-scale calendar chart showing when tasks are to begin, how long
they will take, and when they are planned to end.
The cost budget for the project can be produced by analyzing the tasks being performed during each unit of
time and dollars being spent for capital assets and direct costs. (The mechanics of how to produce the
schedule and budget are discussed in the next chapter.)

Step C: Compare the Preliminary Plan to Objectives
If only a technical objective has been established, cost and schedule are now negotiated by you with senior
management. In most cases, the project objectives are determined by senior management and the client before
the project is assigned to you. The technical objectives are a constant. They are the same for the schedule and
budget established by senior management and for the preliminary project plan you and your team established.
The comparison undertaken is (1) between the completion date established by senior management and the
planned completion date, and (2) between the senior management budget and the planned cost.
If the comparisons are within a reasonable range of each other, there is no need to perform the remaining
subtasks. Negotiations are not necessary when the plan incorporates the commitments of the team and meets
the expectations of senior management. If the comparison is unfavorable, you must proceed to Steps D, E, and
F.
If senior management did not establish a due date for the project and/or a maximum cost, then proceed
directly to Step F and negotiate this with senior management. If the comparison is unfavorable because senior
management has allowed too much time or too high a budget for the technical objectives, you may proceed
directly to Step F and negotiate a reduction in the funding and an earlier anticipated delivery date for the
project. Step E in the estimating process is performed only if the preliminary project plan exceeds the
expectations of senior management.

Step D: Negotiate Revisions to the Estimates
This step is performed if the preliminary project plan exceeds the senior management™s and client™s schedule
and cost objectives. Perhaps senior management has established the objectives based on incomplete
information or an out-of-date historical model. Regardless of the cause of the problem, you must attempt to
reconcile the plan and the objectives through negotiation.
You may feel that the path of least resistance is to ask the client and senior management for additional time
and funds for the project. But be aware that it is not considered appropriate to make these requests until the
plan has been thoroughly reviewed and it has been determined that there are no excesses in it. Usually some
facets of the plan can be modified, and some change in the schedule and cost targets is possible.
The organization needs to be committed to realistic cost and schedule objectives. However, there are dangers
in negotiating estimate revisions, since considerable effort has been exerted to ensure that the project team is
committed to the estimates and motivated to adhere to them. The negotiation of revisions can cause the team
to lose this commitment and motivation. The result may be a set of estimates indicating that the project can be
completed by the due date and within the budget but that the team does not see as credible. Therefore, use
caution in the negotiations. Make sure that the members of the team do not alter the estimates in a manner that
renders them impossible to achieve. (We discuss different types of negotiated revisions in the next chapter.)

Step E: Negotiate Revisions to the Project Objectives
This step is a result of one of two sets of circumstances: (1) You approach the client and senior management
for the first time in order to negotiate a schedule deadline and a budget because these were not established
when the project was initiated, or, more commonly, (2) you realize there is an incompatibility between the
preliminary plan and the project objectives that cannot be eliminated by negotiating estimate revisions (Step
D).
In the first case, when you approach the client and senior management for the first time, the negotiations
should be simple and straightforward. Present the plan for senior management™s reaction and determination of
whether the time frame and cost are consistent with corporate objectives. This results in an immediate move
to Step F, the go/no-go decision.
In the latter case, the negotiations are more complex. Assuming that Step E is being undertaken because the
objectives do not include sufficient time and/or funds for the project, there are four alternatives for
management to consider:
1. Alter the schedule and cost objectives, so that you have sufficient time and funds to accomplish the
work. You will have to assure management that the revision results in a project that is economically
viable and will produce an acceptable return on investment (ROI). (This alternative will not be
acceptable in the absence of such a return, unless the situation is one in which an external requirement
or regulatory requirement is being fulfilled by the project and cannot be fulfilled in a more
cost-effective manner.)
2. Develop a reduced set of technical objectives that can be accomplished within the time and funding
limitations established by senior management. If you recommend this approach, senior management
will seek assurances that the proposed product will nevertheless meet market expectations and provide
an acceptable ROI.
3. Implement a combination of the first two alternatives. Recommend a modest increase in time and
funding, coupled with a small reduction in the technical objectives. If you recommend this solution,
management will want the same assurances as in alternatives 1 and 2 above.
4. Cancel the project. If you believe that the ROI cannot be increased to become attractive or that the
product will fail to meet market expectations, this recommendation is the best choice. Management will
seek assurance that all approaches to achieving the objectives have been explored before approving
cancellation.


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



Regardless of the alternative you recommend and senior management decides on, there are only two
Title
acceptable outcomes to this process: (1) a plan acceptable to you, the project team, the client, and senior
management or (2) cancellation of the project. There is one other possibility, however”one that we do not
encourage: taking on the project on a best-efforts basis, without changing the project objectives. This
approach only postpones the time when the true cost or time needed to complete the project must become a
----------- concern of senior management.
If Step E is being undertaken because the project objectives include an overabundant amount of time and/or
funds, there are thee alternatives:
1. Senior management might reduce the time and budget, with provisions for contingency plans. They
will want assurances that the funds taken from the project will not be required later.
2. The technical objectives could be adjusted at no increase in the time and funds allocated.
Management will want assurances that any added scope will not cause schedule or cost problems later
in the project.
3. Senior management might attempt a combination of the first two alternatives: a modest decrease in
time and funding coupled with a smaller increase in the technical objectives. If you recommend this,
senior management will want the same assurances.
Regardless of the alternative you recommend and senior management adopts, there is only one acceptable
outcome: a plan acceptable to you, your team, the client, and senior management. The other possibility”a
best-efforts approach to the project”does not apply in this situation.

Step F: Make a Go/No-Go Decision
A management review should be conducted when the plan is completed. The scope is evaluated to confirm
that the appropriate product will be produced, and the cost, schedule, and resource allocations are reviewed to
ensure that they fall within the project boundaries. Then the plan is revised as required. There is a possibility
of a no-go decision at this time if the costs are considered excessive in relation to the projected benefits, if the
resources will not be available, or if the project does not fit in with management™s strategic goals and
objectives.

Step G: Prepare Schedules and Budget
The preliminary plans developed in Step B can now be finalized. These final plans consist of three report
documents: a schedule (which portrays when each task begins, its duration, and its end date on a time-scale
calendar), a resource utilization chart (which indicates the allocation of each team member or pool of team
members per unit of time), and a project budget in the form of a spread sheet or graphic representation. We
thoroughly explore the techniques required for producing these documents in the next chapter.

Step 4: Balance the Plan
Balancing is the most challenging stage in developing the plan. Balancing limited resources of the plan should
occur within the project and against other project and nonproject efforts. Projects compete with each other and
with nonproject work for two scarce commodities: human resources and funding. The typical organization
lacks sufficient staff to perform all project and nonproject work approved by senior management and
sufficient funds to perform all needed work. For these reasons, balancing is critical.
Frequently organizations apportion their funds so that approved projects are adequately funded. A lesser
number of organizations allocate human resources by dividing the staff into pools or groups, one of which is
available for projects. But regardless of how the allocation between project and nonproject work is made,
individual projects compete for the limited human resources and funding available. The priority of the
projects influences balancing. Before balancing between projects can occur, there is a need for balancing
within each project.
Balancing a single project can help to ensure that its personnel demands do not exceed the organization™s
capacity. Time-phased resource and asset utilization plans can be laid out in tables or graphs and can be
produced by project management software packages. If a team member is overcommitted, then you as project
manager (in conjunction with the functional manager when necessary) need to analyze the reason for the
overcommitment and to resolve the problem by using resource balancing (leveling) techniques.
In an organization with a significant project workload, management of resource supply versus demand is a
key concern. Some resources are elastic in that supply can be readily increased to meet demand. Others are
nonelastic and a significant lead time and/or cost is necessary to increase supply in order to meet the demand.
Supply versus demand reporting should be performed for both elastic and nonelastic resources. When there is
a significant difference between supply and demand, balancing, or leveling, is performed.
Resource leveling requires knowledge of anticipated supply and demand. Supply is typically determined by
looking at the current size of the resource pool available and projecting changes to that pool over the period of
the forecast. Demand is calculated by adding the requirements of all approved projects to the nonproject
workload of the organization. Supply and demand are examined over a period of months, and periods of
underutilization and overutilization of resource pools can be identified. Resource leveling occurs with the
attempt to reduce demand during a period of forecasted overutilization or to increase demand during a period
of forecasted underutilization. (We illustrate the details of leveling in the next chapter.)
Once individual project balancing has occurred, project needs are balanced with those of previously approved
projects. Multiproject balancing can be performed manually, although the amount of data to be manipulated
makes it complex and time-consuming. Balancing can be automated by delegating the decision making to a
computer algorithm. The most effective approach may be computer-assisted balancing, where management
utilizes the software as a decision support tool to achieve the required balance. Multiproject reports, based on
the entire workload of the organization unit, are produced to support this step. Omission of any component of
the workload from the reports renders the entire process meaningless. Several components of these data are
the responsibility of the functional managers (e.g., the percentage of time allocated for administrative activity,
nonproject activity, and vacations).


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



Step 5: Approve and Publish the Plan
Title

At this point, a document recording the plan targets (target completion date, target cost, target resource
utilization, and target asset utilization) and the objective maxima (latest completion date, maximum cost,
maximum resource utilization, and maximum asset utilization) should be prepared. This is the agreement
----------- among the project manager, the project client, senior management, and functional managers (where
appropriate) and serves as a basis for negotiating changes in scope during the project, as well as measuring the
team™s performance. These agreements should be signed by the appropriate parties and distributed. Keep in
mind, though, that this stage of the planning process cannot begin until balancing is complete.
Obtaining commitments for project funding is a complex undertaking. When projects extend beyond one
fiscal year, obtaining a commitment for the total funds required may be impossible. In many organizations,
funding commitments are made on an annual basis. Where the availability of funds has been determined
during the balancing stage, securing the fund commitment should be a formality. If difficulties arise in this
effort, revisiting Step 4 may be required.
In essence, obtaining commitment is the acid test of your performance in developing an integrated plan. If the
process has been followed exactly, obtaining functional manager commitments to the plan is a pro forma
exercise since their ability to make the commitments has been determined in the balancing stage, and any
resource problems have been resolved. However, if you have not adhered to the planning process, the
functional managers will refuse to commit to the resource plans, and you will have to repeat portions of the
planning process. The formality of placing the functional manager™s signature on a commitment sheet, to be
used as a cover sheet for the plan, should be all that is involved in this step.
Similarly, obtaining senior management approval should be a pro forma exercise. Management has already
reviewed the plan, and now, more than likely, they want to determine if the functional managers™
commitments have been obtained before signing the cover sheet. Since quality assurance is a major thrust of
management, the plan may be checked to ensure that there are adequate reviews of milestones for the end
products. Once senior management has approved the plan, changes to the plan must be managed. (This is
discussed in Chapter 6.)
The final step in the planning process is distribution of the integrated plan to the team, management, and other
interested parties. The schedule, resource, asset, cost, and achievement plans should be graphic in nature for
effective communication. Typically, work on the project begins during the planning process because many
projects have extremely tight schedules. But once the plan is completed, the team begins working from it
rather than on an ad hoc basis.

Strategic Planning
In order to implement the five-step planning model, a strategy for managing the conceptual versus detailed
planning is necessary. Conceptual planning is usually referred to as top-down planning, whereas detailed
planning is referred to as bottom-up planning. Most organizations do both. However, when a top-down plan
is prepared and presented to the client, who then accepts it, the project parameters of schedule, resource
requirements, and budget are often set in concrete. Often when the bottom-up plan is completed, it does not
match the committed parameters stated in the top-down plan.

Top-Down and Bottom-Up Planning
Top-down (or conceptual) planning begins with the development of the project™s technical objectives. The
technical objectives may be very detailed, or they may simply identify the major characteristics of the product
anticipated from the project. Top-down planning includes the development of a preliminary work breakdown
structure, which is not completed until later, during bottom-up planning. Once the major work tasks in the
WBS have been identified, estimates that are based on intuition or historical data are prepared and then used
to assemble the top-level project plan.
Bottom-up (or detailed) planning also begins with the development of a set of technical objectives for the
project; however, the technical objectives must be very detailed. Bottom-up planning also includes the
development of WBS. The WBS is completed down to the level of detail for each task that must be performed
in order to achieve the project objectives. Then estimates are assembled, from the bottom up, by the members
of the project team. Finally, the detailed project plan is assembled from the estimates.
Let™s work with an example. In Figure 4-1, the need or requirement for the work to be performed is illustrated
in the triangle. This triangle can be used to characterize the results of top-down and bottom-up planning. After
the client has developed a scope for the project, a partial WBS is formulated, presenting major elements of the
effort required. Then a cost and schedule objective for the project is established, from the top down, based on
the partial WBS and a host of factors external to the project, such as competitors™ faster time-to-market rates.
Figure 4-2 shows what can happen if only top-down planning is done. In this case, the WBS is only partial
and does not contain all of the tasks needed at a level of greater detail. The resulting project coverage,
provided by the WBS and estimate, contains no work that is irrelevant, but it may fail to contain certain
elements of work essential to meeting the project™s technical objectives.




Figure 4-1 Effort required to achieve the project objectives.
If the idea for the project is transmitted to the project manager and team without the benefit of top-down
planning, there may be a lack of direction on the project. Figure 4-3 shows what can happen if the project
manager elects to prepare only a bottom-up plan. All of the detailed elements of the work have been
identified, but included with them are a number of elements of work that are not essential to deliver the
technical objectives of the project. In addition, there is no strategic hierarchy of planning elements, an
oversight that will affect the manner in which the project is controlled. The cost and schedule objective for the
effort includes these unnecessary elements of work.
A combination of top-down and bottom-up planning will produce a radically different and much improved
result. After a top-down plan has been prepared, giving the project strategic direction and focus, and perhaps
after the effort has been approved, a detailed, bottom-up plan is completed. This planning effort begins with
the partial WBS prepared in the top-down planning effort. Then the WBS is fleshed out, and bottom-up
estimates are prepared for each work element. The result is a focused plan (Figure 4-4) in which top-down
planning provides the strategic focus, and bottom-up planning provides the detailed coverage. In order to
assemble a project plan that is thorough and contains all of the elements of work necessary to meet the project
objectives, but without containing unnecessary work, both top-down and bottom-up planning are necessary.
The two approaches complement each other and yield a plan that is most likely to reflect the true requirements
of the project.
Figure 4-2 Effort covered in the top-down plan.




Figure 4-3 Effort covered in the bottom-up plan.




Figure 4-4 Effort covered in a combination of top-down and bottom-up plans.


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



There is a potential problem with the combined use of top-down and bottom-up planning, however. Often
Title
top-down planning is used as the basis for seeking project approval. The schedule and budget developed as
part of the top-down planning process are presented to senior management and/or the client to obtain their
approval for the expenditure of funds on the project. This is convenient and makes economic sense, because
the cost of developing the top-down plan is significantly less than that of the more detailed, bottom-up plan.
----------- But if the top-down plan is used as the basis for obtaining funding, there is no guarantee that the funding or
time frame approved for the project will be adequate until after the detailed, bottom-up plan has been
completed. We know of several instances in which there has been a considerable discrepancy between the
totals of the top-down plan and the totals of the bottom-up plan. How can this problem be avoided? The
answer is quite straightforward: by employing a rolling wave (or phased) approach to project planning.

A Rolling Wave Approach to Planning
How often have you been asked for estimates of the duration and cost of a project before thoroughly
understanding the scope and objectives of the effort that will be required? How often have you been correct?
Although assured that these estimates were only rough figures, how often were these top-down planning
figures set in concrete, never to change? What can be done to structure a more realistic alternative? Consider
an analogy.
You are an expert mountain climber standing at the bottom of an imposing mountain you have never seen
before. It is your job to climb this mountain and reach the bottom on the other side. The person who is
funding your expedition asks, “How long will it take to get to the other side of the mountain, and how much
money do you need?” Your thought processes are, “How do I know how long it is going to take to get to the
other side or how much money it will cost? I have never seen this mountain before.”
Would an “I don™t know” answer be satisfactory to your client? Probably not. You were hired because you are
an expert mountain climber and are expected to produce reasonable answers. If you shoot from the hip, the
accuracy of your guess will be suspect, and sooner or later you will have to confront your error. This is
top-down planning at its worst. There is no time to produce a bottom-up plan, but you know you will be held
accountable to the commitments made in the top-down planning process. You seem to be caught in a lose-lose
situation. Is there an alternative?
Consider the rolling wave approach illustrated in Figure 4-5. At the beginning of the wave, or climb (using
the mountain climber analogy), you are standing at the bottom of the mountain with minimal knowledge of
what is confronting you. But with your mountain climbing background and experience, combined with
historic data gathered from other people who have tried to climb this mountain, you approximate the time and
resources required. Note that the term is approximate, not estimate. This approximation should be presented
in a way that provides you with as much flexibility as possible. For example: It will take six to nine weeks to
climb the mountain, require ten to twelve people, and cost about $50,000, plus or minus 15 percent. These are
your top-down estimates. Because you are giving yourself room to alter your approximations over the life
cycle of the project, this approach suggests that the planning process rolls out detailed plans for the
foreseeable future and, as the project evolves, periodically reevaluates the schedule and budget developed in
the top-down planning process.




Figure 4-5 Rolling wave approach.

Simultaneously, provide the project client with a plan detailing everything required to prepare the party to
start moving up the mountain. Consider determining the necessary equipment, pinpointing the right people,
acquiring and studying information about this particular mountain, and plotting a route. This is called
scheduling through the first planning horizon. A planning horizon is described as planning out as far as you
can see. The target may be stated as number of days, the next phase of the project, or when the next major
milestone is reached. Up to this point, you have provided the client with a top-down plan of the time and
resources necessary to finish the total effort and a detailed estimate for the first planning horizon.
Now the benefits of rolling wave come into effect. In the mountain climbing analogy, once the equipment and
people required to make the climb have been selected and the route is mapped, planning the next phase
begins. This step, which is to acquire the resources and prepare for the start of the climb, is relatively easy.
Furthermore, the approximation of time and resources at this stage can be refined with a higher level of
accuracy and greater confidence. At each subsequent reevaluation, the projections of the final deadline and
dollars become more realistic. Eventually enough information will become available and the scope and
objectives well enough defined to prepare a bottom-up detailed plan for the remainder of the project. You
control using the detailed plan established for the first planning horizon. At the end of each phase, many
unknowns have been resolved, and many decisions have been made.

Saving Time and Funds With Historical Files
Over time, many projects bear a striking resemblance to others your organization has previously executed.
The planning process that we have described thus far is “from scratch”; we have used no historical data from
prior projects. When relevant historical data exist, planning can be accomplished more quickly and more
cheaply. A central repository for files coupled with expertise in the approach to project management is a
valuable asset.
Historical files, however, can be a two-edged sword. They can provide marvelous benefits; but if history is
used extensively and the members of the team do not participate in the review and modification of the
historical data being used, the team may lose a sense of ownership, commitment, and motivation. Moreover,
there is a tendency when using unedited history to repeat bad performance since the historical data may have
failed to set objectives correctly in the first place. The team must edit all historical data.
Even if there are no relevant historical data, the development of an integrated project plan may not be
completely from scratch. An organization that has a product development methodology or cycle can use it as a
generic work breakdown structure. Keep in mind, however, that every phase, task, and milestone included in a
generic work breakdown structure is not required on every project. The team must edit the generic model
much as they would edit a historical project of a similar nature in order to develop a sound plan with
meaningful commitments.


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



Facilitating the Project Planning Process
Title

It is probably obvious by now that one of your key roles as project manager is to facilitate the project
planning process. You must produce a schedule plan, organize functional representatives into a workable and
effective project team (we use the term organize to indicate that a project team is created not by magic but by
-----------
the use of consciously employed consideration and concentration), and prepare the project team for
postplanning roles and responsibilities.
“To facilitate” means to make something easier. In the case of the planning process, it means to ease the use
of project management tools in the building of a project team. Facilitating is leading others through a process,
sometimes referred to as indirect training, that culminates in the development of concrete deliverables. The
objective is to assist project team members in working through the planning process in order to develop the
schedule, resource plan, and budget.
The facilitation process requires you to elicit or draw information from the team. To accomplish this, you
must put team members at ease. The team members should know who is on the team and why, what will be
expected of them in meetings, and that you will guide them through the process. This facilitation is best
accomplished through private meetings with each team member in advance of the first team meeting.
Project communication meetings are integral to the planning model. The number and length of these meetings
will vary according to the size and complexity of the project, as well as the level of knowledge that team
members bring to the project. For some projects, the sequence of communication meetings necessary to
produce the project plan may be quite short”perhaps even a few hours. For others, significant amounts of
time between meetings may be required for team members to develop additional data and levels of work
detail. In other words, adapt the following agenda of team communication meetings to your own situation.

Meeting 1: Orient and Prepare the Project Team
You need to reach agreement on the objectives of the planning process with the team and demonstrate your
capacity and willingness to help. Therefore, the objective of the first project communication meeting is to
define the roles of team members, describe the project goals and the function of the communication meetings,
and discuss how you will achieve these goals. It is important that you involve the team members in
determining the agenda for future meetings so that they will attend these meetings and support the planning
process.

Meeting 2: Develop Objectives, Scope, and Work Breakdown Structure
Prior to this second meeting, provide team members with a clear statement of goals for the meeting,
appropriate reading materials, and assignments. The reading materials should include the business case that
initially justified the project (if one had been created), a statement of work defining the goals and objectives
of the project, and the proposed first level of the WBS. Team members should be requested to review the
business case and project goals and objectives, to document their role in meeting the objectives, and to isolate
the first level of work effort in which they see themselves involved and develop a second level of their work
breakdown.
The meeting itself addresses the project objectives and goals. They should be discussed openly by the team,
with comments and questions thoroughly addressed. The scope of the project is the next item. At this point,
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.
In order to calculate the late start and late finish dates for the critical path, refer to the two boxes in the bottom
row of the key in Figure 5-7. The latest date on which each task can finish (LF) is the late start of the
succeeding task. The latest date on which each task can start (LS) is the late finish of the preceding task minus
the elapsed time. For example, the sample project ends at Month 10, so the late finish for each of the final
tasks, I and J, in our example is 10 (Figure 5-7). The latest that each task could be started is the late finish of
the task minus its elapsed time. For example, Task I has a late finish of 10 and a late start of 8.5, which was
derived by subtracting its elapsed time, 1.5, from the late finish, 10. Moving backward on the path, the late
finish of Task F is the late start of Task I, or 8.5.
There is one more important calculation to make regarding the sequence of tasks surrounding the critical path:
float. Float is the leeway time existing within noncritical path tasks. Technically, float is the difference
between the late finish and early finish times for tasks on noncritical paths. In Figure 5-7, the float
calculations for each task are recorded in the top right-hand corner of the bottom quadrant. For Task J, the
float is 1.0 month (late finish of 10.0 months minus early finish of 9 months). Keep in mind that float occurs
only on noncritical paths. Did you notice that the ES, EF and LS, LF are the same for tasks on the critical
path? Also, two or more tasks on the same noncritical path will calculate the same float, which they must
share. So the float time of 1.5 months for Tasks C and F must be shared between them, and the float time of
2.5 months for Tasks D and G must be shared.




Figure 5-7. Development of early start, early finish, late start, and late finish.

Scheduling
The major objective of a schedule, sometimes referred to as a Gantt chart, is to place the data from the
previous four techniques”the WBS, the network, the estimates, and the critical path analysis”on a time
scale. In order to develop a comprehensive time scale, it is important that we see when work tasks start and
end, which are critical path tasks, which tasks have float and where it has been allocated, and what the
dependencies of tasks are to one another.
In order to plot the schedule, use a calendar format similar to the one shown in Figure 5-8. The units of time
are recorded along the horizontal axis and the task identifications are recorded along the vertical axis. In our
example, we have ten months of time and ten work tasks (A-J). Beginning with the critical path, plot Task A
on the schedule with an up-triangle indicating the early start (zero in this case) and a horizontal line drawn to
a down-triangle indicating the early finish (one month). Continue plotting the tasks on the critical path (B, E,
and H), being sure to connect each work task vertically with its immediate predecessor(s). When you come to
the first critical path work task that has input from a noncritical path(s) (Task I in our example), plot the
parallel noncritical paths (C, F and D, G) before plotting this next task. Use slash lines to depict the float at
the end of the noncritical path(s), unless you have determined another special allocation. In our example, the
float for Tasks C and F (1.5 months) begins at the end of Task F (Month 7) and continues to Month 8.5.
Similarly, the float for Tasks D and G (2.5 months) begins at the end of Task G (Month 6) and continues to
Month 8.5. Work in this fashion until all activities have been translated to the schedule. In this way, we have
planned to complete the tasks (except Task J) as soon as possible and to use the float at the end of our project.
We have decided to put Task J on its late schedule since training is best done just before people need to use
the skills. As a result, Task J is now added to the critical path.
Initially, during planning, the float can be used as a buffer to manipulate the schedule to be more compatible
with resource availability. Later, during monitoring and controlling, float tells you when a particular task may
be in jeopardy. If a task has no float, it is on the critical path. If a task has slipped, using up all of its float, it is
behind schedule, and you must find a way to recoup that time on the critical path. If the task has float and it is
behind schedule, watch that task carefully. If the task has used all its float time and is stretching beyond that,
recognize that it has become a critical task, with a changed critical path, and will affect the completion of the
total project. Not only must you ensure that this activity is completed as quickly as possible, but those
responsible for succeeding activities dependent on that late task must be informed. The lost time must be
made up in one of the succeeding activities to complete the project on time.




Figure 5-8. Project schedule.


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



Resource Loading
Title

Resource loading is used to determine how resources will be allocated over the duration of a project and how
to verify that they are being allocated correctly. In other words, the purpose is to ensure that no team members
are ever overloaded. There are several options to determine resource loading:
-----------
1. Verify by name of employee that the number of activities (or projects) any one person (or pool) is
working on simultaneously is reasonable. For example, according to the diagram shown in Figure 5-9,
Marie Scotto (MS) appears to be very busy during the middle of the project.
2. Sum the percentage of time each team member plans to commit to each activity (or project) in a
single time frame in order to determine a total percentage greater than or less than the time the
individual has available. The diagram shown in Figure 5-10, for example, indicates that MS has
scheduled 150 percent of her time between Months 9.5 and 10 (summing vertically during this time
period would give us 50 percent of her time on Task I and 100 percent of her time on Task J).
3. Calculate the individual effort allocation for each team member. The diagram shown in Figure 5-11
points out that Marie™s time will be spent working on Tasks A, B, D, E, G, I, and J. The individual
effort estimate for her time on each of these tasks is posted vertically in the boxes falling under her
name. For example, her individual effort estimate for Task A is .1. This means that Marie will be
spending .1 effort months on this task. The total effort estimate of 1.0 for all team members is located
in the top box under the column heading Total Effort Estimate.
For the example, we have chosen to use 1.0 as a standard figure to represent forty hours of work, or one
week. This estimated forty hours of total effort for Task A is determined by summing the individual
effort estimates of the team members who will be working on this task”in this case, Joan™s .5 (twenty
hours) and the .1 estimate for the remaining team members (Bob, Guy, Marie, Jean, and Seth). If we
take this individual effort estimate for each team member on each task and divide it by the elapsed time
for the task, we will have calculated individual effort allocation. We will have dispersed the estimate of
each team member™s effort time over the elapsed time of the task. As a result, we now have a precise
measure for determining how team members™ times will be used for each task when posted onto the
time schedule.
Figure 5-9. Resource assignment posted on schedule.




Figure 5-10. Percentage committed posted on schedule, for Marie S.




Figure 5-11. Calculation of individual effort allocation for Marie S.
Let™s go back to Marie. The last column in the diagram Figure 5-12 shows Marie™s individual effort allocation
for the tasks she will be working on. Next let™s post these allocations to the schedule. You try. In Figure 5-13,
each team member™s individual effort allocations are posted above their corresponding task in the diagram.
Post Marie™s allocations above the tasks on which she will be working. Then for each of the major time
periods blocked out in the grid below the time schedule, write down Marie™s total individual effort allocation.
When you have completed these two steps, compare your answers with those shown in Figure 5-14.
As you can see, Marie will be working a total of .10 (or 10 percent of her time) during Month 1; .30 during
Months 1-3.5; .85 from Months 3.5-5; 1.18 during both time periods in Month 5; .18 from Month 6 to 7.5; 0
from 7.5-8.5; .33 from 8.5-9.5; and 1.33 during the last half-month of the project. The histogram in Figure
5-15 provides a picture of how Marie™s individual effort allocation is used over the life cycle of the project. (A
histogram is a graphic representation of how work effort changes over time during the project.) We have
graphed Marie™s effort allocation according to the vertical axis, designated FTE (full time equivalency). In
other words, 1.00 FTE is equal to forty hours of work. Anything above this marker is considered overtime;
anything below might be considered underutilization. Marie obviously is working overtime during Month 5
and the last half of Month 9.
Figures 5-16, 5-17, and 5-18 present the same resource analysis for the total effort allocation of the project
team. Later in the chapter, we will consider how to balance or level individual and team allocations.

Key Business Applications
Two business decisions often need to be made when applying planning techniques: making adjustments to the
schedule in order to meet mandated target dates and leveling or smoothing out overloaded resources.

Meeting Mandated Target Dates
Imagine that you and your team have produced a schedule. But then”for some legitimate or whimsical
reason”the client or senior management requires that the project be completed more quickly. What do you
do now?
The original duration of the project was determined by isolating the longest series (or path) of activities”the
critical path. Therefore, it is the critical path activities that must be shortened. This is commonly called
critical path compression. By compressing some activities on the critical path, you can shorten the duration
of the project. The major technique of critical path compression is to break a critical path activity into
overlapping tasks, a technique sometimes called fast tracking the project. There are five alternatives for fast
tracking:




Figure 5-12. Calculation of effort allocation for Marie S.
Figure 5-13. Calculation of effort allocation for Marie S.
1. Decompose the work even further. Break the critical path activity into subtasks, which are
scheduled, to the greatest extent possible, in parallel. The more subtasks that can be scheduled in
parallel, the faster the activity can be completed.
2. Alter the finish-to-start relationships. The relationships we have discussed so far have been
finish-to-start relationships; that is, one task cannot start until its predecessor task has been completely
finished. There are two types of finish-to-start precedence relationships: mandatory and judgmental. A
mandatory finish-to-start relationship cannot be changed without violating a law, regulation, or
corporate policy; therefore, it cannot be altered through negotiation. Even if the project schedule is
unacceptable to the client, mandatory finish-to-start relationships must be preserved. In our experience,
though, fewer than half of all finish-to-start relationships are mandatory. (The percentage tends to vary
from industry to industry; safety-related nuclear industry projects have a higher percentage of
mandatory relationships than almost any other industry.)




Figure 5-14. Calculation of effort allocation for Marie S.
A judgmental finish-to-start relationship is one in which the task owner of the successor task sees a risk in
overlapping the tasks. The finish-to-start relationship is a result of the team member™s believing that it is not
prudent to overlap the two tasks in question. This is a statement of professional judgment on the part of the
person responsible for the successor task. All other things being equal, it is wise for you to respect this
judgment of the task leader and to leave the finish-to-start relationship alone. However, when altering one or
more of the judgmental finish-to-start relationships makes the difference between undertaking or shelving the
project, it may be appropriate to negotiate revisions to these judgmental relationships.


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



You and the task owner must remember that altering the judgmental finish-to-start relationship represents an
Title
additional risk, which depends on the specifics of the tasks being overlapped. There is always a risk when
such action is taken; although the period of performance for the project may be shortened and the cost may
not increase, the decision has some potential to backfire, causing both a schedule delay and increased costs.

-----------




Figure 5-15. Individual resource loading histogram for Marie S.




Figure 5-16. Team resource availability.




Figure 5-17. Team resource availability and scheduling.




Figure 5-18. Team effort loading histogram.

Relationships that are judgmental can be reevaluated as partial relationships. There are several approaches:
1. Establish percentage dependencies in which the critical path activity requires less than 100 percent
of its immediate predecessor. For example, perhaps only 20 percent of the entire design process needs
to be finished before development can be started.
2. Try start-to-start relationships with a lag. The critical path activity starts at the same time as its
predecessor, with a predetermined lag or delay time. For example, development can start one month
after design has started.
3. Choose a finish-to-finish relationship with a lead. The critical path activity must be completed at a
specified number of time units before its successor is completed. For example, the design work must be
completed two weeks before the development is scheduled to be completed.
4. Reevaluate and break dependencies since dependencies indicate that one activity must be completed
before another can begin. For example, the design of the product is not going to begin until funding is
obtained. But what if there is a marketing window to be met? It may be wise to break the conservative
relationship of receiving funding before the start of design, starting the design at the same time that the
acquisition of funding begins. This option may put the project at a higher risk, but if the higher risk is
agreed to, the alternative is viable.
Implementation of any of these alternatives assumes that there are enough resources available to work on all
of the subtasks that would be going on in parallel.
3. Assign more resources. There are several ways to assign more resources to the critical work
activities. First, try to work within the resources already assigned to the project. Perhaps a project
member is not working on the critical path and could give the project more time.
You could analyze the noncritical paths to determine if any resource with the correct skill mix is available to
be reassigned to other, parallel critical path activities, thus shortening the duration of the critical path
activities. Remember that removing a resource from a non-critical path activity will lengthen the duration of
that activity and that the noncritical path may turn into the critical path.
If there are an inadequate number of people assigned to the project, recruit from within the organization or
from outside contractors. Continually reevaluate the extra dollars that these resources will cost the project.
Keep in mind, however, that the resources must have the appropriate skills required by the critical path
activities. Do not assign resources to an activity based upon their time availability alone.
4. Remove an activity from the critical path. This option certainly will shorten the critical path, but it
may also reduce the functionality of the end product or increase the risk of failure on the project.
5. Expedite a critical path activity. The duration of a critical path activity may be shortened by making
it more efficient or finding a faster way to get the job done. This may mean spending more money.
However, the additional cost may have a positive return on investment by getting the project done
sooner, with the benefits accruing at an earlier date. This does not mean slicing days off the estimate
with no thought of the reality of the new estimate.
Too often when the project planner is given a mandated completion date shorter than the derived critical path
time estimates, additional dollars and/or resources are requested as a knee-jerk reaction. Through the use of
some of these techniques, responding to a constrained time frame may be accomplished without spending
additional resources or dollars.

Resource Leveling
Leveling Within the Project
If there are resources that have been overloaded after they have been allocated, how do you level (or smooth)
them out?
When supply falls short of demand, there are a number of approaches to leveling:
• Tasks can be shifted or extended within their float. This may eliminate unacceptable peaks without
altering the cost of any part of the workload.
• Use overtime to meet the demand during the period of forecasted overutilization.
• Ask the team members to exert extra effort. Compensation or time off can be offered to staff
members working a number of hours substantially in excess of the norm.
• Augment the resource pool through the use of temporary help. (This is often not feasible, however,
due to the need to provide work space, tools, and facilities to the temporary workers.)
• Contract out a portion of the workload. This relieves the organization of the burden of providing
space, tools, and facilities, but it also potentially increases the cost of achieving the organization™s
objectives.
• Increase the size of the resource pool permanently. If the forecast of supply versus demand yields
multiple periods of overutilization well into the future, adding staff to the resource pool may be the
most effective approach to manage the workload.
• Select a portion of the workload to be delayed beyond its approved completion date in order to
eliminate the peaks in the demand for the resource. Performing this alternative, referred to as
resource-constrained scheduling, requires an understanding of the relative priorities of each component
of the project and nonproject workload of the resource pool.
When supply exceeds demand, some of these same approaches can be used to level demand:
• Tasks can be moved within their float to take advantage of the resource pool™s available time.
• Overtime can be eliminated, and any temporary help being employed by the organization can be
replaced with permanent staff.
• Management can consider reducing the size of the resource pool selectively if the forecast shows a
prolonged period of oversupply.
• Low-priority work can be moved up in the organization™s schedule to take advantage of the
availability of the resources.
There are two other possibilities that represent unique opportunities during oversupply:
• Use these periods to develop new methods for the cost-effective performance of the work of the
resource pool.
• Cross-train staff during these periods so that they can be allocated in the future to components of the
workload they are not now qualified to perform.


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



Leveling by the Functional Manager
Title

Resource leveling on the part of the functional manager is a key element in efficient and cost-effective
management of the organization™s project workload. In order to perform resource leveling well, the functional
managers must understand the objectives of the organization, be familiar with the relative priority of each
----------- component of the workload, and obtain the cooperation of project managers.
Problems of oversupply of resources and assets (underutilization) or excess demand for resources and assets
(overutilization) are solved in the same manner. The following approaches, all of which require negotiation
between the functional and the project managers, are helpful:
Solving Resource Utilization Problems
• Move tasks on any project, within float, to level demand.
• Alter the time-cost-resource mix to level the demand. (This may alter the cost of the task.)
• Use overtime to accommodate demand. (This may alter the cost of the task.)
• Use temporary help, under the supervision of the functional unit, to address demand peaks. (This
may alter the cost of the task.)
• Rent equipment to address peak demands. (This may alter the cost of the task.)
• Contract out a portion of the workload to address peak demands. (This may alter the cost of the
task.)
• Seek management permission to acquire additional resources or assets to address peak demands.

If the functional manager cannot resolve the problem with these techniques, the final alternative is to identify
the lowest-priority project that is contributing to the unacceptable peak demand and delay it. This may require
the approval of management and several group business managers, since it will alter an approved completion
date. Plan revisions that must be made to resolve resource and asset demand problems must be forwarded to
the project managers, so that they can produce updated plans. This step cannot be completed unless senior
management establishes priorities for project and nonproject workloads. Senior management tends to make
such priority decisions as they are required and to communicate them effectively. It is counterproductive to
level demand for resources over a long time frame. The only constant in project management is change, and it
is expected that demand for resources in future periods will change.
Project Budget
The purpose of a project budget is to take each category of one-time developmental expenses (budgeted) and
allocate it across the duration of the project, indicating when the dollars are committed or booked to be spent.
This step has two parts:
1. Allocate budget onto a cost spread sheet. Based on the resource loading, the resource (labor) dollars
required may be determined over time. Other categories of expenses may be spread across time and
summed to determine a complete budget. Figure 5-19 shows a periodic cost spread sheet in which the
budget is spread out on a month-to-month basis over the nine-month cycle of the project. Figure 5-20
shows a cumulative cost spread sheet in which the budget is spread out to date by period. Remember
that the cost spread sheet is cumulative period to date. Validate the cost spread sheet, remembering that
expenses can never decrease.
2. Plot the budget expenditures on a cost line graph in order to translate the cost spread sheet into a
graphic representation. Draw the grid with “Units of Time” along the top and “Costs” along the left
side of the grid, and plot the committed expenses in a line graph format (Figure 5-21). Create an
individual line graph for each category of expenses as well. Validate the cost line graph by checking
that it looks like an elongated capital letter S, or a straight diagonal, which is possible, but unlikely.

Risk Assessment and Contingency Planning
Risk is a certainty in project planning; managing it can be the pivotal factor in successful project
management. A sound approach to the management of risk requires an additional effort in planning but can
achieve a worthwhile return on investment. Risk analysis is a what-if exercise to identify areas of concern.
Contingency planning may mean making backup plans or more conservative scheduling of tasks and
resources.
One way to introduce the subject of risk assessment is to ask the project team members to describe the
unexpected things that have gone wrong during other projects on which they have worked. Perhaps
management introduced new priorities; the best people suddenly were not available; the budget was reduced;
another group or vendor was late; another group or vendor was over budget; another group or vendor made
something that didn™t work; or unforeseen technical problems appeared.
Isolate risk in the areas of the schedule (to include factors that may cause delays), resources (to include factors
that may threaten availability), finances (to include factors that may threaten the project budget), and scope (to
include factors that make the completion of the end product uncertain).




Figure 5-19. Periodic cost spread sheet.




Figure 5-20. Cumulative cost spread sheet.




Figure 5-21. S-curve/cost line graph.
Specific Risk Factors
Schedule
• Tasks on the critical path
• Tasks that have several predecessors
• Tasks that have minimal float
• Optimistically estimated tasks
• Tasks reliant on external dependencies, such as vendor shipments
• Major milestones
Resources
• Tasks with one individual working alone
• Tasks with many people assigned
• Tasks using scarce resources
• Underskilled or unqualified people
• Illness and turnover
Budget
• Uncertainty of funds
• Shifts in budget priorities
• Uncertain resource costs
Scope
• Uncertainty of new product development
• Dynamics of customer requirements
• Availability of tools and/or techniques
• Large number of defects

Follow these key guidelines for developing contingency plans:
Guidelines for Contingency Planning
Revise the schedule by:
• Negotiating deadlines of high-risk tasks to accommodate potential slippage
• Scheduling tasks that can be postponed or canceled if necessary later in the project
• Conservatively estimating durations of tasks on the critical path
• Generating a schedule that takes the contingency into account
Revise plans by:
• Reassigning strong staff to high-risk and critical path tasks
• Assigning a person, if only minimally, as a backup to any tasks where the loss of a team member
would be damaging
Make and document backup plans including:
• Preventive actions that will be taken to reduce or remove risk
• Contingent actions that can be implemented should a problem occur
• The circumstances that would trigger each contingency plan into action




Figure 5-22. Contingency planning worksheet.
For each risk, ask the following questions and then assign a value of high, medium, or low: (1) What is the
probability this risk will occur? (2) What would be the impact if this risk should occur? For risks with high
rankings for either impact or probability, take preventive steps by making revisions to the schedule or
adjusting resource assignments or negotiating a contingency fund and by generating backup contingency
plans. For each backup contingency plan, specify the circumstances that would trigger the plan into action
(see Figure 5-22).
Contingency is essential to good project management; without it, corrective action cannot be taken when
problems are encountered in the execution of the work. Keep in mind that it is not prudent to hide or bury
contingency within the estimates of budgets or durations, or the budgets of the tasks. Contingency should be
based on the amount of risk associated with the project, and a risk assessment must be prepared as the project
plan is being developed. Some risks have the potential to affect the entire project, others might affect only one
phase of it, and still others might affect only a single task. Your goal should be to return the contingency to
the general funds of the organization at the conclusion of the project. Unexpended contingency increases the
profitability of the project or the return on investment associated with the project.


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 6
Managing Project Change
Change affects our lives dramatically, ruining our plans, causing us to destroy completed work, and forcing us
-----------
to plan, replan, replan, and replan again. We work, rather consistently, to discourage it, and yet it is inevitable.
An efficient change management process can make the difference between project success and project failure.
Changes to the project will inevitably occur in the baseline of the schedule, resource allocation, and budget, as
well as in the scope of the end product. These changes must be analyzed, their impact determined, and
corrective action taken when necessary. In this chapter, we focus on two major types of change that affect
projects: scope changes and baseline changes. We discuss the different sources for each of these changes and
recommend procedures for successfully managing these all-important dynamics of your project.

Scope Changes
Sources of Scope Changes
Changes in the scope of a project refer to the additions, modifications, or deletions made to the end product or
service. In most organizations, changes in scope occur within the areas of the project requirements and design,
as well as the overriding technology, business cycle, and, last but certainly not least, personnel:
• Requirements changes: This common type of scope change originates with the client, who may need
an additional capability or feature that was not specified in the original scope definition. In most cases,
clients are not attempting to cause extra work. Rather, they probably have not considered this particular
feature before and now are placing great importance on including it within the scope of the project.
• Design changes: During the effort, the designers may find a much better way to produce or provide
the end product. Usually this type of change occurs within the natural flow of idea generation and
testing. As in the case of requirements changes, designers may place great importance on including the
design change within the project scope.
• Technological changes: As a project evolves, new types of technology in equipment, materials, or
expertise may become available. These technological discoveries must be addressed in terms of
changes to the original project scope.
• Business changes: Nothing stands still, especially time. And with the passage of time, circumstances
within the business environment change. If a competitor announces a new product or the value of the
dollar declines, for example, the project scope can be affected to a greater or lesser degree. There is a
need for proactive response mechanisms to adjust the project scope.

<<

. 2
( 5)



>>