<<

. 4
( 6)



>>

D. Other
VIII. OTHER ADMINISTRATIVE TOPICS
IX. APPENDICES

Questions for Getting Started
1. If developing procedures, did you:
• Identify the topics?
• Determine the types of procedures needed?
• Receive reviews by all relevant people?
• Distribute the procedures?
• Document the procedures?
• Place the procedures under configuration control?
• Seek feedback?
2. If developing flowcharts, did you:
• Identify the topics?
• Determine the types of diagrams to use?
• Issue standard templates?
• Determine whether the flowchart will supplement or replace a procedure?
• Distribute the flowchart?
• Seek feedback?
3. If developing forms, did you:
• Determine what forms you need?
• Design each form according to the characteristics described in this chapter?
• Determine how people can obtain a copy of the form?
• Determine how and where people can submit a completed form?
• Institute a way for people to provide feedback on the forms?
4. If developing reports, did you:
• Determine the necessary types of reports to use?
• Design each report according to the characteristics described in this chapter?
• Inform everyone who need to receive the reports?
• Develop a distribution list?
• Determine the frequency of generation for each report?
• Determine where to store the reports?
• Seek feedback from users?
5. If you need to prepare a memo, did you:
• include a date, subject title, address, signature block, and purpose statement?
• Answer the who, what, when, where, and why questions?
• Check for clarity, conciseness, directives, legibility, and structure?
6. If you decide to publish a newsletter, did you determine: Who will prepare the newsletter?
• The frequency of the publication?
• Who must review it prior to each publication?
• The topics?
• The layout?
• The method of distribution?
7. If you decide to have a project manual, did you:
• Determine the method for keeping the manual -- that is, hard copy, electronic copy, Web site?
• Determine the contents?
• Develop a structure, reflected in the form of a table of contents?
• Determine the number of copies?
• Select the mode of binding?
• Assign responsibilities for keeping the manual current?
• Set up a format for reviewing the contents?
• Seek feedback?
8. If you elected to set up project history files, did you:
• Determine the contents?
• Determine the organizational structure?
• Assign responsibility for maintaining them?
• Establish a procedure for accessing, removing and replacing them?
• Communicate their location and procedure for accessing, removing, and returning them?
9. If you decide to set up a project library, did you:
• Determine the contents?
• Determine the filing system?
• Assign responsibility for maintaining it?
• Establish a procedure for accessing, removing, and replacing material?
• Communicate the location and procedure for accessing, removing, and returning material?


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 14
Team Dynamics and Successful Interactions
The organization functions of the project manager™s job extend well beyond developing the team, allocating
-----------
resources, estimating costs, and providing documentation. The project manager also needs to set up the
elements for facilitating team dynamics”in other words, making it all work. This includes setting up a
project office, holding regular meetings, making presentations, and using people skills to encourage team
members to reach the project goal.

Set Up the Project Office
Since his project is comparatively large and has high visibility, Perry sets up a project office. Despite
employing a Web site and other computer technologies for communications, he™ll need a central location to
manage the efforts.
Perry™s ideal office has telephones, fax, and other communications equipment, as well as storage space for
hard-copy forms, the history files, and the project library. Since the project office will also be a meeting place
for team members, it has cubicles for working and conference rooms to hold meetings, training sessions, and
other project-related activities. There is equipment such as easel stands, overhead projector with extra bulbs,
screen, whiteboards, and tables with a sufficient number of chairs. In addition, the project office has tape,
writing instruments, paper, viewfoils, sticky notes, paper clips, easel pads, and the like.
While this all sounds like common sense, the reality is that many projects, even those with a project office,
lack such simple resources. Some advance planning in this regard can make managing the project much
smoother.
Often overlooked, too, is the realization that the project office is a communications center. It is like a
computer network control center where all information flows in and out. In this communications center is a
very important tool, called a visibility wall or visibility room. This wall or room is where all project
documentation is showcased. Perry puts on the walls of his visibility room his bar charts, maps, minutes of
key meetings, network diagrams, organization charts, photographs (e.g., recognition awards), process flows,
responsibility matrices, statements of work, technical drawings, and work breakdown structures. Essentially,
what goes on the walls depends on what Perry deems important for everyone to see.
When setting up a visibility room, Perry remembers the following points.
1. Plan in advance. On a sheet of paper, Perry draws a picture of what goes on which wall. This
prevents rework and reduces costs, especially if he is using high-quality graphics.
2. Keep the walls current. This way people have a reason to review the walls. The walls serve no
purpose if no one looks at them.
3. Use the walls. Perry will hold meetings in the room and refer to the items posted; his actions enforce
the importance of the information on the walls.

Conduct Meetings
There will be meetings frequently, and they will consume a large percentage of everyone™s time. These
meetings are usually one of three basic types: checkpoint reviews, status reviews, and staff meetings. In
addition, there are occasional ad hoc meetings.
The checkpoint review is held at specific points in time, usually after a red-letter day or significant event (e.g.,
completion of a major milestone). Its purpose is to determine what has been done and decide whether to
proceed or cancel the project. Exhibit 14-1 is an agenda from one of Perry™s checkpoint reviews.
The purpose of the status review is to collect information to determine progress in satisfying cost, schedule,
and quality criteria. The status review is held regularly (e.g., weekly or biweekly). Exhibit 14-2 is an agenda
from one of Perry™s status reviews.
Like the status review, the staff meeting is held regularly. All team members receive information from the
project manager and share additional data and insights. Exhibit 14-3 is an agenda from one of Perry™s staff
meetings.
The ad hoc meeting is held irregularly, often spontaneously by team members. The idea is to resolve an issue
or communicate information. Exhibit 14-4 is an agenda from one of the Smythe Project™s many ad hoc
meetings.
Whether conducting a staff meeting, status review, checkpoint review, or ad hoc meeting, Perry applies five
rules to ensure efficient and effective meetings.
Exhibit 14-1. Checkpoint review agenda.
Agenda
April 7, 19XX
I. Background
A. Previous red-letter events/milestones
B. Challenge in the past
II. Lessons regarding this event
A. Achievements/successes
B. Problems and challenges
C. Remaining issues
III. Decision whether to proceed as is, differently, or halt
IV. Remaining issues
V. Open forum

