Speed it Up: Release the Ownership of Making Changes

Looking for ways to speed up operations on your project?

Think about Releasing the Ownership of Making Changes.

On many processes, there is a Process Owner and the definition of ownership for that process owner includes:

  • Ownership of Making Changes
  • Ownership of Implementing Changes

Ownership of Making Changes is when the process owner must approve a change before its made.

Ownership of Implementing Changes is when the process owner must approve the change before it’s implemented.

The problem with the Ownership of Making Changes is that it takes longer for changes to happen.

Longest Process

The usual flow is:

Someone (let’s call her the Change Agent) recognizes a need for change

  • The Change Agent preps a request to Make the Change to the Process Owner
  • The Process Owner gives approval to Make the Change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for the Change Implementation

Ok so, what if we pulled out the need for approval to Make the Change? We’d lose a bunch of steps and gain more time.

Shorter Process - Ownership for Making Changes has been released

That flow would look like:

  • The Change Agent recognizes a need for change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for Change Implementation

Now…you can really speed things up by training a group of people to do the work, so that anyone can make the change. If you encourage Change Agents to communicate the recognized need for change transparently, maybe through a collaborative system, then any one of the group can pick up the change and make the change. Assuming that the person who picks up the change did so because they don’t have any other work, they don’t have to shuffle it in priority with other things on their plate. So the work gets done faster.

That flow looks like this:

Shortest Process - Many Trained People Can Do the Work

This idea is why Kanban and Agile teams get things done faster.

The Big Picture of Time Savings by Removing the Ownership of Making Changes

Implementation Guidelines

To really make this work, the Change Agents must be people with the skills and training to make the changes. Ensuring that you have a key skilled group of people provides a measure of confidence to Process Owners and prevents chaos when making change.

The Process Owner must still approve the change, which also prevents chaos. You should also create some type of way to rollback if the change is not approved or a place to make visible and shareable drafts.

Try this on a small process and feel it out. You may find that Removing the Ownership of Making Changes results in large, beneficial gains in productivity.

Make Process Docs More Storyboard, Less Schematic

I love PS Magazine.

PS is the Army’s way of making the maintenance of very complicated and dangerous equipment easy to understand.

I love PS because they’ve figured out a way to do the following:

  • Make process visual
  • Communicate difficult concepts in easy to understand terms

In business process management (BPM) world, business process notation is one way to make process visual, as are swimlane diagrams, process flows, decision trees.

What I love about PS is that PS knows its audience and engages the reader, and acheives the same goals as BPM in gaining process management and efficiencies, but in a very natural way.

For the Processs Geek, PS is the best process read you’ll ever have. Why?  Because PS is a Comic.

Here’s what works with PS:

All pictures except the BPN picture are from PS Issue 702, May 2011

Big chunky breakdowns of process with pictures

This type of visual is easy to grasp.  This is a process flow about how to mount a gun.  There’s Step 1, which has three possible decisions points 1a, 1b, 1c and then there’s Step 2.  Each step has a picture and notational direction.

Compare that to this:

Business Process Notation for the Same Process

Personification of Objects

The artifacts come alive – they have likes and dislikes.  This is somehow easier to grasp than a long list of Do’s and Don’ts.

Poor computers - they're overheating - Better store them correctly!

Multiple User Characters

There are multiple types of machine users and people on base who interact with the process. Each one gets thier own persona.  So instead of swimlanes on a diagram, we actually see the person, give them a name and watch how they interact with the process.

So many users...

Dialogue of Process Interactions

Process is demonstrated through dialogue- the scene is acted out, and the users verbally describe how and what they do in the process.  Compare this to task boxes on a process flow diagram.

And one thing I learned from my audience at a presentation I gave on BPM for Small Business; start with the picture first, then work back through the process.

My instinct is to give someone a documented process visual – swimlane or something of the sort, and then documented process steps that correspond to that document.

But what PS teaches, and what my attendees taught me, is that you start with the picture of what you’re trying to achieve, then introduce the schematics.

It’s like when you go to Ikea – you pick the design you like, take it home, and then you follow the process doc.  If we ordered furniture using process docs, Ikea would go out of business.

So wouldn’t it be cool if we could produce process documents like this – more storyboard and less schematic?

How to Find Where New Process is Really Needed

Thanks to David Kohrell for inviting to write a Guest Post on Tap University’s blog.  You can find the original here and below please find a reprint of my guest post.  And BTW Tap University does all kinds of training from CMMI to Kanban, so mosey on over there and take yurself a course or two!

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.

Conclusion

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.

What Happens When I've Gone? Will Process Maturity Stand the Test of Time?


Washington turns it all over

Washington turns it all over

