<< . .

. 15
( : 22)



. . >>


Summing Up Quality Assessment
Collecting and analyzing metrics takes considerable time and effort. Perry knows, therefore, that it is
imperative to define and get agreement upon what quality means, what metrics are necessary, and how to
calculate them prior to taking the first step. He then proceeds to implement metrics for the project, which in
turn provide a baseline for managing change.




Exhibit 16-8. Standard deviation calculation.

Questions for Getting Started
1. Do you know exactly what the customer™s requirements are? If relevant, the internal customer? The
external customer?
2. Is there an agreed-upon definition of what constitutes quality?
3. Did you get agreement on what to measure?
4. Did you get agreement on what metrics to use?
Exhibit 16-9. Quartile example.
From the table on page 161, Perry determines a quartile by taking the total number of customer responses
(100) and dividing it into fourths. Thus, 100 divided by 4 equals 25. The following calculates the quartiles
using the example in the table.
Perry now begins to calculate the first quartile. The “poor” rating contains five responses. The first quartile,
however, is 25; therefore, he is 20 responses short (25 - 5). Thus, he must go to “fair,” the next class, which
has 0 responses. When 0 is added to 5, Perry is still 20 responses short of the first quartile. From the next
higher class, “good,” there are 25 responses; Perry needs 20 of those 25 to calculate the first quartile.
The formula for the first quartile is:
1 [from the "poor" rating] + 20/25 [from the "good" rating] = 1.8
Perry calculates the second quartile by taking the “first-half” of the responses, or 100 divided by 2, which
equals 50. He now needs to add the 5 “poor” responses, 0 “fair” responses, 25 “good” responses,“ and 20 of
the 30 “very good” responses to equal 50.
The formula for the second quartile is:
3 [the “good” rating] + 20/30 [from the “very good” rating] = 3.7
Perry calculates the third quartile by taking the first three-fourths of the responses, or three-fourths of 100,
which equals 75 responses. He now needs to add the 5 “poor” responses, 0 “fair” responses, 25 “good”
responses,“ 30 “very good” responses, and 15 of the 40 excellent responses to equal 75.
The formula for the third quartile is:
4 [the “very good” rating] + 15/40 [from the “excellent” rating] = 4.4
Hence, 25 percent of the respondents, or the first quartile, gave the hotel a rating of 1.8, which is
approximately “fair.” The second quartile, or 50 percent of the respondents, gave the hotel a rating of 3.7,
which is almost “very good.” This means that 50 percent of the customers gave the hotel a rating of “very
good” or lower. For the third quartile, 75 percent of the respondents rated the hotel between “very good”
and “excellent.” This means that 75 percent of the customers gave the hotel a rating between “very good”
and “excellent” or lower.
5. Have you identified what databases to use for metrics? Are the data reliable and valid?
6. Have you identified the expertise needed to perform the metrics? Is that expertise available? If not,
how will you get that expertise?
7. Have you identified the hardware and software tools to do metrics? Are those tools available? If not,
how will you get those tools?
8. How often do you plan to collect metrics?
9. Do you plan to use qualitative or quantitative metrics or both?
10. Are business considerations the major determinants of what metrics to use? If not, did you get
buy-in to the metrics you plan to develop?
11. Have you identified your key process indicators (KBIs)?
12. For quantitative metrics, have you developed a formula? Did you get buy-in to the formula?
13. When using data for calculating metrics, did you cleanse the data? Standardize the data?
14. If developing Pareto charts, did you define the x- and y-axes? The flags to look for?
15. If using checksheets, did you determine the intervals to record each occurrence? Do you plan to
display this information in the form of a histogram? The flags to look for?
16. If developing a histogram, did you define the x- and y-axes? The flags to look for?
17. If developing a control chart, did you identify the upper and lower control limits? The flags to look
for?
18. If developing a trend chart, did you define the x- and y-axes? The flags to look for?
19. Do you need to calculate the mean? Median? Mode? Standard deviation? Quartile?
20. Do you have a plan for communicating the 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 Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 17
Managing Changes to the Project
Ideally, Perry would like the Smythe Project to proceed as smoothly as possible ” that is, according to plan.
-----------
Yet he knows that nothing goes exactly according to plan. A project environment is dynamic, not static, and
changes will have to be made.

