Archive for the ‘Process’ Category

PERFECT example of bureaucracy vs. process

Sunday, October 26th, 2008

What is the world coming to?!  Two posts in a month?

Well, when life hands you perfectly fitted, hand-picked, juicy, gift-wrapped, actual too-good-not-to-share learning-rich examples on a silver platter… you’ve just gotta take ‘em and share ‘em!

bureaucracy (by Bennett)One such example was handed to me a little while ago — thanks to the US Department of State via the US Postal Service. 
No, the Postal Service didn’t deliver something to me from the State Department.  It’s more like the Post Office was the instrument of the State Department’s bureaucracy.

A perfect duet of two bureaucracies operating in perfect bureaucratic harmony.  Though, when I think of "bureaucratic harmony" it sounds like an out-of-key dirge played in a decaying public school building by a poorly equipped elementary school ensemble.

But, enough of the musical analogies… We’ve got a bureaucracy to pick on and how and why my experience at the post office that week provided me such rich fodder for a blog post about processes.

This experience crystallized a way to teach the distinction between: Process, Procedure, and Bureaucracy.

So, the context of the lesson is in the State department’s requirement to verify the parentage of minors (children under 16) applying for a US Passport.  To avoid issuing passports to minors (or in particular, to adults in the company of minors), the relationship between the minor and the adult must be established.  In a typical example, parents must demonstrate that they are, in fact, the children’s parents.  When applying for a passport for a child, parents must show that (a) they and their children are US citizens and that (b) the children belong to them.  The State department requires that the children and both parents be present while applying and that the parents supply the child’s birth certificate.  So far so good.

image The lesson appeared when we were applying for a passport for a child for whom we already had a passport.  In other words, we’d already provided the necessary documentation to prove we are our child’s parents when we first obtained the passport.  We appeared at the post office with an expired passport in hand and all the other documentation, except for the birth certificate (for the child who already had a passport, and thus we’d already proven our relationship).  Since we’d already provided the birth certificate in order to obtain the original passport, we figured the post office merely had to ensure that we were still who we said we were by looking at our government-issued ID (which is also required when applying).

Even if there was risk of someone else finding our child’s passport and attempting to represent themselves as our child’s parents, their IDs wouldn’t match the names, and even if they did, in such a case whether or not they were *us* wouldn’t matter.  Imposters with that level of sophistication could get anything they needed.  But, under normal circumstances, if someone else were to try to pass themselves off as us, their names wouldn’t match up.   In other words, if adults show up claiming to be a child’s parents, then their names should match that on the application and the child’s documentation.  If the names don’t match, then additional documentation would be appropriate, as in the case of adoption or other name-mismatching situations.

Anyone can buy a birth certificate, so, in fact, the longer we exist, the better the chances of identity theft.  Therefore, the earlier someone gets a passport, the more likely it was obtained with authentic data.  So again, the best "proof" that we are our child’s parents is the fact that we had a prior passport along with the other documents.  However, the State department’s bureaucratic procedures, dutifully executed by the Post Office, required that we present a birth certificate nonetheless.

At Entinex, we define a Process as the high-level depiction of a value-adding activity that produces an outcome.  Processes are the activities that are necessary for the product being worked on (or work being done) to achieve the outcome the customer of the work desires to have.  If the proper outcome is achieved, as long as the cost and schedule was within the customer’s expectations, the customer ought not care how the outcome was achieved.  The process can be the same from context to context.  In fact, minimizing unique variants of a process in a given organization makes it easier to manage.  In our passport example, if the State department had issued a process rather than a procedure the process would simply be: Establish and Confirm parent and child’s identity, relationship and citizenship.

image The how of the process we define as a Procedure — the specific steps needed by the process to produce an output.  There are likely many ways (i.e., many possible procedures) to accomplish the process’ expectations.  Procedures are best applied to very particular contexts and ought to change from context to context.  From a value stream perspective, procedures actually consume value.  The intention of any organization ought to be to minimize the gravity of the procedure since if/when the procedure takes more time or resources, it costs more and therefore raises the cost of the process and often reduces its value.  Procedures are served best minimally.  Had the Post Office been allowed to create their own procedure(s) to accomplish the above process, they could have created procedures to check for artifacts that identity has been established/confirmed by means of some level of reasonableness.  The Post Office could have different procedures for first-time applications, subsequent applications, and name-mismatches.

