When you work in an internal product setting, you’ll often get the opportunity to revisit existing business processes and look for ways to make them more effective. This usually involves finding ways to improve the interactions your customers have with those processes and automating some or all of the process.
Some times that work is considered part of a digital transformation.
Whether you call it that or not is not necessarily important. The key is to approach the work in a way that allows you to improve the business process in a way that allows you to deliver more value to your customers.
Here’s how you can use some techniques described previously on KBP.media to improve business processes in a way that adds value to your customers and streamlines the business process for your organization.
These techniques help you to build a shared understanding about what you’re trying to accomplish and the business process itself. Once you understand that, you can work collaboratively to identify areas for improvement in the business process.
Identify a metric to determine impact
When you want to improve a business process, you should start with defining what “improve” means.
How will you know that the business process is better? You could view improving a business process to mean that the process is more efficient or less expensive, but that is a short sighted view.
You don’t want to make your business process so efficient and inexpensive that you place the entire burden of activity on your customer. If you’ve ever fallen into an endless phone tree loop or been lost in a poorly designed online request form you’ll know what I’m talking about.
An improved business process is one that provides more value to your customers. To know that you’re actually doing that, it can help to have some way to measure success.
You need an outcome based metric. Ideally that metric represents a meaningful impact for your customers that aligns with how your organization wants to operate.
Some situations lend themselves to outcome based metrics more so than others, but it’s always worth trying to identify an outcome based metric. When you have a metric you can measure frequently, you can get guidance on whether the changes you’re making are having the intended impact.
At the Agile Alliance one example of an outcome based metric may be the amount of time it takes for someone who submits a conference session proposal to get helpful feedback. A unique aspect of the submission process for Agile Alliance conferences is that the team selecting the sessions for a conference provide feedback to submitters and provide them an opportunity to revise their session proposal. This feedback process is only valuable for the submitter if they get timely, helpful feedback that they can react to.
So if the program team wanted to improve the feedback process and determine that timely feedback is an indication of a good process, they could establish the following outcome based metric:
| Name | Session Feedback Percentage |
| Units | The percentage of sessions submitted that receive feedback within 48 hours of requesting feedback |
| Method | (Count of sessions where feedback was posted within 48 hours of submitter requesting feedback/total count of sessions) |
| Target | 90% |
| Constraint | 65% |
| Baseline | 65% |
If the program team decides that actionable feedback is another important aspect of a good business process, they may also decide to track the percentage of feedback that the submitter marks as helpful.
Map the Business Process As it Currently Exists
Once you have a shared understanding about what it means to improve the business process and have a way to know if your actions are actually improving it, you can then make sure everyone agrees what the process looks like currently.
You want to collaboratively create a process model with the right group of people. In the case of the feedback process that group might include a few members of the program team that play different roles (program chair, track chair, reviewer, and submitter) as well as the product team.
In an ideal world, you’re able to do this discussion at a whiteboard so you can use sticky notes and whiteboard markers to model out the process, but you may have to do it remotely, in which case it’s helpful to find a modeling tool such as Lucidchart or Visio.
Be explicit about the process you’re trying to improve and where it begins and ends. In the case of the feedback process, the program team may say the process starts when someone asks for feedback on a session proposal, and the process ends when someone on the program team provides feedback in the submission system.
Chose the most common path through the process and identify the actions and decisions that occur. Use sticky notes to represent the actions and decisions and connect those sticky notes with arrows drawn with whiteboard markers. The feedback process is quite straightforward in terms of specific actions. A submitter asks for feedback, appropriate members of the program team get notified, and then one (or more) program team members go to the session proposal and provide feedback. This simple flow provides a good basis to have discussions about variations that might happen.
Once you’ve walked through the most common scenario, identify other scenarios to walk through the process and make adjustments to the process model based on those new scenarios. Usually different scenarios drive new decision points, or additional paths off existing decisions. In the case of the feedback process the program team may discuss different ways that program team determines who provides feedback. For example should only one person provide feedback initially, or can multiple people jump in.
Select a couple of examples to walk through the process. These examples may represent one of the scenarios you had already identified, or they may represent slight variations. With the feedback process you may walk an actual example where only one person provides feedback and when multiple people provide feedback.
When you feel like you’ve captured the current state, take a picture of the process model, but wherever possible try to keep the original. It will be useful for the next step where you start to identify improvements.
Identify opportunities for improvement
Once you’ve identified the current state, you’re now ready to identify opportunities for improvement. Give the people involved with your discussion different colored sticky notes than what you used to map the process out originally. Ask them to identify all the opportunities for improvement on the business process, note those ideas on the sticky notes and place them at the appropriate place on the process model. These sticky notes represent potential product backlog items.
In the case of the feedback process, the program team may identify different ways to notify program team members, or they may identify changes in how they use the submission system that do not require any software changes, such as a commitment to check the submission system once a day.
Once your team has identified potential backlog items, ask the team to walk the model and see if there’s anything they think is missing, if there appears to be duplicates or if they have questions on anything. Have the appropriate discussions and add backlog items that seem to be missing and consolidate duplicates.
When you feel you’ve identified the relevant product backlog items, guide a conversation to prioritize the product backlog items. You may choose to do this via dot voting or by discussing the potential items in comparison to each other. This step allows you to focus on only the backlog items that are essential to accomplishing your desired outcome.
Implement and measure
Select a particular product backlog item, deliver that item give it enough time to have some effect and then compare the current value of the metric with your target and constraint. Did you reach your target? Then you can stop working on that particular business process and move to something else.
Did you make progress toward the target, but didn’t reach it? Identify the next possible solution you could try in addition to the one you just delivered.
Did you hit the constraint level? Back out the solution you just tried and try something else, or stop work on the effort.
For example in the feedback process the team may determine that the notification emails get lost in their email boxes so they want notifications to go to the team Slack Workspace. The product team makes the appropriate changes, and then the program team tries it out for a week, noting the Session Feedback Percentage right before the change was deployed and a week later. They note that the Session Feedback Percentage went from 65% to 70%. The program team could conclude that the changed helped, but other changes are needed. Those changes could be further code changes, or the team could look at their work practices and decide if there is something they could change in those.
How have you improved business processes
The approach I described above involved setting a target, understanding your current state, identifying possible changes to a future state, making one of those changes and then measuring the result. I’ve found it to work fairly well when you want to improve a business process, but aren’t quite sure of the best way. What approaches have you found helpful for improving business processes? Leave your thoughts in the comments.
Jeffrey says
April 27, 2019 at 3:14 PMHey, Kent. Great post, like usual.
I love this method and I’ve been using it for years. And to be honest, I sometimes skip or change the “Constraint.” This particular part of the metric is the fuzziest part of the metric for me. Can you give us some more depth about this area?
Also, what about timelines? As in, how long should it take to make this improvement? How do you ensure you are making progress in a timely manner? Where do you like to see them included within the outcome based metric?
Kent McDonald says
April 27, 2019 at 4:48 PMHi Jeffrey,
Thanks for your comment and glad you like the post.
The constraint is a value of the outcome based metric that you’re trying to avoid. If you end up hitting the constraint value, that may be a signal that you should back out whatever change you did, or it may be a signal that you need to completely rethink your approach.
The value of the constraint will vary depending on the nature of the metric and the situation in which you work. The constraint may be equal to the baseline, which means that you want to see a change in the metric but you don’t want to get worse than the current baseline.
The constraint may be between the baseline and target which means you want to see some change in the baseline in order to not consider your effort a failure.
In a case where you want the metric to increase from baseline to target, your constraint may be less than the baseline which indicates that you’re willing to see a decrease in the metric temporarily as you explore different options to eventually get to the target.
There is no one specific timeline that’s appropriate for every metric, but it is helpful to establish a timeline when you set your target and the other aspects of the metric. Generally thinking, I think it’s best to try and get to the change you’re seeking sooner rather than later, but you will most likely need some time to implement a change in order to see any results. Balance that out with striving toward as short a feedback cycle as possible.
So ideally you can get to the position where you’re able to introduce small changes on a frequent basis (in the form of days or weeks rather than months or years) and then measure the results after every change you introduce.
I probably should adjust the format I use to record that information to include a timeframe – good catch.