Skip to main content

Tag: Facilitation

Managing Conflict and Managing Emotions

A recent incident reminded me of how important it is to stick to the content of conflicts and how difficult it is to deal with emotions disruptive behavior.

As I point out in my recent book, Managing Conflict in Projects, there are two major categories of conflict – content based and emotionally based conflict.  It is best to avoid emotionally based conflict and focus on the content.  This is easier said than done for a number of reasons.  For one, emotionally based conflict is often disguised as content based conflict.  For another, emotions are extremely powerful and often hidden behind a wall of rationality, particularly in organizations.  

Many people are so identified with their positions and with the need to win that anger comes up whenever anyone confronts them with opposition. Others are frightened into submission or lack the self confidence to engage in a content centered conflict.  Often the individual is so habituated to emotional reactivity that they do not consciously recognize what is driving their behavior.  They just act without reflecting on the impact of their actions.

To effectively manage conflict one must address the content through a communication and decision making process.  The process is affected by emotionality and, often unconscious, conflict styles.

The content can be anything from decisions about vendor selection to estimates, to the cause and cost of a change in requirements.  Content centered conflict is a good thing. It is an opportunity to find optimum resolutions that improve project results.   For example conflict over a design or over a tactic in selecting a vendor can lead to an optimal resolution that would not have been found had one party’s position prevailed without opposition.

But, when the communication process is disrupted the ability to come to an effective resolution that is in the best interest of a project and organization is diminished.  Anger leads people to turn to rhetoric, personal attack, even violence and lose track of the content and the mutual desire for a win-win resolution.  Fear leads to people withholding their information and avoiding a healthy exchange of ideas and facts.  People get lost in their emotional reactions.  Satisfying personal agendas becomes the focus.

When faced with a conflict that moves into the realm of emotionality and disruptive behavior the healthy flow of dialogue, debate and decision making is disrupted.  It is necessary to take action to avoid this and if it is occurring to address it and return to a healthy process.  

Most organizations and many individuals do not do well in addressing their communication process, particularly when it comes to interpersonal exchanges and emotions.  It is necessary to reflect on the cost of allowing emotionality to impact effective conflict management and to address the issue on a personal and organizational level.

On a personal level an individual can make it his or her responsibility to monitor emotions and mange them so as not to disrupt the communications process and distort the decision making.  This means stepping back and being self reflective and disciplined enough to recognize the rising of emotional charge and taking control of one’s words and behavior to avoid displaying emotions in a way that would change the focus of the conflict from the content and work against the goals of a win-win resolution and healthy relationships.  This is hard work that requires the cultivation of sufficient mindfulness and concentration to manage oneself and one’s situation.  The individual must increase his or her level of emotional intelligence.

On a team or organizational level, the group must be made aware of the nature of dysfunctional conflict management and its cost.  The organization that ignores this dysfunction is bound to perform less effectively than one that sets as a value for rational and effective decision making and then supports that value by teaching it’s members how to manage conflict so as to obtain optimal resolutions for individual conflicts or disputes while building and maintaining healthy relationships.

Emotions are a fact of life.  They are to be acknowledged and not suppressed.  At the same time reactive, emotionally driven behavior is to be avoided to achieve personal health and optimal performance.

Don’t forget to leave your comments below.

The Problem with Red, Yellow, Green Project Status

Many years ago I worked in a Project Management Office at a large financial institution. Once a week I prepared a project status report for executive management and the PMO director. I would calculate how we were tracking to budget, list any major issues or risks, and summarize overall status.

GregAug291

I was also told to mark the project as red, yellow, or green – using the following definitions:

Red: Serious issues and the project will probably be delayed or have significant budget overrun.
Yellow: Potential issues with schedule or budget, but both can probably be saved with corrective actions.
Green: On schedule, on budget, all good.

 

The red/yellow/green approach seems simple and logical. You only worry stakeholders if something goes wrong, so green projects do not need much review or attention.

Related Article: Starting at Red

However, in my experience the color approach has many shortcomings and potential repercussions. Let’s look at few.

Expectations

What happens when a green project turns yellow or red? In my experience there is an emotional conversation with stakeholders. Here are some of comments I frequently hear when a project goes from green to yellow:

