Posts Tagged ‘uncertainty in projects’

Chaos and Complexity #4: Push on or Regroup?

by Gary Monti on October 5, 2010

One of the most brutal forms of punishment is solitary confinement. At the other end of the spectrum is multitasking. Stating the obvious, what works best is finding a balance point. This means keeping it simple, something that sounds nice but can be quite challenging. Why? A hallmark of a complex environment is unpredictability. In other words, one doesn’t know where things are leading. In fact, they aren’t leading anywhere – that’s why the situation is called “complex” or, worse yet, “chaotic.” (We will look at the similarities and differences between these two terms in a later blog.)

This creates an interesting conundrum: Where does one place their focus when the environment provides no clues as to whether it is best to push on or regroup? Let’s explore.

Pay Attention

A really short answer to dealing with this situation is, “Just look and decide.” Okay. Given that, where do you look and what do you decide? The answers lie within the team. Determining just how far the team can go sets the limits in the situation. The specific concern in working within those limits is seeing whether the team should experiment (regroup) or continue with what is in place (push on). The goal is working in a predictable situation, one where a schedule can be developed.

Success and Failure

An honest appreciation of the possibility of failure is essential. Now, this isn’t something to dwell upon. In fact, the project manager’s challenge is paying attention to how close to the edge of the cliff the project is but then having the courage to stay focused on working effectively to back away from that cliff and stabilize the situation.

Achieving that stabilization usually requires some experimentation. This goes beyond best practice where alternatives are present. Rather, the experimentation is the team making calculated stabs at what they think might work and accepting that some of those experiments may fail but still yield good information.

For example, a common contributor to complexity is lack of clear requirements. This puts an unfair burden on the team since they are probably being held to an end date and maybe a budget. So, what do you do? Some experimentation is needed where the PM and team create what they believe the requirements to be and then offer this up for approval. Now, the odds of this working the very first time are usually small since stakeholders are probably pulling the project in different directions. If this weren’t true there would be clear requirements to begin with. So, the team must think of alternatives and have more than one arrow in their quiver.

Professional Gambling

With a sense of the team’s limits the project manager will do best being a professional gambler. The gamble is this: Can the team come up more than one set of requirements and can the PM push to get one set, or a variant, accepted. This means allocating time for the team to go out to the edge, almost being a little bit wild, and come up with options as to what might work, e.g., looking at what the best that could happen is, what the worst is, what could be expected, etc.. It is up to the PM to decide how to play the politics and push for acceptance of some realistic set of requirements. This is a very fluid situation requiring focus and discipline.

Come Back From the Edge

The PM’s main goal is to get to some set of requirements allowing the team to move, at the very minimum, to a best practice situation where they can choose from several realistic options how best to proceed with the project in a linear fashion, i.e., creation of a realistic schedule. In other words, the team needs to get to a spot where they can start predicting outcomes based on a given set of requirements. Without this a schedule is impossible and the situation will collapse.

Let’s recap. We see that a certain amount of time is spent trying to establish order from the bottom up and getting buy-in from power brokers and senior managers so that top-down support is established. Unified commitment from senior management is what is needed.

The PM must subtract the time the team spends experimenting plus the time the PM spends politicking from whatever time is left in the schedule.

The PM and team then need to regroup and determine how much of the approved scope can be accomplished in the remaining time. This leads to another potentially difficult decision point.


Typically, what happens is by the time senior management gets behind the scope of work there is insufficient time left. The PM is then faced with the distasteful task of offering some combination of the following options:

  • Cut scope;
  • Ask for more resources but not so many that the project is pushed into confusion;
  • Extend the schedule, and;
  • Worst case, cancel or delay the project

The PM has to watch and not get caught in the middle, i.e., potential team burn-out on one hand and senior management having unrealistic expectations on the other.

A Solution

The best way I known of to handle such situations is simply working to avoid them. The odds of successfully avoiding a train wreck of a project go up when the above realities are applied at project inception. Ask the question, “Why shouldn’t I believe this is a complex project?” If there’s insufficient information to create a network diagram then the situation is complex and the team is going to have to go to the edge and do the experimentation mentioned. The PM does best by staying with that reality. It’s not a good formula for winning a popularity contest but it does help develop the reputation for being honest about what the organization can do under the circumstances.  In the long run working this way in a respectful manner is what brings about the most growth possible under the circumstances.