At the Museum of American History yesterday, I was quite struck by the outstretched hand of George Washington, offering his sword, hilt first, tip pointed directly at his heart, to an implied awaiting predecessor.    The statue is meant to convey the peaceful transition of power, but I see in it a sort of painful realization of the fragility of continued stability.  It was by his sword, a metaphor for his position as a General,  that he helped build the infant nation, establishing repeatable processes for long-term stability.   Yet, to continue that stability, he has to hand over the very sword that wrought it.   The tip points at his heart, suggesting that the handover could in fact destroy his heart, or vision.  Yet and still, he continues the transition, aware of the risk, but perhaps aware of a more tangible risk of destruction of all he’s built if he does not.

And believe it or not…this got me thinking about project maturity!  (I know – geek to the core over here).  We  spend a lot of time building project management maturity into our process.  But what happens when we’re gone; like 10 years from now?  How do I know that process maturity  will live on long after I’ve started living the cafe lifestyle in Paris?

Why keep the process going? Because it meets my needs!

Abraham Maslow was a psychologist who posited that there is a basic hierarchy, or progression, of human needs.   Once the basic need for food and shelter is met, then one can address safety needs and so on.  I refer to Social, Safety and Physiological needs as the Basic Needs and the Self-Actualization and Self-Esteem needs as the Higher Level needs.  The needs groups are:Maslow

Higher Level

  • Self-actualization — Creativity, education, spiritual beliefs.
  • Self-esteem — The confidence that comes from mastery of tasks and work. It is reinforced by recognition from other people.
  • Basic

  • Social needs — The desire to be accepted by others and feel part of a group.
  • Safety needs — The psychological security of having a family and a safe home.
  • Physiological needs — The basic needs for food, water, warmth, etc. We can only think about higher things when these basics are in place
  • Project Management Maturity (PMM) models found in CMMI and OPM3 are usually put in place initially to address an unmet need for safety in the guise of reliability and repeatability.  For example, we feel unsafe when we start a project and the process differs from project lead to project lead.  But we feel fairly safe if there is a repeatable process that we can rely on.  We don’t have a sense of uncertainty and fear in safe repeatable process, where roles are clearly defined, and I’m clear on what I’m supposed to do.

    In my experience, I’ve observed that the process of initiating CMMI has had a tremendous effect on the self-esteem needs of my team. What could be better than setting up a process that meets basic human needs, that burns in safety and reliability.  The team members appreciate it, the product is so much better and the clients love it and rely on it.

    But as processes become burned in, higher level needs will be more difficult to achieve.  I see a paradox.  The creation of the solid structure at the beginning satisfies higher level self-esteem needs of the team; ie the mastery of a problem and the solving of that problem.  But once the problem is solved, then the existing system can become simply a set of rules, whose rigidity can actually work against the innovation required for self-esteem and self-actualization.    I’ll call it the PMM Paradox, more succinctly put, building project management maturity satisfies higher level needs which the new structure itself can prohibit in the future.

    Satisfying higher level needs assures longevity

    And that is where I see the threat to the continuation of the PMM processes we’ve built.  When this project ends how will those higher level needs be met?   And if they aren’t, will everyone just look at all this good process we’ve put in place as bureaucracy, or too much overhead and scrap it?

    I think the only way to make this process stick is to:

  • Satisfy basic needs  through repeatability and reliability of the PMM structures
  • Continue to provide satisfaction of higher level needs through other means within the organizational culture.
  • Hulya Julie Yazici’s recent  study The role of project management maturity and organizational culture in perceived performance in the September 2009 PM Journal concludes that there is a connection between organizational culture and the ‘stickiness’ of PMM.  Yazici writes, “This study shows that organizational culture has a significant influence on project performance and the long-term success of organizations.”

    Four types of cultures are described; clan, adhocracy, hierarchy, and market. “The clan culture stresses the importance of participation, cohesion, shared values, commitment, and high morale, while the adhocracy culture assumes that innovation and initiative lead to success and encourage entrepreneurial, creative, and visionary behavior. The hierarchical culture is characterized by a structured workplace with formal rules and policies and a focus on efficiency, timeliness, and control. The market culture perceives the external environment as hostile with choosy consumers and a need for the organization to be both results- and production-oriented.”

    The study concludes that, “Clan culture, which is characterized by high cohesion, collegiality in decision making, and a special sense of institutional identity, is perceived to be significantly influential in project effectiveness and efficiency, as well as in the internal and external business performance of these organizations”

    A Clan culture’s very foundation is premised on the satisfaction of higher level needs.  Within a Clan culture, process improvement provides the safety and reliability that satisfy basic needs, while higher level needs are met within the organizational culture.  So the process gains remain just that…gains, not losses.

    Doing what I can do

    I don’t have a lot of control over the organizational culture of my company and of course, no control over my client’s organization.  My takeaway is that to ensure PMM longevity on my team, and improve project success rates, I’ve got to create a mini-culture that address the full hierarchy of needs modeled on a Clan culture.   This looks like my best chance of ensuring that what we’ve built, will last.