Effective Project Management Traditional, Adaptive, Extreme phần 6 doc

Thistype of variance is good news to the project manager, who would rather hear thatthe project is ahead of schedule or under budget.. For this project, the firstproject report at month

Report resource effort (hours/day) spent and remaining (in-progress work only). Whereas the preceding numbers report calendar time, these num-bers report labor time over the duration of the activity There are two numbers One reports labor completed over the duration accomplished.The other reports labor to be spent over the remaining duration.

Report percent complete. Percent complete is the most common methodused to record progress because it is the way we tend to think about whathas been done in reference to the total job that has to be done Percent com-plete isn’t the best method to report progress, though, because it is a sub-jective evaluation When you ask someone “What percent complete areyou on this activity?” what goes through his or her mind? The first thing

he or she thinks about is most likely “What percent should I be?” followedclosely by “What’s a number that we can all be happy with?”

To calculate the percent complete for an activity, you need something tifiable At least three different approaches have been used to calculate thepercent complete of an activity:

quan-■■ Duration

■■ Resource work

■■ CostEach of these could result in a different percent complete! So when we saypercent complete, what measure are we referring to?

If you focus on duration as the measure of percent complete, where did theduration value come from? The only value you have is the original estimate.You know that original estimates often differ from actual performance Ifyou were to apply a percent complete to duration, however, the onlyone you have to work with is the original estimated one Therefore, percent complete is not a good metric

Our advice is to never ask for and never accept percent complete as input

to project progress Always allow it to be a calculation Many softwareproducts will let you do it either as an inputted value or as a calculatedvalue The calculated value that we recommend above all others is onebased on the number of tasks actually completed in the activity as a pro-portion of the number of tasks that currently define the activity Recall thatthe task list for an activity is part of the work package description Here wecount only completed tasks Tasks that are underway but not reported ascomplete may not be used in this calculation

Frequency of Gathering and Reporting Project Progress

A logical frequency for reporting project progress is once a week, usually onFriday afternoon There are some projects, such as refurbishing a large jet

airliner, where progress is recorded after each shift, three times a day We’veseen others that were of such a low priority or long duration that they wereupdated once a month For most projects, start gathering the informationabout noon on Friday Let people extrapolate to the end of the workday.

Variances

Variances are deviations from plan Think of a variance as the differencebetween what was planned and what actually occurred There are two types ofvariances: positive variances and negative variances

Positive Variances

Positive variances are deviations from plan that indicate that an ahead-of-schedule

situation has occurred or that an actual cost was less than a planned cost Thistype of variance is good news to the project manager, who would rather hear thatthe project is ahead of schedule or under budget Positive variances bring theirown set of problems, which can be as serious as negative variances Positive vari-ances can allow for rescheduling to bring the project to completion early, underbudget, or both Resources can be reallocated from ahead-of-schedule projects tobehind-schedule projects

Not all the news is good news, though Positive variances also can result fromschedule slippage! Consider budget Being under budget means that not alldollars were expended, which may be the direct result of not having com-pleted work that was scheduled for completion during the report period

CROSS-REFERENCE

We return to this situation later in the Cost Schedule Control section of this chapter.

On the other hand, if the ahead-of-schedule situation is the result of the ect team’s finding a better way or a shortcut to completing work, the projectmanager will be pleased This situation may be a short-lived benefit, however.Getting ahead of schedule is great, but staying ahead of schedule presentsanother kind of problem To stay ahead of schedule, the project manager willhave to negotiate changes to the resource schedule Given the aggressive proj-ect portfolios in place in most companies, there is not much reason to believethat resource schedule changes can be made In the final analysis, being ahead

proj-of schedule may be a myth

Negative Variances

Negative variances are deviations from plan that indicate that a behind-schedule

situation has occurred or that an actual cost was greater than a planned cost

Being behind schedule or over budget is not what the project manager or hisreporting manager wants to hear Negative variances, just like positive vari-ances, are not necessarily bad news For example, you might have overspentbecause you accomplished more work during the report period than wasplanned But in overspending during this period, you could have accom-plished the work at less cost than was originally planned You can’t tell by look-ing at the variance report.

Applying Graphical Reporting Tools