However, instead, the State Department issued a procedure that was not context specific and wasteful.  It didn’t give the Post Office (or anyone else) the flexibility to find the most appropriate way to determine identity or relationship, or to distinguish between the permutations of application situations.

In other words, the State Department established a bureaucracy:  A procedure in absence of context

Bureaucracies are often intended to compensate for lack of competence or trust, or as input to an over-engineered system.

Take your pick on this one.

I’m about to say something cliché…

Wednesday, May 21st, 2008

… Expect to learn all the time, and you will learn.

I’m working with a great client in Connecticut.  A referral thanks to Bob Lewis.

First off, over coffee Bob unknowingly gave me a new set of metaphors for a topic he admits to having little understanding of: CMMI.

To spare you the details of what he said and how I processed it, please allow me to simply explain the gist.  In CMMI there are lots and lots of things called "practices".

Many people interpret these practices as though they are processes, or worse even, procedures, and they execute the practices mechanically.  Yes, that’s usually because these same people either (a) are chasing a maturity level rating, or (b) simply don’t understand how to use the model to reap the greatest benefit, or often, (c) both a & b.

Here’s how to actually and properly use the practices in CMMI:

They are underlying motivations.

When you think of what doctors, lawyers, athletes and performers do, they practice their art.  And it’s a practice because they’re constantly applying, learning, adjusting, and responding to the non-ideal and unpredictable conditions presented to them in real-time.  If they were simply following procedures every time, they’d fail most of the time.  Yet, they practice, practice, practice, so that when it comes time to perform the practice they aren’t worried about following pre-determined procedures because they must be able to respond to what’s thrown at them in reality.  The procedures assume a pre-determined situation and the responses to procedures are ideal to those situations.  What they’re exactly doing in real-time comes from their practice, but doesn’t necessarily look exactly like what they did last time.

Procedures are good when all the inputs are controllable.  Processes help know what major transformations an object or an idea must go through to become an outcome.  Processes generally follow an expected sequence, but what happens inside the process should have enough flexibility to be rearranged to meet the needs of or to normalize the input conditions.  What the procedures must do, however, is respond to reality.  The way in which procedures inside a process respond to reality to become rearranged or redefined based on the principles and motivations of practices; which are not necessarily even explicit.  They’re "just there".

For example, at the process level, a doctor goes through several steps prior to, during and after performing surgery, (e.g., consult, exam, test, analysis, advise, prepare, communicate, operate/investigate, clean/close, protect, follow-up…). Each of these sub-processes to the process may have certain procedures, but each of those procedures is contained within at least one practice.  The practice may not even be written, or formal, but they’re certainly part of what the doctor is trained to do based on principles and motivation.  These principles and motivations are taught and refined over time, with practice.  And true, some practices can be beyond the capability and/or maturity of some people.

It’s no wonder when an organization’s true underlying motivation is the shallow ceremonial decoration of a rating that their results are equally shallow despite the time, energy and money that went into the production effort to pull off ceremonial decorations. (Think: big, gaudy, wedding where everyone knows the couple won’t last.)

While learning this lesson, Bob pointed out that what he and I do for a living are, in fact, practices (i.e., consulting practices) and the next morning I find myself before a cozy crowd of client staff and despite having thought through much of how things would go, I still felt like I was winging most of it.  In reality, in real-time, I *was* winging it.  I was responding to the reality, but was never out of my element because I was still…. practicing.  Following the basic principles and motivations to achieve an outcome.

So it all worked out and everyone was pleased.  We made a lot of progress and then I learned the next lesson in this 24 hour period of time: It’s really a lot of fun to actually be on the sharp end of the stick once in a while… actively blending Scrum and the immediately useful bits of CMMI.  The real lesson, though, was in gaining re-enforcing validation as I witnessed this organization actively absorb and propose process ideas.  There was no push-back.  Quite the opposite.  Processes were being embraced as one of the things that would lead them towards success.  The alternative would be a slow dissolution of the company.

