Does your business process do what it’s supposed to do?
This is a common question for those involved in business process management, and of course there are many existing methodologies designed to address this. Additionally, process improvement can be carried out at both the macro and micro levels. At the macro level, the business develops processes at the organizational level in order to achieve strategic goals. At the micro level, individual teams, departments, or individuals may develop processes (both formal in informal) to help them accomplish their work.
The issue with existing process development and analysis methodology is that it remains relatively waterfall-ish. Define all of the requirements, develop the process, communicate and implement, then occasionally analyze and change (improve) as needed. The cycle time involved with this approach can be considerable, and especially at the formal, macro level, once initiated the process may be particularly challenging to analyze or change.
An iterative approach to process design and management.
What if we considered process design in an adaptive, iterative way?
In other words, design a narrow process around the first, most important requirement, enabling rapid creation and implementation, feedback, and improvement, while developing toward additional requirements.
This serves two important purposes: first, it enables us to rapidly design and implement a process to satisfy the most important business need, while, second, enabling the process manager to receive fast feedback about the usefulness of the process as implemented thus far.
Once the critical first requirement has been met, the process can be adapted through iteration to satisfy additional requirements, again enabling feedback on the utility of the process overall.
Let’s look at an example of process improvement in new hire onboarding.
CDE Company has a challenging and sub-optimal process in place for onboarding new hires. CDE Company knows this because it is the number one pain point new hires relate about their experience joining the company. Let’s help CDE Co. improve their process through the application of Agile practicies – the same ones their Scrum teams are currently using to develop their products (so everyone is already familiar with and can use them!).
Step 1 – for an existing process, conduct a Process Retrospective
Define the goals of the process itself – what is the process supposed to do? “Minimize the amount of time new hires need to get up to speed quickly and become productive.”
Analyze the current process plan (how it is supposed to work). “New hire is welcomed and given a desk; requests are sent to create and activate their email account and grant access to the folders, tools, and utilities which they will need to do their job; new hire is added to email lists, meetings, and taken out to lunch; new hire will work alongside another developer to understand the code base and standard practices, and will be given an overview of the main products on which they’ll be working; new hires begin to work.”
Gather feedback on the actual current process and how it is executed. “New hire is welcomed and requests are sent; email and access to environments/tools takes anywhere from a couple of days to a week; being added to email lists/meetings requires finding the owners and asking to be added individually; buddying with another developer works ok; lunch is always good.”
Identify the lessons from analyzing the current process, the intended plan, and the actual goals. “Onboarding is slower than it should be and we are not achieving the goal of getting new developers up to speed and working quickly; getting email / account / tools / utilities / environments access is too slow and holds developers up; our buddying model works well once the new developer has the access needed; getting the new developer into meetings / email lists is fractured and takes too long.”
Transfer those lessons into a plan of action. “We need to re-prioritize and redesign the process to address the issues found in Lessons Learned. Specifically we need to plan to get access for the new hire on Day 1; we need to have email lists / meetings cleared up prior to Day 1; we should maintain the onboarding buddy system.”
Step 2 – hold a Process Improvement Planning Session
Set a Timebox for this process improvement / development cycle (1 or 2 weeks should generally be enough time – otherwise you’re taking on too much work).
Using the process owner(s) as a sort of Product Owner, determine what the most important requirement(s) of the process is in terms of either the Lessons Transferred from the Retrospective or the needs of the business, team, or individual. “Get the new developer access to email / development tools / environments on Day 1.”
It is important to note that the size / number of planned improvements should be something achievable within the agreed timebox. (Just to re-iterate: 1 improvement implemented is better than 5 improvements “in work”.)
Plan how to achieve the requirement identified, and name an owner. “Develop a consolidated list of tools / utilities / environments and work with infrastructure & engineering leads to create account permissions according to that list for new hires at Day 1 minus 2; on Day 1 minus 1 Operations places the account in a password reset state; on Day 1 new hire completes password reset process and has access to email and all required tools & utilities.”
Step 3 – implement the Plan
The next new hire through the door gets to use the new process.
Step 4 – conduct the next Retrospective and Planning Session
Retrospect and then prioritize any new lessons along with the existing work which is still in the backlog and waiting to be done (such as improving new hires getting added to email lists and meetings). Moving forward to the next planning session, plan improvements for the next highest priority item(s) which can be achieved within the timebox.
An iterative approach to process improvement also provides the opportunity to stop working on process improvements once the process has been improved enough to be generating sufficient utility – regardless of whether every conceived improvement has been implemented.
Although certainly feasible, the majority of business value will likely be derived from implementing a portion of the desired improvements to a process, but not necessarily all. If we can determine that the Pareto principle (80% of the value of our process is delivered by 20% of the features/work) is indeed applicable to our process, then eliminating sub-processes or work not required will further contribute to business capacity by eliminating waste.
Whatever process you’re seeking to implement or improve upon, an Agile approach can help you build and deliver faster and with greater effectiveness. Payroll, feature request intakes, customer polling, software bug remediation, hardware certification, inventory management, data analysis and reporting – it is challenging to think of a single process which couldn’t benefit in some way from utilizing an iterative, Agile approach to design and continuous improvement.