|
The thinking then goes on:
we have informal processes and those are causing problems for us. We need to
introduce formal, defined business processes. This all sounds sensible
enough.
Now let’s ask the question
“why do we want to introduce defined processes”? The answer (based on our
experience) is likely to be “so that everyone knows what the proper
procedure is, who’s supposed to do what and we can track what’s going on”.
Again, good sensible stuff.
So what’s the problem ?
Any Process is
Better Than None. Really ?
You may have heard a statement like this “any
process (meaning defined) is better than none”. Well actually, no.
The informal processes in place may be performing poorly but may
still be getting the job done – eventually.
Surprisingly, formal processes
can actually make this unhappy situation worse. Why? It can make
things worse because the exclusive
focus on ‘what the process has to do’ (ie. its functional requirements)
often leads to elaborate, complicated process designs that operate too
slowly or poorly in some other way in the real world. You may well have
witnessed this. A common example of the poor operation in the real world of
a perfectly logical and well-defined process is the frequently disappointing
results from the use of PRINCE2 processes in the management of projects (eg.
UK government IT project failures over many years).
The very real risk for a newly designed process with its newly defined roles and
responsibilities, is that it proves problematic to implement and once
operational, work actually takes
longer because the working relationships which underpinned the previous
informal process have been fractured.
The consequences for the organization
are disruption of its day-to-day work, disenchantment and scepticism with
the improvement efforts, as well as further rework of the process design with its
resultant delays and additional costs.
What's the Real Aim?
So let’s start with a
different, but slightly ‘dumb’ sounding question. The question is “why do you
want your organisation to be more effective”?
This can lead to rather
more fundamental answers such as… "we’re losing customers because we never
meet delivery deadlines" or, "we can’t deliver software on time", or "our system
deployments never go well".
This time, the answers are talking about how well
the organization needs to work. That is, they are highlighting shortcomings
to do with performance. The need is to do
things better. To perform better in some way compared to now.
Now we're on track to
get meaningful answers by asking useful questions like "if our processes
aren't performing well enough at the moment, how well would they have to
perform to meet our real needs"? And then, "how can we meet those needs"?
"What are our options, what would work in the real world and how can we test
our ideas"?
Yes, "we need a defined process" is an
attractive idea. But what's the real problem we're trying to solve? It is,
we would suggest, something to do with how well the process performs or
doesn't for your organisation. What's the real aim?
_________________________________________________ |
