How to Visualize, Measure and Optimize Your Processes

If you are familiar with Value Stream Mapping (vsm) then you know its a macro-level map of the end to end delivery flow of a particular service or product from the beginning until it reaches a customer.  Metric Based Process Mapping (mbpm) on the other hand is a more detailed or micro-level view of how some of the stages or single processes of a vsm deliver value.

These detailed level views show flow and metrics to help provide insights into bottlenecks.

Mbpm is also applicable to any business process and not limited to what happens in the IT department.

Understanding the Map

Let's start with a simple example of a software development flow, generally, in the real world the map should be more granular giving you more detailed steps and roles but for the sake of not overwhelming the reader, let's look at this simplified example:

The maps layout:

• Each actor or role is arranged in a horizontal swim lane.  The roles are the leftmost column (yellow stickies in the above example).
• There is a defined starting point and ending point that should be identified before starting the exercise. In the example above It has a defined start at gathering requirements and defined end with the code delivered in production.
• Each non-actor sticky note (teal in the example above) has a title that corresponds with an event.
• The actor role that owns the work for that event lines up horizontally with the actor sticky
• The events flow from left to right, with the earlier events on the left and later events to the right.
• Events that happen in parallel are lined up vertically.  If there is shared work between roles those should also be separate stickies lined up vertically as well
• Each card contains three metrics:
  • Lead Time (LT): The total amount of time within normal business hours from start to finish it takes to complete the task. This includes any idle time or time waiting on other roles to complete work.
  • Process Time (PT): The total amount of time someone is actively engaged in working on the task.  This is a subset of lead time.
  • Percentage Complete and Accurate (PCA): The percentage of time a task is completed accurately on the first attempt.  This is compounding percentage with earlier dependent steps.

In the example above, we have a software delivery flow that looks like it follows a traditional waterfall pattern of gathering requirements, developing, testing, and deploying code.  Even many agile projects still follow this pattern with shorter time frames (the effectiveness of this flow is a whole other blog post).  

Typically mbpms would go even lower level than the example to help drill down into more granular issues for example instead of saying the developers “implements code,” you could break that down to: 

• Writing unit tests
• Writing implementation code
• Building code
• Deploying code
• Developers integration test
• Peer review
• Fixing identified issues from peer review
• Documentation
• Etc

Finding and Making Improvements

Once you have your map completed, you now have communication tools for the team and stakeholders to absorb.  This map also helps management see the pain points. These costs have a time value and that time value has a cost as these issues continually occur.  If you have a more forward-thinking management then they may be thinking about lost opportunity costs as well. You may have faster-moving competitors generally delivering value faster, possibly cheaper and this is eating into your market share.

Things to look for to make improvements:

• Lead time is much higher than process time, and this may indicate things sitting in queues or waiting on someone else; this typically happens at handoffs.  Is there any way to reduce this waiting time?
• Low percentage complete and accurate, why is it so low?  If the answer is not obvious; this is a great time for a blameless retro with the team, I bet someone has some insights as to why it is happening.
• Unnecessary steps, can you deliver value without a step or a scaled-back step?
• Things that could be automated.  Reducing manual steps can increase speed and accuracy.
• Could changing the order of operations help, maybe completing one step sooner or in parallel improve accuracy?

You may see many problems, and it may be tempting to try to tackle every obvious problem at once but start with the biggest and easiest wins first and prioritize a list of ideas from there.  Remember to be agile about the improvements themselves: focus on small chunks of work to ensure faster delivery of work. Get a fast feedback loop and re-prioritize based on feedback.

Once you make a change, you need to adjust your map accordingly.  You should pay close attention to the metrics, are the metrics improving given the volume of work flowing through?

Back to our example that there was a step that required a change approval board (CAB) to approve changes, but they only met once a week and were slowing down the flow. The board didn’t have enough knowledge to know if a given change was going to cause harm, so they rubber-stamped the change assuming the CAB’s Word doc template was correctly filled out.  In this example, they decided to eliminate the CAB. In addition, the developer and ops team implemented a continuous delivery pipeline that could accurately deploy code to production. They still restrict the prod deployment button to Ops, however. This pipeline also reduced the need to document the deployment procedure in the CAB Word document as the instructions are now pipeline code and configuration checked into source control. In addition it is now peer-reviewed using source tools and techniques which work better for technical reviews than those provided by microsoft word.  The peer review has given valuable feedback on the procedure and caught errors. The peers have proven to deliver much more valuable feedback than the CAB since the peers are closer to the work and have a working knowledge of the pipeline. The peers also are much more available, and you don’t need to wait for the weekly meeting, so wait times have been dramatically reduced. The deployment accuracy has increased since human error only comes in the forms of bad instructions (bugs) now instead of both bad instructions and missed execution of the instructions.