Managing Change
The key to handling project changes is to not resist them but to manage them. Perry puts in place good change
management disciplines that will help him determine whether to implement contingency plans to deal with
unanticipated events, take corrective action to get back on schedule, or make new plans for part of the project.
Each action he will take significantly impacts project execution.
Managing change makes good practical sense. It helps Perry focus on the plan by identifying variances. It
helps him maintain control by providing feedback on what is and should be happening at each step. Finally, it
allows him the opportunity to adjust or modify plans so the goals remain realistic.
Of course, Perry knows that managing change is not easy. The project is constantly moving ahead, making it
difficult to get an accurate snapshot. The right information in the right form at the right time is not readily
available and in some cases is nonexistent. It takes time to develop and implement an infrastructure to detect,
review, evaluate, and respond to changes. To deal with these obstacles and challenges, Perry must meet
certain requirements.
1. He must have reliable, valid information. Bad data lead to bad information, which in turn can result
in bad decisions.
2. He must have baselines to measure against. The baselines typically relate to cost, schedule, and
quality. The baseline is the criterion against which to judge actual performance. The variance is the
difference between what is supposed to be and what is. Perry must make decisions regarding any
variance. Those decisions might be to do nothing or to make changes.
3. He must have people who are adaptable to change. They should not be reactionaries or
revolutionists, but realists. Presumably he has chosen such team members, but if not, he must determine
how to deal with anyone who is overly resistant to change.
4. He must establish an infrastructure to manage change. He must institute policies, processes, and
procedures for reviewing, analyzing, and responding to change. He must communicate these policies,
processes, and procedures to team members. This infrastructure should also include people who are
responsible for identifying, reviewing, analyzing, and responding to changes. If necessary, these people
should help with scheduling, tracking, and monitoring the implementation of changes.
Perry will need to have a medium for capturing changes and tracking their fate, from identification to
disposition. The medium, typically an electronic or hard copy form, is shown in Exhibit 17-1.




Exhibit 17-1. Approved request form.
Decision-Making Basics
As a project manager, you will make decisions throughout a project. The hardest decisions with the most
risk come during latter phases, when the time is less and the impact more acute. Remember the following
basics of decision making.
1. Know when a decision is required. Be able to look at circumstances and determine if a decision is
necessary. Usually an anomaly or variance to a plan signals the need for a decision.
2. Determine your objectives. In other words, the decision must be purposeful.
3. Develop several alternatives. Brainstorm either by yourself or with team members.
4. Select the alternative that promises to provide the greatest payoff. How do you determine which
alternative that is? By developing a method, such as a weighted point scheme, to evaluate how well
each alternative satisfies the objectives. Then you rank the alternatives by score. The alternative with
the highest score is the one you select.
5. Develop and implement a plan. Since a project manager rarely has command and control over
team members, get buy-in for your plan.
6. Seek feedback while implementing the plan. This feedback will help you to refine the plan and
indicate how well you are achieving the objectives.

Types of Changes
To identify whether a change is necessary, Perry establishes a series of baselines. Baselines are agreed-upon
points of reference. In the project environment, baselines are set for schedule, budget, and quality.
Ideally, a project proceeds according to its baselines. However, variances can occur, and the project manager
must decide how to respond to those variances. First, however, the project manager analyzes and evaluates the
nature of a change. Many changes are internal, such as adjusting how a task is done because of an unrealistic
specification. Other changes originate from external sources. The customer or senior management may, for
example, arbitrarily reduce funding or change scope.
Perry develops a classification scheme for such changes. He classifies them as major, minor, or corrective.
• A major change dramatically affects schedule, cost, or quality. Examples include across-the-board
cuts in budget, expansion of the scope of the project without increasing the budget, or acceleration of
the scheduled completion date.
• A minor change is one that does not fit in the major category. Examples include a small change in the
specifications or requirements.
• A corrective change is nice to have but unnecessary. An example might be addressing an overlooked
“nice-to-have” specification.
Whether major, minor, or corrective, Perry assigns each change a priority. A priority can be either major,
minor, or deferral.
• A high priority change demands immediate attention. It is a “show stopper.” Generally, such changes
are major changes, too, but not necessarily. The customer, for example, would like to significantly
change the specifications, but the change is not doable without substantial changes to the schedule,
budget, or quality of the desired result.
• A medium priority change does not require immediate attention. However, it must be addressed
before the project ends. An example is an important but small change to the specifications.
• A low priority change is addressed, if time permits. These changes include “nice-to-have” features or
offers in a product or service, respectively.
Perry, of course, does not alone make decisions or change categories and priorities. He forms a change board,
which consists of people responsible for classifying and prioritizing changes. The people on the change board
are typically the project manager, selected team members, and customer representatives.
The change board does more, however, than just categorize and prioritize changes. It also analyzes the impact
of such changes on cost, schedule, and quality. It approves or disapproves the changes, and it assigns
responsibilities for executing these changes.


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 Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Corrective Action
Title
Sometimes the contingency plans do not work or an unanticipated event occurs. Either case, it impacts cost,
schedule, and quality and requires corrective action. This means taking steps to get the project back on track.
To take corrective action, Perry must address some challenges.
-----------
1. He must have sufficient data to define the problem and determine a solution.
2. He must distinguish between causes and symptoms. Using good analytical techniques can help, but
so will good data, especially if it answers the who, what, when, where, why, and how of the situation.
3. He must respond quickly. Procrastination and indecisiveness can convert a problem into a crisis.
4. He must recognize that corrective action occurs throughout the project cycle. There is a tendency for
project managers to think that ever-thing is fine up front, only to be surprised toward the end that
corrective action should have been taken earlier.
5. He must seek feedback on the corrective action taken. The feedback should indicate whether the
problem disappeared.

