Description

‫المملكة العربية السعودية‬
‫وزارة التعليم‬
‫ر‬
‫اإللكتونية‬
‫الجامعة السعودية‬
Kingdom of Saudi Arabia
Ministry of Education
Saudi Electronic University
College of Administrative and Financial Sciences
Assignment 3
Project Management (MGT323)
Deadline: 30/04/2022 @ 23:59
Course Name: Project Management
Course Code: MGT323
Student’s Name:
Semester: II
CRN:
Student’s ID Number:
Academic Year:2021-22, II Term
For Instructor’s Use only
Instructor’s Name:
Students’ Grade:
Marks Obtained/Out of 10
Level of Marks: High/Middle/Low
Instructions – PLEASE READ THEM CAREFULLY
● The Assignment must be submitted on Blackboard (WORD format only)
via allocated folder.
● Assignments submitted through email will not be accepted.
● Students are advised to make their work clear and well presented, marks
may be reduced for poor presentation. This includes filling your information
on the cover page.
● Students must mention question number clearly in their answer.
● Late submission will NOT be accepted.
● Avoid plagiarism, the work should be in your own words, copying from
students or other resources without proper referencing will result in ZERO
marks. No exceptions. Atleast two Scholarly Peer- Reviewed Journals are
required as references.
● All answered must be typed using Times New Roman (size 12, doublespaced) font. No pictures containing text will be accepted and will be
considered plagiarism).
● Submissions without this cover page will NOT be accepted.
● Do not make any changes in the cover page.
Assignment Workload:
● This Assignment comprise of a Case Study and Discussion questions.
● Assignment is to be submitted by each student individually.
Assignment Purposes/Learning Outcomes:
After completion of Assignment-3 students will able to understand the
1. Defining the concepts, theories and approaches of project management. (L.O1.1)
2. Analyze to work effectively and efficiently as a team member for project related
cases. (L.O-3.1)
3. Evaluate to monitor and control the project. (L.O-3.2)
Assignment-3: Case Study & Discussion questions
Assignment Question:
(Marks 10)
Please read the Case-8.3 “Tham Luang Cave Rescue.” from Chapter 8
“Scheduling Resources and Costs” given in your textbook – Project
Management: The Managerial Process 8th edition by Larson and Gray page
no: 304-307 also refer to specific concepts you have learned from the
chapter to support your answers. Answer the following questions for Part-1,
Part-2.
Part-1: Case study questions
1. How did the physical environment of the cave affect the rescue
plan? Explain in 250 words (3 Marks).
2. How did the rescue team respond to the risks of the project?
Explain in 250 words (3 Marks).
3. Some have called the rescue a miracle and that luck was the
decisive factor. Do you agree? Explain in 150 words (2 Marks)
Part-2: Discussion questions
Please read Chapter 8 Pg-No. 279 & 281 carefully and then give
your answers on the basis of your understanding.
4. Why would people resist a multi project resource scheduling
system? (1 Mark) (100 words)
5. What do you think would have happened if the Washington
Forest Service did not assess the impact of resources on their
two-year plan? (1 Mark) (100 words).
Answers:
1.
2.

