Calculating the ROI of Flow Engineering

This post is adapted from the book Flow Engineering: From Value Stream Mapping to Effective Action by Steve Pereira and Andrew Davis.

If you don’t currently have clear performance data on your workflow, a clear picture of what it looks like, and a clear path to better, wouldn’t you like to have that ASAP?

Let’s say after mapping using the techniques from Flow Engineering you identify three high-priority, relatively simple improvements to implement right away. It will likely take at least three months to see measurable progress. Then, with three more months of progress and operation, you’ll have enough data and experience with the current state that you can map it again and look to a new outcome. In six months, you’ll have made enough progress that you’ll have a new desired outcome and will have found new bottlenecks to identify and tackle.

In practice, Outcome Mapping requires at least one two-hour session to go from scratch to a fully formed map ready for action. We can see in the figure above a very extensive Outcome Map, which covers goals and pains, values and principles, prioritization, and experiment definition. As you go from the raw input toward insight, you can rearrange the maps as you like and easily export them to be shared throughout the organization.

Since knowledge work is increasingly done across time zones rather than shared offices, collaborative online mapping has moved from a bonus to a necessity. With Flow Engineering we’re concerned with improving the flow of work in the next three to six months within a specific value stream. Our aim is to not only improve operations but outcomes. Common desired outcomes we’ve seen in Flow Engineering efforts with clients and partners include:

• Deliver software three times more often.
• Deploy changes to test environments ten times faster.
• Recover from production issues five times faster.
• Reduce production defects by half.
• Reduce variability by half.

One reason that teams (especially remote teams) may hesitate to carve out time for a mapping exercise is that they are afraid to set aside or request sufficient time for the teams to meet. This is a perfect example of false economies, and we need to counter that tendency clearly. 

The highest-paid members of any organization are the executive leadership team. But those are also often the teams that most regularly have long team off-sites for thinking and planning and multi-hour meetings each week to plan and strategize. Thinking takes time. Communication takes time. Time costs money. But the cost of inadequate thinking and communication vastly outweighs the up-front cost of thinking correctly from the outset.

The amount of time, money, energy, and goodwill that are burned through ineffective organizational activity is certainly hundreds of billions, if not trillions, of dollars globally. This effect is often described as expending organizational energy as heat instead of as work. Terms like “thrashing” are also used to describe the activity of staying busy without having an optimal impact. 

A perfect example of thrashing is people whose calendars are filled with thirty-minute meetings pertaining to a huge number of parallel initiatives. Such meetings leave little time to accomplish real work, and even with buffer time, it takes an average of twenty-three minutes and fifteen seconds to effectively “get back to work.” Parallel projects invariably drag on for far longer and yield far lower quality than selectively taking up projects and completing them as quickly as possible before taking on new work.

We can estimate direct and indirect costs of a member in an IT organization being brought into a meeting at $125 an hour (opportunity cost could be higher). For the mapping exercises described in this book, it’s reasonable that they might involve eight people each. Some exercises, like Dependency Mapping, may not be required depending on what’s discovered in the earlier stages. This allows us to estimate a cost of $1,000 per hour of Flow Engineering exercises. 

To estimate the benefits, we can imagine that we are influencing the activities of twenty knowledge workers who are each doing work valued at $200,000 per year (value delivered should be greater than salaries paid). Our goals in Flow Engineering are to help the team increase their throughput, improve quality, reduce attrition by increasing job satisfaction, and reduce the chances of a project being unsuccessful. Assuming they are all working full time, that team should be bringing $4 million of value per year. 

Table: Estimated Costs of Flow Engineering Exercises

If we can help the team to increase their throughput by 20% (the common average improvement impact delivered by mapping), that $18,000 investment brings an equivalent of $800,000 benefit per year. Similarly, if we can prevent 20% of their work from being wasted or ineffective, that’s worth $800,000 per year. Reducing attrition also brings financial benefits by averting the need to rehire, retrain, and burden the team with disruption.

That back-of-the-envelope estimate shows a 44x benefit from these activities. This cost accounting approach is obviously an oversimplification, but it can be a useful way to illustrate the cost benefit. What’s also notable is that improvement in one stream is typically replicable across multiple streams, magnifying the impact for far less investment. Even if the costs were scaled by several times or the benefits reduced significantly, this represents a remarkably positive effect from investing this time.

- About The Authors

Steve Pereira

Steve Pereira has spent over two decades improving the flow of work across organizations. He’s worked through tech support, IT management, build and release engineering, and as a founding CTO for enterprise SaaS. He serves as lead consultant for Visible Value Stream Consulting, as a board advisor to the Value Stream Management Consortium, Chair of the OASIS Value Stream Management Interoperability technical committee, and co-founder of the Flow Collective to bring flow-focused professionals together. Since 2017, he has been developing and facilitating Flow Engineering to make flow improvement in large organizations accessible, collaborative, and actionable.

Follow Steve on Social Media

• 
• 

Andrew Davis

Andrew is Chief Product Officer at AutoRABIT, focused on the next generation of DevSecOps on the Salesforce platform. He is also the author of the leading book on the Salesforce development lifecycle, Mastering Salesforce DevOps. He was formerly Senior Director of Methodology and Training at Copado.

Follow Andrew on Social Media

• 
•