Exhibit 14-2. Status review agenda.
Agenda
February 28, 19XX
1. Input to status regarding:
A. Schedule
B. Budget
C. Quality
II. Issues and concerns regarding:
A. Schedule
B. Budget
C. Quality
D. Other
III. Open forum
IV. Next meeting

Exhibit 14-3. Staff meeting agenda.
Agenda
March 3, 19XX
I. Information
A. Announcements
B. Issues of concern
• Schedule
• Quality
• Budget
• Other
C. Recognition
D. Upcoming issues and events
E. Open Forum
F. Next Meeting
1. Prepare an agenda. He will follow an agenda like the ones in Exhibits 14-1 through 14-4. An agenda
is a logical listing of topics to cover. It keeps the meeting focused and ensures that it is productive.
2. Announce the meeting. He notifies attendees about the meeting in advance. Even if it is an ad hoc
meeting, he informs people about the purpose of the meeting.
3. Be prepared. He comes with the right supplies, equipment, and copies of documents to distribute.
This way there™s no last-minute searches for equipment or extra copies.
4. Encourage participation. He gives everyone the opportunity to contribute, but avoids letting anyone
dominate the meeting. He makes sure the meeting doesn™t become a platform for someone™s
pontification, including himself.
5. Take notes and distribute the minutes afterwards. By taking notes and converting them into minutes,
he communicates the importance of the meeting and increases the likelihood of people honoring their
commitments.


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

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management 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



Give Effective Presentations
Title

Perry and his team will be giving presentations, either among themselves, to senior management, or to the
customer. These presentations require more than standing in front of people and talking. They involve
communicating.
-----------
Exhibit 14-4. Ad hoc meeting agenda.
Agenda
June 11, 19XX
I. Description of situation or problem
A. Previous red-letter events/milestones
II. Background details
A. Who
B. What
C. When
D. Where
E. Why
F. How
III. Alternative courses of action
IV. Select appropriate course of action
V. Plan to implement course of action
A. Who
B. What
C. When
D. Where
E. Why
F. How
VI. Follow-up meeting

Perry will likely have to give three fundamental types of presentations. The first is a presentation to persuade.
He will, for example, probably have to convince senior management to provide more resources. The second
type of presentation is to inform. He will probably have to communicate information, for example, to senior
managers about cost and schedule performance. And the third type is to explain. For example, he might have
to instruct people on project management tools and techniques.
Of course, team members will likely have to give the same types of presentations. Whether you are a project
manager or team member, as a presenter you must follow six fundamental steps:
1. Know yourself and the audience. Find out about the audience to ascertain your commonalities and
differences. You can get useful information, for example, by interviewing people who know audience
members. Follow up by making a list of what you share and don™t share with the audience. This
knowledge will prove useful in preparing the presentation.
2. Perceive your audience and how it perceives you. Look at ways to influence the audience to see you
in a favorable light. This will make it easier to communicate your message. You can win the audience
over, for example, by expressing values or experiences you share with its members.
3. Determine the type and structure of the presentation. Answer all the who, what, when, where, and
why questions pertaining to your topic. Determine if your presentation is meant to inform, persuade, or
explain. Then formulate your overall strategy to achieve the goal of your presentation, and your tactics
for executing that strategy.
4. Develop the material. Build your presentation. Determine the content and logically arrange it. For
example, you can arrange topics chronologically or by level of importance. Also incorporate visual
aids, statistics, and other materials.
5. Rehearse. Practice as if you were actually giving the presentation”do a dry run. Try to improve
your delivery. This is also the time to become familiar with the location for the presentation”room
size, lighting, sound equipment, and so on. Rehearse there, if you can.
6. Deliver the presentation. You have polished your delivery, eliminated any poorly designed visual
aids and distracting mannerisms (e.g., pacing about with your hands in your pockets or playing with
pocket change). You should encourage and be prepared to answer questions. You might elicit questions
from a reluctant audience by asking a question yourself.

Apply Interpersonal Skills
Interpersonal skills, also called people skills, play an integral part in the success of every project. Whatever
gets accomplished is done by people and their interactions, so interpersonal skills can seriously impact results.
Interpersonal relations embrace three primary skills: being an active listener, reading people, and dealing with
conflicts effectively.

Being an Active Listener

One of the best communication tools a project manager can have is active listening. It means listening
genuinely to what the speaker is saying”in short, focusing on what is said and how it is said.
Active listeners:
• Avoid interrupting the person except to clarify a point.
• Give listening cues (e.g., nod the head or use an expression) to indicate involvement in the
conversation.
• Are not preoccupied with something else during the conversation (e.g., working on documentation
while the other person talks).
• Do not change the topic abruptly during the conversation.
• Do not daydream while the other person talks.
• Pay as much attention to body language as to the oral message.
• Remove all distractions (e.g., radio playing in the background).
The key is to be active, not passive, by becoming fully engaged in what is being said.

