Flow Engineering: A Practitioner's Guide to Closing the On-Ramp Gap
- 4 days ago
- 23 min read
By Allan Ung | Founder & Principal Consultant, Operational Excellence Consulting (OEC)
Published: 13 August 2026
Allan Ung is the Founder and Principal Consultant of Operational Excellence Consulting (OEC), a Singapore-based management training and consulting firm established in 2009. With over 30 years of experience deploying Value Stream Mapping and Lean systems across manufacturing and — through senior roles at IBM, Microsoft, and Underwriters Laboratories (UL) — complex digital and knowledge-work delivery organisations, Allan has facilitated VSM and Lean Thinking programmes for organisations including the Ministry of Social & Family Development, IBM Japan, IBM Singapore, Microsoft, Underwriters Laboratories (UL), Micron, Panasonic, Tokyo Electron, and Temasek Polytechnic.
He holds a Bachelor of Engineering (Mechanical) from the National University of Singapore and completed advanced consultancy training in Japan as a Colombo Plan Scholar. Allan is a Certified Management Consultant (Japan), a Certified Lean Six Sigma Black Belt, and an accredited TPM Instructor.
Flow Engineering is the lightweight, five-map system that lets digital and knowledge-work teams do what Value Stream Mapping has always promised — see the work, find the constraint, and act — without a black belt or a facilitator who has spent a decade in ISO-standard VSM notation.
A single billing checkbox. That was the whole feature. It needed to fire an API call so the company could resell a partner's service — a change that, on paper, looked like an afternoon's work for one developer. By the time it shipped, it had touched product, engineering, billing, legal, compliance, and marketing, duplicated across two lines of business and three channels each. Sixty-plus teams. Twelve months from conception to done. Twenty-eight million dollars. Nobody set out to spend that. Nobody could see the scope until it was already spent.
I have run Value Stream Mapping sessions for more than three decades, across manufacturing floors and, in my years at IBM and Microsoft, across exactly the kind of sprawling digital delivery organisations where checkbox-shaped disasters like this one live. The uncomfortable truth in that case — documented by Steve Pereira and Andrew Davis in Flow Engineering: From Value Stream Mapping to Effective Action (IT Revolution Press, 2024), the source text behind this guide — is not that the checkbox was hard. It's that the coordination overhead was invisible until someone finally mapped it. Nobody could challenge a scope nobody could see.
This is the argument at the centre of Flow Engineering, and it is the reason OEC now teaches it as a companion to our long-standing Value Stream Mapping programme rather than a competitor to it. Most digital and service organisations treat traditional VSM as a manufacturing tool — too heavy, too symbol-laden, too dependent on a facilitator with years of Lean training to run credibly. So they don't run it. They stay in the fog, "too busy to improve," while checkbox-sized decisions quietly become eight-figure ones. Flow Engineering exists to close that specific gap — what Pereira and Davis call the on-ramp gap — and this guide walks through the full system: why scale breaks teams in the first place, the five maps that rebuild value, clarity, and flow, the mistakes that derail most first attempts, and how the practice scales from one team's pilot to an organisation-wide capability. If you've already read my companion piece on classic Value Stream Mapping, think of this as the sibling discipline built for the teams that VSM, in its traditional form, never quite reached.
🛠️ Run Your First Flow Engineering Session This Month The full 160+ slide facilitation-ready deck behind this guide — five map templates, the facilitator's rules of engagement, timing benchmarks for every session, and the complete case study library, including the $20M redirect and the Bolt Global worked example referenced below. 👉 Download the Flow Engineering Training Presentation & Practitioner Toolkit Here |
The On-Ramp Gap: Why "We're Not Ready for VSM" Is Costing You Millions
Organisations scale for good reasons. Every doubling in size buys roughly ten percent more efficiency, a relationship Geoffrey West's research on urban and organisational scaling laws has documented consistently. Scale also buys resilience and competitive weight — Amazon doubled headcount between 2019 and 2021 simply to keep pace with demand. None of that is in dispute. The catch is that extreme scale demands extreme coordination, and coordination has a cost that rarely shows up on the same balance sheet as the benefits.
That cost lands on people first. As organisations grow, most teams absorb the same three human costs regardless of industry: distraction (it takes roughly twenty-five minutes to refocus after a single interruption), disorientation (different people looking at the same initiative and seeing entirely different problems, goals, and scopes), and disengagement (only one in five employees worldwide reports being genuinely engaged at work, per Gallup's most recent Global Workplace report). Structurally, those same costs show up as silos — design, engineering, QA, and operations each trained, measured, and optimised in isolation — and a breakdown in what Gene Kim and Steven Spear call an organisation's "social circuitry": the processes, routines, and norms that quietly set people up to succeed together. It is not a coincidence that six well-established bodies of theory — Weick's theory of organising, complexity theory, attention economics, transaction cost economics, Metcalfe's Law, and Conway's Law — all point the same direction. Bigger is structurally harder to coordinate. This is not a management failure to be shamed out of a team; it is closer to a law of physics.
Most organisations know something is wrong and reach for a fix. Pereira and Davis frame the available fixes as a spectrum. At one end sit prescriptive solutions — centralised, expert-defined frameworks like PRINCE2 that offer high clarity but a heavy learning curve and an all-or-nothing feel. At the other end sit generative approaches — open workshops and retrospectives that build genuine buy-in through the "IKEA effect" of co-creation, but take longer and rarely convert cleanly into measurable business value. Neither extreme, on its own, closes what the book identifies as the three real gaps standing in the way of effective action: the alignment gap (no shared, valuable target), the visibility gap (no shared picture of current or future state), and — the one most existing solutions ignore entirely — the on-ramp gap: the simple, practical difficulty of getting started, restarting after a stall, or building momentum from wherever the team happens to be standing today.
That on-ramp gap is where the Checkbox Project actually failed. It is also, not coincidentally, the exact shape of the objection I hear most often when I bring traditional VSM into a digital or service organisation for the first time: "We want to do it. We know we have to. But we're not ready for it." Traditional VSM's ISO-style symbols and deep Toyota Production System grounding are genuinely powerful — they are also genuinely intimidating to a team of product managers and engineers who have never seen a supermarket icon or a kanban post symbol in their lives. Any credible fix, per the book's framing of the Iron Triangle of constraints, has to respect budget, scope, and schedule simultaneously: it has to be inexpensive, minimal, and quick to pilot. That is the specific design brief Flow Engineering was built against.
Value, Clarity, and Flow: The Three Elements Every Effective Action Needs
Before any map gets drawn, it's worth naming what a map is actually for. Pereira and Davis root the whole system in cybernetics — the same target-sense-compare-respond feedback loop that governs a thermostat, a guided missile, or, at organisational scale, James Martin's "cybercorp" vision of closing the gap between people and technology into one connected system rather than separate silos of "the business" and "IT." Set a goal, observe reality, find the gap, take action, repeat. That loop, running continuously, is what flow feels like when it's working.
Three elements make that loop function, and each one is mutually dependent on the others. Value is our shared preference for some outcomes over others — the reason the work is worth doing at all. Clarity is the ability to accurately understand our situation: mental models that actually match reality, rather than six people in a room each holding a different picture of the same project. Flow is unobstructed, sustainable action in pursuit of value — smooth handoffs, steady progress, no thrashing. Value shapes what we look for; clarity reveals the path; flow optimises movement along it — and progress, in turn, generates new value, closing the loop.
Remove any one element and the failure mode is predictable and specific, not vague. Flow without value or clarity produces motion without direction — a team that stays visibly busy while making no real progress toward anything that matters. Value without clarity produces stalled initiatives and endless debate: everyone agrees on the goal, nobody can see the path there. Clarity without flow is the most frustrating of the three — everyone understands the problem perfectly, but structural blockers (silos, approval queues, hidden dependencies) prevent any real movement regardless. And it's worth being precise about the actual target here: individual flow — the psychological state of focused, uninterrupted progress most of us associate with the word — is a by-product. The real target of Flow Engineering is collective flow: smooth handoffs from person to person, built on a shared target and a shared picture, rather than any one person's personal productivity.
That distinction — collective flow over individual flow — is the whole reason a map matters more than a to-do list. Two people looking at the same problem genuinely see different things: a "business" view and a "tech" view of the identical situation, speaking past each other in good faith. When a group jointly builds a map, they aren't just documenting a process — they're constructing a shared mental model that synthesises both perspectives into one. Pereira and Davis call this the map's function as a Rosetta Stone, and it's the mechanism underneath everything that follows.
The Five-Map Framework: From Outcome to Roadmap
Flow Engineering delivers value, clarity, and flow through a structured sequence of five maps, run roughly in order: Outcome Map, Current State VSM, Dependency Map, Future State VSM, and Flow Roadmap. For a skilled facilitator, the full sequence takes about six hours; for a first attempt, plan for nine to ten, typically spread across two to three weeks so teams have room to reflect between sessions. Sessions work best with twelve people or fewer, including anyone in the room who can actually change the system being mapped.
It's worth being precise about what this framework is and isn't, because the nuance matters to anyone who already runs traditional VSM. Two of the five maps — Current State VSM and Future State VSM — are Value Stream Maps, simplified for a non-Lean audience. Flow Engineering doesn't replace VSM; it wraps VSM's two most powerful steps in three additional maps — outcome-setting, dependency-diagnosis, and roadmapping — that make the whole exercise land in real, owned action rather than a poster on a wall.
Outcome Mapping: Building Value Before Anything Else
Outcome Mapping answers the question every other map depends on: why are we doing this at all? It's a collaborative workshop — buildable in as little as ten minutes and evolved over time as a living document — that clarifies a group's primary goal before any mapping of process begins. The logic traces to Stephen Covey's habit of beginning with the end in mind, and it echoes a 2020 Boston Consulting Group framework on what companies must answer to transform successfully: why are we doing this (Outcome Mapping, building value), what should we do (Value Stream and Dependency Mapping, building clarity), and how do we implement it (Future State VSM and the Flow Roadmap, opening the door to flow).
The workshop runs through five stages, each answering one question. Outcome Discovery has participants independently surface everything on their mind across five categories — context, goals, pains, questions, and ideas — with roughly five minutes to write and five to discuss. It's fine, even expected, for the same idea to land in multiple categories; the goal is surfacing everything, not filing it correctly. Defining the Target Outcome is where the group votes on the theme that matters most and crafts one SMART statement — specific, measurable, attainable, relevant, time-bound — replacing something vague like "we want to move faster and be more efficient" with something testable like "release twice as often within six months." Defining Benefits asks why the outcome matters, and a genuinely powerful outcome creates a win for three groups simultaneously: customers, the organisation, and individual contributors. Defining Obstacles names what could get in the way — skills gaps, unknown technical challenges, competing priorities, and unspoken doubt from the "disagreeable givers" in the room who raise real risk and need a safe way to say so. And Defining Next Steps closes the session the same way every good workshop should: with a named owner and a deadline, because without single-threaded ownership, nothing here gets done.
The book's worked example is instructive precisely because it's small: Sharon, leading a software delivery team at a company called Bolt Global, gathered her team to sort through a tangle of scattered concerns. Anonymous voting let a genuine doubt surface safely — "won't speeding up compromise quality?" — and the team landed on a single target: "release twice as often," with quality explicitly protected at every step. That protection clause, surfaced through the process rather than imposed by a leader, is the kind of detail that makes an outcome durable instead of decorative.
Current State VSM: Seeing How Work Actually Flows Today
This is where Flow Engineering's simplified notation earns its keep. Traditional VSM uses three sections — information flow, material flow, a lead time ladder — built on ISO-style icons for supermarkets, kanban posts, and push/pull arrows, requiring genuine Lean fluency to read at a glance. Flow Engineering strips this to one section: a plain sequence of boxes and arrows, cycle time and wait time annotated under each step, readable by anyone in the room immediately. As the source material puts it, if you can host a board game, you can host this.
The five stages move through stream selection (using the "5 Rs" — pick a step that is recent, real, reaches the full stream, representative of typical work rather than an emergency, and road-tested in production), adding activities (working backward from delivered value, plotting each distinct step — roughly ten minutes), adding timing (cycle time for active work versus wait time sitting in a queue — the clock never lies, and wait time is almost always the bigger, more fixable surprise), adding dimensions like Percent Complete & Accurate (which compounds multiplicatively across steps, not additively — four steps each at roughly 80-95% accurate can still deliver barely half the work complete and correct end to end), and finally highlighting the constraint: the single change that would most improve the end-to-end duration.
Approximate is the right level of precision here, not a compromise. The book's cautionary case is a bank that spent four grueling days exhaustively documenting a 2,000-step release process, then simplified it to fifteen steps on a second pass — and the team was too demotivated by the ordeal to actually benefit from what the simplified map revealed. Rough estimates, gathered quickly, are almost always enough to expose the real constraint. Teams routinely recover about twenty percent of their time — a full day a week — from nothing more than a first, imperfect map.
Dependency Mapping: Tracing Only What Feeds the Constraint
Dependency Mapping is deliberately narrow, and that narrowness is the point. It functions like a stack trace or a packet trace for organisational work: isolate the general area (the constraint you just found), then dig deep — not a complete map of everything the team depends on, just enough to find viable opportunities for improvement. The book's discipline here is worth naming explicitly: only dig where there's gold.
Five stages narrow the focus progressively — start with the constraint, zoom in with a sub-VSM, identify hot spots, identify direct causes, and dig deeper with Five Whys. That last tool is worth walking through in full, because it's where a lot of Dependency Mapping sessions either land somewhere genuinely useful or stall out on the first plausible-sounding answer. In the book's worked example, environment setup for Sharon's team took twelve days. Why? It waited in another team's queue. Why did it wait? That team, led by a colleague named Karl, was short-staffed for scripting work. Why short-staffed? Only one team member knew the required scripting language. Why only one person? Nobody had cross-trained or automated the process. Why hadn't it been automated? Because nobody outside Karl's team knew this was the constraint — until the mapping session made it visible.
The resolution is the part I find most instructive as a practitioner. Sharon's team happened to include someone who could write the exact scripting language Karl's team was short on. Rather than escalating a request, Sharon offered capacity in exchange — the two teams solved the constraint together. That is the practical difference between approaching a dependency with curiosity ("seek first to understand") and approaching it with the accusation that so often derails cross-team problem-solving. It also illustrates a discipline worth remembering on its own: any dependency governed by a service-level agreement behaves according to Parkinson's Law — the work will expand to consume the entire time the SLA allows, whether or not it needs to.
Future State VSM: Designing the Flow You Want
Future State Mapping is the same format as Current State — with two deliberate differences: it depicts the intended future rather than today's reality, and it annotates each improvement needed to get there directly on the map. Critically, this map is not built from a blank canvas; it starts from a literal copy of the Current State Map, which keeps the redesign grounded in what's real rather than what's aspirational. This map, together with the Outcome Map that set the original target, plugs directly into what the book calls the Improvement Kata — the same target-sense-respond cybernetic loop from the framework's foundation, now applied continuously: the Outcome Map sets the target, Current State and Dependency Mapping inform the improvements, the Future State Map defines the plan, and the Flow Roadmap guides the action — after which the team re-maps, studies the result, and adjusts. Four stages carry the session: reviewing the target and findings (five minutes), identifying targets for improvement (twenty minutes), redesigning the stream (twenty minutes), and measuring the future state (fifteen minutes) — sixty minutes total, at a brisk pace.
The identification stage leans on DOWNTIME, the eight wastes of classic Lean adapted for knowledge work: Defects (bugs, rework, missing documentation), Overproduction (unused features, duplication), Waiting (delays, slow handoffs, queues), Non-utilised talent (underused skills, lost morale), Transport (manual handoffs between systems), Inventory (backlogs, too much work in progress), Motion (context switching, cognitive load), and Extra processing (unneeded approvals, gold-plating). David Anderson's line — "stop starting and start finishing" — captures why work in progress gets singled out as the silent killer in this list: it burdens people with context switching and delivers precisely zero value until it actually ships.
Two practical disciplines are worth carrying out of this session specifically. First, wait time is almost always more improvable than cycle time — it hides in the gaps between steps rather than inside any one step, and it's usually the fastest lever available. Second, work-in-progress limits are, per the book, the only real way to reduce overload without anyone having to say "no" explicitly to a stakeholder — a governing constraint that counterintuitively lets a team get more done, not less.
The Flow Roadmap: Turning Design Into Owned Action
This is the map traditional roadmaps skip entirely. Product and technical roadmaps say what a team will deliver; the Flow Roadmap says how the team will improve how it delivers everything else on those other roadmaps. Pereira and Davis quote a line from Karen Martin and Mike Osterling's earlier work on Value Stream Mapping that I've seen play out too many times to count: organisations routinely produce beautifully designed current-state maps with no future-state map, or beautifully designed future-state maps with no action plan for realising them. Without this fifth map, everything built in the previous four sessions risks staying exactly that — clarity, with no action attached.
Three stages carry the work: identifying improvement opportunities, prioritising each candidate activity, and sequencing everything into a roadmap. Prioritisation runs on two axes — importance and feasibility — and feasibility itself breaks down into four honest questions: does this need one contributor or several, does it use a capability the team already has or one it needs to build, does it depend only on the team's own work or on others, and is the scope known or genuinely open-ended. Distance from the upper-right corner of that grid sorts every candidate action into three honest time horizons.
The reason this discipline matters is captured in a line from Mike Burrows that reshaped how the book frames ownership: "Measure before Method." Early versions of the Flow Roadmap tracked "methods of progress" instead of owners, and experience shifted the emphasis — at this stage, who leads matters more than exactly how they'll do it. Without a name attached, an action is a wish, not a plan.
The Five Headwinds That Derail Flow Engineering Efforts
None of the above works if the group running it walks into one of five predictable traps, and in my experience these five account for the overwhelming majority of Flow Engineering — and, frankly, traditional VSM — sessions that produce a nice-looking artifact and no lasting change.
Neglecting the narrative. Rushing straight to a tool or a solution without a shared story of why invites resistance from people who were never brought inside the reasoning. The fix is to meet people where they already are, using language they already trust — GE's rebrand of Lean Startup thinking as "GE FastWorks" is the book's example of the same idea wearing a familiar wrapper. Include stakeholders in the mapping from the start, not after the fact; a detractor invited in early tends to become an ally, not an obstacle.
Misaligned incentives. Short-term targets fighting long-term innovation, sales volume rewarded independently of delivery quality, individual metrics undermining teamwork — Goldratt's line on this is the sharpest I know: "Tell me how you'll measure me and I'll tell you how I'll behave." Naming the conflicting reward openly, rather than pretending it doesn't exist, is usually the only real countermeasure.
Not mapping the full stream. Limited visibility invites micro-optimisation — fixing your own segment while quietly overburdening whoever's downstream of you. An incomplete map is still worth bringing to the people who can fill the gaps; local focus, left unchecked, is often the enemy of global progress.
Craving unnecessary precision. A detailed dashboard consulted once a year is still waste. When your constraint costs weeks, a few hours of variance in your data won't change the picture. As one line from the source material puts it: precision doesn't matter in the beginning — you need direction first.
Conflict with existing operating models. The fifth headwind — friction with whatever framework, governance structure, or operating rhythm a team already runs on — is usually the least visible until it stops a rollout cold, which is exactly why it deserves the same deliberate narrative-and-inclusion treatment as the first trap on this list.
The book's SAFe case study is the cleanest illustration I've seen of what happens when a large organisation finally maps around these traps rather than into them. One of the world's largest financial institutions had never seen its end-to-end release flow before mapping it. Cost per release ran at $2M; lead time ran sixty-four weeks; only seventeen percent of that lead time was value-adding activity — the rest was the "watermelon effect," green outside, red inside, where every team measured only its own segment using best-case timing. After mapping identified a single constraint and redesigned non-value-adding stages to run in parallel — with no changes to any individual activity's own speed — lead time halved to thirty-two weeks and value-adding activity more than tripled to fifty-three percent.
The Five Principles That Guide Action After the Maps Are Built
Maps are a snapshot. Principles are what a team carries into the thousand small decisions a map can never anticipate. Adapted from Womack and Jones' five principles of Lean Thinking, Flow Engineering's five principles function as what the book calls decentralised, nonlinear control — held in each person's mind and applied autonomously, without a playbook to consult in the moment. Decision filters do the same work at a smaller scale: Satya Nadella's rule at Microsoft — faced with a choice between a feature and developer productivity, always choose developer productivity — is the pattern. Faced with X or Y, we choose X. No meeting required.
Specify Value. Value is subjective and transitory, experienced by a particular person at a particular moment — not a fixed property of the work. Multiple parties each need to walk away net-positive for an outcome to be sustainable, which means designing for feedback deliberately: value can only be measured by asking, not assumed from a spec document.
Map the Value Stream. A value stream is genuinely greater than the sum of its parts, and local point-fixes rarely help unless they target the real constraint. Visibility enables observability; observability enables clarity — and it's worth remembering that roughly thirty percent of the human brain is dedicated to visual processing, which is part of why a shared drawing does work that a shared document rarely can.
Create Flow. This is where the book names what I think of as the central trap of most improvement efforts: the efficiency paradox. Resource efficiency — the percentage of time a person or team is busy — feels productive; everyone looks occupied. It also ignores that a system is more than the sum of its parts, and at high variability it quietly explodes wait time. Flow efficiency — cycle time divided by actual lead time — is what Flow Engineering optimises for instead, which requires deliberately holding slack capacity to absorb variation rather than filling every hour. Goldratt's Theory of Constraints gives the mechanism for acting on this: identify the constraint, exploit it for maximum value as-is, subordinate everything else to it, elevate it with added capacity only if more throughput is genuinely needed, and repeat — because inertia sets back in fast.
Pull, Don't Push. Give customers what they want, when they want it, in the amount they want — not more. Smaller batches and WIP limits reduce work in progress, improve flexibility, and make constraints far easier to spot because there's less concurrent work obscuring them. David Anderson's motto for this — "stop starting and start finishing" — is worth putting on a wall.
Pursue Perfection. Perfection is pursued by continuously removing waste, and that requires an organisation that can actually learn. Deming's discipline here — drive fear out of organisations — sits alongside the scientific method (form a hypothesis, change one variable, run a test) and "go and see," the practice of standing where the work actually happens rather than reasoning about it from a conference room.
From Mapping to Management: Scaling Flow Engineering Across the Organization
A single mapping session is a workshop. Value Stream Management is what a workshop becomes when it stops being an event and starts being a practice — a distinction Peter Hines drew as far back as 1998, describing it as a strategic and operational approach to achieving a genuinely lean enterprise. The shift from project thinking (a finite solution to an infinite opportunity, mostly forgotten once delivered, the team disbanded and the knowledge dispersed) to product or stream thinking (a continuous flow, a stable team, sustained customer value) directly counteracts the three Ds of scale this guide opened with. Mapping and Management aren't competitors here; they're complementary functions with genuinely different characters. Mapping is iterative, easy to start, human-centric, and an enabling constraint. Management is continuous, harder to start, tool- and data-centric, and a governing constraint. You need both, in that order — and the book is specific about why the order matters: diving straight into VSM tooling before mapping invites the streetlight effect, measuring what's easy to instrument rather than what actually matters, and it risks what Reinertsen calls the Inactivity Principle — the easy, and wrong, habit of attributing delays to people rather than to the system they're working within.
Scaling doesn't mean mapping everything. Many value streams share the same hidden constraints, so fixing one well-chosen constraint can ripple benefit across teams that never sat in the same room. The mechanisms are lightweight and familiar to anyone who's run a community of practice: sharing completed maps with adjacent teams to validate understanding and spark their own mapping, running a quick survey ("what's your biggest dependency?") to synthesise many perspectives fast, and forming guilds — the book cites Spotify's popularisation of the term — that share learning across team boundaries formally or informally. A Value Stream Network Map, plotting every stream across two spectrums (Developmental versus Operational, Core versus Supportive), lets leadership see the organisation as a connected system of relationships and dependencies, rather than the hierarchy of roles and reporting lines an org chart shows.
Two low-risk ways exist to pilot this without waiting for a formal programme: a single thirty-minute conversational Outcome Map, run mentally or on a napkin using the same five discovery categories as a full session, checked with "did I hear this right?" — or a real pilot team given one target outcome and roughly six to eight hours of mapping, a modest bet for the level of insight it typically returns. The one discipline that determines whether either pilot actually spreads is remembering that the target outcome is never "implement Flow Engineering." That's a means, not an end. Pick a real problem and put the maps to work on it.
The Discipline This Guide Is Really About
Every mistake in this guide — the $28M checkbox, the four-day bank mapping session nobody had the energy to use, the SAFe organisation that had never seen its own release flow — shares a single root cause. Someone was operating on a mental model that didn't match reality, and nobody had built a shared picture cheap enough, fast enough, and simple enough to correct it before the cost compounded. Flow Engineering is not a new philosophy. It is a deliberately lightweight on-ramp onto a discipline Lean practitioners have trusted for decades, rebuilt specifically for the teams traditional VSM was never going to reach in time to matter.
The question worth asking after reading this, then, isn't "should we try Flow Engineering." It's narrower and more useful than that: what is the one constraint in your team's flow right now that everyone privately suspects but nobody has actually mapped? You already have candidates in mind. The five maps in this guide are how you find out whether your suspicion is right — in hours, not months.
Build Flow Engineering Capability
Reading about a five-map framework and running one in a room with your own team are two different skills, and the gap between them is exactly what a facilitation-ready deck is built to close. If you're ready to bring Flow Engineering into your own organisation, these OEC resources give you the structured starting point:
Flow Engineering Training Presentation & Practitioner Toolkit — the complete 160+ slide deck behind this guide, with blank templates for all five maps, facilitator timing benchmarks, and the full case study library.
Value Stream Mapping (VSM) Training Presentation — the traditional, ISO-notation discipline Flow Engineering's two VSM maps are simplified from, for teams ready to go deeper into full Lean rigor.
Root Cause Analysis (RCA) Training Presentation — deepen the Five Whys technique used in Dependency Mapping with the Fishbone diagram and Pareto prioritisation.
A3 Thinking Training Presentation — a disciplined single-page format for tracking and reporting on the actions your Flow Roadmap commits to.
About the Author
Allan Ung is the Founder and Principal Consultant of Operational Excellence Consulting (OEC), a Singapore-based management training and consulting firm he established in 2009. Before founding OEC, Allan spent years at the National Productivity Board of Singapore leading Cost of Quality and Total Quality Process work, driving reductions in the cost of quality of up to fifty percent for client organisations. He went on to hold senior roles at IBM, Microsoft, and Underwriters Laboratories (UL) — the last of these giving him a deep grounding in global certification and compliance work, the first two placing him inside exactly the kind of large-scale, cross-functional digital delivery organisations where Flow Engineering's on-ramp gap shows up most often.
Allan holds a Bachelor of Engineering (Mechanical) from the National University of Singapore and completed advanced consultancy training in Japan as a Colombo Plan Scholar. He is a Certified Management Consultant (CMC, Japan), a Certified Lean Six Sigma Black Belt, and an accredited TPM Instructor. His Value Stream Mapping and Lean Thinking programmes have been engaged by organisations including IBM Japan, IBM Singapore, Microsoft, Micron, and Temasek Polytechnic, alongside a broader client base spanning manufacturing, healthcare, education, and the public sector across Singapore and the region.
His practitioner philosophy, distilled from three decades of watching maps succeed or fail in the room: "Insight without ownership is just an expensive observation." It is the reason every map in this guide — from the first Outcome Map to the last card on a Flow Roadmap — ends with a name attached, not just a diagram.
OEC's facilitation-ready training toolkits, built from this same practitioner-led approach, are used by managers and practitioners across Asia, Europe, and North America to build Lean capability and drive organisational improvement.
👉 Learn more at: www.oeconsulting.com.sg
Further Learning Resources
Pereira, S., & Davis, A. (2024). Flow Engineering: From Value Stream Mapping to Effective Action. IT Revolution Press.
Value Stream Mapping (VSM) Practitioner Guide — the companion piece to this guide, covering the traditional, full-rigor discipline that Flow Engineering's Current State and Future State maps are drawn from.
Root Cause Analysis (RCA) Training Presentation — go deeper on the Five Whys technique that powers Dependency Mapping's final stage.
Kaizen Training Presentation — the continuous-improvement discipline that keeps a Future State VSM from becoming a one-off event.
Change Management Training Presentation — for leaders scaling Flow Engineering past a single pilot team into an organisation-wide capability.