As mentioned earlier in the chapter, senior managers may have only a fewminutes of uninterrupted time to digest your report Respect that time Theywon’t be able to fully read and understand your report if they have to read 15pages before they get any useful information Having to read several pagesonly to find out that the project is on schedule is frustrating and a waste ofvaluable time

Gantt Charts

As we discussed in Chapters 4 and 6, a Gantt chart is one of the most convenient,

most used, and easy-to-grasp depictions of project activities that we haveencountered in our practice The chart is formatted as a two-dimensional repre-sentation of the project schedule with activities shown in the rows and timeshown across the horizontal axis It can be used during planning, for resourcescheduling, and for status reporting The only downside to using Gantt charts isthat they do not contain dependency relationships Some project management

software tools have an option to display these dependencies, but the result is agraphical report that is so cluttered with lines representing the dependenciesthat the report is next to useless In some cases, dependencies can be guessed atfrom the Gantt chart, but in most cases, they are lost.

Figure 10.2 shows a representation of the Cost Containment Project as a Ganttchart using the format that we prefer The format shown is from MicrosoftProject 2000, but it is typical of the format used in most project managementsoftware packages

Milestone Trend Charts

Milestones are significant events in the life of the project that you wish to track.

These significant events are zero-duration activities and merely represent that

a certain condition exists in the project For example, a milestone event might

be that the approval of several different component designs has been given.This event consumes no time in the project schedule It simply reflects the factthat those approvals have all been granted The completion of this milestoneevent may be the predecessor of several build-type activities in the projectplan Milestone events are planned into the project in the same way that activ-ities are planned into the project They typically have FS relationships with theactivities that are their predecessors and their successors

Let’s look at a milestone trend chart for a hypothetical project (see Figure 10.3).The trend chart plots the difference between the planned and estimated date of

a project milestone at each project report period In the original project plan,the milestone is planned to occur at the ninth month of the project That is thelast project month on this milestone chart The horizontal lines represent one,two, and three standard deviations above or below the forecasted milestonedate Any activity in the project has an expected completion date that isapproximately normally distributed The mean and variance of its completiondate are a function of the longest path to the activity from the report date Inthis example, the units of measure are one month For this project, the firstproject report (at month 1) shows that the new forecasted milestone date will

be one week later than planned At the second project report date (month two

of the project), the milestone date is forecasted on target The next three projectreports indicate a slippage to two weeks late, then three weeks late, then fourweeks late, and finally six weeks late (at month 6 of the project) In otherwords, the milestone is forecasted to occur six weeks late, and there are onlythree more project months in which to recover the slippage Obviously, theproject is in trouble The project appears to be drifting out of control, and infact, it is Some remedial action is required of the project manager

ID Description 24 Determ chars of a departmental profile 25 Profile usage of each department 49 Analyze current office supplies in use 57 Estab CS dist ser

71 Det corp usage of office/copy supplies 50 Propose office supplies standards 56 Estimate CS walk-up ser

8 Define copy machine re-stocking procedure 4 Design copy ser

51 Dist office sup's standards for commence 107 Resear

9 ID alternative copy charge back sys's 5 Print copy ser

26 Collect office sup expenses by type 72 Inventor

Figure 10.3 A run up or down of four or more successive data points.

Certain patterns signal an out-of-control situation These are given in Figures10.3 through 10.6 and are described here:

Successive slippages. Figure 10.3 depicts a project that is drifting out ofcontrol Each report period shows additional slippage since the last reportperiod Four such successive occurrences, however minor they may seem,require special corrective action on the part of the project manager

Radical change. Figure 10.4, while it does show the milestone to be ahead

of schedule, reports a radical change between report periods Activityduration may have been grossly overestimated There may be a data error

In any case, the situation requires further investigation

Successive runs. Figure 10.5 signals a project that may have encountered apermanent schedule shift In the example, the milestone date seems to bevarying around one month ahead of schedule Barring any radical shiftsand the availability of resources over the next two months, the milestonewill probably come in one month early Remember that you have negoti-ated for a resource schedule into these two months, and now you will betrying to renegotiate an accelerated schedule

Figure 10.4 A change of more than three standard deviations.

9 8 7 6 5 4 3 2 1

