Project Management

pmStudent

by
Ranting and raving about project management and systems engineering.

About this Blog

RSS

Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Categories

Agile, Career Development, Certification, Change Management, Communications Management, Cost Management, Documentation, Earned Value Management, Education, Integration and Test, Kanban, Leadership, Lean, Lessons Learned, Methodology, Misc, Multitasking, New Project, Operations, Planning, PMP, Productivity, Professional Development, Project Estimation, Project Leadership, Quality, Requirements Management, Risk Management, Schedule Management, Scope Management, Software, Systems Thinking, Tools, Video, Work Breakdown Structures (WBS)

Date

Conflict Resolution Diagram For Projects

Categories: Systems Thinking

linkedin twitter facebook Request to reuse this  

If you are a fan of Theory of Constraints (TOC) as I am, you may know of the Evaporating Cloud Diagram.

As I have been using Kanban for some time now, I have found myself going back to my TOC roots and unpacking some of the tools I am somewhat familiar with, but haven't used nearly enough in practice until recently.

The following figure is an example of this tool put to use.

Conflict Resolution Diagram

The Goal

This tool is useful when you have two competing interests that appear to be at odds.  Mapping it out like this helps walk through the assumptions being made.  Each of the arrows carries at least one assumption, perhaps many assumptions.  The 5 sentences below the diagram are the default assumptions being made here.

So in the main, this helps everyone understand the underlying assumptions so they can be analyzed with a skeptical eye.

Let's Walk it Through

The objective here is to have a cost-effective, quality system.  We want to maximize quality and minimize costs at the same time.  

I'm sure this is just a weird example, we've never run into this before, right?

One of these assumptions as I walk through them stands out to me.  Do we really have to sacrifice functionality and scaleability in order to minimize costs?  What about that statement seems like it may not be quite right?

In this example, I discovered that "minimize costs" was a requirement, but put this way, it was being assessed in the narrow and short-term way of project cost.  The life time cost (and from all sources) were not being properly factored into the ROI equation.

Quality was being assessed as a lifetime dimension of the system...but because of accounting practices and separate funding sources, costs were only being assessed in the scope of the project.

Looking at it this way (and using this as a tool to help senior management understand) is a great method to apply systems thinking to conflict resolution on your projects.  It's helped me personally to help sponsors "see the light" when it comes to justifying the expense of licensing software, procuring specific hardware, etc.  It has helped me in many instances.

Give it a shot!

Like this? Share it!
Posted on: April 19, 2011 06:17 PM | Permalink | Comments (1)
ADVERTISEMENTS

"In three words I can sum up everything I've learned about life. It goes on."

- Robert Frost

ADVERTISEMENT

Sponsors