Exercise 3 – chapter 2
Review materi dibawah ini, dan buat ringkasan dalam bahasa Indonesia.
http://www.projectconnections.com/knowhow/bq_subject_pages/conflict_issue_mgmt.html
Know-How > Organizational Processes > Conflict and Issue Management
Conflict is inevitable in a project setting, and conflict resolution is part of a project manager's
core responsibilities. But conflict resolution is more than just refereeing disputes. The root
causes of conflict in a project setting are largely due to flaws in the project plan, process, or
organization. These project "issues" need to be recognized, captured, remembered, prioritized, and
resolved in a systematic manner in order to minimize conflict in your project.
1. What is "Conflict and Issue Management"? Why both?
2. How can I prepare for managing conflict?
3. What are some of the root causes of conflict and how do I resolve them?
4. How do I manage project issues and priorities?
5. There's a serious conflict in my project. What should I do right now?
6. My design reviews always get emotional. What can I do?
7. Two team members are fighting, no matter what. Now what do I do?
1. What is "Conflict and Issue Management"? Why both?
Conflict and Issues. Conflict is the result of incompatible or opposing needs, drives, wishes, or
external or internal demands. Conflict is inevitable in a project setting, and conflict resolution is
part of a project manager's core responsibilities. Projects are always a delicate balance among
a myriad of tradeoffs, and cross-functional projects have the addition tension of functional
organizational goals versus project goals. Some types of conflict can even be positive - a
healthy byproduct of innovation, growth, and change that can lead to positive results. But some
conflict can escalate into damaging behavior that can cripple or kill a project.
Since conflict results from the gap between what your work environment is now and what you
want it to be, conflict resolution is therefore a kind of gap analysis: finding root causes that
create these gaps and resolving them. And the root causes of conflict in a project setting are
largely due to flaws in the project plan, process, or organization. Resolving these project
"issues" is a crucial part of conflict resolution. Project "issues" need to be recognized, captured,
remembered, prioritized, and resolved in a systematic manner. We're treating conflict and
project structural problem-solving in the same subject because we believe they are almost
always tied together. It's a mistake to treat conflict and stress as a separate issue from project
planning, execution, and control. You need to do both the immediate "damage control" that may
be necessary to contain a conflict, and also the identification and resolution of the root causes of
the conflict.
Here are some general resources on managing conflict:




Kerzner, Project Management (Sixth Edition), Chapter 7, "Conflicts"; also see Section
6.4 and 6.5 (Sixth Edition) on Stress and Burnout, close cousins to conflict and often
indicators of underlying issue with the project that need fixing.
Jim Murphy, Managing Conflict at Work, a concise, 80-page gem on identifying and
resolving conflicts in the workplace.
William Ury, Getting Past No: Negotiating Your Way from Confrontation to Cooperation
For white papers on change and issue management, one of the principal root causes of
project conflict, see Merant's web site (formerly Intersolv) at www.intersolv.com. Choose
"MERANT PVCS" in Products and Services and follow the "Guidebooks and White
Papers" link.
Return to Top
2. How can I prepare for managing conflict?
Assume responsibility for dealing with conflict. There are several ways to react to a conflict:




Ignore it (and hope it goes away)
Leave the area as soon as possible and avoid further contact
Smooth it over
Step in and take charge of resolving the conflict.
The first step in preparing for managing conflict in your project is to acknowledge that "you're it" when a conflict occurs, it's part of your core responsibility as a project manager to step in, take
charge, and start the resolution process. It's not an easy part of your job, but the other three
alternatives can lead to serious damage to the project. And if you yourself are one of the
combatants, it may be even more difficult to "step out" of the fray and start behaving as a
mediator instead of a combatant. Conflict management is risk-taking, and you may feel
uncomfortable and make mistakes at first. But as you gain some experience and win some
victories, you'll gain confidence.
So read on for some tips and advice on how to prepare for this role, lay some conflict-mitigating
foundation in your project, perform "root-cause analysis" when conflicts occur, and
systematically resolve the issues that are causing the conflict.
Understanding personality types and group dynamics. One way to prepare for conflict is to
understand the personality mix in your project team and try to identify the "hot spots" -- the
places in the relationship matrix where clashes may occur. Even conflicts that have root causes
in project issues may be catalyzed or amplified by personality clashes. There are a number of
personality modeling and typing methods, among them the Enneagram and the Myers-Briggs
Type Indicator®. These methods are controversial (see the counterpoint discussion on MyersBriggs for a healthy dose of skepticism). Nevertheless, some people swear by them as an
important team-building and managing tool, providing both better self-awareness and also the
ability to forge better business and personal relationships. And putting a new team through such
tests does at least have some value in "breaking the ice" and helping team members to get to
know each other. Here are some resources on personality modeling methods:



For a good counterpoint discussion on the Myers-Briggs method, see the Skeptic's
Dictionary's entry on Myers-Briggs at http://skepdic.com/myersb.html.
A thorough FAQ page on the Enneagram and a sampler test by an Enneagram test
vendor (leading to a pitch to buy their self-scoring Riso-Hudson Enneagram Type
Indicator test) is available at the Enneagram Institute's web site at
http://www.enneagraminstitute.com/index.htm.
Another self-administered Enneagram test, the Stanford Enneagram Discovery
Inventory and Guide, is available through Mind Garden, Inc. at
http://www.mindgarden.com/. Follow the Enneagram link under "Types of

Assessments".
Please Understand Me II: Temperament, Character, Intelligence by David Keirsey. As in
the 1984 original book, this recent revision includes the Keirsey Temperament Sorter, a
"personality inventory" which now includes an additional short questionnaire that
identifies and classifies basic temperament types.
Create an open communication plan. Planning project communications is more than just
specifying meetings and reports. It is implementing processes and setting behavioral examples
that encourage an open communicating behavior among team members. As project manager,
you need to exemplify this behavior in your everyday management duties if you want your team
to respond in kind.
Make the following bullets part of the "mission statement" of your communication plan:




Create a climate of openness and trust where people feel free to speak their minds and
contribute their thoughts
Encourage and engage in feedback and exchange of thoughts
NO HIDDEN AGENDAS
Discover and resolve issues before they become serious conflicts
Besides specifying meetings, reviews, and reports (they are important, too), include the
following tasks in your communication plan:






Periodically re-communicate the project goals to the team in an informal, two-way
communication. Constant refreshing of the project goals nips in the bud a major source
of project conflict.
Create a "project memory" of some kind (more on this below) where project issues are
captured and remembered. Make it easy for any team member to submit an issue to the
"project memory". These are (hopefully) very busy people; if submitting an issue is
laborious, it won't happen.
Conduct "spontaneous" one-on-ones with all members of your team. Take a genuine
interest in how they are doing; don't just collect status. Ask them questions about their
work, get them talking, find out how they feel about their work, not just where they are
on a schedule.
Ensure you are covering your entire team. You may need to "schedule your
spontaneity" to be sure you are covering even the introverted team members who may
not easily and readily engage in conversation.
Review performance against goals regularly, but don't always do it formally across a
desk or table.
Give copious credit to your team members for contributing good ideas to the project.
Finally, periodically test how well you are doing with the following self-assessment:




Assess honestly how readily your team members speak their minds and how much
feedback you are getting from them.
Are you receptive to new ideas? Does your team feel that you are?
Do you actively solicit and encourage feedback? When was the last time you did a
round robin with each member of the project team?
Do you give so much credit to your team that your own management occasionally
reminds you to take some credit for yourself?
Note that the first step of conflict resolution is perceiving that a conflict exists. The level and
quality of communication in your project is a vital part of this detection process. Don't assume
you are always going to know when a serious conflict erupts in your project. A conflict may
simmer for days, weeks, or months, doing real damage to the project, until the lid finally blows
off and scalds everyone, including you. Keep your antennae up, and keep lines of
communication open.
There is a discussion on managing conflict through effective communication in Verma,
Managing the Project Team, Chapter 5, "Inspiring High Team Performance."
Prepare for cultural differences. If your project team is geographically spread out, don't
underestimate the effect that cultural differences can have on team cohesiveness. And cultural
differences don't just occur in international projects. Different regions within the U.S. -- the
Midwest, New England, southern California - can have dramatic cultural differences as well. And
there may even be different organizational cultures among sites and departments of the same
company. Styles of work (like work hours, dress code, etc.), communication styles, and
management styles may differ substantially. You may be loosely united under the same parent
organization's mission statement, but different departments and sites may be marching to
notably different drummers. Here are some things you can do to mitigate cultural differences:



The most powerful mitigator of cultural differences is face-to-face social contact. Get
your team members together as often as possible. If they are really spread out, get
them together at least once, preferably at the beginning of the project. Make it part of
the budget of an international project - you'll get a good return on this investment. And
don't just make it a business meeting. Put them in a setting where you can all get to
know each other, attach faces to voices, and explode some cultural myths and
mysteries.
To prepare for significant business cultural differences (Japan, the Middle East, etc.),
put your team through a 2 or 3-day cultural awareness course.
And finally, as part of your leadership training, improve your general cultural literacy with
references such as Hirsch's Cultural Literacy: What Every American Needs to Know and
the Dictionary of Cultural Literacy."
Look-up tables": containment and treating symptoms. There are a number of "table look-up"
and "at-a-glance" resources for handling difficult people. These books list personality and
behavior types and offer advice and strategy on how to deal with them.
While these books may be useful for immediate containment, damage control and "treating the
symptoms" of a conflict, keep in mind that "difficult people" is often a euphemism for reasonable
people caught in difficult circumstances. You should always go after the root causes of a conflict
in a project. Don't just do a table look-up and recite your lines. Here are a few of these
resources:




Muriel Solomon's Working with Difficult People categorizes dozens of difficult
personality types by "your boss", "your colleague", and "your subordinate."
Robert M. Bramson's best-selling Coping with Difficult People offers clear advice - down
to precise quotes - on how to handle a number of difficult personality types.
Getting Past No: Negotiating Your Way from Confrontation to Cooperation, by William
Ury, offers strategies for turning adversaries into negotiating partners.
Dealing With People You Can't Stand: How to Bring Out the Best in People at Their
Worst, by Rick Brinkman and Rick Kirschner; this is the book form of their seminar and
audio tape series on dealing with difficult personality types.
Return to Top
3. What are some of the root causes of conflict and how do I resolve them? How do
I manage priorities?
The principal suspects, and some solutions. Here is a summary of the principal causes of
conflict in projects, taken from a study by Dugan, Thamhain, and Wilemon and summarized in
Kerzner, Project Management, Section 7.3, "Managing Conflict". We list the causes here in
overall order of intensity across the entire project cycle. Note that these causes are often
interrelated - e.g., conflicts over scheduling and cost, for example.
Schedules. Disagreements on estimating task duration and task sequencing is
the number one cause overall. A root cause here is poor planning, notably
incomplete work breakdown structures. See our Scheduling and Estimating and
Tracking and Control subjects for tips, advice, and references on creating and
tracking schedules. Remember that there is a big difference between
"aggressive" scheduling based on solid planning and risk analysis, and
"optimistic scheduling" based on good intensions and wishful thinking. In Rapid
Development, Chapter 9, "Scheduling", Steve McConnell has an excellent
discussion on why optimistic scheduling does not work. The key point is that
"the shortest actual schedule results from the most accurate planned schedule".
Failure to construct an achievable initial schedule will guarantee a project with
plenty of schedule conflict.
Project priorities. Conflict over priorities stems from a project's innate attribute of
having a component of new work never before done in the organization. It
includes both inter-team conflict and conflict between the team and support
groups. A flawed vision is often the root cause, with poor project communication
and unclear expectations often being a contributing cause of conflict over
priorities. Another cause is a mismatch between team goals and individual
performance evaluations in an organization that has strong functional group
management and weak cross-functional team management (which bleeds into
the project administration cause below). Solutions include a communication
plan that emphasizes constant restatement of the project goals, and a
systematic method for capturing and prioritizing project issues that is built into
the project team's behavior. We discuss such a method below in project issues
and issue management.
Manpower. Sources of conflict include "multiplexing" people across several
projects, especially among support groups that provide resources to projects.
Solutions include early team building with well-defined roles and responsibilities
and firm, periodically refreshed commitments from team members and their
management. Download our Project Team Organization and Assignments
checklist to help document the roles and responsibilities of your team.
Technical issues. The point of conflict over technical issues is often between the
project manager's view of budget, cost, and schedule; and the technical design
group's view of functional performance, technical elegance, and quality.
Solutions include doing early architecture and design during the creation of the
project vision, early feasibility testing of proposed solutions, and a well-defined
design review process. See Projects at Warp Speed with QRPD®, Phase II,
"Development", for help in designing a design review process.
Project administration. A root cause of administration conflict is the "temporary"
nature of a project manager's responsibility, authority, and reporting path,
combined with an organization that does not have a strong, cross-functional
project management structure. Solutions include a strong senior management
project sponsor or "champion" who helps clear obstacles and supports the
project manager's authority. Download our Project Sponsor checklist, a list of
characteristics and responsibilities of the Project Sponsor. See our
Implementing Project Management subject for resources on implementing and
strengthening cross-function project organizations.
Personality conflicts. Not a predominate cause, but difficult to deal with.
Solutions include examining team member personality models such as the
Enneagram and the Myers-Briggs Type Indicator®. There are also guidebooks
for "treating the symptoms" of personality conflicts - see the paragraph on "Look
up tables": containment and treating symptoms for some resources.
Cost. Ranked last as a source of conflict. But it may still be tightly coupled with
other conflict sources such as schedule slipping and tight manpower resources.
Besides identifying these causes, the study also showed that the ranking of the predominate
causes varies depending upon the phase of the project lifecycle. For example, project priorities
are the number one cause of conflict during the early stages of the project, while schedule
conflicts predominate during the later stages. This is in line with the emphasis on trade-off
decisions early in the project, and performance to schedule toward the end. And note that
personality problems are ranked relatively low on the overall scale, reinforcing the idea that most
conflict in projects has deeper root causes than just "people problems". Interestingly, personality
does bubble up to second place as a cause of conflict in the delivery and phase-out of a project.
This may point to the strain and stress of project closeout amplified by personality clashes.
Kerzner's presentation of this study in Project Management, Chapter 7, is well worth reading.
See especially Figure 7-2, "Relative intensity of conflict over the life cycle of projects" and Table
7-1, "Major conflict source and recommendations."
Return to Top
4. How do I manage project issues and priorities?
Project issues and issue management. Issues are project anomalies - deviations and conflicts
between project goals and current reality. A well-understood subset of issues includes design
defects or "bugs" - the deltas between desired functionality or requirements and the current
emerging design. Project issues are deltas between the overall desired functioning of the project
and the current reality. Some examples are the following:





Design defects - "bugs", omissions, unexpected behavior.
Requirements problems - are we still solving the customer's problem in light of
environmental change?
Testing problems - is there enough testing? Is it effective? Is defect containment poor?
Communication problems - too many meetings, not enough meetings, meetings run
poorly, no status reports, too many status reports, "I never see the project manager",
"the project manager never leaves me alone to work", etc.
Design reviews - are there enough? Are they efficient in discovering and resolving
defects and design issues? Are they organized shouting matches?
Sometimes a project will do a good job of applying tools and a systematic process for capturing,
remembering, prioritizing, and fixing defects. This same defect-tracking model that is used in the
testing lab or developer's bench also needs to be applied to the wider domain of project issues
and needs to be incorporated into the greater project management process. The reasons for this
include the following:
Change management. Issue management isn't just an important part of change
management - it IS change management. The changing environment is going to
pepper your project with anomalies and you must deal with them systematically
to keep control of your project.
"Issue storms". Issues are going to occur faster than you can resolve them, and
more issues will occur than you can remember. You must have a "project
memory" to hold them and a systematic method of choosing a subset of issues
(prioritization) and driving that subset to completion.
The Lazarus effect. During the lifecycle of a project, it is a certainty that some
long-dead issues will come back to life. A bug that was thought to be fixed will
reappear months later, a request for a feature enhancement identical to a
previous request will resurface, or the need for more environmental testing will
be voiced a second time by QA.
All of us have experienced the sinking feeling that we've seen a bug, problem, or enhancement
request before, that we had valuable knowledge about it at one time that is now lost, and that
there was a previous decision process laying this problem to rest that we can no longer recall
and must now be recreated. The first time that you can save significant work by simply going
back to a closed issue and quickly recovering the needed information, you will be forever sold
on issue management and you will incorporate it into your behavior as a project manager.
In the following Knowledge Nugget paragraphs below, we'll outline the attributes, the process
steps, and the states of the issue management process.
Attributes of project issue management. Issue management is a state machine. This means
that issues are captured into a project "memory" and then moved through various states until
they are closed with some resolution. Here are some attributes of this state machine:
Issue items. An issue is at the minimum a description of the item - a problem,
anomaly, conflict, etc. - with a summary title. An example is Title: Problems in
design reviews; Description: Our design reviews constantly erupt into emotional
battles, whenever we can find enough people to have them at all. We need to
improve our design review process.
"Project Memory". All issues are kept in one place. It must be very easy to add
to this list, but virtually impossible to lose anything. A database is an ideal tool
(most bug tracking software has a database foundation) but a spreadsheet or
word processor file will work, too.
Ownership. Every issue has one and only one owner. The project manager
owns all issues by default unless he/she has explicitly assigned another owner.
State. Every issue has a state. Open and Closed are the minimum. We'll
discuss additional states below to help manage issues.
Description. Contains both the initial description, problem, symptoms, etc.
(which may be vague) and also subsequent entries that are made when
something new is learned or a decision is made. Include date and initials when
adding information and status to the description. Capturing decision processes
is crucial to avoid having to rediscover information and remake decisions.
Priority and Severity. Simple designators for priority like "A, B, C" and "High,
Medium, and Low" for severity. Use more descriptive designators if your quality
system requires it (e.g., if your development is "safety significant", you may
want "Safety" as a top priority).
You may want to include other fields - for example, a flag that distinguishes design defects from
other project issues. This allows you to quickly separate out defects for particular treatment by a
design/test/review development process.
The issue management process. Here are the major steps in the issue management process.
Detection. Sources of issues include root causes of conflicts; results of reviews,
inspections, and testing; results of audits; and just plain good ideas from people
who want to improve the project.
Recording. Submitting issues MUST BE FAST AND EFFORTLESS. Depending
on how wired and computer literate the team is, you may have an in-basket on
a staff person's desk for a brief hard-copy input form, or a staff person
designated to receive e-mail issue forms and enter them into a list or database
tool; or a pop-up or pull-down on everyone's screen that accepts issue input.
But if entry of an issue is laborious, the system won't be used.
Sifting. This is the KEY PROCESS that must be an integral part of your
management routine. You periodically make a pass through all of the open
issues, examine their state and what is known so far, prioritize any new issues,
pick a subset of issues to treat, and take action to move this subset toward the
closed state. The actions include assigning resources to investigate the issue (if
not enough is known), assigning resources to fix or resolve the issue, making a
decision to defer the issue, or making a decision to close the issue either
because it has been resolved or because no resolution is necessary or
possible. As you treat each issue, change its ownership, state, and priority as
necessary. Normally, you do a sifting meeting with appropriate core team
members.
Prioritizing issues is the heart of the sifting process. This is where you and your
consensus group must make the hard decisions on what issues you are going
to solve right now with assigned resources and due dates (the "A" priority
items), what issues are important but you can't do it yet (the "Bs"), and the "blue
sky" issues that you may never get to (the "Cs"). Don't equivocate here. Don't
invent a new "A minus" priority category. And don't make an issue an "A" and
put it in the "Investigate" or "Fix" state until you have a committed owner
working toward a date.
Updating. This is a scaled-down version of sifting. You use a one-on-one
discussion, hallway conversations, a group conversation, or a team status
meeting to update the status and description of a few issues. Individuals who
have been assigned issues can update the description field with new
information or status. You may also allow them to change a state of an issue (or
you may want to keep control of the states yourself), but only the project
manager should close an issue.
Change of ownership. This is part of sifting and updating. It has a special rule:
issues are assigned to owners only in the new owner's presence and with the
new owner's understanding and commitment on what he/she is to do in order to
advance that issue through the states, and by when he/she is going to do it. If
no one else owns an issue at any point in time, then the Project Manager owns
the issue by default.
Incorporate elements of issue management in all of your project planning, tracking and control
activities. Take a few key active issues to status meetings and see if you can record new
information or advance their state. Train your team to "get it into the issue list" when they run
into a problem that cannot be solved immediately, and encourage them to use the "language" of
issue management by discussing issues in terms of "state", "owner", and "priority". And make
periodic sifting part of your management routine.
Issue management states. As we've seen so far, issue management is a state machine, with
recording, sifting, and updating being the main state-change drivers. Here is a suggested set of
states through which to drive issues. You can eliminate some states or add more. But it is best
to keep the states simple and intuitive. You want the entire team to be able to keep this "state
diagram" in their heads and to use a common language when discussing the state of issues.
This team behavior on issue resolution is an important factor for issue management process
success.
OPEN. The issue has been newly submitted, and has not yet been examined
and prioritized.
UNDER INVESTIGATION. The issue has an owner who has committed time to
investigate the issue, find out more, and report back on what has been
discovered by a set date. At that time, the issue's Description will be updated
and further action will be taken.
DEFERRED. The issue is important, but we can't think about it or do anything
about it right now. Deferred issues will be routinely sifted and eventually put into
another state as resources become available or if new information determines
that the issue should be killed.
FIX. An owner has been assigned who has committed time to resolve this issue.
If not already explicit in the Description field, then the tasks necessary to
resolve the issue are added to the Description.
TEST. Some issues may need an independent test to ensure they are fixed.
Issues in this state have an owner that is responsible for testing the issue's
resolution.
CLOSED. The issue has either been resolved or it has been killed without
resolution. In all cases, the Description field should be updated with a summary
of the resolution and the decision process for closing. This is a crucial step to
avoid wasting time relearning lost information and reconstructing the decision
process on a "resurfaced" issue.
Tools for issue management. You can use commercially available defect trackers, a desktop
database, a spreadsheet, or even a word processor document to house issues. If your project
and organization is large, consider investing in an enterprise-strength tool. However, it's not
important to have an elaborate tool. What is important is the ability to create several "custom"
fields (or table columns) for Title, Description, State, Severity, Priority, and Owner; and to be
able to quickly update these fields. Defect tracking software and databases give you the ability
to control these fields and keep them uniform.
Also important is the ability to sort on any field and to create one-page issue reports. Quickly
printing out a handful of active issues to take to a status meeting or a "one-on-one" is a core
functionality of the issue management process. And driving sifting meetings by printing a stack
of current issues in a uniform one-page format and rapidly going through them one by one, redlining any new information and change in status, is a good method for rapid sifting of a large
number of issues in a short period of time.
Here are some vendors of tracking tools that can be used for issue tracking:



Teamshare™ at www.teamshare.com: These are the folks that created the Defect
Control System at Software Edge in the early '90s; their latest offering is TeamTrack
Suite, a state-of-the-art issue tracking system. Can be scaled up from a few seats to a
large organization. They offer a web-based tracking service as well.
Merant (formerly Intersolv) at www.intersolv.com: From the originators of the venerable
PVCS configuration management software comes PVCS Tracker, an issue and change
management tool (they also have a number of white papers and guidebooks on issue
management, change control, document control, etc.).
For an enterprise-strength tool, Remedy Corporation at www.remedy.com offers
Remedy Quality Management, part of their eCustomer Relationship Management
(eCRM) series of large-scale enterprise tools.
Lessons Learned and other augmentations. The set of issues generated during a project will
be a rich source of lessons learned data. Be sure to include a review and the "mining" of the
issue database as part of the project close-out process. Some quality-conscious organizations
mandate that at the end of a project all issues must either be resolved or have a written rationale
for deferring them further.
It will be tempting to augment the issue management process to capture additional information
for metrics. For example, an "area" field could capture in what process, product, or design area
the issue occurred. Issues relating to defects could capture defect containment data such as
development phase where issue was detected and the phase where the root cause was created
(in order to see how far through the development process the defect got before it was detected).
But, be careful here not to burden the process with too much overhead. Keeping the issue
management system lean, fast, and easy to understand and use is the key to successfully
incorporating it into your project team's behavior (and your own).
The "ABC" List as a stand-alone tool. You can use the "ABC" prioritizing process as a standalone tool in meetings where you are faced with difficult choices among a number of alternatives
and you must limit near-term goals to the resources at hand. Create an ordered list of the
alternatives in rough priority order, then start at the top and assign named individuals to own the
item and a date by which the item will be worked on. The individuals assigned must be in the
room or must otherwise be polled for their commitment to the task and date before this process
is completed. As you work down the list, don't skip any items; move them lower on the list if you
can't assign an owner. When you run out of owners who can immediately commit to doing active
work in the near term on these items, draw a line under the last item with an owner assigned.
The items above the line are the "A" priority items. Now take a hard look at the rest of the list
and estimate which items can be done at all within the overall timeframe and resources
remaining. Order the list so that these items come next, and then draw another line below the
last one. These are the "B" items that MAY get done if time and resources allow. And the items
below this line are the "C" items that probably will not get done on this round but they may be
done in the future and you don't want to forget them.
You can use this prioritizing tool during a vision brainstorming, where lots of good ideas have to
be culled down to the few that you're going to actively work on. Another example is a release
content planning meeting, where you are selecting from a large number of alternatives what
handful of features, attributes, and bug fixes are going into the next release. In short, this
prioritization tool and discipline can be used in any meeting where tough priority decision must
be pragmatically and dispassionately made.
And don't bend the rules. Don't flood the "A" level with tasks that don't have committed
resources. Don't invent new priority categories that have a vague ownership or date
requirement. Make the hard choices and move forward.
Return to Top
5. There's a serious conflict in my project. What should I do right now?
Conflict resolution steps. For completeness, we'll point out that when you know you have a
conflict in your project, you've already accomplished the first step of conflict resolution:
detection. The symptom may be a chronic impasse that normal project process is not able to
break, or a simmering feud between two people or groups, or a serious vocal (or even physical)
battle. There's no time to take a course or read a book on conflict resolution. You need to start
immediately with step two: take the initiative. We'll use the example of a conflict between two
people, but you can map this discussion to multiple people, groups, etc. If you are one of the
"combatants", then you must either make a substantial behavior adjustment or get outside
mediator help.
Take the initiative. Assume responsibility for resolving the conflict. Resist the temptation to
ignore, gloss over, or escape from the conflict. Be assertive (not aggressive), take charge, and
start the process.
Control, contain, and defuse. Get the combatants together. Resist the temptation to do one-onones (unless legal employee relations considerations mandate this). One-on-one meetings are a
form of avoidance. Establish some ground rules for the discussion, such as everyone is honest,
everyone gets a say, one person speaks at a time (use the "speaker's baton" if necessary), lots
of listening, no personal attacks, support allegations with facts, and no hidden agendas. The
latter includes you as well; for example, if you're mediating a long-running, exasperating,
destructive battle and you're getting near the end of your rope, then say so. Using these rules,
allow people to vent if they need to; getting emotions out on the table and out of the way now
will keep them from complicating the real work in determining causes and resolving the conflict.
Determine the root causes. The only thing worse than avoiding conflict resolution is to wade into
it and assertively solve the wrong problem. Ask some initial questions, using a journalistic
"who/what/when/where/why". After these initial questions, much of the discussion will be eventdriven by responses. Ask lots of open-ended questions that cannot be answered by "yes" or
"no". Ask for clarifications and examples. Ask people for their advice on solutions. Be an active
listener and encourage their responses; don't cut them off, get noticeably impatient, or dictate
results.
Keep in mind the model of "gap analysis". You are looking for deltas between the actual and the
desired state of project goals, environment, and process. Keep drilling down until you find a
solvable, actionable root cause; it will be rare that you don't find one. If possible, lead the
combatants toward suggesting the root cause and possible solutions themselves.
Specify solutions. When you've identified root causes, create an action plan - a set of tasks that
resolve the issues causing the conflict. These tasks should have the following characteristics (if
you have an issue management system, use it to track these solutions):