3 Early 2 1

On Schedule

1 2 3 Late

Project Month

9 8 7 6 5 4 3 2 1

3 Early 2 1

On Schedule

1 2 3 Late

Project Month

Figure 10.5 Seven or more successive data points above or below the planned milestone

date.

Schedule shift. Figure 10.6 depicts a major shift in the milestone schedule.The cause must be isolated and the appropriate corrective measures taken.One possibility is the discovery that a downstream activity will not berequired Perhaps the project manager can buy a deliverable rather thanbuild it and remove the associated build activities from the project plan

Cost Schedule Control

Cost schedule control is used to measure project performance and, by tion, uses the dollar value of work as the metric As an alternative, resourceperson hours/day can be used in cases where the project manager does notdirectly manage the project budget Actual work performed is comparedagainst planned and budgeted work expressed in these equivalents Thesemetrics are used to determine schedule and cost variances for both the currentperiod and cumulative to date Cost and resource person hours/day are notgood objective indicators with which to measure performance or progress.While this is true, there is no other good objective indicator Given this, we areleft with dollars or person hours/day, which we are at least familiar workingwith in other contexts Either one by itself does not tell the whole story Weneed to relate them to one another

tradi-One drawback that these metrics have is that they report history Althoughthey can be used to make extrapolated predictions for the future, they primar-ily provide a measure of the general health of the project, which the projectmanager can correct as needed to restore the project to good health

Figure 10.7 shows an S curve, which represents the baseline progress curve forthe original project plan It can be used as a reference point You can compareyour actual progress to date against the curve and determine how well theproject is doing Again, progress can be expressed as either dollars or personhours/day

9 8 7 6 5 4 3 2 1

3 Early 2 1

On Schedule

1 2 3 Late

Project Month

Figure 10.6 Two successive data points outside three standard deviations from the planned

milestone date.

By adding the actual progress curve to the baseline curve, you can now see thecurrent status versus the planned status Figure 10.8 shows the actual progresscurve to be below the planned curve If this represented dollars, we might betempted to believe the project is running under budget Is that really true?

Figure 10.7 The standard S curve.

3 Early 2 1

On Schedule

1 2 3 Late

Project Month

Figure 10.8 Baseline versus actual cost curve illustrating cost variance.

Projects rarely run significantly under budget A more common reason for theactual curve to be below the baseline is that the activities that should havebeen done have not been, and thus the dollars or person hours/day that wereplanned to be expended have not been The possible schedule variance is high-lighted in Figure 10.9

Figure 10.9 Baseline versus actual cost illustrating schedule variance.

Progress

Cost Variance

Time

Update Date

Baseline

Actual

Schedule Variance

To determine whether there has really been a progress schedule variance, youneed some additional information Cost schedule control (CSC) comprisesthree basic measurements: budgeted cost of work scheduled, budgeted cost ofwork performed, and actual cost of work performed These measurementsresult in two variance values: schedule variance and cost variance Figure10.10 is a graphical representation of the three measurements.

The figure shows a single activity that has a five-day duration and a budget of

$500 The budget is prorated over the five days at an average daily value of

$100 The left panel of Figure 10.10 shows an initial (baseline) schedule withthe activity starting on the first day of the week (Monday) and finishing at theend of the week (Friday) The budgeted $500 value of the work is planned to

be accomplished all within that week This is the planned value (PV) The ter panel shows the actual work that was done Note that the schedule slippedand work did not begin until the third day of the week Using an average dailybudget of $100, we see that we were able to complete only $300 of the sched-uled work This is the earned value (EV) The rightmost panel shows the actualschedule as in the center panel, but now we see the actual dollars that werespent to accomplish the three days’ work This $400 is the actual cost (AC).The PV, EV, and AC are used to compute and track two variances The first is

cen-schedule variance (SV) SV is the difference between the EV and PV, which is –$200

(EV – PV) for this example That is, the SV is the schedule difference betweenwhat was done and what was planned to be done, expressed in dollar or personhours/day equivalents The second is cost variance (CV) CV is the differencebetween the EV and the AC, which is $100 in this example That is, we overspent

by $100 (AC – EV) the cost of the work completed

Figure 10.10 Cost/performance indicators.