Reading People
It would be nice to know the true motives of people; however, that is impossible, since many people are not
open and honest. Project managers, therefore, must identify the real issues and motivations of people.
Fortunately, there are tools to help project managers understand the motivations of people. Unfortunately,
these tools do not always work, owing to the vagaries of human nature. Still, many project managers find
them useful.
One tool is the Myers-Briggs Type Indicator for personality preferences. This identifies personality types
based on a combination of four preferences: extrovert (outward) versus introvert (inward), sensing (actual)
versus intuitive (sixth sense), thinking (structuring information) versus feeling (personal), and judging
(organized) versus perceiving (spontaneous). These categories are useful, but require a good understanding of
the preferences.
This approach does not specify which personality is better or worse or which one is good or bad. It states only
that people have a preference that is reflected in the way they deal with reality, their environment, and their
relationships. An excellent resource for using this indicator is Please Understand Me: Character and
Temperament Types, by David Keirsey and Marilyn Bates.
Another popular tool is Abraham Maslow™s hierarchy of needs, described in Chapter 4. This model is easier
to use, since it identifies people™s needs according to hierarchical order: physiological (food), safety (shelter),
social (acceptance), esteem (sense of importance), and self-actualization (becoming). The satisfaction, or lack
of earlier needs, dictates the motivations of people.


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



Another popular, though less widespread, personality tool is Robert
Title
Transactional Analysis
Transactional analysis, or TA, describes how people interact with each other via ego states. An ego state is a
combination of feelings and experiences that manifest themselves in the way people consistently behave.
----------- Essentially, behavior reflects one™s feelings and experiences.
TA posits three ego states: parent, child, and adult.
• The parent ego state reflects parental feelings and experiences, like being critical and directive.
• The adult ego state reflects being realistic and objective when dealing with people.
• The child ego state reflects childlike behavior, like trying to please, uncontrollable laughter, or
rebelliousness.
The interaction between two people reflects a transaction. There are several types of transactions between
people, with some being parent-to-parent, parent-to-child, and parent-to-adult. Such transactions can be
detected through body language and verbally.
An excellent book on TA is Born to Win: Transactional Analysis with Gestalt Experiments, by Muriel
James and Dorothy Jongeward (Reading, Mass.: Addison Wesley, 1987).

Bolton™s social style matrix. Bolton divides social styles and personal expectations into two dimensions:
assertiveness and responsiveness. Assertiveness is the energy or effort individuals invest in influencing others.
Responsiveness is the energy or effort individuals invest in controlling their emotions when dealing with other
people. The combination of assertiveness and responsiveness creates social stereotypes: analytical (logical),
driver (determined), amiable (diplomatic), and expressive (spontaneous). Bolton™s topology does not say
which social style is better or worse, or which one is good or bad. It simply states that people have to deal
with life in general and social environments in particular. For more information, see Social Style/Management
Style by Robert and Dorothy Bolton.
There are, of course, a plethora of theories about people and how to understand them, from Sigmund Freud
and Carl Jung to B. F. Skinner and Frederick Herzberg. The key is to find a model or tool that works best for
you, then apply it in your own circumstances.
An interesting and often reliable side concept about people is their body language. According to motivational
experts, our body language reveals more about us than what we say. Some experts estimate that body
language makes up 70 to 90 percent of a conversation. This means you need to pay attention to facial
expressions, body movements, posture, and eye movements. A mastery of the art of reading body language
can help the project manager discern whether people are truly committed to the project or providing honest
status information.
There are two caveats about relying on body language. The first is to look at body language in totality”that
is, avoid relying on one body movement alone. The other is that cultural differences can mislead in the
interpretation of true motivations. In some cultures, for instance, it is acceptable behavior to stand closer
together or to maintain eye contact while in others it is not. A misinterpretation can result in real problems.
Perry keeps this thought in mind, since the Smythe wedding will occur in Italy; body language in Italy can
have entirely different meanings from that in the United States.

Deal With Conflict Effectively

Conflict is a way of life and it can surface anytime during the project cycle. Conflict can arise over sharing
people, equipment, supplies, or money; over goals and specifications; between personalities; over differences
of opinion; and even over power.
The potential for conflict is highest, however, at the beginning, when a project manager competes for
resources or when difficulties arise over contractual requirements. And conflict at the beginning can lead to
even more difficulties later if it is not addressed properly. The potential for conflict is high, too, at the end of
the cycle, when participants face schedule pressures. Conflict in and of itself is not bad. It can alert project
managers to problems that must be addressed. The challenge is to manage the conflict in a manner that leads
to project success rather than failure.
Project managers, like all people, deal with conflict differently. Some project managers avoid it, letting it
smolder. Some project managers give up every time a conflict surfaces. Other project managers deny that
conflict exists at all. And some masterfully blame others. These are all defense mechanisms. Nevertheless,
they do not deal with the conflict. All these mechanisms manage to do is avoid conflict or push it into the
background.


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



The question, then, is how to deal with conflict constructively. Since it really centers on people, it makes
Title
sense to view conflict as primarily a people issue. Perry takes several actions to respond to conflict.
1. He diffuses the charged emotion within himself. If he has to, he will do something as simple as
count to ten before doing anything.
2. He diffuses the charged emotions in other people. He will calm down people by calling for a
-----------
cooling-off period, especially when emotions run high.
3. He identifies the facts of the situation to determine the cause of the conflict. He avoids comments
that can be viewed as taking sides or being accusational.
4. He applies active listening. He listens for the facts to acquire an objective assessment of the
situation. Active listening helps to avoid being “pulled into” the conflict.
5. He acknowledges any anger that may be present, while focusing on the merits of the conflict. If
anger is justified, he acknowledges it.
6. He keeps everyone focused on the cause of the conflict. He avoids the tendency to blame someone
or to rationalize it away.
7. He keeps the big picture in focus. He asks himself what the best way is to resolve the conflict so as
to achieve the project goal.
8. He sets a plan for resolving the conflict. He also remains objective.
9. He seeks participation in the resolution. Unless an impasse occurs, he lets the people decide on a
mutually agreeable solution. That builds bridges and commitment to the solution.
10. He encourages a win-win solution, not a win-lose or lose-lose. With a win-win solution, emotions
will subside and there will be little or no room for bitterness.
Handling Difficult People
Project managers work under pressure, with little formal authority over people. Dealing with difficult people
under such circumstances just adds stress as they try to bring their projects in on time and within budget.
If that were not enough, project managers must deal with different types of difficult people. In his superb
book Coping with Difficult People (New York: Dell Publishing, 1981), Dr. Robert Bramson identifies what
he calls the hostile aggressive, com-pleat complainer, clam, super-agreeable, negativist, bulldozer, balloon,
and staller.
In the project environment, all these categories of difficult people are present.
The hostile aggressive, for example, likes to “shoot holes” in any schedule proposal. The super-agreeable
agrees to perform a task by a certain date but changes his mind based on who he talked with last. The staller
is the customer who is required to make a decision and takes forever, causing the project to be delayed.

