Good process modelling can have a massive positive impact in almost any project so why is it a corner often cut and what are the tips and tricks to good process modelling?
Process modelling as a discipline has been around for decades in various forms. Grady Booch, Ivar Jacobson, and James Rumbaugh created the Unified Modeling Language (UML) in 1995 while working at Rational software. UML includes a number of ‘behavioural diagram’ notation types including Activity Diagrams and at it’s core, UML has always been more suited to developing IT systems and less suited to improving processes.
Business Process Modelling Notation (BPMN) was designed to be a more holistic process modelling notation, usable for both business and IT processes. The original BPMN notation guide (version 1.0) was released in 2004. It has continued to evolve and now BPMN 2.0 is the de facto standard for process modelling.
They say a picture tells a thousand words and, regardless of what notation is adopted, it’s important to keep in mind the purpose of any such modelling. Namely, process modelling is a means of communication. It’s a way to describe either ‘as is’ or ‘to be’ processes in a manner that brings people together into a common understanding.
If your communication is not being understood and there’s a failure to achieve common understanding then rigid adherence to a particular notation is not a cogent defence. This doesn’t necessarily mean ‘dumbing down’ diagrams but it should prompt some introspection as to whether there’s more attention being paid to the form of communication rather than the substance.
Some of the most common pitfalls we see around process modelling are:
| Ignoring process modelling altogether |
It’s unfortunately all too common for process modelling to be skipped during a project. Maybe there’s an assumption that the ‘as is’ process is so well understood, it doesn’t need to be documented. Or, maybe there’s the view that there are too many unknowns and so ‘to be’ modelling is considered impossible. Or it’s not a requirement of the project. The danger here is that we end up with a system that doesn’t ‘fit’ in with existing processes and/or the business is unclear what changes to processes are required. |
| Down the rabbit hole |
We’ve probably all seen these process flow diagrams at one point or another in our professional lives – diagrams that end up a sea of intricate symbols covering multiple A3 pages. Perhaps the person compiling the diagrams didn’t know where to stop, ended up straying into processes that are irrelevant to the project or diving into intricate but unnecessary detail. Whilst technically correct they end up being far too complex for most people to read or understand and therefore the massive effort to create them is wasted. |
| Paying ‘lip service’ |
Perhaps the opposite problem from above, this is where process modelling is only covered in the most cursory sense. Perhaps a high-level to-be process flow map only. Or one which is an aspirational to-be model that doesn’t ‘fit in’ with other existing processes within the organisation. Another version of this problem is not sharing process flow diagrams and/or ensuring all necessary stakeholders understand and agree on the process flows. |
How often have you come close to the end of a project, the system has been built and perhaps the features within the system tested but, on exposure to real end-users, it’s discovered that some of the features built aren’t required or can’t be used because they don’t fit business processes? Or worse, there are business processes that weren’t considered which means there are features or interfaces that are required and have been missed?
From a change management perspective, missing or poor process flow modelling presents a poor message to end users whose uptake is critical to project success. The message implied is that it’s not worth trying to understand their current processes and/or there is no concern for how future processes might adversely affect performance.
Our top 5 tips around process modelling to ensure successful delivery of change initiatives are:
| Include it | Ensure time and funds are included in the project budget for process mapping. Check whether any process documentation exists for as-is processes. If not, consider including some as-is as well as to-be process modelling as part of the scope of the project. |
| Know your audience | Take the time to understand who you will need to talk to for process modelling, what experience they’ve had with it before, what style of diagrams they may be used to and perhaps if there are tools within the organisation for creating and storing such modelling. This doesn’t necessarily mean you need to adhere to previous modelling notation but if the audience isn’t used to BPMN (for instance) then some measure of education might be required. |
| Just enough detail | During process modelling make sure the work-in-progress models are being reviewed. Not just by stakeholders but it might be an idea for an arms-length independent reviewer to make sure modelling is being done at an appropriate level of detail. For instance, a Business Analyst not involved in the project. |
| Communicate | There is little point a Business Analyst shutting themselves away for weeks on end creating magnificent process models if they are not going to be shared and understood by a wide audience. This should include not just the people involved in explaining the processes but senior stakeholders who often may have limited insight into some of the processes taking place. |
| Storage post project | All too often the great work done creating process models is lost within labyrinthine ‘knowledge repository’ systems within an organisation. Perhaps they are stored on a project site but that site is inaccessible to future users within the business. Find out where all as-is process models are kept. If there isn’t such a place, discuss with senior stakeholders how you could start one. |
There’s a bit of an art to good process modelling but, done right, it can be an invaluable tool to ensure project success. It can also be an asset that continues to provide an organisation value long after the project is delivered.