Scheduled/Budgeted

to do $500 work over 5 days in a 5-day window

PV = $500

Actual cost of work performed = $400 AC=$400 Actual cost variance = ($100)

Management might react positively to the news shown in Figure 10.8, but theymight also be misled by such a conclusion The full story is told by comparingboth budget variance and schedule variance, shown in Figure 10.11.

To correctly interpret the data shown in Figure 10.9, you need to add the EVdata that was given in Figure 10.10 to produce Figure 10.11 Comparing the EVcurve with the PV curve, you see that you have underspent because all of thework that was scheduled has not been completed Comparing the EV curve tothe AC curve also indicates that you overspent for the work that was done.Clearly, management would have been misled by Figure 10.8 had they ignoredthe data in Figure 10.10 Either one by itself may be telling a half-truth

Figure 10.11 The full story.

Progress

Schedule Variance

Cost Variance

Time

PV

AC

EV

Cost/Schedule Control Terminology

For those who are familiar with the older cost/schedule control terminology, we have used the new terminology as defined in PMBOK 2000 The old terminology compares to the new terminology as follows:

◆ ACWP is the actual cost (AC).

◆ BCWP is the earned value (EV).

◆ BCWS is the planned value (PV).

In addition to measuring and reporting history, CSC can be used to predict thefuture status of a project Take a look at Figure 10.12 By cutting the PV curve

at the height from the horizontal axis, which has been achieved by the EV, andthen pasting this curve onto the end of the EV curve, you can extrapolate thecompletion of the project Note that this is based on using the original esti-mates for the remaining work to be completed If you continue at the rate atwhich you have been progressing, you will finish beyond the planned completion date Doing the same thing for the AC shows that you will finishover budget This is the simplest method of attempting to “estimate to com-pletion,” but it clearly illustrates that a significant change needs to occur in theway this project is running

The three basic indicators yield one additional level of analysis for us ule performance index (SPI) and cost performance index (CPI) are a furtherrefinement They are computed as follows:

Sched-SPI = EV/PV CPI = EV/AC

Figure 10.12 PV, EV, and AC curves.

Progress

Time

PV AC

EV

Estimate to Complete

Baseline Finish Date Update Date

Schedule performance index. The schedule performance index is a sure of how close the project is to performing work as it was actuallyscheduled If we are ahead of schedule, EV will be greater than PV, andtherefore the SPI will be greater than 1 Obviously, this is desirable On theother hand, an SPI below 1 would indicate that the work performed wasless than the work scheduled Not a good thing.

mea-Cost performance index. The cost performance index is a measure of howclose the project is to spending on the work performed to what wasplanned to have been spent If you are spending less on the work per-formed than was budgeted, the CPI will be greater than 1 If not, and youare spending more than was budgeted for the work performed, then theCPI will be less than 1

Some managers prefer this type of analysis because it is intuitive and quitesimple to equate each index to a baseline of 1 Any value less than 1 is unde-sirable; any value over 1 is good These indices are displayed graphically astrends compared against the baseline value of 1

Using the WBS to Report Project Status

Because the Work Breakdown Structure (WBS) shows the hierarchical ture of the work to be done, it can be used for status reporting, too In its sim-plest form, each activity box can be shaded to reflect completion percentages

struc-As lower-level activities are completed, the summary activities above themcan be shaded to represent percent complete data Senior managers willappreciate knowing that major parts of the project are complete Unfortu-nately, the WBS does not contain scheduling or sequencing information To theextent that this adds to the value of the report, narrative data or brief tabulardata might be added to the report Figure 10.13 shows an example statusreport using the WBS

Although this report is rather intuitive, it does not contain much detail Itwould have to be accompanied by an explanatory note with schedule and costdetail

ID Description 47 Central stores operations 48 CS standardize supplies 49 Analyze current office supplies in use 50 Propose office supplies standards 51 Dist office sup's standards 52 Revise office supplies standards 53 Obtain office supply standards 54 Notify depart's of final supplies standard 55 CS ordering 56 Estab CS dist ser

Deciding on Report Level of Detail

There are always questions about the level of detail and frequency of reporting