Replanning
If corrective actions are inadequate, Perry knows the next step: replanning. Replanning is redoing the project
plan by making wholesale changes to cost, schedule, and quality factors.
There are several reasons for replanning. First, it makes more sense to follow a realistic plan. Likewise, the
team works more efficiently because the changes have reduced confusion. The team is also more effective in
achieving the project goal.
To replan well, Perry must address certain prerequisites.
1. He must have reliable and valid data to determine whether replanning is necessary.
2. He must act quickly. If not, replanning will break synergy. It will also detract from productivity,
even under the old plan.
3. He and everyone else must have patience. Replanning takes effort and diagnosing past performance
can be sensitive. Some people do not want to replan; it only adds frustration. Other people fear being
blamed for the circumstances that led to the replanning.
4. He does replanning as early as possible. During the early phases of a project, replanning is easier.
Many unknowns are expected and the momentum is just beginning. However, it is more difficult to
replan during the latter phases. The momentum is faster, people are rushing to accomplish major
milestones, and it becomes more costly to do any rework.
5. He understands the impact that replanning will have. Will the replanning be expensive? How much
time and other resources will be required to replan? When must replanning be complete? What impact
will replanning have on cost, schedule, and quality?
When replanning, Perry remembers that there is no such thing as a free lunch. If he decides to schedule, there
will be negative and positive effects. The same can be said for cost, quality, and people factors.
Problem Solving
Life is full of problems, and projects have their share. These problems can overwhelm the best project
managers. It is important, therefore, to approach identifying and solving problems systematically.
Here are some rudimentary steps for solving problems.
1. Define the situation. That is, determine the variables or factors that indicate whether a problem
exists. Sliding of tasks on the critical path is an example.
2. Keep your cool. Do not let your emotions rule you and do not jump to conclusions. Focus on
defining the problem, answering the who, what, when, where, why, and how.
3. Do not confuse symptoms with causes. It is easy to misdiagnose the problem by focusing on a
symptom. Look at the big picture and then narrow to the issue. Define the problem in one or two
sentences.
4. Keep personality out of the picture. Liking or disliking someone usually has nothing to do with a
problem; failure to recognize that fact can cloud your objectivity in developing a meaningful solution.
5. Develop a plan. Devise a miniature project plan, if you will, to implement a solution.
6. Seek feedback. You may have addressed the cause but perhaps not in a way that completely fixes
the problem. Feedback will help you to refine your plan and achieve your solution.

Perry, for instance, decides to change the logic of the network diagram because the Smythe family wants to
have the bridal shower two weeks earlier. The Smythe family also wants to increase the number of attendees
by 20 percent and add more events. All this affects the schedule, of course, but also the scope of the project.
The changes also have positive and negative impacts. A positive impact is satisfying the customer; a negative
impact is temporarily slowing the momentum of the project, which in turn reduces productivity.

Contingency Planning
Ideally, risk assessment (see Chapter 12) provides the basis for good contingency planning. Contingency
planning involves developing responses to situations that have a good probability of occurrence and could
impact project performance.




Exhibit 17-2 Contingency plan form.
For the Smythe Project, Perry develops a contingency form, shown in Exhibit 17-2. He records the description
of the event; its probability of occurrence; its impact on cost, schedule, and quality; and the appropriate
response.
Reliable contingency plans don™t just happen, as Perry well knows. They require having information about
possible events, including their potential impact; time preparation; and feedback indicating when the events
do occur.

