How to eat an elephant
The start to end of a process involves breaking it down into sub-processes, and digesting it one bite at a time.
When mapping out a process, a common oversight made by many professionals is the sheer ambition of it! Quite a statement... but let me explain.
Often, a singular process can be so big and complex that the mere thought of documenting it can be daunting, let alone using such a document for other objectives, like GAP analysis or the basis of an automation project.
The other massive caveat to approaching a large process all at once is, more often than not, the end never truly comes to pass. Mostly, there will be a grey area, and if the defining never stops, there will be an inability to move past the initial phase.
How do project teams start and finish a process, then? The answer is actually very simple: sub-processes.
When dealing with a difficult customer, or being the difficult customer, it can be agreed that an effective process is one that is clearly defined, with no grey areas, and which caters for all possible variables and deviances.
The only way for mere mortals to achieve such mastery is by splitting the proverbial monster into smaller ones that can be defeated. Enter the sub-process.
By splitting up the process, the project manager is not only getting a better idea of 'what' the process is, s/he also starts to form a structure that can be used for planning. Typically, this will take the shape of an overarching process, or skeleton - with other processes forming the body to flesh it out.
Following this structure allows the project manager to identify key areas that need to be planned first. In addition, and perhaps more importantly, it also ensures an end that can be worked towards. If the project manager's focus is on a singular part of the big process, there will be an end that can be defined.
As with any process, inputs and outputs are needed. At the sub-process level, this actually helps to eliminate grey areas because each sub-process needs something out of the one before it in order to function.
Many companies today implement processes in chunks.
Above all these sub-processes, a wireframe offers a bird's eye view of where the process starts and ends.
Bringing it together
So, now there is the method, how does this actually all get going?
Communication is critical to the success of any undertaking, and unsurprisingly, key to making decisions when defining a process.
Once everyone is on board with splitting up the process into smaller processes, the next big step is deciding which parts are more important than others.
These chunks are handled in phases, at the end of which the project manager will either review or implement, depending on the end goal of defining the process in the first place.
Many companies today implement processes in chunks. There should still be a business benefit even with just a part of an automation project being in place, not so?
Again, this highlights the need for communication, as the chunks must be grouped together in a way that makes sense, especially if the intention is to use a completed piece while working on the others.
An added benefit will be lessons learnt from partial implementations, allowing even better definition of the parts to follow.
The result, in the end, is what the project manager has been aiming for all along: the massive monster of a process, with a clearly defined start and end, no grey areas, and able to cater for variables and deviances.
More than the sum of its parts
As the cheesy television sales ad would say: "But wait, there's more!"
Now that this process has been conquered, there is likely to be more to define, but suddenly, there's a whole toolbox of already defined processes, each with their own inputs and outputs, ready to be re-used.
These smaller processes, with a more singular purpose, can often be re-used in other processes, sometimes as is, sometimes with minor tweaks.
It is important to hold onto these. In the long run, the time to deliver can decrease dramatically if portions of a big process are defined before starting. This is even truer if the intention is to automate.
Take a finance approval process, for example. It is essentially the same process no matter where it is used. How great would it be to just 'drag and drop' the finance approval sub-process whenever a new process required it?
My next Industry Insight will focus on the return of processes.