We have all been there – your organizational change project has finally gained traction, the “nay-sayers” have quieted and the organization is beginning to actually use the new workflows for the major business processes. There are rumors of accolades and awards and you are actually thinking that you may be able to take some well-deserved time off – maybe even really go somewhere. Visions of palm trees and grass skirts fill your mind as you explore the possibilities. That is, until the phone rings.
On the other end is a user that is complaining of tasks that are not included in the workflow and how these missing tasks are significantly impacting the processing of work through the organization using your workflow. How can this be? The workflows were designed with care and you made sure that EVERYONE was in agreement that the processes addressed all the needs of the business. But before you start poring over old status reports and e-mail to verify that you had not missed anything, let me remind you of the one ultimate business truth…
Business changes – constantly.
The best-designed processes will fall out of synch with business – be it because of new product offerings, new technologies or new methods of performing the work. Soon after a new workflow is implemented, changes within the organization will necessitate changes to the business process workflow. This is the reason that I stress the importance of implementing process change using a workflow management system (see Operational Maturity – One step at a time). To many executives, process documentation is considered “shelf-ware” that provides little to no value to the organization. But by instantiating the business process into a workflow management system, the organization is forced to use the process. And once the process is actually being used, the process documentation becomes a useful reference for the overall process flow. Change is inevitable and you should always develop a change process as part of any organizational change project. This change process includes not only the identification and qualification of the change, but also includes the oversight and governance bodies that are needed to balance the need for change against the disruption of the business.
But as anyone who has had any exposure to ITIL or other process frameworks has noticed, Change alone does not meet the business need for process change – it is ALWAYS bundled or “joined at the hip” with Release. Change and Release share the responsibility for process change – Change identifies the NEED and JUSTIFICATION for a change, as well as the identification of the STAKEHOLDERS and PRIORITY of the change within the business, while Release manages the PACKAGING of the change, the IMPACT of the change on the overall business and the COORDINATION of the change implementation into the production environment.