Getting Teamwork to Work
How people on a team interact can influence the results of a project. Setting up an adequate project office
contributes to effective teamwork in any project-oriented team. In addition, good communication and
interpersonal skills, and effective use of conflict management techniques can go a long way toward producing
positive results for a project. Perry realizes, however, that the responsibility lies with everyone to exercise
positive team dynamics throughout the life of the project.

Questions for Getting Started

1. If setting up a project office, did you:
• Develop a layout?
• Determine the contents?
• Determine the location?
• Determine who will work there?
• Determine the necessary equipment and supplies?
2. If setting up a visibility wall or room, did you:
• Develop a layout?
• Determine the contents?
• Determine its purpose?
3. If holding checkpoint review meetings, did you:
• Decide to have agendas?
• Determine the locations?
• Determine how to notify attendees?
• Decide to have minutes taken?
• Determine the necessary equipment and supplies?
• Make an effort to get everyone™s participation?
• Determine length of the meetings?
4. If holding status review meetings, did you:
• Decide to have agendas?
• Determine the locations?
• Determine how to notify attendees?
• Decide to have minutes taken?
• Determine the necessary equipment and supplies?
• Make an effort to get everyone™s participation?
• Determine length of the meetings?
5. If holding staff meetings, did you:
• Decide to have agendas?
• Determine the locations?
• Determine how to notify attendees?
• Decide to have minutes taken?
• Determine the necessary equipment and supplies?
• Make an effort to get everyone™s participation?
• Determine length of the meetings?
6. If holding ad hoc meetings, did you:
• Decide to have agendas?
• Determine the locations?
• Determine how to notify attendees?
• Decide to have minutes taken?
• Determine the necessary equipment and supplies?
• Make an effort to get everyone™s participation?
• Determine length of the meetings?
7. If giving presentations, did you:
• Determine the types to give?
• Determine your audience?
• Recognize the key perceptions?
• Prepare the logical structure?
• Develop clean, meaningful material?
• Rehearse?
• Give a successful delivery?
8. Are you an active listener?
9. Can you “read people”? Do you need a way to do that? What is that way?
10. How well do you deal with conflict? What approach do you take to deal with it? On an individual
basis? On a team basis?


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 15
Performance Assessment: Tracking and Monitoring
With a solid project definition, plan, and organizational infrastructure, Perry is confident that he can control
-----------
his project. He is not naïve enough, however, to think that he can sit back and remain idle. Quite the contrary,
he knows all about Murphy™s law. He knows from the physicist™s view of the universe that entropy can occur.
So he responds”not reacts”to changing circumstances. He does that best by tracking and monitoring
performance. And the keys to tracking and monitoring performance are status data and status assessments.

Collect Status Data
Status data offer several advantages for Perry. From the data he can determine project performance ”
specifically, how well the goals of the project are being met. He can also determine how efficiently work is
being done. He can reduce his and everyone else™s frustration and anxiety by providing feedback. It instills
confidence in everyone that the project is under control, that the project manager is monitoring its pulse.
Finally, he can maintain communications and information sharing among the participants.
Unfortunately, status data are often not collected well. The task can be labor intensive and time-consuming.
This is especially the case when there is no previous infrastructure in place or when the team members lack
experience. If the project manager, or the team, lacks the expertise or knowledge of collection, there may be
an inappropriate assessment. Also, the project team may be using incompatible computing tools and
converting the data requires considerable effort and expertise. Teams using older software and hardware
particularly find this situation complicates data collection.
The style of the project manager can affect data collection. If she prefers to “shoot from the hip” or rely less
on administration, the project manager will likely rely more on intuition and informal methods for data
collection. Though there™s some merit under certain circumstances, this can result in gross misjudgments.
Likewise, the project manager may not have a good grasp of the project™s scope. Failure to understand the
scope can result in problems determining what data are needed.
Perry, fortunately, is not one of these project managers. He understands the importance of reliable data. He
must have certain prerequisites in place to do meaningful assessments.
• A solid information infrastructure. He sets up a process for identifying, collecting, and compiling
data that will be reliable and valid.
• Available expertise. He assigns responsibility for collecting data to someone who has a good
understanding of data collection techniques.
• A standardized set of tools to collect and compile the data. He knows that a mixture of incompatible
hardware and software will cause frustration levels to rise and nobody, not even himself, will bother to
collect data.
• Clear value in collecting data. If people do not see the value of data collection, they will be reluctant
to expend the effort. Collecting data must be meaningful on both individual and group levels. This
distinction is important, since it affects how the data will eventually be formatted and reported.

Methods of Collection