“What went wrong?”, “Why didn’t you manage this project better?, “How can we avoid this happening again?”, “Why didn’t you see this coming?”.

As a project manager I often feel great guilt with these conversations and I too question my competency. But if we spend a moment and work our way through the guilt and emotion, we can see this issue from a more analytical perspective.

Not in line with normal project uncertainty

You may be familiar with the cone of uncertainty. The cone of uncertainty tells us that you cannot completely understand all of the tasks and potential issues within a project, at the beginning of a project.

GregAug292

As the project progresses we learn more and there are less risks,  but we can never anticipate everything that could go wrong until the project is 100% complete.
When we label a project as green we are telling the sponsor everything is OK, today.

Sponsors interpret green as everything is OK today and it should be for the entire project. It is human nature to assume the project is under control and should stay under control.

A Different Approach

But since any experienced project manager knows that green does not necessarily mean green forever, we need to speak in verbiage that stakeholders can relate to. To address this issue I have changed my color scheme when working with sponsors and removed green from my status options.

My options are now:

Yellow: The project does not have any known issues but there is still high risk that something could go wrong (as demonstrated by the cone of uncertainty). As with any project in flight, we are managing it cautiously and we are doing our best to deliver successfully.

Orange: An issue has surfaced and the project goals are in jeopardy. We are triaging the issue(s) and at this time we believe we can still be successful
Red: An issue has surfaced and we do not believe 100% project success can be obtained due to the discovery. More than likely we will either miss the desired date, or exceed budget, or not be able to deliver the desired scope by the target date.

Conclusion

What do you think of my approach? I welcome your thoughts. I know many stakeholders will “freak-out” at seeing no greens, but I believe all projects are yellow until they are delivered.  We need to teach stakeholders that this a reality of doing business.  

Don’t forget to leave your comments below.

As a Project Sponsor, What is Your Documentation Risk Tolerance?

To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question.  This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.”  As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD).  The comment was:

“… I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic – the environment for BRD seems to be getting squeezed by those who find the whole process “too cumbersome” and not (lowercase) “agile enough”. I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don’t meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that’s more relevant to the customer….”  #Tony 2012-01-25 22:20
This comment caused me to pause and wonder if one could construct a BRD risk tolerance model based on the contents of the BRD.  In other words, what is the risk tolerance if only certain best practice components are included in the BRD?  And can the BRD risk tolerance be represented as a sliding scale.  The purpose of this article is to propose a risk tolerance model as a sliding scale based on what is included in the contents of the BRD.

What Makes a Project Sponsor Approve the Business Requirement Document?

Risk tolerance.   The project sponsor signs-off the business requirement document when the document matches or surpasses the risk tolerance of the sponsor.  Note risk tolerance is relative to the sponsor and changes depending on the risk of the project.  For example depending on the size of the company, a $10M project motivates the sponsor to have a much lower risk tolerance than a $10K project.  Project sponsors could cite several other reasons for variable risk tolerance such as project complexity, resources, etc.  The follow-up question and point of this article is:  Can portions of the BRD be equated to various levels of risk tolerance?

A Proposed Business Requirement Document Risk Tolerance Model

Below is a BRD Risk Tolerance model (Figure 1).  It depicts a cumulative risk tolerance incline starting from a high-risk tolerance (lower left corner) to a low-risk tolerance (upper right corner).  Supporting the risk incline are seven best practices for writing a BRD.  Under each best practice are key words describing the practice; for details see “Verifying Requirements Documentation” (1).  On top of each best practice is a cumulative risk tolerance percentage.  This percentage represents the cumulative risk the project sponsor assumes when BRD components are missing.  For example, a risk tolerance of 50% equates to signing-off a BRD with all the best practices above the percentage (data requirements, transitional requirements, and traceability) missing from the BRD.  Note that for every missing BRD component the probability of defects increases in the deliverable.

MarkAug22nd

Figure 1. Business Requirements Document Tolerance Risk Model

First a Note on Project Risk

