Understanding The DFOW Flywheel
Reimagining the Definable Feature of Work
Introduction: Expectations, Goals, and Intent
The most expensive mistake in our industry is the perfect execution of the wrong priorities. Projects can meet every specification, yet still be a failure in the client's eyes. When we try to focus equally on everything, we focus meaningfully on nothing. Our clients notice.
As Bent Flyvbjerg noted in his book How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between:
“People say that projects ‘go wrong,’ which they all too often do. But phrasing it that way is misleading; projects don’t go wrong so much as they start wrong.” (pg. 19)
The most important elements of our projects are hidden beneath casual layers of commentary during the first conversations with our clients. These details get lost during the busyness of project work. Bent goes on to say:
“[...] it’s easy to get consumed by the blizzard of details and difficulties that arise during the planning of any project, while the goal, which was only vaguely understood to begin with, fades from view.”(pg. 52)
I think of the industrial example from a previous article where what a client really wants gets missed:
A mid-sized general contractor building an industrial warehouse near Memphis, TN created their Definable Features of Work (DFOW) log shortly before mobilization. The DFOW list originated from the project specifications. Each specification section became a DFOW and served as the basis for the Inspection and Test Plan (ITP). The construction team held the required planning meetings and intended to meet and exceed their client’s expectations by building per the plans and specifications. Twelve months later at substantial completion, the building was indeed built per the construction documents, but their client was frustrated and unhappy. The general contractor failed to understand the importance of the loading dock to the client’s operations. The design team also failed to coordinate the electrical drawings and specifications for the dock equipment. Two mockups were missed, creating rework in two critical areas. Partnerships between all stakeholders diminished and the construction team did not win the next project with that client. (You can read the full article here.)
We see this scenario often. Teams strive to build exactly what's specified, yet clients still say: "That's not what I bought,” or “That’s not what I thought it would look like.”
Our clients rarely measure success only by whether the building was delivered on time and on budget. I as discussed previously, these are expectations, not goals. Expectations must be met. Goals are a client’s true purpose for the project - their intent. A project is truly successful when it enables the client’s business goals. Bent addresses this as well:
“Developing a clear, informed understanding of what the goal is and why - and never losing sight of it from beginning to end - is the foundation of a successful project.” (pg. 51)
I believe our main industry challenge is maintaining a focus on the right things: our client’s intent. Interpretation of a client’s goals are frozen too early and too narrowly. Once design and construction begin, the client’s purpose gets buried beneath budget constraints, value engineering exercises, and schedule pressures.
To solve this challenge, I developed the “The Definable Feature of Work (DFOW) Flywheel,” an enhanced framework and planning tool for delivering our client’s intent.
The DFOW Flywheel
The US Army Corps of Engineers originally defined DFOWs as "tasks separate and distinct from other tasks." By connecting this with Deming's insight that "quality begins with intent," we can enhance the scope of a DFOW and solve the industry’s planning and focus problem while translating client intent into tangible outcomes.
I'm grateful to my colleagues who helped refine this idea over the past few years. Jason Hansen noted that design isn't linear, rather an iterative path, traversing in a circle, revisiting the same point as many times as needed to get it right. Jennifer Groen described it as a funnel, through which all elements of the project flow and are organized. I connected both of these ideas with Jim Collins' flywheel concept in Good to Great, turning the DFOW framework into a flywheel. This illustrates that planning isn't straight-line progression, rather building momentum through consistent, reinforcing cycles and conversations. It also gives the industry a common language to communicate across disciplines, orienting our systems and organizing our projects effectively.
The DFOW Flywheel creates value through iterative cycles of understanding, planning, and execution that build upon each other, gaining clarity with each revolution.
Foundational Categories
The DFOW Flywheel creates the project’s list of Definable Features of Work from four foundational categories:
Client Intent: Elements explicitly valued by the client - their business goal and purpose.
Critical Activities: High-risk or schedule-critical elements.
Experience and Lessons Learned: Insights from past projects.
Drawings and Specifications: Technical requirements from the specifications and drawings.
In the traditional DFOW approach, only the Specifications served as a source for the DFOW list. I noted previously why this is insufficient and why adding Client Intent, Critical Activities, and Experience and Lessons Learned is essential for creating a clear delivery vision:
As teams strive to build per plans and specifications or exceed expectations, we don’t recognize that “[q]uality approaches that focus on satisfying requirements fail in recognizing […] that plans and specs might not be totally accurate, complete, or might not clearly express client expectations.”
This is the problem with leveraging only the project specifications as the basis for identifying Definable Features of Work. While the construction documents are a great communication tool, we underestimate two elements of managing a project:
How difficult it is for the designer to accurately capture and translate the client’s exact expectations into the specifications.
How difficult it is for the construction team to interpret and translate the client’s exact expectations from the specifications.
This is not the fault of the designer or contractor. The specifications alone are not sufficient to convey client intent – or mitigate other risks on the project.
These four foundational categories create a more comprehensive framework for identifying what truly matters on a project. However, simply identifying the right DFOWs is only the beginning. The power of the DFOW Flywheel comes from how these elements interact and build momentum through a set of guiding principles. These principles transform static project requirements into a dynamic system that maintains focus on client intent throughout the project lifecycle.
Principles
The DFOW Flywheel operates on a dynamic set of principles that transform design and construction from linear sequences into a self-reinforcing system. Unlike traditional approaches that treat project elements as static requirements, the flywheel concept recognizes that DFOWs evolve through repeated cycles of identification, refinement, planning, and execution - creating momentum that delivers the client's intent.
The early identification of critical DFOWs (like Client Intent) creates initial momentum.
The handoff of the DFOW list between project phases (development, design, preconstruction, then construction) maintains continuous momentum.
As each DFOW moves through identification, planning, and execution, it adds energy to the system.
New insights gained during execution might prompt adjustments to planning for other DFOWs still forthcoming in the schedule.
Later project phases might circle back to revisit and refine DFOWs identified in earlier phases.
Each DFOW doesn't exist in isolation, rather contributes to the overall momentum of the project.
As more DFOWs are identified and refined throughout the project lifecycle, the flywheel spins faster.
The learning from completed DFOWs feeds back into the system to improve the approach to upcoming DFOWs, and DFOWs for future projects.
Understanding these principles provides the theoretical foundation, but seeing the DFOW Flywheel in motion reveals its true power. As we examine how these principles operate in practice across the project lifecycle, we'll discover how this approach creates alignment between client intent and project delivery, addresses emerging challenges proactively, and builds institutional knowledge that benefits not just the current project but future work as well.
Conclusion: Building the Foundation
In this Part 1, we've established the fundamental concept of the DFOW Flywheel and its potential to transform how we deliver projects. By expanding our understanding of Definable Features of Work beyond specifications to include client intent, critical activities, and lessons learned, we create a framework that captures what truly matters. Through the flywheel's guiding principles, we transform project planning from a static, linear process into a dynamic system that builds momentum with each revolution.
The DFOW Flywheel isn't just a theoretical construct—it's a practical tool that addresses our industry's persistent challenge of delivering on client intent rather than merely meeting specifications.
The power of the DFOW Flywheel lies in its practical application. As we'll see in the upcoming parts, organizations that embrace this approach are not only delivering better projects—they're transforming their entire approach to client relationships and project delivery.
Thank you for reading!