in project status reports Our feeling is that the more you report, the morelikely it is that someone will object or find some reason to micromanage yourproject Let’s examine this issue in more detail by considering the reportingrequirements at the activity manager, project manager, and senior managerlevels

Activity Manager

The activity manager will want the most detailed and granular informationavailable After all, the activity manager is directly responsible for getting thework done Because he or she manages the resources that are used to completeproject work, he or she will want to know what happened, what was sched-uled to happen, who did what (or didn’t do what), why it happened as it did,what problems have arisen, what solutions are within reach, and whatchanges need to be made Reports that reflect very detailed information are ofuse to the activity manager and the project manager but, because of their verydetail, are of little value to anyone outside of the project team

Project Manager

The project manager is concerned with the status information of all activitiesopen for work during the report period Activity reports are for the use of theproject manager He or she may decide to pass them forward to senior man-agement in his or her report The activity-level reports can follow a format sim-ilar to project-level reports

Reports for the project manager present data at the activity level and showeffects on the project schedule If project management software is used, theposted data from the activity managers is used to update the project scheduleand produce reports on overall project status Any slippage at the activity levelripples through the successor activities, triggers a new activity schedule, andrecomputes project completion dates These reports display all schedulinginformation, including float and resource schedule data In effect, they becomeworking documents for the project manager for schedule adjustments andproblem resolution Because these reports are at a very detailed level, they arenot appropriate for distribution beyond the project team In many cases, theymay be for the project manager’s eyes only

Senior Management

We recommend using a graphical exception report structure to report projectstatus to senior management For many projects, reports at the activity levelwill be appropriate For large projects, either milestone-level or summary task-level reports are more effective Senior managers have only a few minutes toreview any single project report Keeping a report to a single page is a goodstrategy The best report format, in our experience, is the Gantt chart Thesecharts require little explanation Activities should be listed in the order ofscheduled start date, a line designating the report date should be given, and allpercent completed displayed

TIP

If the project is sick, attach a one-page get-well plan to your report This plan usually

is in the form of a narrative discussion of the problem, alternative solutions, mended action, and any other details relevant to the issue at hand.

recom-Managing Project Status Meetings

To keep close track of progress on the project, the project manager needs tohave information from his or her team on a timely basis This information will

be given during a project status meeting At a minimum, you need to have astatus meeting at least once a week On some of the major projects on whichwe’ve worked, daily status meetings were the norm for the first few weeks,and then as the need for daily information wasn’t as critical, we switched totwice a week and finally to weekly status

Who Should Attend?

To use the status meetings correctly and efficiently, it’s important to figure outwho should be in attendance This information should be a part of your com-munication plan

When choosing who should attend, keep a couple points in mind:

■■ At first your status team may have a tendency to include people who areneeded only in the planning phase If they don’t have a need to knowinformation, don’t make them come to a meeting and sit there without agood reason You are going to put out meeting minutes anyway, so thosepeople that aren’t needed at the actual meeting will get the minutes in any case

■■ There will be times in a status meeting when two people will get into adiscussion where the other people in the meeting aren’t needed If thishappens, ask them to do a sidebar meeting so that your own status meet-

ing can go on A sidebar meeting is one in which a limited number of

peo-ple need to participate, and these types of meetings can be done moreeffectively away from your status meeting Having everyone in the roomlisten to these sidebar topics isn’t useful

Ask the people who are going to the sidebar meeting to let you knowwhat happens in the meeting, particularly if what they talk about impactsthe project If possible, get a meeting summary from the people, even ifit’s only a sentence or two long Get this circulated to the rest of the teamwith your minutes so that everyone on the team is kept up-to-date Typi-cal attendees at sidebar meetings will be the people who must have theproblem solved and those who should be able to solve it, or at least thosewho can escalate it to those who can solve it

When Are They Held?

Usually, status meetings are held toward the end of the week Whatever the day, make sure it’s the same one time after time People get used to prepar-ing information for a status meeting if they know exactly when the meetingwill occur

What Is Their Purpose?

The reason for a status meeting is to get information to the whole team It may

