How to Find Where New Process is Really Needed

Posted on March 31, 2011 by


It’s great to learn new models. I LOVE models. I like to think about how they can be applied, and I get excited about both the predictive ability of models and the capacity for goodness that exists when a model is well executed.

Root Cause

Focus, find, and determine your root cause

But I’ve learned that the reality is that you will never be able to apply everything you’ve learned. This is because either it’s not needed or the organization can’t handle it. Every organization is different and has a different set of problems. What worked in one place, may not work in another.

What I’d like to talk about today is how to determine what is really needed process-wise when you first start a new project in a new culture. I’ve seen lots of Project Managers start new positions and want to apply everything they’ve learned from the PMBOK, only to actually slow things down and create inefficiency, and even, in some cases, bad will. There’s a stereotype out there about the ‘check the box’ Project Manager (PM). Someone who has all the correct process, but none of the wisdom to really correctly use process and tools to fantastic result. I don’t want you to become one of those PMs. I want you to become that indispensable, brilliant PM who analyzes the situation and correctly applies the tools.

You may be familiar with the Pareto rule. The Pareto rule says that 80% of effects come from 20% of the causes. In practice, this means that if you have problems on your project, most of them have the same cause or set of causes. It’s like there are ‘source’ causes for most of the problems that you see.

Success lies in addressing that 20%, the source causes, and neutralizing them before they balloon into 80% of your problems.

Here’s a process I’ve used to discover that 20%. Let’s call it the ‘The Real Need”  process. The goal of this process is NOT to apply everything in a model. The goal IS to apply the right process, in the right amount and to the right situation.

The Real Need Process:

Step 1: Force Yourself to Observe :

For people like me, sitting back and watching is really hard. But, I’ve fell flat on my face so many times racing to apply process, that I’ve finally learned to sit back and watch. I don’t mean don’t do your job. I mean, before you suggest brand new processes, watch and wait for a while.

Do this for about a week to a month – depending on the culture of your organization.

Step 2:  Analyze and Evaluate the Stream of Artifacts and Behaviors:

As you read documentation, or watch behavior, or read emails, start to breakdown what your next step would be according to the model. So for example, say you receive an email from a team member about how the client is angry with something. Most Project Management models would encourage that you take action. They would advise perhaps discussing the issue with a SME, maybe adding the issue to a list of risks to monitor. Let’s not forget potentially adding the issue into the change management system, and ensuring that the issue is added to action items for further discussion.

That’s a whole lot of behavior that you could do, and that the model predicts are best practices, because if you don’t do these things, the project can go into a lot of crazy directions, most of them unfavorable.

The key here is to document what the model says you should do, but not to do any of it, yet.

Instead, watch and see how the organization responds.

Step 3: Watch How the Organization Responds:

There is value in the repeated pathways of human behavior. Human beings are capable of developing success behaviors, which have been learned from past failures. When you first come into an organization, you probably don’t know those behaviors. Most of them aren’t documented. So what you may have interpreted as a failure behaviors based on your previous experience may in fact be a success behavior in the new environment.

Likewise, what the product/process model predicts as failure behaviors may in fact be success behavior in the new environment.

So, armed with your notes from step 2, watch the behavior and outcomes of the stream you observed in step 1. The organization will do two things; a) what you think they should do and b) what you think they shouldn’t do.

Step 4: Take Action:

For anything that is b) what you think they shouldn’t do, that winds up not causing further problems, strike that from your list of things to address immediately. This means that it’s not part of the 20% causing the 80% of the problems. In other words, the model (and your previous experience) may have predicted failure…but failure didn’t happen. Therefore, there’s some wisdom of experience in the behaviors of the organization that you should make a note to learn.

However, for anything that was a) what you think they should do that they didn’t do, and that led to a problem, focus in on that. That is your golden entre into solving problems. In that case, your instincts, and the model, predicted that a problem would occur. And because you’ve been learning, and have process and project tools at your disposal, you can rapidly suggest and hopefully implement a solution.


This isn’t a perfect way to get at all problems, but it’s a start. And it will prevent you from applying process where process probably isn’t needed. The idea here is to help you eliminate extraneous information by focusing on actual observed outcomes rather than on theory alone. This approach enables you to quickly find the failures, and use the theory for what it was meant for…project success.

by Michiko Diby, Blogger, Kosmothink

Enhanced by Zemanta