Perry uses formal and informal modes for collecting data. Formal modes include status reviews, one-on-one
sessions, and forms.
The status review, discussed in Chapter 13, is held regularly. The meeting covers cost, schedule, and quality
measures. Perry collects data prior to the status review, so that at the meeting he can discuss the current status,
make an assessment, and determine corrective actions. With proper technology, he could, at the meeting, enter
the data into a computer, generate the necessary reports, assess the program, and decide an appropriate action
to take.
There are problems with collecting data at status review meetings. For example, sometimes the meetings can
skew results. Peer pressure can directly or indirectly force people to fudge the data in order to paint an
optimistic or pessimistic picture. It is also important to remember that while collecting status data, the project
manager remain objective and not influence the reports. The project manager must hear what he needs to hear
and not what he wants to hear. Biased data lead to biased assessments.
One-on-one sessions work best for collecting data just prior to a status review. The project manager or her
representatives meet with each person individually to collect status data.
But as the number of team members increases, so does the time needed to collect data and, as time passes by,
the data age. Also, the data collected in one-on-one sessions could be more subjective than if gathered in a
group setting. If peer pressure does not overtake a status meeting, more objective data will likely be available
as people question the reports.
Forms are another way to collect data. Team members complete the forms with status data and submit them to
the project office for processing. The data are then compiled. Ideally, the forms are computer-based and team
members can forward them electronically for quick, easy compilation.
Collecting data on forms presents a challenge, however. Getting the forms submitted on time is one problem,
since some people often procrastinate. The other is that forms may get lost. Both problems grow in magnitude
as the number of team members gets larger.
Informal modes of data collection include holding ad hoc sessions, using word of mouth, and relying on your
own judgment regarding status. Informal modes are quicker and involve less administrative hassles; they are
the path of least resistance. But the data collected may not be objective, resulting in a greater chance of error.
Still, many project managers rely on informal methods.
Perry decides to use both formal and informal modes of data collection. He uses status reviews to verify the
accuracy of the data collected in one-on-one sessions and via forms. But he also keeps his ears open for
additional information.

Data Validity and Reliability

When collecting data, Perry keeps two main concepts in mind: reliability and validity. Reliability implies
consistent results”in other words, does the data yield reliable results? Validity involves the approach or tool
used to collect data. Does it influence the results, thereby introducing bias, which in turn slants the results?
Some validity errors include inconsistent application of measurement tools, failing to account for changing
circumstances, using a collection tool that guarantees a particular result, and undue influence by the
personality of the data collector. These are threats to data validity because they influence the data being
inputted and the information being derived.
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



There are other examples of how collection efforts can negatively influence data reliability and validity.
Title
• The “90 percent syndrome.” Team members say they have 90 percent completed a task; for its
remainder, it stays 90 percent complete. Then the task slides past its completion date. Of course, the
problem is that the last 10 percent proves the most difficult.
• The Hawthorne effect. What was accomplished just prior to collection influences a person™s estimate
-----------
of the amount of work done. The problem is that what was done last may not be significant, giving a
misleading impression.
• Overly negative or positive data. Some team members always exaggerate, saying too much or too
little has been done.
• The “good news” effect. Some team members tell the project manager what she wants to hear,
usually good news. Hence, the project manager does not get a balanced view.
• Lies. Rather than give honest data, some people lie, figuring perhaps no one will know or the project
manager will eventually leave before anyone finds out.
Faulty data collection can have a big impact on project performance. Garbage in, garbage out: the quality of
output is only as good as the quality of input. Good data lead to good decision making; bad data lead to poor
decision making.

Assess Status
With reliable and valid data, Perry can assess overall project performance. Assessment involves determining
how well the project has and will achieve its goals. Perry focuses on three areas: schedule, cost, and quality.
Perry assesses status via two principal reviews, looking back (history) and looking forward (the future).
Looking at past performance is called tracking; projecting into the future using past performance is called
monitoring. Both are important for determining where the project has been and where it will be if the current
level of performance continues.
A key concept behind assessing status is variance, the difference between what is planned and what has
actually occurred up to a specific point. The formula is quite simple:
Variance = planned ” actual
If the difference between the two is zero or a positive number, then the project is proceeding as expected,
whether from a cost, schedule, or quality perspective. If the difference between the planned and the actual is a
negative number, then the project is not progressing as anticipated. Quality variance is discussed in Chapter
16; the remainder of this chapter deals with cost and schedule variances.
It is important to note, however, that variance is a deviation from what is expected. The deviation in itself
may not necessarily mean something is wrong”it can indicate something good, too. A variance is a signal to
investigate the situation and determine whether to take action.

Determining Variance

The tracking portion of the variance calculation is the actual to date. The monitoring portion is the estimate at
completion; it is based on actual progress to date plus the remainder of work to do, assuming the current rate
of progress is maintained.
Cost variance is calculated by using this equation:
Cost variance = budgeted cost ” actual cost
The equation result tells Perry whether he has spent more money than planned up to a specific point in time.
He calculates it for each task, which in turn is accumulated to give the total estimate at completion for the
entire project. A positive value is called an underrun and a negative one is called an overrun. Exhibit 15-1
shows examples of cost variances on the Smythe Project.
Exhibit 15-1. Cost variances.
Smythe Project Budget Sheet
$ in Thousands
April 16, _____
Budget to Actual to Total Estimate at
Task Date Date Underrun Overrun Budget Completion
6.1.1.1
Identify limousine 168 360 192 840 1,032
service to church
6.1.1.2
Coordinate limousine 56 104 48 280 328
service to church
6.1.1.3
Identify limousine 168 110 58 840 782
service to reception
6.1.1.4
Coordinate limousine 56 124 68 280 348
service to reception

Schedule variance follows the same pattern. It is the difference between planned and actual start and end
dates, respectively. This variance tells Perry whether he has spent more time than planned on a task up to a
specific point in time. He calculates it for each task, which in turn is accumulated to give the total estimate at
completion for the entire project. A positive value represents an ahead-of-schedule condition while a negative
one represents a behind-schedule situation. Exhibit 15-2 has some examples from the Smythe Project.

