Software Development, Technology and Innovation

Controlling Processes vs. Facilitating Outcomes

I wonder how many people in the workforce know the difference between controlling processes and facilitating outcomes. My guess would be not many. If you look at how people are introduced to a role today they tend to be given a walkthrough of the processes that they have to follow to get their job done – the outcome might be mentioned but the important thing is “the process” – you know, that thing between you and the outcome.

Let us imagine that we have the following grid which represents the start of a process, and he outcome, along with some intermediate steps.

The steps in the process have been wired up such that each piece is executed sequentially, even though it is possible that some of those steps dont need to performed – the have just “always been done that way”.

Along comes your impatient person and identifies that they can have the outcome that they want just by bypassing the other steps in the proces – they are outcome focused.

The problem with being outcome focused is that process steps can sometimes produce outcomes in their own right. For example – lets say that I have just gone out and purchased a laptop outside of the standard corporate procurement process and have expensed the device. The problem is that the standard procurement process included steps to notify the accounting department that we now have a new asset.

So – who is right? The process controller (procurement officer), or the outcome facilitator (the person with the credit card). You will probably never get agreement on which way is best but what is for certain is that there is a perception that “the process” is too slow and long winded.

What if it was possible to optimised the process? Over years of operation many processes explicit steps which are no longer required, yet the people executing the process don’t know that (especially common where there is no feedback mechanism). Through a process of continual refinement it may be possible to eliminate uncessary steps in the process.

One way to do this is to be explicit about the outcome that each step involves. For example – if we take the ficticious laptop procurement process we could spell it out like this.

Identify laptop the purchase, this ensures that you are getting the laptop that meets your requirements.

Send laptop cart to procurement officer who will then check the order for minimum specifications and make the purchase on the corporate card, this means you don’t have to use your own credit card.

When the laptop is received send the serial numbers to the accounting department. This will allow them to depreciate the asset over time and arrange any necessary insurances.

Enjoy your new laptop!

I think that this helps everyone because unless you can explain why a particular step in the process is performed and what value it adds then it is a candidate for being dropped.

Now – with systems like SharePoint 2007 natively supporting Workflow we need to be careful not to turn the entry points into our processes into a black hole. A workflow should be as transparent as possible so that when someone kicks it off they know when to expect a result and what they can do if they need to try and make it go faster.