Once in a while it’s nice to really see just how effective blending good ideas can be when this process stuff is put into context of what must be done to succeed.  It just demonstrates again that too many organizations are using CMMI for the wrong reasons made worse by a lack of practice.

What’s in a Policy?

Tuesday, February 12th, 2008

This post is part gripe part informative.

Let’s start with the gripe (it’s also informative).

Two of my kids go to a pre-school with the following inclement weather policy:
(Only the names of the places have been edited. Otherwise, this is verbatim.)

  1. Our policy is based on [B] County School Announcements. We do not make specific [OurSchool] Announcements.
  2. If [B] County Schools are closed due to inclement weather, our school will follow the same procedure.
  3. If public schools are opening one hour late, we will open on time. There will be no before school care.
  4. If public schools open 2 hours late, we will open at 10:00 AM. There will be no before-school care. The morning session will end at 12 Noon.
  5. If public schools open more than 2 hours late, we will open at 12 Noon for extended day children.
  6. If [B] County closes early, we will also close.
  7. If inclement weather develops while the children are in school, it may be advisable to close school early. Listen to your radio for [B] County closing announcements. Parents concerned about inclement weather should pick up their children as soon as possible. Working parents are responsible for making arrangements to have their children picked up on time.
  8. Our facility is air-conditioned in cases of extreme heat.

Inclement Weather Procedure
Please read carefully.
There have been changes to our policy.

Notice anything strange?

How about they don’t know the difference between a Policy and a Procedure. (Don’t even get me started on where “process” fits into this!)

How about the problem that what their “policy” boils-down to are:
a) we don’t have a policy,
b) we follow what the County does,
c) except when we don’t.

In reality, how this “policy” plays out is this: If/when (and it *has* happened) that our kids’ school decides to not follow the County’s lead, they have no reliable way of notifying parents. They expect us to either call them, monitor email, or just show up. The issue with calling them is that they’ve got about 100 families of kids at their school. Not like 20 in a daycare.

Here’s another problem. Today, public schools were closed for Primary Elections (our County uses the public schools as voting locations), and, there was inclement weather. How exactly was the policy going to work today?!?!

Don’t think I haven’t brought this to their attention from the very first time the first of my kids attended that school. Of course, I was ignored by the school administration. To say that my concerns were “dismissed” as insignificant details would be giving them too much credit for even comprehending why my observation was even an issue.

So, here’s the “informative” part of the post.
And, the “agile” connection.

A policy is little more than a charter for doing something. When it comes to processes and process improvement, the policy gives “teeth” from upper leadership to the performance of the processes by projects. Existence of policies for doing a process are the first indication that processes are being worked into the fabric of an organization. In CMMI, being worked into the fabric of an organization is called “institutionalization” and is carried out by performing the Generic Practices. Since “being worked into the fabric of an organization” is about making an impact on the organization’s culture, I like to call this aspect of process implementation, acculturation.

Here are some other hints and tips for policies:

  • They don’t include processes or procedures, though they may reference them for clarification, edification, or example.
  • They could easily be replaced with a “charter” if that works better for your organization.
  • They shouldn’t be so weak as to be rendered obsolete or useless under the strain of simple integrity (read: “smell”) tests.
  • Someone should care whether the policy is followed because having the policy ought to be essential in helping the organization and its stakeholders make decisions and be predictable.
  • Policies should be clear about what’s expected of people’s conduct and performance (which makes them *not* the same a vision or mission statements — if it reads like one of those, it’s not a policy).
  • They can actually be carried out, and you know when they aren’t, and when not it’s either very unusual, or, someone’s not gonna be happy.
  • Suggest a certain priority of activities, and when in doubt or when conflict arises, the policy should help sort through it, or at least let those operating under the policy know when they’re in unchartered territory so they can seek leadership input.
    And, most importantly,
  • Policies set expectations, not steps, not work-flows, not checklists.

In agile organizations, or in “traditional” organizations looking to become “agile”, look to policy to ensuring minimal ‘prescriptiveness’ or, respectively, a source of unnecessary limitations, restrictions and undue ‘proceduralizing’.

In our experience, our kids’ school isn’t alone in having intractable policies. Only, when our kids’ school ran into me, they were up against someone who actually thought having a “policy” meant something.

Silly me.