Earned Value

In the previous section, cost and schedule variances were treated independently. There is, however, a way to
treat them as an integrated entity, called earned value. It is the preferred way to measure project performance.
Earned value consists of three basic variables:
Exhibit 15-2. Project schedule sheet.
Smythe Project Schedule Sheet
April 16, _____
Duration Actual Estimate at
Task Early Start Early Finish (days) Actual Start Finish Completion
6.1.1.1
Identify limousine April 1 April 3 3 April 2 April 5 April 5
service to church
6.1.1.2
Coordinate limousine April 7 April 7 1 April 9 April 11
service to church
6.1.2.1
Determine
transportation April 4 April 6 3 April 6 April 7 April 7
requirements to
church
6.1.2.2
Coordinate
April 7 April 8 2 April 7
transportation to
church
6.1.2.5
Arrange for valet April 9 April 9 1
service for church
• Budgeted cost for work scheduled
• Budgeted cost for work performed
• Actual cost of work performed
The budgeted cost for work scheduled (BCWS) is the estimated cost for a task, or group of tasks, that are
scheduled to be performed for a specific time period. In other words, it is the estimated value of the work
scheduled. The budgeted cost for work performed (BCWP) is the estimated cost that is approved for a task or
group of tasks, to be completed up to a specific period of time. In other words, it is the estimated value of the
work completed up to a specific point in time. The actual cost of work performed (ACWP) is the actual costs
accrued for a task, or group of tasks, up to a specific point in time.


Previous Table of Contents Next




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

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management 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



The BCWS, BCWP, and ACWP are all instrumental in calculating the cost variance (CV) and the schedule
Title
variance (SV), which in turn are used to assess individual and project performance. Here are the calculations
for both:
CV = BCWP - ACWP
-----------
SV = BCWP - BCWS
For the Smythe Project example (using $ in thousands):
CV = 200 (or BCWP) - 300 (or ACWP) = - 100, indicating a cost overrun
SV = 200 (or BCWP) - 220 (or BCWS) = - 20, indicating behind schedule
For ease of calculation, the best approach is to convert the cost variance and schedule variance to percentages:
CV % = (BCWP - ACWP) / BCWP
SV % = (BCWP - BCWS) / BCWS
For the Smythe Project example (using $ in thousands):
CV % = (BCWP - ACWP) / BCWP
= (200 - 300) / 200
= -50%, indicating a cost overrun
SV % = (BCWP - BCWS) / BCWS
= (200 - 220) / 220
= -9%, indicating the task is behind
schedule

The values are then plotted cumulatively over time for all three variables as shown in Exhibit 15-3. Again,
this can be performed for one task or the entire project.
After calculating the BCWS, BCWP, and the ACWP, Perry can determine in what combination of the
following circumstances he might find the project:
BCWP = BCWS On Schedule
BCWP < BCWS Behind Schedule
BCWP > BCWS Ahead of Schedule
BCWP = ACWP Meeting Cost Target
BCWP < ACWP Cost Overrun
BCWP > ACWP Cost Underrun




Exhibit 15-3 Earned value.
The BCWS, BCWP, and ACWP also are useful for determining overall project performance. The measures
for doing so are the cost performance index (CPI) and the schedule performance index (SPI), which are
calculated as:
CPI = BCWP / ACWP or planned costs / actual costs
SPI = BCWP / BCWS or planned costs scheduled costs
Smythe Project example ($ in thousands):
CPI = BCWP / ACWP
= 200 / 300 = .66, indicating cost
performance is not very
efficient since the result is less than
1.00
SPI = BCWP / BCWS
= 200 / 220 = .91, indicating
schedule performance is not
very efficient since the result is
less than 1.00

The measure of performance is determined by how close the calculated value approximates 1.00. If the CPI
and SPI are less than 1.00, then performance needs improvement. If greater than 1.00, then performance
exceeds expectations. This can be performed for one, a group, or all tasks on the project.

Making Performance Assessment Count
A project plan serves no purpose if no one knows or cares if it is being followed. Perry, therefore, regularly
keeps a “pulse” on the schedule and cost performance of the project. He collects and analyzes data to ensure
that plan and reality match as closely as possible. If a variance exists, he determines whether to take corrective
action. Of course, a variance can exist for quality as much as it does for cost and schedule. Perry knows that
and ensures that metrics also exist to measure quality.

Questions for Getting Started

1. When collecting data for determining cost and schedule status, did you determine:
• Expertise needed?
• Mode of collection (e.g., formal versus informal)?
• Obstacles you will face?
• Tools to do the job?
• Type of information infrastructure you want in place?
• Ways to communicate the value of collecting status?
2. In regard to status reviews, did you determine whether to collect data prior to or during the
meetings?
3. When collecting data, did you identify the threats to reliability? To validity? How will you deal with
those threats?
4. When assessing status, what variables will you look at? Variances? Cost variance? Schedule
variance? Earned value? How will you go about calculating them and how often? Will the calculations
be for selected tasks or the entire project?


Previous Table of Contents Next




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

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights
reserved. Reproduction whole or in part in any form or medium without express written permission of
EarthWeb is prohibited. Read EarthWeb's privacy statement.
Project Management 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 16
Quality Assessment: Metrics
In Chapter 15, Perry developed ways to assess performance with regard to cost and schedule variances.
-----------
Quality assessment is the other element in monitoring performance.
Establishing measurements for quality is a way to identify opportunities to reduce waste, determine how the
project is achieving its goals, ascertain trends, and establish baselines for future projects.
Quality can have several meanings, so Perry defines the word in terms of his project. After consulting the
customer and reviewing project documentation (the statement of work), he defines quality as service that
satisfies a defined degree of excellence. In terms of the Smythe Project, quality is satisfying the requirements
set by the Smythe family. Focusing on his customer™s requirements, Perry can determine the measurements to
use. Metrics are the tools and techniques he will use to track and assess quality.