If you have an improvement like that, the example would then be updated to something like this:

Improving through Iteration

A tool like this should not be a one and done type of improvement.  It needs to be an iterative endeavor where you make constant improvements.  Your map should be wall art (if you have a physically co-located team) that is living and changing as you improve. It's there to remind and inspire future improvements.  It's also great for onboarding new team members as you can show them how the process works visually.

In our example, perhaps there is an additional improvement that could be around testing, so maybe the next step might be some sort of test automation.

As you tackle the obvious issues and implement more modern industry practices, you may find yourself getting to a point where the improvements are not as obvious or even questionable.  Here is where metrics can help inform you if your changes make you faster. However, in order to figure this out, you need to experiment. Technically when you were knocking out the obvious changes early on, you were experimenting, but given these had such a high chance of succeeding it may not have seemed like an experiment.  As you move on to the less obvious changes you may get it wrong and implement something slower based on your metrics. This is okay, you are learning (the top performers are always learning), just stop and reflect. This is a good place for a retro. Maybe you can change the idea or perhaps you need to roll back that change and try something completely new.

I like to think about improvements through automation in layers.  If you are in an IT department of a non-tech company, the department was likely founded to automate business processes in the industry you are serving.  However over time, the IT department itself needed to be automated to deliver faster business process automation. This is the second layer of improvement.  Within this second layer, you could bring in a tool like mbpm to help identify areas within the IT department that can be improved. You may end up with common industry solutions like automated testing and CI/CD pipelines for instance. You can take the automation even further, you may quickly realize you need automation around the area of metrics collection.  Manual mbpm metrics collection can be time-consuming, repetitive and have human errors. In order to speed up the feedback loop and free people up for other work you may want to automate the collection of metrics.

Of course, all this automation work comes at a cost but also can have benefits, and that is why metrics are so important to help inform you if the benefits are worth the costs.  Also you should not wait until you have metric collection automated before you even start using mbpm. Start simple, understand the process and what information you want to collect first, then automate once you get your rhythm going.

Logistics and considerations when running a mapping exercise for the first time

Here are some logistics to consider when getting started with a physically co-located team:

• Get a cross-functional team together for this exercise, at least a lead from each major role you expect to cover. Get middle managers involved as well as they often have a great view of the flow at this level. Project managers can also be very useful to help gather metrics.
• Find a room with some continuous wall space.
• Bring: butcher paper or a wide roll of paper to act as a backing so you can move this easily when you are done, especially if this is a temporary room, like a conference room. Scissors are also useful.
• Other supplies: sticky notes bring a variety of colors, use the colors consistently for different types of notes.  Bring painters tape, it's usually the easiest on the walls and don't forget the sharpies.
• Be prepared for this to last a half day to 2 days for more complicated processes. It's important that different roles are in attendance most of the time.
• If you have a part-time co-located team do this exercise at a time when the team is physically present together.
• Short of some miraculous software coming onto the market, try not to spend too much time capturing this digitally in your first meeting, spend time focusing on the task using sticky notes and go with the path of least resistance for recording the outcome.
• The one exception to the digital capture on the first meeting is when you have a full-time distributed team, it will take a little more time this way, but everyone will see it come together.
• Pick a facilitator to lead the discussion, place the stickies, and keep the group focused.
• Work on start and endpoints of the map first, actors and flow second, and metrics third.
• Focus on the current state as you build out the map.  Any insights into improvements should be discussed when the map is complete.
• Any participant should feel able to speak up at any time and contribute throughout the exercise. 
• Go detailed, more than in my simplistic example, this will give you more detailed insights.

Video

Steve Briand and I did a Whiteboard video that inspired this post:

http://www.youtube.com/watch?v=g1XSbEwR3bU

Other Resources

Open Practice Library: https://openpracticelibrary.com/practice/vsm-and-mbpm/

Karen Martin’s Presentation: https://vimeo.com/149407030

Accelerate Book

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Understand the value of Red Hat Certified Professionals