Early in this blog’s life, I posted quite a bit on ‘sticking points‘ that IT organizations find about mid-way through the journey to high Business-IT Maturity.  Process discipline can be one of the quintessential such sticking points.  Process management can get you out of the mess of Low business-IT maturity to a mid-level, but simply cranking up the degree of rigor and discipline will prevent you from getting to high maturity.

Three Ways to Abuse Process Discipline

  1. Forgetting that the heart and soul of process thinking is Process Improvement.
  2. Process becomes a substitute for thinking, rather than an aid to it.
  3. Not everything lends itself to detailed work processes.

Let’s examine these.

Come Back Deming – All Is Forgiven!

When the likes of Deming and Juran began spreading the gospel of Process Thinking, they weren’t talking about creating a process and freezing it in concrete!  The ‘Deming Cycle‘ – Plan, Do, Check, Out – was all about continuous (and sometimes, discontinuous, as in process re-engineering) process improvement.  And yet many IT organizations somehow leave this aspect behind as they institutionalize worksteps, activities, deliverables and milestones.  People are encouraged (forced”) to follow the project management methodology or systems development life cycle, and punished for violations.  For a while, things improve – some process is generally better than no process!

But then people begin to realize that the process seems to get in the way – inhibits agility.  Intelligent choices are held victim to the process, and bureaucracy reigns.  To get past this sticking point, people need to understand, believe in and be passionate about process improvement.  Be it incremental, stepwise improvement or breakthrough re-engineering, the missing ingredient of continuous improvement is essential to getting the intelligence back into the work and non-value-adding activities out of the work – especially if these inhibit speed, agility or quality.  The trick is to throw out the ‘bathwater’ of blind rigor without throwing out the ‘baby’ of process management discipline.

Three Ways to ‘Standardize’ for Repeatability and Predictability

Many years ago, my esteemed colleague Roy Youngman was co-authoring a book with me (Development Effectiveness: Strategies for IS Organizational Transition) and pointed me to this great work by Henry Mintzberg.  If a goal is to make work consistent, repeatable, predictable and of high quality, there are three ‘degrees of freedom‘ that can be tackled – the tasks, the deliverables, or the people.  The degree to which you ‘standardize’ within this mix is a function of the nature and complexity of the work you are trying to achieve.

For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.

For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.

For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below tries to capture this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, think training and performance support.

Some Process Management Questions To Ponder

  • Are your IT processes holding you back – or setting you free?
  • Are they an aid to thinking, or a substitute for it?
  • Is it time to move past the blind discipline of mindless processes to a more context-sensitive and effective approach?
  • How often to your processes improve, and where is the impetus and insight for those improvements coming from?
  • How are process improvements recognized and rewarded?
  • Is it clear who owns ‘improvement’ for any given process?
  • Is it clear who owns the ‘services’ that are delivered by given processes?

Answers on a postcard, please!

Enhanced by Zemanta