My previous post described conflicts that people experience, and asked how those conflicts should be resolved. Here I’ll try to answer from both a Theory of Constraints perspective and an Agile Management perspective.

From a Theory of Constraints (TOC) point of view, the first step would be to put the conflicts into a “conflict” or “evaporating cloud” diagram. Let’s start with the first conflict, priorities versus responsiveness. Here’s a picture:

This diagram is read as follows: In order to be the best worker I can be (A), I need to have excellent relationships with my colleagues (B). That, in turn, means I need to be responsive to my colleagues (D). For example, I may need to interrupt what I’m doing to help a colleague move forward on their work. On the other hand, I also need to maximize the impact of my work on the business (C), which means I need to follow my priorities (D’). If I’m being responsive, I’m not following my priorities: a conflict between D and D’. This conflict is represented by the red arrow.

Such a conflict is typically resolved by compromise: sometimes we’re responsive, sometimes we aren’t. We end up with neither great relationships nor great productivity. How often or how well a person follows their priorities depends on the situation, the individual, and the ways they decide to compromise. Note that uncertainty surrounding day-to-day decisions people make, added up across the compromises people make across all four values, can create tremendous variation in what an individual can accomplish over any given day or week – variation that’s independent of uncertainties in the work content itself.

The second step is to list the assumptions behind the arrows. Rather than do that, I will point to a couple of specific assumptions. An assumption between B and D might read: “In order to have excellent relationships with my colleagues (B), I must be responsive (D), because everyone expects it.” An assumption between D and D’ might read: “I can’t both be responsive and follow global priorities, because responsiveness has nothing to do with my global priorities.”

The third step, challenging the assumptions, is easy, mainly because I’ve only included the assumptions I want to challenge. Suppose we were to prioritize our responsiveness, and make that a company-wide expectation. That is, we put responsiveness in the context of priorities, and expect everyone to do that. If they are asked to be responsive, understand where that response falls within their priorities. That way we challenge both the assumptions I’ve listed. For example: before asking me for help, people are expected to have a pretty good idea that the work they want help with is higher priority than what I’m currently working on.

The approach I’ve shown could work for all the conflicts, but it doesn’t sound easy. There are a lot of steps to the solution, and I haven’t really provided a convenient framework for explaining the answer clearly and simply. The conflict diagram guides us in the right direction, but does it really help anyone to change?

A more concise explanation comes from the world of Agile, the Agile Manifesto. That document leads with four core principles, phrased as “We value x over y”; for example, “We value working software over comprehensive documentation.” Documentation is not bad, but working software is better. When presented with a potential conflict, it’s usually right in the Agile world to create working software.

If I express the four conflicts from the last post in this way, we have this list:

• We value priorities over responsiveness.
• We value finishing over starting.
• We value speed over deadlines.
• We value shared goals over individual goals.

These four values comprise the Project Manifesto. It’s not that we don’t value the second; it’s that we value the first more. We need to put the second in the context of the first. The second needs to subordinate to the first.

To effect change for a project organization, it helps to have an overarching concept, a message or paradigm. Agile (be quick, nimble, and responsive), Lean (minimize waste) and Six Sigma (maximize quality and minimize variation) all concisely describe paradigms. We can summarize the Project Manifesto concept – and, I believe, “Critical Chain Project Management” (CCPM) – as follows: perform project work as if it were a relay race. When you have something to do, work it as quickly as possible, start to finish; then make a good handoff. In order to describe the paradigm in more detail, use the Project Manifesto values: priorities over responsiveness, finishing over starting, speed over deadlines, and shared goals over individual goals.

CCPM is a very effective way to schedule and manage project environments. It fixes many of the problems with the Critical Path method. The Project Manifesto doesn’t just describe CCPM execution; it extends CCPM to areas that may not need schedules.

In subsequent posts, I’ll explain more about why the Project Manifesto is important, and discuss the kinds of issues that arise during its implementation.