Learning Blog

Random despatches from places where L&D meets software and systems

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/37/d420554721/htdocs/makemhome/makemhomenew2/components/com_k2/models/item.php on line 881

Process optimisation, wiki-style

Here we describe the development of a wiki which was designed to break down silos in a large organisation, share best practice and facilitate the standardisation and benchmarking of a large number of complex, end to end processes.

I am indebted to a new friend, Stephen, who, in a training event I attended a little while ago in South Wales, said something like “in spite of what you might think faced with all the books available on leadership, the work we all do on competence frameworks and so on, a lot of what it takes to be a really good leader boils down to just two things: self-awareness and the ability to learn”. Little more than ten seconds’ worth in a whole day of psychometrics, influencing skills and stakeholder management (with a few jaffa cakes thrown in to help us through it all), this was a throw away line that was just too good to throw away. I’ve been thinking about it ever since.

Self-awareness and the ability to learn aren’t just prerequisites for really good leaders though; they’re prerequisites for really good businesses too. To be sustainable and scalable – no mean feat in these hardened yet rapidly changing times – businesses have to know what they’re good at, where there are opportunities for improvement, why they do things the way they do them, and so on. Such is the stuff of self-awareness. And with self-awareness come opportunities to learn and improve.

Going back to the individual just for a second though, in establishing and maintaining social relationships unconsciously we strive to make a good impression, maintain face and do our best to seem coherent. Businesses also need to seem coherent if they are to win and keep clients and customers. This has to be done consciously if they are to appear professional, reliable and consistent. In a particular sense an operating model is an attempt to cohere different parts of the organisation so as to better co-operate in delivering value to clients and customers. Operating models can also lay down standards, principles, ways of working, legislate the degree to which processes can and should be standardised, and so on.

Speaking of standardisation, when you think of the word “process”, what images spring to mind? I can’t predict what you’re visualising but I’ll bet you a penny it isn’t very glamorous or romantic. Imagine my first reaction, then, when I was recently asked to be the business sponsor of something called the “process model”, one of a handful of components of the target operating model our 1000+ FTE part of the business is working toward. Truth to tell, I’ve only been able to stop thinking about barge poles once I’d convinced myself of the potential benefits of having a coherent way of presenting our business to our various stakeholders, ourselves included. Although it’s a lot of work – hence the initial barge pole reaction – the potential upsides include:

  • making perfectly explicit what we’re selling
  • thinking end to end and understanding all the dependencies
  • breaking down silos
  • productising our knowledge to avoid “it’s in her head” syndrome
  • shortening time to deployment by re-using assets and know how, avoiding mistakes and actively discouraging variability
  • shortening time to competence for people new to the job
  • increasing efficiency and effectiveness, reducing costs and, not to be sniffed at, gaining competitive advantage

Having carried out a small amount of desk research into methodologies prescribed by, for example, USMBOK, CMMI and ITIL, we’ve concluded that huge investments are required to do this exhaustively but that a lighter touch approach could still be worth doing. To this end we’ve embarked on a social learning project to capture, standardise and make improvable the different kinds of work that we do. We’ve also realised that this should be done by using a particular kind of wiki, one in which a skeleton framework is carefully curated but our people are encouraged to put their own meat on the bones.

We have started out by assuming five levels of adequacy (or different ways of grading the meat) in our framework. These are as follows:

1)     “Observed”. You can see these processes going on, but you won’t necessarily know who’s doing them, how or why. This uncharted, lowest level will likely feel a bit chaotic and will probably contain gaps, inconsistencies, duplication, bottlenecks, variation in the work and a lot of waste. You can probably see some of these problems but you won’t necessarily know their extent or impact.

2)     “Described” processes are one step up as they are documented as well as observed. This is often done by means of a nested series of maps, one set per process. Level 0 is usually the top level; by the time you get down to level 4 or 5, you’re usually reading work instructions in one form or another. Described processes provide qualitative assurance as to way things are supposed to happen, with different parties’ responsibilities clearly shown sometimes by separating participants into “swim lanes”. Processes that are properly qualitatively described should predict what inputs can and can’t be satisfactorily processed.

3)     “Measured” processes add in quantitative information, annotating process maps with KPIs, cycle and takt times, volumes, capacity and so on. This information is more potent as a well measured process will not only show who’s supposed to be doing what, but how many, how often, how good, and so on.

4)     “Contracted” processes are measured processes that have been iteratively discussed, negotiated and optimised by the various parties so that clients perfectly understand their responsibilities, the services they can reasonably expect if they keep to their side of the bargain, the quality of service levels to be maintained and what contingencies / liability / compensation arrangements are in place should service levels disappoint. This is the stuff of Service Level Agreements.

5)     “Explained” processes are those contracted processes which have been matured to such an extent that they can be said to be predictive. This fifth level is the most potent and is the ultimate but never-ending target level for all processes. This level should be able to tell you what level outputs you should expect from what level inputs: at this level you are likely to see multivariate statistical analysis taking place to establish the relative contribution of different variables upon overall service levels. This should really put you and your client in the driving seat as you should be able to model different what-if scenarios scientifically. Level 5 is the best place to construct future state maps and plan to move from current to future.

We hypothesise that leap frogging levels is not advisable: thus, it’s not a good idea to contract a process before it’s properly measured otherwise arguments will descend into opinions rather than facts. Doubtless you will be aware of measures in your own company which don’t bear too much scrutiny. This could well be because that which is being measured is not properly observed, never mind described. It’s also important to remember that work at all levels can and should be the subject of Continuous Improvement (CI), following on from what I was saying a couple of issues ago on what the business of CI has to say about the business of learning and vice versa.

Interestingly, most companies I guess will operate at different adequacy levels within and across their lines of business. Creatives may be generally less process-ie than techies (“how very dare you!”) but there’s likely to be huge variation within each. The trick is to plan and control which processes need to be taken to what level to maximise the value that can be delivered to the client – bearing in mind, of course, that not everything can nor should be done at once. Ask yourself whether you want to progress up the levels in breadth (“all company functions to reach level 2 by the end of the financial year”) or in depth (“the production function to reach level 3 by the end of the financial year”).

Hopefully this initiative will help to make our business more self-aware and make explicit what can and should be learned around making things better. This is all very aspirational (and learningful) stuff, of course, and we’re only at the very beginning of our (meta-) process. If we get anywhere with this little lot, I’ll describe our progress in another article sometime. And if we don’t, we will write a lessons learned document and you must promise to forget I ever mentioned it.

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/37/d420554721/htdocs/makemhome/makemhomenew2/components/com_k2/templates/default/item.php on line 248
More in this category: Open source road trip »