3.
4.
5.
page 258
CHAPTER
EIGHT
8
Scheduling Resources and
Costs
LEARNING OBJECTIVES
After reading this chapter you should be able to:
8-1
Understand the differences between time-constrained and resourceconstrained schedules.
8-2
Identify different types of resource constraints.
8-3
Describe how the smoothing approach is used on time-constrained projects.
8-4
Describe how the leveling approach is used for resource-constrained projects.
8-5
Understand how project management software creates resource-constrained
schedules.
8-6
Understand when and why splitting tasks should be avoided.
8-7
Identify general guidelines for assigning people to specific tasks.
8-8
Identify common problems with multiproject resource scheduling.
8-9
Explain why a time-phased budget baseline is needed.
8-10
Create a time-phased project budget baseline.
A8-1
Define the term critical chain.
A8-2
Identify the reasons projects are late even when estimates are padded.
A8-3
Describe the basic critical-chain methodology.
A8-4
Describe the differences between critical-chain scheduling and the traditional
approach to scheduling.
OUTLINE
8.1
Overview of the Resource Scheduling Problem
8.2
Types of Resource Constraints
8.3
Classification of a Scheduling Problem
8.4
Resource Allocation Methods
8.5
Computer Demonstration of Resource-Constrained Scheduling
8.6
Splitting Activities
8.7
Benefits of Scheduling Resources
8.8
Assigning Project Work
8.9
Multiproject Resource Schedules
8.10
Using the Resource Schedule to Develop a Project Cost Baseline
Summary
Appendix 8.1:
The Critical-Chain Approach
page 259
Project network times are not a schedule until resources
have been assigned. Cost estimates are not a budget until
they have been time-phased.
—Clifford F. Gray
We have consistently stressed that up-front planning results in big payoffs
on predictable projects. For those who have diligently worked through the
earlier planning processes chapters, you are nearly ready to launch your
project. This chapter completes the final two planning tasks that become the
master plan for your project—resource and cost scheduling. (See Figure
8.1.) This process uses the resource schedule to assign time-phased costs
that provide the project budget baseline. Given this time-phased baseline,
comparisons can be made with actual and planned schedule and costs. This
chapter first discusses the process for developing the project resource
schedule. This resource schedule will be used to assign the time-phased
budgeted values to create a project budget baseline.
FIGURE 8.1
Project Planning Process
There are always more project proposals than there are available
resources. The priority system needs to select projects that best contribute
to the organization’s objectives, within the constraints of the resources
page 260
available. If all projects and their respective resources are
computer scheduled, the feasibility and impact of adding a
new project to those in process can be quickly assessed. With this
information the project priority team will add a new project only if
resources are available. This chapter examines methods of scheduling
resources so the team can make realistic judgments of resource availability
and project durations. The project manager uses the same schedule for
implementing the project. If changes occur during project implementation,
the computer schedule is easily updated and the effects easily assessed.
8.1 Overview of the Resource Scheduling
Problem
LO 8-1
Understand the differences between time-constrained and resource-constrained
schedules.
After staff and other resources were assigned to her project, a project
manager listed the following questions that still needed to be addressed:
Will the assigned labor and/or equipment be adequate and available to
deal with my project?
Will outside contractors have to be used?
Do unforeseen resource dependencies exist? Is there a new critical path?
How much flexibility do we have in using resources?
Is the original deadline realistic?
Clearly this project manager has a good understanding of the problems she
is facing. Any project scheduling system should facilitate finding quick,
easy answers to these questions.
The planned network and activity project duration times found in
previous chapters did not take into account resource usage and availability.
The time estimates for the work packages and network times were made
independently with the implicit assumption that resources would be
available. This may or may not be the case.
If resources are adequate but the demand varies widely over the life of
the project, it may be desirable to even out resource demand by delaying
noncritical activities (using slack) to lower peak demand and, thus, increase
resource utilization. This process is called resource smoothing.
On the other hand, if resources are not adequate to meet peak demands,
the late start of some activities must be delayed, and the duration of the
project may be increased. This process is called resource-constrained
scheduling.
The consequences of failing to schedule limited resources are costly and
project delays usually manifest themselves midway in the project when
quick corrective action is difficult. An additional consequence of failing to
schedule resources is ignoring the peaks and valleys of resource usage over
the duration of the project. Because project resources are usually
overcommitted and because resources seldom line up by availability and
need, procedures are needed to deal with these problems. This chapter
page 261
addresses methods available to project managers for dealing
with resource utilization and availability through resource
leveling and resource-constrained scheduling.
Up to now the start and sequence of activities have been based solely on
technical or logical considerations. For example, assume you are planning a
wedding reception that includes four activities—(1) plan, (2) hire band, (3)
decorate hall, and (4) purchase refreshments. Each activity takes one day.
Activities 2, 3, and 4 could be done in parallel by different people. There is
no technical reason or dependency of one on another (see Figure 8.2A).
However, if one person must perform all activities, the resource constraint
requires that the activities be performed in sequence or series. Clearly the
consequence is a delay of these activities and a very different set of network
relationships (see Figure 8.2B). Note that the resource dependency takes
priority over the technological dependency but does not violate the
technological dependency; that is, hire, decorate, and purchase may now
have to take place in sequence rather than concurrently, but they must all be
completed before the reception can take place.
FIGURE 8.2
Constraint Examples
One may ask, “Why not factor resource availability along with technical
dependency when creating the original network?” First, resource
availability may not be known until the initial schedule is completed.
Second, even if resources are known, one could not assess the impact of
resources unless a resource neutral schedule were created. For example, one
would never know that the wedding could be planned in three days instead
of five if three people were available instead of the assumed one. When the
premise behind this simple example is applied to other, more elaborate
projects, the implications can be significant.
The interrelationships and interactions among time and resource
constraints are complex for even small project networks. Some effort to
examine these interactions before the project begins frequently uncovers
surprising problems. Project managers who do not consider resource
availability in moderately complex projects usually learn of the problem
when it is too late to correct. A deficit of resources can significantly alter
project dependency relationships, completion dates, and project costs.
Project managers must be careful to schedule resources to ensure
availability in the right quantities and at the right time. Fortunately, there
are computer software programs that can identify resource problems during
the early project planning phase when corrective changes can be
considered. These programs only require activity resource needs and
availability information to schedule resources.
page 262
SNAPSHOT FROM PRACTICE 8.1
Working in Tight Places
In rare situations, physical factors cause activities that would normally
occur in parallel to be constrained by contractual or environmental
conditions. For example, in theory the renovation of a sailboat
compartment might involve four or five tasks that can be done
independently. However, since space allows only one person to work at one time, all
tasks have to be performed sequentially. Likewise, on a mining project it may be
physically possible for only two miners to work in a shaft at a time. Another example is
the erection of a communication tower and nearby groundwork. For safety
considerations, the contract prohibits groundwork within 2,000 feet of the tower
construction.
iStockphoto/Getty Images
The procedures for handling physical factors are similar to those used for resource
constraints.
See Snapshot from Practice 8.1: Working in Tight Places for a third
constraint that impinges on project schedules.
8.2 Types of Resource Constraints
LO 8-2
Identify different types of resource constraints.
Resources are people, equipment, and material that can be drawn on to
accomplish something. In projects the availability or unavailability of
resources will often influence the way projects are managed.
1. People. This is the most obvious and important project resource.
Human resources are usually classified by the skills they bring to the
project—for example, programmer, mechanical engineer, welder, inspector,
marketing director, supervisor. In rare cases some skills are interchangeable,
but usually with a loss of productivity. The many differing skills of human
resources add to the complexity of scheduling projects.
2. Materials. Project materials cover a large spectrum—for example,
chemicals for a scientific project, concrete for a road project, survey data
for a marketing project. Material availability and shortages have been
blamed for the delay of many projects. When it is known that a lack of
availability of materials is important and probable, materials should be
included in the project network plan and schedule. For example, delivery
and placement of an oil rig tower in a Siberian oil field has a very small
time window during one summer month. Any delivery delay means a oneyear, costly delay. Another example in which material is the major resource
scheduled was the resurfacing and replacement of some structures on the
Golden Gate Bridge in San Francisco. Work on the project was limited to
the hours between midnight and 5:00 a.m., with a penalty of $1,000 per
minute for any work taking place after 5:00 a.m. Scheduling the arrival of
replacement structures was an extremely important part of managing the
five-hour work-time window of the project. Scheduling materials has also
page 263
become important in developing products where time-tomarket can result in loss of market share.
3. Equipment. Equipment is usually presented by type, size, and
quantity. In some cases equipment can be interchanged to improve
schedules, but this is not typical. Equipment is often overlooked as a
constraint. The most common oversight is to assume the resource pool is
more than adequate for the project. For example, if a project needs one
earthmoving tractor six months from now and the organization owns four, it
is common to assume the resource will not delay the pending project.
However, when the earthmoving tractor is due on-site in six months, all
four machines in the pool might be occupied on other projects. In
multiproject environments it is prudent to use a common resource pool for
all projects. This approach forces a check of resource availability across all
projects and reserves the equipment for specific project needs in the future.
Recognition of equipment constraints before the project begins can avoid
high crashing or delay costs.
8.3 Classification of a Scheduling Problem
Most of the scheduling methods available today require the project manager
to classify the project as either time constrained or resource constrained.
Project managers need to consult their priority matrix (see Figure 4.2) to
determine which case fits their project. One simple test is to ask, “If the
critical path is delayed, will resources be added to get back on schedule?” If
the answer is yes, assume the project is time constrained; if no, assume the
project is resource constrained.
A time-constrained project is one that must be completed by an
imposed date. If required, resources can be added to ensure the project is
completed by a specific date. Although time is the critical factor, resource
usage should be no more than is necessary and sufficient.
A resource-constrained project is one that assumes the level of
resources available cannot be exceeded. If the resources are inadequate, it
will be acceptable to delay the project, but as little as possible.
In scheduling terms, time constrained means time (project duration) is
fixed and resources are flexible, while resource constrained means
resources are fixed and time is flexible. Methods for scheduling these
projects are presented in the next section.
8.4 Resource Allocation Methods
Assumptions
Ease of demonstrating the allocation methods available requires some
limiting assumptions to keep attention on the heart of the problem. The rest
of the chapter depends entirely on the assumptions noted here. First,
splitting activities will not be allowed. Splitting refers to interrupting work
on one task and assigning the resources to work on a different task for a
period of time, then reassigning them to work on the original task. No
splitting means that once an activity is placed in the schedule, assume it will
be worked on continuously until it is finished. Second, the level of
resources used for an activity cannot be changed. These limiting
assumptions do not exist in practice but simplify learning. It is easy for new
project managers to deal with the reality of splitting activities and changing
the level of resources when they meet them on the job.
page 264
Time-Constrained Projects: Smoothing Resource
Demand
LO 8-3
Describe how the smoothing approach is used on time-constrained projects.
Scheduling time-constrained projects focuses on resource utilization. When
demand for a specific resource type is erratic, it is difficult to manage, and
utilization may be very poor. Practitioners have attacked the utilization
problem using resource leveling techniques that balance demand for a
resource. Basically all leveling techniques delay noncritical activities by
using positive slack to reduce peak demand and fill in the valleys for the
resources. An example will demonstrate the basic procedure for a timeconstrained project. See Figure 8.3.
FIGURE 8.3
Botanical Garden
For the purpose of demonstration, the Botanical Garden project uses
only one resource (backhoes); all backhoes are interchangeable. The top bar
chart shows the activities on a timescale. The dependencies are shown with
page 265
the vertical connecting arrows. The horizontal arrows
following activities represent activity slack (for example, irrigation requires
six days to complete and has six days of slack). The number of backhoes
needed for each task is shown in the shaded activity duration block
(rectangle). After the land has been scarified and the plan laid out, work can
begin on the walkways, irrigation, and fencing and retaining walls
simultaneously. The middle chart shows the resource profile for the
backhoes. For periods 4 through 10, four backhoes are needed.
Because this project is declared time constrained, the goal will be to
reduce the peak requirement for the resource and thereby increase the
utilization of the resource. A quick examination of the ES (early start)
resource load chart suggests only two activities have slack that can be used
to reduce the peak—fence and walls provide the best choice for smoothing
the resource needs. Another choice could be irrigation, but it would result in
an up-and-down resource profile. The choice will probably center on the
activity that is perceived as having the least risk of being late. The
smoothed resource loading chart shows the results of delaying the fence and
walls activity. Note the differences in the resource profiles. The important
point is that the resources needed over the life of the project have been
reduced from four to three (25 percent). In addition, the profile has been
smoothed, which should be easier to manage.
The Botanical Garden project schedule reached the three goals of
smoothing:
The peak of demand for the resource was reduced.
The number of resources over the life of the project was reduced.
The fluctuations in resource demand were minimized.
Smoothing improves the utilization of resources. Backhoes are not easily
moved from location to location. There are costs associated with changing
the level of resources needed. The same analogy applies to the movement of
people back and forth among projects. It is well known that people are more
efficient if they can focus their effort on one project rather than multitasking
their time among, say, three projects.
The downside of leveling is a loss of flexibility that occurs from
reducing slack. The risk of activities delaying the project also increases
because slack reduction can create more critical activities and/or near-
critical activities. Pushing leveling too far for a perfectly level resource
profile is risky. Every activity then becomes critical.
The Botanical Garden example gives a sense of the time-constrained
problem and the smoothing approach. However, in practice the magnitude
of the problem is very complex for even small projects. Manual solutions
are not practical. Fortunately, the software packages available today have
very good routines for leveling project resources. Typically they use
activities that have the most slack to level project resources. The rationale is
that those activities with the most slack pose the least risk. Although this is
generally true, other risk factors such as reduction of flexibility to use
reassigned resources on other activities and the nature of the activity (easy,
complex) are not addressed using such a simple rationale. It is easy to
experiment with many alternatives to find the one that best fits your project
and minimizes the risk of delaying the project.
Resource-Constrained Projects
LO 8-4
Describe how the leveling approach is used for resource-constrained projects.
When the number of people and/or equipment is not adequate to meet peak
demand requirements and it is impossible to obtain more, the project
manager faces a resource-constrained problem. Something has to give. The
trick is to prioritize and allocate resources to minimize project delay
without exceeding the resource limit or altering the technical network
relationships.
page 266
The resource scheduling problem is a large, combinatorial one. This
means even a modest-sized project network with only a few resource types
might have several thousand feasible solutions. A few researchers have
demonstrated optimum mathematical solutions to the resource allocation
problem but only for small networks and very few resource types (Arrow &
Hurowicz, 2006; Talbot & Patterson, 1979; Woodworth & Shanahan, 1988).
The massive data requirements for larger problems make pure mathematical
solutions (e.g., linear programming) impractical. An alternative approach to
the problem has been the use of heuristics (rules of thumb) to solve large,
combinatorial problems. These practical decision or priority rules have been
in place for many years.
Heuristics do not always yield an optimal schedule, but they are very
capable of yielding a “good” schedule for very complex networks with
many types of resources. The efficiency of different rules and combinations
of rules has been well documented (Davis & Patterson, 1975; Fendly,
1968). However, because each project is unique, it is wise to test several
sets of heuristics on a network to determine the priority allocation rules that
minimize project delay. The computer software available today makes it
very easy for the project manager to create a good resource schedule for the
project. A simple example of the heuristic approach is illustrated here.
Heuristics allocate resources to activities to minimize project delay; that
is, heuristics prioritize which activities are allocated resources and which
activities are delayed when resources are not adequate.
The parallel method is the most widely used approach to apply
heuristics, which have been found to consistently minimize project delay
over a large variety of projects. The parallel method is an iterative process
that starts from the beginning of project time and, when the resources
needed exceed the resources available, retains activities first by the priority
rules:
1. Minimum slack.
2. Smallest duration.
3. Lowest activity identification number.
Those not able to be scheduled without delaying others are pushed out
further in time. However, do not attempt to move activities that have
already started. When considering activities not to delay, consider the
resources each activity uses. In any period when two or more activities
require the same resource, the priority rules are applied. For example, if in
period 5 three activities are eligible to start (i.e., have the same ES) and
require the same resource, the first activity placed in the schedule would be
the activity with the least slack (rule 1). However, if all activities have the
same slack, the next rule would be invoked (rule 2), and the activity with
the smallest duration would be placed in the schedule first. In very rare
cases, when all eligible activities have the same slack and the same
duration, the tie is broken by the lowest activity identification number (rule
3), since each activity has a unique ID number.
When a resource limit has been reached, the early start (ES) for
succeeding activities not yet in the schedule will be delayed (and all
successor activities not having free slack) and their slack reduced. In
subsequent periods the procedure is repeated until the project is scheduled.
The procedure is demonstrated next; see Figure 8.4. The shaded areas in the
resource loading chart represent the “scheduling interval” of the timeconstrained schedule (ES through LF). You can schedule the resource
anyplace within the interval and not delay the project. Scheduling the
activity beyond the LF will delay the project.
FIGURE 8.4
Resource-Constrained Schedule through Period 2–3
page 267
The Parallel Method:
Period Action
See Figure 8.4.
0–1
Only activity 1 is eligible. It requires 2 programmers.
Load activity 1 into schedule.
1–2
No activities are eligible to be scheduled.
2–3
Activities 2, 3, and 4 are eligible to be scheduled. Activity 3 has the least slack (0)—
apply rule 1.
Load activity 3 into schedule.
Activity 2 is next with slack of 2; however, activity 2 requires 2 programmers and only
1 is available.
Delay activity 2. Update: ES = 3, slack = 1.
The next eligible activity is activity 4, since it only requires 1 programmer.
Load activity 4 into schedule.
See Figure 8.5.
3–4
Activity 2 is eligible but exceeds limit of 3 programmers in pool.
Delay activity 2. Update: ES = 4, slack = 0.
4–5
Activity 2 is eligible but exceeds limit of 3 programmers in pool.
Delay activity 2. Update: ES = 5, LF = 11, slack = −1.
Delay activity 7. Update: ES = 11, LF = 13, slack = −1.
5–6
Activity 2 is eligible but exceeds limit of 3 programmers in pool.
Delay activity 2. Update: ES = 6, LF = 12, slack = −2.
Delay activity 7. Update: ES = 12, LF = 14, slack = −2.
6–7
Activities 2, 5, and 6 are eligible with slack of −2, 2, and 0, respectively.
Load activity 2 into schedule (rule 1).
Because activity 6 has 0 slack, it is the next eligible activity.
Load activity 6 into schedule (rule 1).
The programmer limit of 3 is reached.
Delay activity 5. Update: ES = 7, slack = 1.
7–8
Limit is reached. No programmers available.
Delay activity 5. Update: ES = 8, slack = 0.
8–9
Limit is reached. No programmers available.
Delay activity 5. Update: ES = 9, LF = 11, slack = −1.
9–10
Limit is reached. No programmers available.
Delay activity 5. Update: ES = 10, LF = 12, slack = −2.
10–11
Activity 5 is eligible.
Load activity 5 into schedule.
(Note: Activity 6 does not have slack because there are no programmers available—
3 maximum.)
11–12
No eligible activities.
12–13
Activity 7 is eligible. Load activity 7 into schedule.
The programmers are limited to three. Follow the actions described in
Figures 8.4 and 8.5. Note how the limit of three programmers starts to delay
the project.
Observe how it is necessary to update each period to reflect changes in
activity early start and slack times so the heuristics can reflect changing
priorities. When using the parallel scheduling method, the network in
Figure 8.5 reflects the new schedule date of 14 time units, rather than the
time-constrained project duration of 12 time units. The network has also
been revised to reflect new start, finish, and slack times for each activity.
Note that activity 6 is still critical and has a slack of 0 time units because no
resources are available (they are being used on activities 2 and 5). Compare
page 268
the slack for each activity found in Figures 8.4 and 8.5; slack
has been reduced significantly. Note that activity 4 has only 2
units of slack rather than what appears to be 6 slack units. This occurs
because only three programmers are available, and they are needed to
satisfy the resource requirements of activities 2 and 5. Note that the number
of critical activities (1, 2, 3, 5, 6, 7) has increased from four to six.
page 269
FIGURE 8.5
Resource-Constrained Schedule through Period 5–6
page 270
This small example demonstrates the scenario of scheduling resources
in real projects and the resulting increase in the risk of being late. In
practice this is not a trivial problem! Managers who fail to schedule
resources usually encounter this scheduling risk when it is too late to work
around the problem, resulting in a project delay.
Since manually using the parallel method is impractical on real-world
projects because of size, project managers will depend on software
programs to schedule project resources.
8.5 Computer Demonstration of ResourceConstrained Scheduling
LO 8-5
Understand how project management software creates resource-constrained schedules.
Fortunately, project management software is capable of assessing and
resolving complicated resource-constrained schedules using heuristics
similar to those described in the previous section. We will use the EMR
project to demonstrate how this is done using MS Project. It is important to
note that the software is not “managing” the project. The software is simply
a tool the project manager uses to view the project from different
perspectives and conditions. See Snapshot from Practice 8.2: Assessing
Resource Allocation for more tips on assessing resource problems.
SNAPSHOT FROM PRACTICE 8.2
Assessing Resource Allocation
One of the strengths of project management software is the ability to
identify and provide options for resolving resource allocation problems.
One project manager who uses MS Project shared the following checklist
for dealing with resource conflicts after preliminary assignment of
resources.
1. Assess whether you have overallocation problems (see Red in the resource sheet
view).
2. Identify where and when conflicts occur by examining the resource usage view.
3. Resolve the problem by
a. Replacing overallocated resources with appropriate resources that are
available. Then ask if this solves the problem.
If not:
b. Use the leveling tool and choose the level within slack option.
i. Does this solve the problem? (Are resources still overallocated?)
ii. Check the sensitivity of the network and ask if this is acceptable.
If not:
c. Consider splitting tasks.
i. Make sure to readjust task durations to take into account additional start-up
and shutdown time.
4. If 3 does not work, then either
a. Use level tool default option and ask if you can live with the new completion
date.
If not:
b. Negotiate for additional resources to complete the project. If not possible:
c. Consider reducing project scope to meet deadline.
While this checklist makes specific references to MS Project, the same steps can be
used with most project management software.
page 271
EMR is the name given to a hand-held electronic medical reference
guide that is being developed to be used by emergency medical technicians
and paramedics. Figure 8.6 contains a time-limited network for the design
phase of the project. For the purpose of this example, we assume that only
design engineers are required for the tasks and that the design engineers are
interchangeable. The number of engineers required to perform each task is
noted in the network, where 500 percent means five design engineers are
needed for the activity. For example, activity 5, feature specs, requires four
design engineers (400 percent).
The project begins January 1 and ends February 14, a duration of 45
workdays. The calendar for the project has been set up to work seven days a
week so the reader can trace and more easily see the results and impa