Before reading the below examples, note the percentages on the model are the sponsor risk tolerance for a project equated to “allowed” missing BRD components.  As stated before, project risk depends on the characteristics of the project (i.e., size, complexity, cost/benefits, technology, resources, duration, etc.).  The point here is that the project risk may well influence the project sponsor on what is an acceptable BRD.   

BRD Risk Tolerance Model Examples

Below are examples of BRD risk tolerance using the model in Figure 1.      

  • A project sponsor may well be justified assuming a high-risk tolerance with the BRD missing various components for a project entailing a small modification to an existing system (i.e., the cost of the BRD should not exceed the benefit of the modification).  
  • A project sponsor could assume a low-risk tolerance missing any components in the BRD for a project providing a strategic new service for the business (i.e., product defects will have a major impact to the business).  
  • If a project sponsor decides to accept a BRD with only process improvement targets and functional requirements documented, the sponsor assumes a risk tolerance of 70% (i.e., still assuming considerable risk of defects in the product or service).
  • And so on up and down the risk tolerance incline.    

BRD Risk Tolerance Model Use

The business analyst can possibly use this model as a guide for management on the level of risk assumed when approving a BRD.  On almost every project, there is a question on how much to document in the BRD.  The answer lies within the range of the project sponsor’s BRD risk tolerance.  Using this model, the business analyst can associate the BRD components with levels of risk tolerance.  With this model plus the characteristics of the project, the project sponsor has enough information on the appropriate risk to assume. 

MarkAug22nd2

Can This Model Be Used on an Agile Project?

Agile projects do not generate a formal BRD.  User stories are the basis for iterative development.  However, the product owner (sponsor) needs to consider risk tolerance when reviewing the product backlog and during the retrospective prior to approving the product release.  Questions to consider:

  • Are process improvements targets addressed?
  • Are specific functional requirements present?  Are they being addressed in business value order?  Are dependencies considered?
  • Are nonfunctional requirements measured?
  • Are the business rules incorporated within the software decisions, access authorizations, and conditions?
  • Are data relationships and cardinalities present in the files?
  • If replacing a legacy system, are transitions planned?
  • Are the original scope features reflected in the user stories?  Can cost/benefits be linked to the deliverables? 

Summary

What is your opinion of the BRD Risk Tolerance model?  I invite your comments.  Perhaps you prefer a different component order or a different level of percentages on the Cumulative Risk Tolerance line.  If you are a project sponsor needing to know what best practices should be used in a BRD, see the article cited in the reference.   

References

  1. Monteleone, Mark (2012), “Verifying Requirement Documentation,”      

Don’t forget to leave your comments below.

Conflict Management

Many of the questions on the PMI Professional Project Management (PMP) exam will be situational and will deal with handling conflict because this is such an important and challenging topic.

Most of the time, conflicts on projects occur over the following issues:        

  • Schedules
  • Priorities
  • Manpower
  • Technical issues
  • Administration
  • Personality conflict
  • Cost

Many perceive conflict as negative and believe that it should be avoided or eliminated whenever possible. While conflict may be unpleasant, it is inevitable. And not all conflict is bad.

Conflict presents opportunities for improvement and as such must be dealt with. According to Amy Ohlendorf in her article entitled Conflict Resolution in Project Management (2001), “Conflict can be constructive and healthy for an organization. It can aid in developing individuals and improving the organization by building on the individual assets of its members. Conflict can bring about underlying issues. It can force people to confront possible defects in a solution and choose a better one.”

Conflict is best resolved by those involved in the conflict as illustrated by Theodore “Beaver” Cleaver and Violet Rutherford in the Black Eye episode of “Leave It to Beaver” which aired in 1957.
       

June27thPatti1 You wanna be ‘gressive?”   “‘Gressive?”

” ‘Cause if you wanna be ‘gressive, I can be just as ‘gressive as you can.  “I don’t know how to play. What’s ‘gressive?”

“That means do you wanna fight?” “No. I don’t wanna fight.”

“Okay. what else do you wanna do?” “I don’t know. Let’s go spit off the bridge.”

“Uh-uh. I did that on the way over here.”  “Let’s go look at the lady in the jiggle belt.” 