be that on large projects the participants in the status meeting are actually resentatives of their department You can’t have all the people on a 250-personproject team come into a meeting once a week, so make sure that someone isthere to represent the rest of the people in their section The purpose of themeeting is to encourage free flow of information, and that means being sure that the people who need to have information to do their jobs get theinformation at the status meeting Remember once again that you are going tosend out minutes of the meeting, so that will take care of the people who aren’t

rep-in attendance

TIP

Project size may be the determining factor, but in general, we prefer a one-hour limit This is the maximum, and an entire hour should not be needed at every project status meeting Good judgment is needed here Do not waste people’s time.

What Is Their Format?

While the format of the status review meetings should be flexible, as projectneeds dictate, certain items are part of every status meeting We recommendthat you proceed in a top-down fashion:

1 The project champion reports any changes that may have a bearing on thefuture of the project

2 The customer reports any changes that may have a bearing on the future

of the project

3 The project manager reports on the overall health of the project and theimpact of earlier problems, changes, and corrective actions as they impact

at the project level

4 Activity managers report on the health of activities open or scheduledopen for work since the last status meeting

5 Activity managers of future activities report on any changes since the lastmeeting that might impact project status

6 The project manager reviews the status of open problems from the laststatus meeting

7 Attendees identify new problems and assign responsibility for their lution (the only discussion allowed here is for clarification purposes)

reso-8 The project champion, customer, or project manager, as appropriate, offersclosing comments

9 The project manager announces the time and place of the next meetingand adjourns the meeting

Minutes are part of the formal project documentation and are taken at eachmeeting, circulated for comment, revised as appropriate, distributed, and filed

in the project notebook (electronic, we hope) Because there is little discussion,the minutes contain any handouts from the meeting and list the items assignedfor the next meeting The minutes should also contain the list of attendees, asummary of comments made, and assigned responsibilities

A project administrative support person should be present at the project statusreview meetings to take minutes and monitor handouts The responsibilitymight also be passed around to the project team members In some organiza-tions, the same person is responsible for distributing the meeting agenda andmaterials ahead of time for review This advance distribution is especiallyimportant if decisions will be made during the meeting People are veryuncomfortable if they are seeing important information for the first time, areexpected to read and understand it, and then are expected to make a decision,all at the same time

Managing Change

It is difficult for anyone, regardless of his or her skills at prediction and casting, to completely and accurately define the needs for a product or servicethat will be implemented 6, 12, or 18 months in the future Competition, cus-tomer reactions, technology changes, a host of supplier-related situations, andmany other factors could render a killer application obsolete before it can beimplemented The most frequent situation starts something like this: “Oh, Iforgot to tell you that we will also need ” or “We have to go to market no laterthan the third quarter instead of the fourth quarter.” How often have youheard sentences that start something like those examples? Let’s face it, change

fore-is a way of life in project management We might as well confront it and be pared to act accordingly

pre-Because change is constant, a good project management methodology has achange management process in place In effect, the change managementprocess has you plan the project again Think of it as a mini-JPP session

Two documents are part of every good change management process: project

change request and project impact statement

Project change request. The first principle to learn is that every change is asignificant change Adopt that maxim and you will seldom go wrong.What that means is that every change requested by the customer must be

documented in a project change request That document might be as simple

as a memo but might also follow a format provided by the project team Inany case, it is the start of another round of establishing Conditions of Satis-faction Only when the request is clearly understood can the project teamevaluate the impact of the change and determine whether the change can

be accommodated

Project impact statement. The response to a change request is a document

called a project impact statement It is a response that identifies the

alterna-tive courses of action that the project manager is willing to consider Therequestor is then charged with choosing the best alternative The projectimpact statement describes the feasible alternatives that the project man-ager was able to identify, the positive and negative aspects of each, andperhaps a recommendation as to which alternative might be best The finaldecision rests with the requestor

Six possible outcomes can result from a change request:

It can be accommodated within the project resources and time lines. This

is the simplest of situations for the project manager to handle After ering the impact of the change on the project schedule, the project managerdecides that the change can be accommodated without any harmful effect

consid-on the schedule and resources

It can be accommodated but will require an extension of the deliverable schedule. The only impact that the change will have is to lengthen thedeliverable schedule No additional resources will be needed to accommo-date the change request.