Introduction to Metrics
There are two basic categories of metrics, qualitative and quantitative. Qualitative metrics are intangible,
noncalibrated measures. Examples include degree of customer satisfaction and degree of importance. These
metrics are subjective. Quantitative metrics are tangible, calibrated measures. Examples include financial
analysis and parametrics. These metrics are objective.
Qualitative and quantitative metrics can be used to measure the satisfaction of the customer™s requirements, as
well as the efficiency and effectiveness of processes for building a product or delivering a service. In their
simplest form, quality metrics measure the relationship between the number of errors and a unit of measure.
An error is the difference between what is expected and what has occurred”in other words, a variance.
Of course, Perry knows that metrics do not happen spontaneously. He must set up a process for collecting
data, then analyzing the results. So Perry takes the following actions.
1. He determines what to measure. The statement of work provides much information; however, he
also interviews the customer and examines the metrics used for earlier projects of a similar nature.
2. He seeks agreement on what metrics to use. There are quantitative and qualitative metrics, simple
and complex. People must see the value of a metric; otherwise, they will not support the collection
efforts or respect the results.
3. He obtains the software to perform the metrics. These include project management software,
database applications, and modeling packages.

The Collection and Analysis of Data
Perry must build a good database. Without data he cannot do much. If the data lack reliability and validity,
they produce useless results. But having good project management disciplines in place will help in collecting
reliable, valid data. Perry has the expertise to collect good data, including statistical knowledge, analytical
prowess, and communications skills. Without these skills, establishing the metrics would be extremely
difficult. Also, Perry must exercise discipline when implementing the metrics. This means collecting data
regularly and using comparable methods over time.
Perry follows five steps to measure quality: (1) identifying what needs to be measured, (2) collecting the data,
(3) compiling the data, (4) analyzing the data, and (5) communicating the results.

Identify the Measures
As noted earlier, there are multiple ways to identify what needs to be measured. Perry reviews project and
technical documentation. He meets with people directly as well as remotely connected to the project. He
reviews the history of similar projects. He selects benchmarks, or examples from other companies against
which to compare his results. In any event, he must have buy-in for whatever methods he chooses. Without
buy-in, support may decline.
Of course, the audience will largely dictate what metrics to use. The project team may want to measure
technical aspects. Senior management and the customer may want measurements of customer satisfaction.
Perry is interested in measuring his project management. In any question of determinants, business
considerations should be first. Ultimately, customer satisfaction is the quality metric.
A way to determine business metrics is to identify key project indicators, or KPI. These are elements of a
project that contribute to successful completion of a project. On the Smythe Project, a KPI is the number of
complaints about the bridal shower. To identify KFIs, determine all the processes involved in project
management, process management, and technical performance. Then, with selected representatives, rank
those processes and select the most important top ten.
PDCA
A useful concept for performing metrics is the Plan, Do, Check, Act cycle, also known as the PDCA Wheel
or the Deming Wheel.
The Plan is developing an approach for improving a process or implementing a metric or both. The Do is
turning the plan into reality by executing it. The Check is determining if the improvement or metric is
working. The Act is making any changes to improve the process or metric. The cycle is shown below.




This cycle repeats throughout the process or measurement; it ensures stepwise refinement of the plan.
In reality, the PDCA cycle can be applied to any decision-making endeavor. Managing a project lends itself
to application of the PDCA cycle; project plans are continually revised to reflect reality.

Whatever the metrics chosen, Perry answers the following questions for each measurement tool:
• Who is the metric for?
• What purpose will it serve?
• How often will the measurement be taken?
• What is the formula?
• What is the data source?
Collect the Data
Perry uses data from the project data repository created by his project management software. He ensures the
data are current, thanks to input from status review.
In addition to the data repository, he searches the project history files and project library for relevant data. He
can access completed forms, past reports, and memos. He also uses alternative sources like the Internet for
data in the public domain and available through think tanks.

Compile the Data
Perry must put the data into a usable format. One of his first actions is to cleanse the data, identifying bad
(irrelevant) data and standardizing it (putting it into the same format). Perry sorts the data, reviews it to
determine any anomalies (e.g., alphabetic characters in a numeric field) and ensures that it has all the decimal
points in the right place. While doing this, he avoids introducing bias, which would influence the results. For
example, he removes data to which he might respond subjectively, such as data originating from a person or
system that he dislikes.
Data are raw, while information is data in a meaningful form. Perry has several tools to convert data into
information, including Pareto charts, checksheets, scattergrams, histograms, control charts, and trend charts.


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



Pareto charts display information to determine the potential causes of a problem. A bar chart (not a Gantt
Title
chart) shows the major categories or elements on the x-axis and the prioritized numbers of a result (e.g.,
number of complaints) on the y-axis, as shown in Exhibit 16-1. The highest bar has the greatest likelihood of
being the cause of the problem.
Checksheets are documents that record the frequency of distribution of incidents. Each occurrence is recorded
-----------
in an interval identified, as shown in Exhibit 16-2. The information identifies what intervals have the greatest
and least number of occurrences. The checksheet also graphically displays information in the form of a
histogram, as shown in Exhibit 16-3.
Scattergrams, sometimes called scatter or correlation charts, show the relationship between two variables, as
shown in Exhibit 16-4. Normal relationships are “bunched together”; the abnormal relationships are “outside
the bunch,” thereby indicating an anomalous situation.
Control charts, like the scattergrams, identify normal and anomalous situations, specifically variance from the
average. Upper permissible and lower levels of variation are identified. As with the scattergram, the focus in
on variation, with emphasis on reducing erratic behavior. To better understand control charts, here™s an
example for building one.