However, in real life situations, not all conflict is resolved this easily. And in some cases the project manager may need to get involved and possibly escalate to resolve.

The key is learning how to deal with conflict by using appropriate conflict resolution techniques. 

Amy Ohlendorf  also distinguishes types of conflict. Although some conflict is beneficial, destructive conflict is not. She defines 3 unproductive roles in her article: 

  1. Persecutor refers to a person who uses aggressive behavior against another person, attacking the intended victim. An attack can be direct or indirect and be physical, verbal, or both. The persecutor’s actions deliver a message that “you are not okay” while making the persecutor feel righteous and superior.
  2. Victim refers to a person who uses nonassertive behavior so others view them as “I’m not okay.” This behavior encourages others to either rescue or persecute the victim. Victims will feel helpless, inadequate, sad, scared, or guilty. The victim role is often used because the individual is feeling stressed, has low self-esteem, or is being persecuted by another.
  3. Rescuer refers to a person who uses either nonassertive or aggressive behavior. Individuals become rescuers because they will not say “no” and unwillingly assume the responsibility of solving the victim’s problem. In contrast, others will assume the rescuer role to demonstrate superiority over the victim.

And according to Amy, “learning how to identify these unproductive roles and how to effectively handle each role player, managers can prevent some conflicts from occurring and resolve those that do.”

Below are some conflict resolution techniques that a project manager can also use to handle and resolve potential issues and conflicts as they arise:

  • Withdrawal (Avoidance): retreating from a potential disagreement or postponing a decision on an issue.
  • Smoothing: de-emphasizing or avoiding areas of difference and emphasizing areas of agreement.
  • Compromising: bargaining and searching for solutions that bring some degree of satisfaction to the parties in a dispute. Characterized by a “give and take” attitude.
  • Forcing: exerting one’s viewpoint at the expense of another. Often characterized by competitiveness and a win-lose situation.
  • Confrontation: facing the conflict directly, which involves a problem- solving approach, whereby affected parties work out their disagreements.

Don’t forget to leave your comments below.

Avoiding the What the Customer Wanted Syndrome

Feature Apr18 32807816 XSYou have likely seen some variation on the cartoon that illustrates the differences in interpretation of a customer’s requirements by various participants in a project  (if not, click here) so you’d expect that there is a general understanding of how common this issue is and how to avoid it.

Unfortunately, this is another case of practice not aligning with theory. Most waterfall project methodologies utilize documents to provide the contributors for each phase of the lifecycle with knowledge of what the customer wanted.  While we would normally hope to have a business analyst or similar role to ensure consistency of understanding and communication across all phases, in some cases, there may be no resource continuity and this knowledge is transferred purely in documentation form.

If we assume that each handover results in a certain degradation of the knowledge captured in the previous phase, the effects of this requirements corruption compounds the more steps we add.  It is still common to find projects where there might be four or even more handoffs between the customer and the actual creator.  The most likely outcome of this during product handover is a quality variance which will result in customer satisfaction, budget and schedule variance issues.

This is the rationale behind one of the key principles of agile approaches – make the customer an integral part of the project.  Yet even on agile projects, one often sees an increase in the distance between the customer and the creators.  This might be due to legitimate geographical or time zone limitations, but other times it is because of political or priority reasons.  The “easy” answer in such cases is to start introducing proxies for the customer, thereby increasing the likelihood of expectation gaps.  This gets worse in cases where the delivery organization outsources portions of the delivery process as there are likely to be even more hops introduced.

As project managers, we need to avoid the temptation to follow the path of least resistance – if the pushback in involvement is coming from the customer, it is important to have those “difficult” conversations to help them understand the risks introduced and to confirm the relative priority of the project deliverables.  If resistance is originating from the delivery team due to concerns of constant requirements refinement or change, it may be worthwhile to review the outcome of projects where the customer had not been involved to prove the merits of an alternate approach and to explain how other project constraints (e.g. schedule, cost) can be fixed thus allowing scope to be flexible.

While six degrees of separation might be enough to connect you with Kevin Bacon, striving for zero degrees of separation between your project customer and your team might help to bring home the bacon!

Don’t forget to leave your comments below.