Summing Up Change Management
The project environment is not static. No matter what plans or baseline he establishes, Perry knows that he
will have to evaluate and implement changes. He also knows that change affects costs, schedule, quality, or a
combination of them. He is determined to manage change; otherwise, change will manage him and he can
quickly lose control.
Questions for Getting Started
1. If you decided to take corrective action, did you:
• Determine exactly what caused the need for corrective action?
• Determine the most appropriate corrective action and implement it?
• Receive input from the people affected by the corrective action?
• Set a “blockpoint” date for the corrective action to be implemented?
• Communicate the corrective action in advance?
• Seek feedback after the corrective action was implemented?
2. If replanning, did you:
• Determine what is the cause for replanning?
• Determine what areas (e.g., cost, schedule, quality) of the project are affected by the
replanning? The negative and positive impacts?
• Determine resource requirements and their availability for resource planning?
• Determine the data and information requirements for replanning?
• Obtain input from all of the people affected by the replanning?
• Obtain feedback from all the affected people once the new plans went into effect?
3. If doing contingency planning, did you:
• Determine and document the possible events using the risk assessment?
• For each event, determine and document the probability of occurrence, the projected impact,
and the appropriate response?
• Make sure the plans are readily available?
• Assign someone responsible for upkeeping and executing the contingency plan?
• Receive input from the people affected by the contingency plan?
• Obtain and assess relevant feedback from the individuals affected by the contingency plan after
it has been implemented?
4. Did you establish a change management infrastructure that includes a means for:
• Classifying changes?
• Prioritizing changes?
• Evaluating changes (e.g., change board)?
• Documenting changes?
• Tracking, monitoring, and addressing changes?
• Communicating changes?
• Following up on changes?


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 Practitioner's Handbook
by Ralph L. Kleim and Irwin S. Ludin
AMACOM Books
ISBN: 0814403964 Pub Date: 01/01/98

Search this book:
Search Tips

Advanced Search


Previous Table of Contents Next



Title
Chapter 18
Project Closure
All projects eventually end. Some end successfully, others end in disasters. Some common reasons why
-----------
projects end poorly are changing market conditions, lack of cooperation from clients, lack of management
support, lack of resources, politics, technical problems, and poor management. Exhibit 18-1 sums up the
management reasons for failure, while Exhibit 18-2 lists reasons for success.
Fortunately for Perry, the Smythe Project ended successfully: the wedding proceeded as planned, meeting all
milestone dates on time, consuming all monies within the budgeted amount, and giving the Smythe family
exactly what they wanted. Unlike other weddings, the team™s morale was extremely high up to the very end.
Despite overwhelming success, not everything worked perfectly. Some communications, coordination, and
implementation problems arose, and projects Perry handles in the future will benefit from what he learned.
Exhibit 18-1. Common reasons for project failure.
Leading Organizing
• Avoiding conflict • Lacking resources
• Burning out of team members • Lacking accurate knowledge and expertise
• Delaying decision making • Having unclear authorities and responsibilities
• Lacking cooperation
• Lacking customer involvement Controlling
• Lacking senior management support • Failing to deal with a changing environment
• Communicating poorly • Failing to manage change
• Setting unrealistic expectations • Overemphasizing on technology issues at expense of
business issues
Defining • Competing too much for resources
• Having ill-defined, too large, too small a scope
• Having incomplete or unclear requirements Closure
• Finding errors too late
Planning • Failing to learn from past problems
• No planning
• Poorly formulating plans
• Having unclear, unrealistic plans

Exhibit 18-2. Common reasons for project success.
Leading Organizing
• Having the support of senior management • Assigning responsibility for well-defined deliverables
• Obtaining customer involvement
• Maintaining realistic expectations • Having a good communication infrastructure in place
• Encouraging and sustaining a sense of owner
ship by all participants
• Having clear lines of authorities and responsibilities
• Having commitment and cooperation of all
participants
• Having a team with requisite knowledge and expertise
• Promoting integrity
Defining Controlling
• Chunking the project into manageable pieces • Having a documented change management in place
• Keep the scope well-defined
• Clear definition of requirements • Holding regular and frequent meetings
• Focus on customer • Avoiding scope “creep”
• Clear mission and objectives • Taking regular measurements of performance
Planning Closure
• Focusing evenly on technical and business • Releasing people correctly to minimize impacton morale
issues and performance
• Developing meaningful plans
• Having more frequent project milestones
• Having shorter flow time
• Simplifying

<< . .

. 15
( : 22)



. . >>