Exhibit 16-1. Pareto chart example.




Exhibit 16-2. Checksheet example.
Six hotels are interested in knowing the average number of complaints during the summer season. The analyst
collects data from these six hotels and compiles them in the table on pages 157 and 158.
Exhibit 16-3. Histogram example.




Exhibit 16-4. Scattergram example.

Hotel Average Number of Complaints

A 30

B 40

C 60

D 80

E 35

F 25

270

Before drawing the control chart, the analyst determines the “average average,” and the upper and lower
limits of the control chart. The “average average” is the sum of the averages divided by the sample size, or N
(the number of hotels participating); thus, 270 divided by 6 equals 45. See the control chart in Exhibit 16-5 for
a plotted graph. The equation for the upper control limit is
The equation for the upper control limit is




For the lower control limit, the equation is:




Thus, the average number of complaints for Hotel D is out of control because it falls outside these boundaries.




Exhibit 16-5. Control chart example.

Trend charts track past performance and forecast results based on history. As shown in Exhibit 16-6, the chart
shows the relationship between two variables. On the x-axis is a time span and on the y-axis is the value of a
variable.
Using trend charts can be dangerous as well as useful. On the one hand, they require assuming that the future
environment will be as in the past, thereby permitting forecasting. On the other hand, they enable long-range
planning and playing “what-if” scenarios.

Analyze the Data
After compiling the data, Perry analyzes it. He reviews diagrams and looks at statistical compilations. Below
is a table showing the compilation techniques employed and flags for assessing issues dealing with quality.
Compilation Technique Flag
Pareto chart Tallest bar indicates the largest “driver” for the cause
of the problem.
Checksheets Longest frequency of occurrences for a variable;
thereby reflecting the focus of attention.
Scattergram The most frequent occurrences and anomalies; the
latter indicating a problem vis-à-vis normal behavior.
Control chart Exceeding the upper control limit or going below the
lower control limit, thereby indicating possible erratic,
uncontrollable behavior of a process.
Trend chart Upward or downward slope of the line, indicating a
potential problem if the trend continues.

When analyzing the data, Perry will use several standard statistical calculations”specifically, mean, median,
mode, and standard deviation. The mean is the average of the values for items in a group of data. The mean is
best used when the original data are large enough not to be skewed by extreme values. The median is a
position average at the midpoint for a frequency distribution. The median is best used when extreme values in
the frequency distribution could distort the data. The mode is the value that appears most frequently in a series
of numbers. The mode is used to avoid distortion by extreme values.
Standard deviation is another useful calculation. It determines the degree that each occurrence in a frequency
distribution is located from the mean. In other words, it measures dispersion.




Exhibit 16-6. Trend chart example.
Exhibits 16-7 and 16-8 are examples of how to calculate the mean, median, mode, and standard deviation,
respectively. In our example, the limousine service providing transportation for the Smythe wedding from the
church to the reception wants to know the travel time between the two locations. The data they collected for
five transportation times in minutes are shown below:




Another quick, easy way to analyze data is to divide the data into quartiles, or four equal parts, after forming
an array. The analyst counts down the array until he identifies the final item in the first 25 percent and then
calculates up the array. Then he selects the midpoint between the end of the first and the top of the fourth
quartile.
For example, on page 161 is a table of customer responses to a hotel survey of customer satisfaction. The
hotel wants to know the results of their questionnaire, by quartiles. The calculation is shown in Exhibit 16-9.
Fishbone Chart
Not all quality measurement tools are quantitative. The fishbone chart, also known as the Cause and Effect
Diagram, is a diagramming method that identifies the cause of a problem by connecting four M™s: machines,
manpower, materials, and methods. At the end of the fishbone is a description of the effect of the problem.
An example fishbone diagram is shown below:




The fishbone diagram helps you determine if additional research is necessary to verify a cause. In addition,
you can use the diagram to determine another process that will reduce problems associated with machines,
manpower, materials, and methods.



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


Number of
Title
Rating Value Customer Responses Quartile 1 Quartile 2 Quartile 3

Poor 1 5 5 5 5

Fair 2 0 0 0 0
-----------

Good 3 25 20 (of 25) 25 25

Very Good 4 30 20 (of 30) 30

Excellent 5 40 15 (of 40)

25 50 75

Exhibit 16-7. Mean, median, and mode calculations.
Mean
The mean, or average, is calculated by summing the numbers from column A (60) and then dividing by the
number of samples taken (also called N). The formula is:
Average time = sum of column A/N
= 60/5 = 12, which is the average travel time between the two locations.

Median
The median is the middle number in a list of numbers. For our example, Perry arranges the numbers in
column A from low to high: 9, 10, 10, 12, 19. The middle number of these five numbers is the third number,
which is 10. Thus the median, or average, travel time between the two locations is 10.
Mode
The mode is the number occurring most frequently in a list of numbers. Again, Perry arranges the numbers
in column A from low to high: 9, 10, 10, 12, 19. The number occurring most frequently is 10. Thus the
mode, or average, travel time between the two locations is 10.

The Results of Data Analysis
After converting his data into information and analyzing it, Perry win communicate the results. He does that
in several ways, such as in a presentation or by sending e-mail. Whichever method he chooses, he states his
assumptions”he does not hide them. For example, he might state that the information in the trend chart
assumes that the project will proceed at the current pace.
Also, he portrays the data honestly and openly. He does not outlay charts or other information to cover up or
skew the messages. Finally, he is consistent when collecting and reporting the information. Consistency
ensures timely and useful information. Otherwise, he will have a credibility problem with the metrics.

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

<<

. 4
( 6)



>>