It can be accommodated within the current deliverable schedule, but tional resources will be needed. To accommodate this change request,the project manager will need additional resources, but otherwise the current and revised schedule can be met

addi-It can be accommodated, but additional resources and an extension of the deliverable schedule will be required. This change request will requireadditional resources and a lengthened deliverable schedule

It can be accommodated with a multiple release strategy and prioritizing of the deliverables across the release dates. This situation comes up moreoften than you might expect To accommodate the change request, the proj-ect plan will have to be significantly revised, but there is an alternative Forexample, suppose that the original request was for a list of 10 features, andthey are in the current plan The change request asks for an additional twofeatures The project manager asks the customer to prioritize all 12 fea-tures He or she will give the customer eight of them earlier than the deliv-ery date for the original 10 features and will deliver the remaining fourfeatures later than the delivery date for the original 10 In other words, theproject manager will give the customer some of what is requested earlierthan requested and the balance later than requested We have seen severalcases where this compromise has worked quite well

It cannot be accommodated without a significant change to the project.

These change requests are significant They are so significant, in fact, as torender the current project plan obsolete There are two alternatives here.The first is to deny the change request, complete the project as planned,and handle the request as another project The other is to call a stop to thecurrent project, replan the project to accommodate the change, and launch

a new project

An integral part of the change control process is the documentation First, westrongly suggest that every change be treated as a major change until provenotherwise To do otherwise is to court disaster That means that every changerequest follows the same procedure Figure 10.14 is an example of the steps in

a typical change process The process is initiated, and the change request issubmitted by the customer, who uses a form like the one shown in Figure10.15 This form is forwarded to the manager or managers charged withreviewing such requests They may either accept the change as submitted orreturn it to the customer for rework and resubmission Once the changerequest has been accepted, it is forwarded to the project manager, who willperform an impact study

Figure 10.14 A typical change control process.

The impact study involves looking at the project plan, assessing how thechange request impacts the plan, and issuing the impact study, which is for-warded to the management group for final disposition They may return it tothe project manager for further analysis and recommendations or reject it and notify the customer of their action The project manager reworks theimpact study and returns it to the management group for final disposition Ifthey approve the change, the project manager will implement it into the proj-ect plan

Review change request

Review impact study Reject

Reject Rework & resubmit

Rework & resubmit

Submit change request

Request impact study

Change approved for implementation

Figure 10.15 Change control form.

Managing Problem Escalation

Something has happened that put the project plan at risk Late shipments fromsuppliers, equipment malfunction, sickness, random acts of nature, resigna-tions, priority changes, errors, and a host of other factors give rise to problemsthat can affect deliverables, deliverable schedules, and resource schedules Theproject manager owns the problem and must find a solution

Project Name

Change Requested By Date Change Requested

Description of Change

Business Justification

Action

Approved by Date

This situation is very different for the project manager than the case of achange request When a change request has been made, the project managerhas some leverage with the customer The customer wants something andmight be willing to negotiate to an acceptable resolution That is not the casewhen a problem has arisen on the project team The project manager does nothave any leverage and is in a much more difficult position.

When the unplanned happens, the project manager needs to determine theextent of the problem and take the appropriate corrective measures Minorvariations from plan will occur and may not require corrective measures.There are degrees of corrective measures available to the project manager: Intrying to resolve the problem the project manager will begin at the top of thefollowing list and work down the list, examining each choice until one isfound that solves the problem

There are three levels of escalation strategy: project manager–based, resourcemanager–based, and customer-based

Project manager–based strategies. If the problem occurs within a noncriticalpath activity, it can be resolved by using the free float One example is toreschedule the activity later in its ES to LF window or extend the duration

to use some of the free float Note that this strategy does not affect any otheractivities in the project By using total float, you impact the resource sched-ule for all activities that have this one as a predecessor Another approach is

to continue the schedule compression techniques employed in defining theoriginal project plan This strategy can impact resource schedules just as inthe prior case The last option open to the project manager is to consider theresource pool under his or her control Are there resources that can be reas-signed from noncritical path activities to assist with the problem activity?