The tasks are documented in writing, either in the meeting minutes or in an issue
management system.
The tasks have clear and measurable "done" criteria.
They have a date by which time the tasks should be completed or reported on.
They have an owner who has signed up to do the work by the specified time.
Not all conflicts are going to be tied up into a nice solution package like this. But many conflicts
will point to problems that can be solved. Get past the personalities (which you can't change)
and look for things you can change.
Follow up. Schedule a follow-up meeting for a time when some or all of the solutions should
have kicked in. Use the same meeting rules and honestly assess if solutions are working and
conflict is diminishing. If not, reapply the process and look for better solutions.
Additional resources on conflict resolution steps:


Murphy, Managing Conflict at Work, Chapter Four, "Resolving Conflict."
Kerzner, Project Management, Chapter 7, especially Section 7.6, "The Management of
Conflicts."
Controlling a hot discussion: the "speaker's baton". If a conflict resolution discussion (or
any discussion, for that matter) has strong personalities or if emotions are running high, even
reasonable people may find it hard to stick to the rules of polite discussion. If a discussion
deteriorates toward a shouting match, then try formatting their behavior with a "speaker's baton".
This is any physical object that can be handed easily from one person to another. Only the
person that holds the baton can speak, and the baton must be physically passed before the next
person can speak. After a little conditioning, you may only need to actually use the baton for a
few minutes (or just pull it out and show it) before people calm down and recover their
discussion etiquette.
Return to Top
6. My design reviews always get emotional. What can I do?
Define a Design Review Process and stick with it. A major source of conflict in development
projects is a poorly run design review. Treat design reviews as a process, not a meeting. Here is
an outline of the design review process.








Plan the reviews in advance, during initial project planning.
For each design review, specify what materials are to be input, who is to attend, what is
to be accomplished, and what is the output.
Distribute materials and agenda far enough in advance before the meeting to allow busy
people adequate time to study the materials.
Run the meetings with good meeting discipline and plenty of breaks.
Record action items with owners, estimated dates, and completion criteria.
Allow development time in the schedule to execute these action items.
Close out the review minutes only after action items are complete.
Don't advance the development into the next phase until either all action items of design
reviews are complete or there is a consensus agreement that the project can continue
without undue risk.
Here are more resources on design reviews:



Projects at Warp Speed with QRPD®, "Phase II", discusses design review in detail,
including checklists.
Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs,
Projects, and Products, by Daniel P. Freedman and Gerald M. Weinberg, though
somewhat dated, is still a valuable guide for implementing and managing a review
process for product and software development.
Download our Preliminary Design Review Checklist. These are the first design reviews
that commence when enough high-level design work and investigations have been done
to allow the Project Leader and team to suggest alternatives in product performance,
time-to-market, product cost, and project cost.
Code inspections. Software design reviews seem to be particularly prone to emotional
interference. Software inspections are a very effective tool for identifying software defects while
removing the emotional discussion component of less-formal review formats like peer reviews
and walkthroughs. Based on the original work by Michael E. Fagan at IBM, inspections follow a
detailed and disciplined process, with strict rules and steps designed to maximize defect
detection per unit time spent. Studies have shown inspections to be roughly equivalent to unit
testing in number of defects detected. They are also the most resource-intensive of the various
review formats. Here are some resources for how to conduct software inspections:




Principles of Software Engineering Management by Tom Gilb has a chapter with a
thorough treatment of Fagan inspections.
Managing the Software Process by Watts Humphrey has a chapter on how to perform
software inspections. Written by a leading scholar in software development process, this
book lays the foundation for software process· Robert Ebenau and Susan Strauss,
Software Inspection Process, is a good reference work but sometimes out of print.
Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs,
Projects, and Products, by Daniel P. Freedman and Gerald M. Weinberg, discusses
code inspections along with other review formats.
A technology description (but not "how to" details) is available on the Software
Engineering Institute's web site at
http://www.sei.cmu.edu/str/descriptions/inspections_body.html.

The original papers by Fagan (not on-line as far as we know) are "Design and code
inspections to reduce errors in program development", Michael E. Fagan, IBM Systems
Journal, Volume 15, Number 3, pages 182-211, 1976; and "Advances in Software
Inspections", Michael E. Fagan, IEEE Transactions on Software Engineering, Volume
SE-12, Number 7, pages 744-751, July, 1986.
Return to Top
7. Two team members are fighting, no matter what. Now what do I do?
Radical surgery. Try everything first: sit with the two, bring in HR help, talk it out, and listen for
issues and root causes. Make it clear to the combatants that regardless of the cause, this
chronic conflict is an unstable, disruptive state that can't continue. Keep records of these
meetings with descriptions of what was discussed and action items.
There are some battles you cannot win, and hanging on too long to a serious chronic conflict
situation can cause project damage or even failure. If no resolution is possible, then make a
dispassionate judgment on the damage being done to the project and the alternatives if one or
both combatants were removed from the project. What would be the size of the hit, the recovery
strategy, the cross-over point where recovery gets you to the same or better place, etc. At this
point, you must involve a source of legal advice on employee relations: whether from your own
Human Resources organization or, if you are a small group, outside legal help. Don't take any
unilateral steps to remove a person from your project without expert legal advice. With this legal
oversight in place and helping, present your findings. Sometimes the shock of discovering that
he or she is not indispensable to the project's success may change behavior of one or both
combatants. If not, proceed with the radical surgery and get the project into recovery mode as
quickly as possible.
While this is one of the most disagreeable tasks in management, it is still not as bad as
presiding over a project that failed, especially one that failed because of people problems that
could have been resolved with radical surgery. So don't put it off or apply ineffective treatments
that just prolong the agony.