Sunday, 10 January 2010 00:00

Fire the Bastards... and Other Conflict Resolution Techniques

Rate this item
(0 votes)

Conflict resolution is a major part of recovering red projects. The solutions range from firing the bastards to analyzing where the sources of conflicts are and determining a more friendly way to resolve them. I have to admit, when stepping into a project where the estimate at completion is a couple million dollars over the budget, everyone is pointing fingers, and the customer is screaming the supplier is in default, replacing people is sometimes the best option. So much so, my kids occasionally refer to me as 'hatch.'

Case Study: Removing Team Members

In some severe conditions, people may need to be removed. Contrary to common belief, this can have a very positive effect. At one client, nearly two-thirds of the team was going to be laid off in a work force reduction scheduled in a few weeks. All laid-off workers would be given a severance package. However, one individual refused to do requested work and was being non-professional, dishonest and exhibiting behavior destructive to the team. He had been warned of his negativism and was finally recommended for termination—a week prior to the layoff. There was a lot of hesitation since he was on the list for the layoff. The issue was pushed based on the reasoning that letting him go would show the remaining team that management was intolerable of his toxic behavior and would take action. Eventually management gave in and terminated the person. After the layoff, many of the remaining team members commented and thanked the recovery manager for showing fairness and stopping the insanity. They saw the action as positive and as a sign of being able to trust management. Sensible action and control was being applied to the situation.

Do not get me wrong, there are times when termination is the route. Waste no time in releasing destructive team members. The team performs better, not because they are scared that they are next, rather that they are pleased to see some leadership that is stopping the insanity.

Strategic or Tactical

There are more subtle forms of conflict and kinder methods of resolution. Some so subtle the project sponsor is unable to see the conflict and needs help understanding the core problem. For instance, a few years ago I was assigned to a project and had a very difficult time getting people to understand the project was ill defined. The customer's documentation clearly stated the goal of the project was to assess the problems with an existing tool and "stop the bleeding." A tactical solution was a good approach since they were hesitant to invest money in something they may throw away in a few years. Even though this project was listed as tactical, the budget was $1.8 million. The year prior, a similar project was proposed with a budget of only $800,000. Further investigation uncovered statements in the proposal documentation saying, "fifty percent of the code would be reusable." (I am still wondering how they planned to test this.) These seemed a little incongruous with an "extremely tactical project," so I escalated it to the Project Sponsor. Here I ran into something unexpected. The newly assigned sponsor had not been part of the original definition. He put project scope at the top of the triple constraints. The sponsor gets what the sponsor wants, they have the budget.

Tactical Strategic
$800,000 $1.2 Million
Existing Programming Platform New Programming Platform
Stop the Bleeding 50% reusable code
  1. Cost
  2. Timeline
  3. Scope
  1. Scope
  2. Timeline
  3. Cost
Figure 1. Showing the Conflicts

I shook my head and moved on to initial design meetings. Here the architect defined a solution that entailed moving the system, rather than fixing the existing one, to a different platform and enhancing the product to provide the base functionality. In doing this, multiple tasks were added to the activity list. One, titled "Refactor Struts to JSF," looked as if it was stepping way outside the tactical definition. To help me out, the schedule stretched out and the required budget suddenly jumped $400,000. That did it, this was just wrong.

I put the data that I had into a simple table (Figure 1) to present to executive management. I am sure that the nearly 25% increase in budget caught their attention first, but rest of the data allowed them to draw their own conclusions on the how the project's intent had shifted. Within the course of a couple days, the project sponsor had an epiphany and the project was drastically scaled back.

Evaporating Clouds

Critical chain advocates approach the problem from a very different angle—the evaporating cloud. They actively look for the conflict and focus on the problem's root cause. For instance, let's take the following conflicting opinions:

Evaporating Cloud
Figure 2. Evaporating Cloud
  1. Letting the team talk to the customer will cause scope creep;
  2. To gather requirements the team must talk to the customer.

The problem is diagrammed to show the need, translate customer needs into a product, and the resulting logic to get to this result. Figure 2 illustrates this simple case. Boiling the conflict down into two diametrically opposed statements, the analyst can arrive at the conflict and work on the root cause. The theory says at core of the conflict is an incorrect business assumption. In this case, the errant thought may be that the project team will increase scope or an intermediate analyst will be unable to get the correct definition. Proper education and leadership will avert the conflicting concerns. The critical chain team would look for the incorrect assumptions and work at resolving them.

Of course if you fail to resolve it this way, just fire the bastards. (You know I am kidding, right?)

Read 5670 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References