Resource manager–based strategies. Once the project manager hasexhausted all the options under his or her control, it is time to turn to theresource managers for additional help This help may take the form ofadditional resources or rescheduling of already committed resources.Expect to make some trade-off here For example, you might be accommo-dated now, but at the sacrifice of later activities in the project At least youhave bought some time to resolve the downstream problem that will becreated by solving this upstream problem If the project manager has otherprojects underway, some trades across projects may solve the problem

Customer-based strategies. When all else fails, the project manager willhave to approach the customer The first strategy would be to consider anymultiple release strategies Delivering some functionality ahead of scheduleand the balance later than planned may be a good starting point The lastresort is to ask for an extension of time This is not as unpleasant as it mayseem because the customer’s schedule may have also slipped and the cus-tomer may be relieved to have a delay in your deliverable schedule, too

The Escalation Strategy Hierarchy

Our problem escalation strategy is based on the premise that the project ager will try to solve the problem with the resources he or she controls Failing

man-to do that, the project manager will appeal man-to resource managers As a lastresort, the project manager will appeal to the customer

One thing to note here that is very different from the change request situationdiscussed previously is the leverage to negotiate As mentioned, the projectmanager has leverage when the customer has requested a change but has noleverage when he or she has a project problem to solve The customer hasnothing to gain and, therefore, is less likely to be cooperative In most cases,the problem can be reduced to how to recover lost time There are six outcomes

to this problem situation

No action required (schedule slack will correct the problem). In this case,the slippage involved a noncritical path activity, and it will self-correct

Examine FS dependencies for schedule compression opportunities. Recallthat you originally compressed the schedule to accommodate the

requested project completion date by changing FS dependencies to SSdependencies The project manager will use that same strategy again Theproject schedule will have changed several times since work began, andthere may be several new opportunities to accomplish further compressionand solve the current problem

Reassign resources from noncritical path activities to correct the slippage.

Up to a point, the project manager controls the resources assigned to thisproject and others that he or she manages The project manager may beable to reassign resources from noncritical path activities to the activitiesthat have slipped These noncritical path activities may be in the same project in which the slippage occurred, or they may be in another projectmanaged by the same project manager

Negotiate additional resources. Having exhausted all of the resources he orshe controls, the project manager needs to turn to the resource managers asthe next strategy To recoup the lost time, the project manager needs addi-tional resources They may come in the form of added staff or dollars toacquire contract help

Negotiate multiple release strategies. These last two strategies involve thecustomer Just as in the case of a change request, the project manager canuse multiple release strategies here to advantage An example will illus-trate the strategy The project manager shares the problem with the cus-tomer and then asks for the customer to prioritize the features requested inthe project plan The project manager then offers to provide the highest-priority features ahead of their scheduled delivery date and the remainingpriorities later than the scheduled delivery date In other words, the project

manager asks for an extended delivery schedule, but by giving the tomer something better than the original bargain, namely something ahead

cus-of schedule

Request schedule extension from the customer. This is the final tive Although similar to the multiple release strategy, it offers the cus-tomer nothing in trade The slippage is such that the only resolution is toask for a time extension

alterna-The project manager tries to solve the problem by starting at the top of the list and working down until a solution is found By using this approach, theproject manager will first try to solve the problem with resources he or shecontrols, then with resources the resource managers control, and finally withresources and constraints the customer controls

Problem Management Meetings

Problem management meetings provide an oversight function to identify,monitor, and resolve problems that arise during the life of a project Everyproject has problems No matter how well planned or managed, there willalways be problems Many problems arise just as an accident of nature Forexample, one of your key staff members has resigned just as she was to beginworking on a critical path activity Her skills are in high demand, and she will be difficult to replace Each day that her position remains vacant

is another day’s delay in the project What will you do? Nevertheless, the project manager must be ready to take action in such cases The problem management meeting is one vehicle for addressing all problems that need to

be escalated above the individual for definition, solution identification, andresolution

This is an important function in the management of projects, especially large projects Problems are often identified in the project status meeting and referred to the appropriate persons for resolution A group is assembled

to work on the problem Progress reports are presented and discussed at aproblem management meeting Problem management meetings usually begin with a review of the status of the activity that gave rise to the problem,followed by a statement of the problem and a discussion to make sure every-one has the same understanding of the problem At that point the meetingshould move into the problem-solving process that was discussed in detail inChapter 9