(Steps Six of the Cavi Method)
After the Process Analysis and Design stage is complete, (steps four and five of the Cavi Method) you should have a new (“to-be”) process design that follows sound principles, fits within the identified constraints of the 4P analysis, and solves the problem identified during Problem Analysis.
Process enablement is the most difficult step of the entire Method because it involves coordinating physical changes between all the new resource and technology elements called for in your design. Operations can’t just stop while you reconfigure all of these elements, so the work of enabling the new process requires extra energy from staff as they dynamically transition from their as-is process to the to-be process.
This is the last step of the Cavi method:
Getting from design to enablement is effort-intensive, but is made easier by all the work we have done up to this point. Ultimately, you should think of it as a requirements gathering exercise. Requirements management is its own discipline, which I recommend you research on your own if you’re not familiar with it before continuing. You can see Cavi discuss process-based requirements gathering and management in our IIBA live talk on the topic.
In brief, a requirement is NOT a solution, but rather, explains in non-prescriptive language what would be required to satisfy a need in the context of your proposed design. It is always better to design the necessary solutions from the requirements as the detailed project work begins, following, but not during, the initial analysis and design phases. Solutions design is not something to be done at this juncture in the process improvement lifecycle.
Requirements are most often captured in a spreadsheet, and within the Cavi Method, you should organize them directly in accordance with your process maps. By lining up the as-is map and to-be map and tracing step by step what is done currently and what is changing, you have a roadmap to draft all your requirements. Every required change represents an action item, to create whatever is needed to make that change possible.
The types of changes fall into predictable patterns and understanding them will give you confidence when drafting your requirements list:
- Step change – the actual process step is changing (i.e. no longer doing one thing and now doing another). For this change to happen, the requirement is a new detailed procedure. This will usually result in an “action” of building a training guide to clearly explain what changes, why it changed, how to execute the new step, and the success and measurement criteria that will let someone know that it is being done correctly.
- Role change – this is when the same, or a new, step is now being done by a different role (hopefully by a more junior role – our goal is to always move functions to lower cost resources). A role change is either going to come from a simple step having been identified as being done by the wrong role, and writing the new step into their training guide, or capturing new MECE (mutually exclusive and collectively exhaustive) criteria for a decision point and writing that into the training guide as a mechanism to allow this different role to make that decision. (You should consider every decision point on your process map a requirement to ask whether someone more junior can make the decision, given appropriate decision-making criteria.)
- System or technology change – This could be part of changing a step, or more effectively doing the same step, through a change in tools, technology and automated systems. Here, the requirement is to properly configure and to again write up training to make sure the system and staff are ready to adopt the change. New systems require full-on training to implement, and any tasks you make on the task level to extract these instructions should be collated into a formal training to facilitate implementation.
- Sequence, volume, or pacing changes – This won’t be as apparent when looking at the steps on a static map. For these changes, it’s the same as for the others: look at the flow mechanisms that control these elements and make sure there are clear requirements for training or operating documentation written at the appropriate level to explain the changes and enable implementation.
- Team culture or policy changes – These changes will be impacting combinations of steps or the process as a whole, and normally take the form of removing standing meetings, changing email or general communication etiquette, changing reporting schedules, or the like. These are typically one-time action items that need to be written up, trained on, or enabled within the systems as automated forms of control (such as rules on creating and allocating tasks).
This list is not comprehensive but should cover most of what you will encounter in gathering change requirements to enable a newly designed to-be process. Every change should be some combination of the above considerations. All these action items involve carefully documenting requirements, that call for agreed-upon training or criteria to empower employees to easily make changes.
Whether you are combining this documentation into training material, guides, cheat sheets, or technical instructions for IT, all these materials should intuitively distill the elements required. That way, whoever is accountable for the change can digest them and clearly understand how to go from what they are currently doing to what you want them to be doing in the future “to-be” state. All these items could be seen as small projects that need to be done to complete the enablement phase.
Once all your requirements are complete, you have a list of what is needed to get from one phase to another. At this point, all the recommended actions represent project work and you should scope, plan, and schedule the project(s) appropriately within your business context, leveraging good project management principles.
The amount of work can sometimes be overwhelming, so bringing all the requirements into an executive summary or some type of enablement report can go a long way to aligning stakeholders before the work starts. As long as you have strong sponsorship internally and the problem remains relevant, you should be able to push through the project work and successfully transition from the as-is workflow to the to-be workflow. After that, measuring and controlling the process carefully is critical, to ensure that your design was correct and that the problem is solving itself within the new operation. If it looks like you made a design error, you should be able to easily identify the process weakness in the new design and tweak as necessary during the project.
Once the new process is enabled, the process improvement cycle is complete and this brings us to the end of the Cavi Method!
This ends the Cavi Method blog series. I hope that these blog posts have made you feel more empowered to practice process improvement in your own business context. I wish you the best in your future process improvement endeavors. Please comment below or reach out to firstname.lastname@example.org if you have any questions or feedback about your experience applying the Cavi Method – we’d love to hear from you!
Are you enjoying our blog? If so, please subscribe to our mailing list where you will get updates about free and/or beta knowledge products as they become available. Thank you for reading!