Process Mapping Alone Is Not Enough
Many organisations go through the pain of process improvement exercises – devoting resources to running workshops and mapping processes – but they do not complete the exercise properly and so do not achieve desired outcomes as a result.
Usually this means that more efficient processes do not get implemented. Sometimes organisations veer to the other extreme and in their enthusiasm create processes which are too restrictive for the target end-users (especially in professional service organisations).
Ultimately this is due to a failure to recognize that process improvement exercises should be run as projects, with someone acting as a project manager and being responsible for ensuring the right kind of processes are created and put into practice.
In my experience the real benefits of process improvement exercises are usually achieved through the implementation of workflow software. Yes, improving existing procedures without new or upgraded software can result in some performance gains, but this often needs people to change their behaviour – and usually people will fall back to the comfort of old ways if given a chance. Changing how procedures are executed, by using new or upgraded software, reduces the need for people to change existing behaviours as there is now less familiarity for people to fall back to.
Law Firm - national size and reputation
In retrospect, the problem with this project was that the project brief had changed, but this was not communicated to the process mapping and workflow development teams. Originally the idea was to create very detailed process maps and implement them into workflow software so that junior staff could do much more of the day to day work.
The new processes were mapped onto new workflow software. The initial release was successful technically, but less so culturally. The firm concerned had not recruited sufficient numbers of juniors and had not re-calibrated its staffing structure. As a result, experienced staff were being ‘told’ what to do by the workflow every step of the way. Needless to say, this did not go down well. Moreover it soon transpired that the firm had abandoned its idea of re-configuring its staffing.
Phase two of the project therefore became one of making the workflow better suited to the organisation. To do this I translated business requirements into new development priorities, created revised business and system specifications, managed development team project work schedules and acted as the lead interface between the workflow development department and the business.
I organised the controlled re-development and re-release of the workflow software – updates were issued at regular intervals. I also made a sustained effort to improve the relationship between the professional services organisation and its software suppliers (this relationship had suffered given how version 1.0 of the workflow deployment had been received).
By the time I left the project, the workflow was much easier for staff to use, more relevant to their daily work and all technical development activity was fully documented.