Sometimes the lack of simplicity and clarity in a BPM project can be the thing that creates the highest risks. You would think that it would be simple to clearly define what the scope of a project is by determining the start and end of the processes that relate to the BPM project. The most important word in the title of this Column is “clearly”. Too many BPM activities commence, and continue, without having a clear and agreed definition of when a process starts and ends, and the question is not asked “is this start and end point appropriate for what you are trying to achieve?” as an outcome of the project.
This clarity is particularly important for the following reasons:
- your project scope will change depending upon the start or end points;
you risk attempting to solve the wrong business problem, or not achieving the desired project outcomes; - lack of clarity of the process will make it more difficult to identify hand over, cross-over and process rub points, and maybe the services the process delivers;
- restructuring / redesigning processes is easier if you have a clear understanding of the end to end processes; and
- certainly business analysis is made simpler with clarity.
On a more holistic business level the challenges of not having current and clear end to end processes can include:
- In times of significant business change and volatility, knowledge may be 'walking out the door' as employees depart, particularly if processes are not documented well.
- Changing employee situations often necessitates the need to backfill roles. Even with process documentation there is a ramp up period for any new person to be effective. Without process documentation the ramp up time is considerably longer.
- If your BPM activity encompasses multiple business processes, it is critical you have a clear understanding of how the processes fit together, and identify clearly the hand off points.
- Finding efficiencies in (or leaning) work practices is far easier when an organization has 'as is' processes and can make the journey to the 'to be' leaned processes.
Let's look at a couple of case studies.
Government department: a project in the procurement area was underway and the project sponsor, the Chief Financial Officer (CFO), was not happy with the progress being made. He called in a consultant to replace the project manager (the procurement manager). After several days the new project manager realized that the project scope seemed to be continually changing and this was confusing the project team. Decisions as to what needed to be achieved seemed to be continually changing and evolving.
The project manager decided to meet with the project sponsor (the CFO) to gain additional project clarity because he perceived that the project sponsor did not have clarity around the procurement project start and end points.
The project sponsor was initially annoyed that he was being asked this 'obvious' question, however as the conversation continued he realised why it was important and admitted that he was not sure where the commencement point should be. Further discussion agreed the start and end points.
Once the start and end points were agreed the project started to make significant progress.
On this project, and with the particular stakeholders involved, it was essential to maintain the Decision Register which maintained the decisions made, by whom, dates, the reasons for the decision, as well as other details. Each time the sponsor made a decision that conflicted with previous decisions, the register was referenced. It was the prerogative of the project sponsor to change his mind. It was important for him to understand the consequences and the project impacts. This had the desired result of ensuring the sponsor didn't change his mind too often and allowed the project team to make significant progress and achieve the desired project outcomes.
Energy organization: the project team was asked to look at the Collections process. The KPI for the collection of payments was set at 28 days. The current actual average collection time was 45 days. The project team were asked to look at the collection process and fix it to achieve the KPI target.
After some analysis it was discovered that no matter how much the project team worked on and improved the collections process they would never achieve the KPI target. The problem had nothing to do with the collections process, it was the manual based Meter Reading process that was broken.
The meter reading staff were making mistakes and causing customers to receive incorrect and disproportionately large invoices, for example, up to $7,000 when their normal invoice was $1,000. By the time clients progressed through the complaints process the KPI target was unachievable.
An understanding of the 'true' end-to-end process and an increase in project scope to include the meter reading process fixed the project problems and enabled the achievement of the collection KPI target.
Business Case development: one of the authors became briefly associated with the development of a business case to go to tender for an Enterprise Resource Planning (ERP) system. The project team were mapping the business processes and attributing various metrics to the processes with a view of determining the potential savings associated with a change to a new ERP.
It was found that the project team had no process taxonomy and were indeed mapping various sub-processes with no understanding of how the sub-processes fitted together. This made the metrics analysis and identification of the potential cost savings significantly problematic, thus impacting the quality of the business case for change.
How are these situations avoided?
If an organization has a process asset and an understanding of their process taxonomy then they have a fighting chance of understanding its processes better and an ability to scope projects more effectively.
If the organization doesn't have a process taxonomy then the project team needs to firstly determine the part of the taxonomy effecting the business area they are concerned with. This is an essential scoping exercise before the project commences.
To us, it is a critical aspect of project risk management.
John Jeston & Gina Craig
Latest posts by John Jeston & Gina Craig (see all)
- Down Under: The Internet of Everything and BPM. - October 5, 2015
- Down Under: Processes – the Solution to Resolving an Issue or Dumbing Down Staff? - May 4, 2015
- Down Under: The Importance of Clearly Understanding End-to-End Processes - January 5, 2015
- Down Under: BPM is ALL about People Change Management - November 3, 2014
- Bureaucracy and High Performance - May 5, 2014
“Process taxonomy?” A “taxonomy” is a nomenclature used to assign objects to classifications. Objects themselves are categorized using a taxonomy, but as a set, they do not constitute a taxonomy. I suggest that for a set of processes, we might refer to a “process inventory” and go on to suggest heuristics by which we could make the identification and classification of the processes most useful for process engineering.