Now the real work begins. Implementation is harder than getting approval because everyone is held accountable to do what they said they would do. Here are five principles I learned through three years of implementation, some through success, some through failure.

1. Quality Builds Upon Itself. Start small and build momentum. Don’t try to do everything at once. Your program starts small, and momentum builds through all stages. I tried to accomplish too much in Year 1. We simplified processes, rolled out training, implemented new tools, and restructured the team simultaneously. It was overwhelming. A better approach is to pick one high-impact action per quarter. Do it excellently. Build on that success for the next quarter.

   1. Q1: Small wins create early proof of concept, such as simplifying one key process.

   2. Q2: Train 50 people on simplified process. Early adopters spread positive experiences.

   3. Q3: Expand to next process based on Q1 and Q2 feedback.

   4. Q4: Measure adoption and competency growth.

   5. Year 2: Momentum builds as more teams experience benefits.

   6. Year 3+: The program becomes “how we work” rather than “that new initiative”.

2. Everyone Gets to the “Why” on Their Own Timeline. You will encounter unsupportive team members. People who don’t believe in what you’re doing. Perhaps even actively oppose your approach. (I had several of these, and I spent an enormous amount of time trying to satisfy the loudest opinions rather than the meaningful ones.) This doesn’t mean you’re wrong. There are those who, no matter how much data you show them, you can’t change their minds. They need to experience the benefits themselves before they’ll believe. Don’t waste energy converting resisters. The resisters will either come around when they see everyone else succeeding, or they’ll leave. Let people get to the “why” on their own timeline. Your job is creating the conditions for success, not converting non-believers. Instead, focus on:

   1. Early adopters (they become your champions)

   2. The movable middle (they’ll follow once they see success)

   3. Removing barriers for willing participants

3. Focus on 1% Improvements Over Time. Don’t expect transformation overnight. Focus on 1% improvements consistently. 1% improvement every day becomes 300%+ improvement in a year (compound growth). A 1% improvement means one checklist simplified each week, one superintendent trained per day, one process refined based on feedback each week, one barrier removed each month. Small improvements compound. Grand transformations fail. It’s a marathon, not a sprint. Keep perspective.

4. Quality Won’t Necessarily Win a Job, But It Will Lose a Job. Like all the ideas and concepts in this series, this applies to functions beyond quality. There is a point of diminishing returns when investing in any support function. The business case for support functions is about appropriate investment for your risk profile and market position, not about perfection. Understand what level of investment creates competitive advantage without creating diminishing returns. Calibrate your investment appropriately for your business context.

   1. For Quality: Perfect quality is impossibly expensive. “Good enough” quality appropriate to client expectations is the goal.

   2. For Safety: Zero incidents is the goal, but there’s a point where additional safety investment yields minimal additional protection.

   3. For Scheduling: Perfect schedule adherence might require resources that destroy project margin.

5. Changing Your Mind Is Okay—Actually, It’s Required. Building a business case for anything is a learning process. You will learn new information 6, 12, or 24 months into implementation that forces you to change your mind or adjust your plan. That doesn’t mean you were wrong. It means you have new information. You can only decide based on the information you have at the time. Build feedback loops into your implementation. Measure what you said you’d measure. When new information emerges, be honest about what the data shows. Change course when needed. Stubbornness isn’t strength. Adaptation based on evidence is.

The Honest Reality

Here’s what I learned after three years.

• What Worked

  • Systematic feedback gathering created buy-in and right solutions

  • Starting with simplification before adding new things

  • Training on simplified processes (not complex legacy processes)

  • Building a support network of champions

  • Measuring behavior change, not just activity

• What Didn’t

  • Not being explicit enough about Stage 3 transition with executives

  • Under-investing in competency development

  • Not measuring dependency metrics early enough

  • Trying to do too much too fast in Year 2

  • Not adapting quickly enough when data showed dependency increasing

• The Ultimate Lesson

  • I built successful Stage 2 systems, but failed to complete the Stage 3 transition. When market conditions changed and the company needed to reduce overhead, the centralized function I built became a target.

The Path Forward

If you’re building a business case using this framework:

• Follow the methodology rigorously. It works for gathering feedback, analyzing data, and building executive support.

• Be explicit about staging from day one.

• Measure competency growth, not just program activity.

• Build momentum slowly and sustainably.

• Adapt based on evidence.

Meanwhile, avoid:

• Building permanent overhead and hope market conditions stay favorable (they won’t).

• Creating dependency instead of competency (they often look the same).

• Ignoring warning signs in your metrics (be open to shifting your strategy).

• Rushing implementation to show quick wins (culture changes requires years of effort across the organization).

• Sticking to your original plan when data says change course (be open to changing your mind).

Thank You

Thank you for reading this series. I hope it helps you excel in your career and improve operations at your organization. If you put this into practice and have questions or feedback, I’d be eager to hear how it goes.

I encourage you to build what you need to build, but build it with the end state in mind. Create capability, not dependency. Plan the crossing, and plan the exit.

Good luck!

Obstacles to Change

1. It Will Take Longer Than Desired

2. Understand Leader Responsibilities

3. Leverage Existing Training Content

4. Leaders Must Train

5. Ensure Face-to-Face Accountability

1. It Will Take Longer Than Desired

Leading change takes time. The practical how requires a cultural why to reinforce it. While practical changes occur over weeks or months, cultural changes take years. Executives should assume two to four years for any company-wide change to occur.

• 0-12 / 18 Months: Talking about the change, investigating its potential, gathering data, and analysis.

• 6-20 Months: Strategizing and developing the practicalities behind the change, continually communicating what the change will be.

• 12-30 Months: Implementing the change, training, reinforcing.

• 24-36+ Months: Continued follow-up, monitoring per established KPIs, revising those KPIs based on feedback, ongoing improvements.

I confirmed this timeline with Ryan Companies COO during a discussion where I asked about timing and expectations:

“Company leadership has to be fully behind it. This is the fundamentals of it. Not more complicated than this. […] This is a 2 to 4 year process to change things over. To think it will happen overnight is wrong.”

The COO’s follow-up point to this was executives will eventually come to terms with the reality that change will take longer than they want it to. The alternative is that something breaks down in the organization and there’s sudden panic to fix it. There’s a team assigned to push a resolution through, working insane hours. There’s a lot of activity, therefore it feels good. “In three months, we’ll have this turned around.” Yet once implementation starts, it doesn’t stick because while there was a practical change, there was no cultural reinforcement.

2. Understand Leader Responsibilities

Many conference presentations and business books mention that change must come from the top down. They're right, but most don’t know tangibly what that looks like. John Kotter's Harvard Business Review research on organizational transformation found that most change efforts fail because leaders don't properly understand their role in driving adoption.

True executive support isn't standing in the background saying "I support this initiative," approving the budget, or occasional encouragement. Real support means executives direct their teams accordingly: "You will do this."

As a change leader - whether you're a quality manager, operations director, or COO - you often don't have direct reports throughout the organization. You're operating in a matrix structure, influencing across departments. This means the leaders, supervisors, managers, and executives must be the ones directing their teams to execute. Without this direct mandate, initiatives fail.

This doesn't mean delegating responsibility for the program. As the change leader, you own the framework, the systems, and the strategy. But you cannot mandate behavior across an organization where you lack direct authority. It’s shared success between you and organizational managers.

3. Leverage Existing Training Content

One of my biggest mistakes early on was trying to build comprehensive training programs from scratch. I set up Procore Action Plans to facilitate quality planning and execution, and one of the major parts of the training was me showing teams how to use Action Plans. A better approach is to find existing resources (YouTube tutorials, vendor training videos, online courses) such as Procore’s own videos and make them prerequisites to the actual process training. In my example, I found Procore’s own training videos on inspections, observations, and action plans, then sent those out as prerequisites to the new process training. A change leader’s expertise isn't teaching software basics - it's understanding how that technology fits into your specific operational context.

Focus your training efforts on what only you can teach: the specific, straightforward application of new processes within your organization. The "why" behind the change, the workflow integration, the accountability measures. Your role is to bridge the gap between generic training resources and your company's specific needs, not to become a full-service training department.

4. Leaders Must Train

While the change agent owns the process and framework, tools and systems, and must ensure they are effective, the leaders must train their teams. I wrote previously about this (you can find the full article here).

“Successful implementation of quality - or any other discipline - requires the leader to train on what they know, whether it’s quality, safety, schedule, budgeting, or any other skill they are responsible for. It’s a mindset shift for the industry, but one that is much needed.”

If leaders don’t train on the change, the change doesn’t come from a position of authority and the change doesn’t scale. While one person (or a small team) can indeed change the conscience of an organization, changing the actions of the organization requires leadership direction.

MIT Sloan's research on leadership development consistently noted that when leaders personally train their teams on new processes, several things happen:

1. They demonstrate the importance of the change through their time investment.

2. They develop deep understanding of the new process themselves.

3. They can immediately address resistance or concerns.

4. They create direct accountability relationships around the new behavior.

Corporate training departments and change leaders can provide frameworks and resources, but the most effective training happens when someone's direct supervisor explains why this change matters and how it will be implemented in their specific context.

5. Ensure Face-to-Face Accountability

When rolling out change initiatives, resist the temptation to handle everything through video calls or remote sessions. For critical rollouts, look people in the eye and have them commit to execution. Confirm in-person that they understand the change to lead and train it independently.

In Ryan Companies’ “Quality 2.0” rollout, I asked executives to identify two local director-level champions in each region who would become the trainers. We conducted train-the-trainer sessions with them, then supported them as they rolled out training to their teams.

This approach accomplished two things: It created local ownership and expertise, and it ensured I could gauge real commitment versus polite agreement. You can tell the difference when you're in the room.

Closing Thoughts

Every change initiative involves three components:

1. Knowledge: Understanding what needs to be done.

2. Skill: Having the ability to execute.

3. Behavior: Actually doing it consistently.

Change leaders can address knowledge and skill gaps, but can’t resolve behavior problems. That requires executive and supervisor action. When initiatives fail, it's rarely because people don't understand what to do or lack the skills to do it. It's because there are no consequences for not doing it, and no recognition for doing it well.

The most important conversation I had during our second rollout was about responsibility boundaries. Business leaders cannot delegate their accountability for change outcomes, though they can (and should) delegate responsibility for specific implementation tasks. My message as the Vice President of Quality was:

“Every project needs to implement these basic requirements. People not doing it is not a program failure - it's an execution failure. If team members don't know how to execute or the program isn’t effective, I own that. However, directing the teams to do it is part of your responsibility. If we've agreed we should be doing it, you need to hold people accountable for doing it, and I need to be held accountable for the system delivering the results it’s intended to."

This clarity eliminated the finger-pointing that kills change initiatives. The change leader owns the systems, metrics, and frameworks. Leadership owns making execution non-negotiable.

Successful organizational change requires more than good systems and comprehensive training. It requires leaders who understand that their primary job is driving execution, not delegating change management to staff functions.

Whether you're implementing new technology, safety protocols, quality systems, or operational procedures, the same principles apply: clarity of responsibility, face-to-face commitment, leveraging existing resources, and leaders who actively train and hold people accountable.

The most elegant change management strategy in the world fails without leaders who are willing to make new behaviors non-negotiable. That's not the change manager's job. That’s effective leadership.

References

• Kotter, J.P. (1995). "Leading Change: Why Transformation Efforts Fail." Harvard Business Review. Retrieved from https://hbr.org/1995/05/leading-change-why-transformation-efforts-fail-2

• Kerrissey, M.J. & DiBenigno, J. (2025). "How to Successfully Drive Change When Everything Is Uncertain." Harvard Business Review. Retrieved from https://hbr.org/2025/08/how-to-successfully-drive-change-when-everything-is-uncertain

• MIT Sloan Management Review. (2024). "Change Management." Retrieved from https://sloanreview.mit.edu/tag/change-management/

• Do you know what your organization requires for presenting a business case?

• What problem is your business case going to solve?

• What are the main points your business case must address?

• Are you prepared to defend the Stage 3 transition plan?

Preparation

This article brings all the research and information together into a deliverable to present to executives and share with stakeholders.

Every organization has different expectations for business case format. It’s essential to understand how your company formats and presents new ideas. Regardless of your organization’s specific format, every business case should address:

• Purpose: What are you trying to accomplish? What problem are you solving? How does this align with business strategy?

• Findings: What’s going wrong now at your organization? What are the specific facts and observations? What data-driven results show the cost of the current state?

• Opportunity: Articulate the positive opportunity. How will fixing this make you a better organization? What competitive advantage do you gain? Frame the data as exciting potential.

• Risks: What happens if leadership doesn’t approve? What are the costs of maintaining the status quo? What opportunities are you missing?

• Actions: What specifically will you do? Explicitly state these are not just your opinion, rather the result of rigorous research and analysis across the organization.

• Stage 3 Transition Plan: How will you measure progress toward decentralized competency? When will you start reducing support staff? What does success look like if it means your function becomes smaller over time?

• Data: Depending on your executives’ communication style, have supplemental charts ready. Some executives are data-driven and want details. Others prefer high-level summaries. Have backup materials prepared but don’t lead with them unless you know they want it.

Suggested Business Case Outline

1. Aim: What is the business case attempting to do? What problem does it solve? How will this function tactically help your company achieve business goals? Include the staging explicitly.

   1. Example: “This business case proposes a 3-year initiative to establish [function] standards and raise baseline competency across project teams. Year 1-2 will build centralized capability to develop standards and training. Year 3 will transition to decentralized execution with minimal corporate oversight, creating sustainable capability that scales with business growth.”

2. Summary of Findings: In one sentence, what is the biggest problem

   1. Example: “The absence of standardized quality processes coupled with inadequate training results in inconsistent execution, elevated risk, and project teams dependent on reactive problem-solving rather than proactive management.”

3. Specific Observations (factual, numerical): Present 3-5 key findings from your interviews and analysis with the problem and associated data. Examples could be:

   1. 73% of interviewed superintendents reported never receiving formal training on quality processes.

   2. Current inspection checklists average 47 items, cited by 87 respondents as “too long to use effectively”.

   3. Average punch list duration is 45 days, 3× industry benchmark for similar project types.

4. Opportunities: Frame the positive potential.

   1. Opportunity 1: Simplified processes save project teams 5+ hours per week, reallocated to higher-value work.

   2. Opportunity 2: Trained project leaders reduce dependency on support staff, improving scalability.

   3. Opportunity 3: Consistent standards improve client satisfaction and competitive differentiation.

5. Risk Analysis: What happens if nothing changes? Examples could be:

   1. Risk 1: Overhead costs continue growing proportionally with project volume (unsustainable).

   2. Risk 2: Inconsistent execution damages client relationships and limits market growth.

   3. Risk 3: Competency gaps prevent promotion of internal talent, forcing expensive external hiring.

6. Business Actions: List your top 5-7 prioritized actions. Examples could be:

   1. Simplify current program (addresses 87 of 298 respondents’ concerns).

   2. Provide systematic training program (addresses 64 respondents’ concerns).

   3. Clarify support structure and accountability.

   4. Create streamlined tools and templates.

   5. Establish competency-based advancement criteria [etc.].

7. Stage 3 Transition Metrics: This section is critical and often missing. Explicitly state:

   1. Year 1-2 metrics: Program adoption, training completion, process simplification progress.

   2. Year 3+ metrics: Reduced support hours per project, improved staff-to-project ratios, increased project team self-sufficiency.

   3. Exit criteria: What does success look like if the centralized function shrinks over time?

8. Supplemental Data: Include as appendices, not in main presentation.

   1. Detailed analysis charts.

   2. Sample interview quotes (anonymized).

   3. Demographic coverage tables.

   4. Benchmarking data if available.

Business Case Essentials Specific to Support Functions

Regardless of your format, you must address these topics.

1. Centralized or Decentralized Structure. Be explicit about the staging. If executives push back on the transition, you need to explain the economic reality: permanent centralization creates overhead that grows linearly with project volume. That’s unsustainable.

   1. “We recommend a hybrid approach: centralized in Years 1-2 to establish standards and develop training infrastructure, transitioning to decentralized execution in Year 3+ as project team competency rises. This balances the need for initial consistency with long-term scalability.”

2. Realistic Timeline Expectations. Be very clear this is a 2-4 year commitment. This doesn’t happen overnight. For reference, I spent 4.5 years enhancing the design and construction quality program, and it would have taken at least another two years to transition to Stage 3. There must be complete turnover of all projects in your portfolio before culture shift takes hold. Projects started under old approaches must finish before new approaches become “how we work.”

3. Leadership Ownership. Leadership must own this program. They have to actively support it, not passively approve it. State explicitly: “Success requires executive leadership to consistently reinforce expectations, remove barriers during implementation, and hold departmental leaders accountable for adoption. This cannot be delegated to the [quality/safety/scheduling] function alone.” The very definition of executive leadership is long-term thinking. If they can’t commit to 2 to 4 years of active support, don’t proceed.

Practice and Preparation

Before presenting to executives:

1. Practice with your support network. Go back to the people you interviewed who were excited about your effort. Ask them the following questions. This feedback ensures your business case is shaped around your company and the people who use it daily. This builds quality culture and participation from the ground up.

   1. What do you think of this business plan?

   2. Does this solve the problems you shared with me?

   3. Do you know [specific executive]? What motivates them? How would you articulate these points to them?

   4. What am I missing?

2. Have others read your business case. Make as many revisions as needed to make it unstoppable. The business case I presented went through 12 revisions before I sent it to executive leadership. Each revision strengthens the case. Get feedback from:

   1. Peers in other departments.

   2. Your supervisor.

   3. Finance/accounting (does the ROI math check out?).

   4. A trusted skeptic who will poke holes.

3. Prepare for the Stage 3 objection. Someone will ask: “If your plan is to eventually shrink this function, why should we build it at all?” Your answer: “Because we can’t get to Stage 3 competency without Stage 2 scaffolding. You can’t train 300 people on standards that don’t exist yet. We need to build it right, then systematically transfer knowledge and ownership to project teams. The alternative is staying in Stage 1 chaos or building Stage 2 permanent overhead that we can never afford to scale.”

Presenting the Business Case

Format varies by organization (formal presentation, memo, executive summary, etc.). Regardless of format, follow these principles.

1. Be brilliant, be brief. Executives are busy. Your talking points must be focused and honed. Speak clearly and succinctly. If they want detail, they’ll ask questions. Start high-level.

2. Personally address their concerns. Your business case should already account for executive concerns you previously identified. But be sensitive if their feedback isn’t what’s actually happening in the field. When an executive says “But I’m very concerned about X,” you can respond: “I understand your concern. I talked with 150 superintendents and 75 PMs across all regions, and that’s not what I discovered. The primary concerns were Y and Z. Tell me more about your perspective so I can understand what you’re seeing.” You’re not telling them they’re wrong. You’re presenting different data and asking them to help you reconcile. This is respectful and collaborative.

3. Speak their language. Adapt your language based on executive perspective. Below is an example that articulates the same benefit but with different framing. Speak their language.

   1. Example: How your program makes superintendents’ jobs easier.

      1. For financially-focused executive: “This program saves every superintendent 5 hours per week. At a bill rate of $150/hour, that’s $39,000 per superintendent per year. With 50 superintendents, that’s $1.95M in recovered capacity annually.”

      2. For people/client-focused executive: “This program saves every superintendent 5 hours per week by reducing meetings and administrative burden. That’s 5 additional hours on the job site managing work, walking with clients, and mentoring field staff—the high-value work they should be doing.”

4. Address the economic reality directly. Don’t hide from the staging conversation. Bring it up proactively. “I want to be transparent about the long-term model. Many companies build support functions that grow proportionally with project volume. That’s expensive and doesn’t scale. Our plan explicitly transitions from centralized to decentralized over 3 years, creating sustainable capability instead of permanent overhead. This is uncomfortable because I’m essentially planning to shrink my own function, but it’s the economically honest approach.” This level of honesty and strategic thinking is rare. It will impress executives who think long-term and concern executives who wanted permanent support staff (which reveals a different problem).

What Approval Really Means

If your business case gets approved, understand what you’re getting.

• Approved with active leadership support: They understand the staging, commit to 2 to 4 years of involvement, and will help remove barriers. Proceed with confidence.

• Approved with passive support: They like the idea but won’t actively help during implementation. You’ll struggle. Consider whether to proceed.

• Approved with misunderstanding: They think you’re building permanent support but you’re planning Stage 3 transition. Clarify before starting, or you’ll face conflict later.

• Approved without Stage 3 buy-in: They want permanent overhead. Either educate them on the economic reality or look for a different opportunity.

In my example, I got a mix between “approved with passive support” and “approved with misunderstanding.” The “approved with passive support” was a result of the misunderstanding. Executives who didn’t take the time to fully understand the systems and tools were not equipped to understand it, and thus not able to be active participants. When questions arose, they had to direct them to me, the functional business leader, and this kept us in Stage 2. Reflecting on this again, I asked for the executives to “be the voice of the program,” - to bang the quality drum. At the time, I believed this was active participation, but it’s actually passive support.

Referencing the previous article on metrics, one key metric is measuring the behavior change of your executives - not just the teams and individuals using the tools of the new or enhanced business function.

To achieve the higher level performance of a Stage 3 organization, executives must think differently. If they aren’t open to spending the time to understand the new system and act differently, you’ll remain in Stage 2.

Learn from my mistake: Get explicit agreement on the staging before you proceed.

The Honest Question You Must Answer

After your business case is approved, ask yourself:

If there’s misalignment on the staging, you need to clarify immediately. Otherwise, you’ll build something that eventually gets eliminated because the economic model doesn’t work.

Be honest. Be explicit. Get true alignment before implementation begins.

Starter Questions

• How do you establish metrics to measure success?

• What if those first metrics don’t tell the right story?

True Metrics Measure Behavior Change

Establishing success metrics is difficult. I see it as more art than science. Because functions like quality, safety, and scheduling can be subjective, there are no universal measurement standards that apply to all organizations. The success of the business function or program is specific to the company, its culture, and its business strategy. How one company measures quality or productivity won’t apply directly to another.

The business leader needs to spend a lot of time thinking about metrics. It is highly unlikely the correct metric will be identified the first time. True metrics measure a change in behavior, thus the business leader must outline what behaviors should be exemplified across the company, and note specifically what Stage 2 and Stage 3 behaviors look like. This requires a “ship it” mentality, just like in technology product development. Start measuring something and see what story it tells about the process or proposed change. The data may indicate it was not worth the effort, or it show the change was incredibly valuable. Yes, there are those who believe data can be given any narrative to fit the story someone wants to tell. But that’s really about:

• How good the functional leader is at presenting data, and

• Being self-aware and open that the change may not be accomplishing what we originally thought

And that’s okay, because it’s an opportunity to improve the program further.

A Framework For Identifying Metrics

Here’s the framework to get started.

• True metrics measure the change in behavior. Identify what success looks like and the corresponding behaviors you’re looking for when team members use your system. Turn those into metrics. Your metrics should be measurable and identify the change in behavior you’re looking for.

• Example: “Simplify current program.”

  • Context: Feedback revealed inspection checklists were too long and cumbersome (50+ items per checklist).

  • Objective: Simplify the existing inspection checklists.

  • Key Result: All 150 corporate checklists are one page or 10 items or less (whichever is shorter) by October 1, 2025. (Some exceptions for building envelope or building automation systems.)

  • Measured Behavior Change: People actually use the simplified checklists because they’re manageable, not avoid them because they’re overwhelming.

Sitting with the Data: The Creative Process

You have to sit with the data. Look at it. Play with it. Move things around.

• Is profitability the best metric to measure against?

• What about schedule adherence? RFI volume? Client satisfaction? Punch list duration?

• Something else entirely?

This is like tinkering in your garage, or painting, or other creative work. Finding the metric specific to your business and the product you deliver and the change you made, this Venn diagram of context, requires experimentation. There’s no one universal metric. Each organization needs to discover what tells the truth about their specific situation.

• Example: For one company, “rework percentage” might be the perfect quality metric. For another company doing primarily design-build work, “design iterations required” might better capture quality performance. For a third doing fast-track construction, “issues caught in prefabrication vs. field” might be most relevant.

The metric depends on your delivery model, your clients, your risk profile, and what behavior you’re trying to change.

Why “Cost of Quality” Doesn’t Work as a Universal Metric

I want to take a brief detour and discuss metrics specific to design and construction quality programs: Cost of Quality. My main concern is that the cost of quality doesn’t directly measure:

• The cost of YOUR program versus its benefits IN YOUR CONTEXT

• The correlation between the program and outcomes (too many confounding variables)

• Whether you’re building competency (Stage 3) or dependency (Stage 2)

For example, Company A spends 2% of project costs on a quality program and has 3% rework. Company B spends 0.5% of project costs on quality and has 4% rework. Traditional Cost of Quality says: “Company A should reduce quality spending because they’re spending more than B with similar rework.” But the real story might be:

• Company A delivers complex healthcare projects with zero tolerance for defects.

• Company B delivers simple warehouse projects where some rework is acceptable.

• Company A’s 2% investment prevents 10% rework that would otherwise occur.

• Company B’s 0.5% investment is appropriate for their risk profile.

Universal metrics hide essential context. The functional business leader’s job is to reveal the truth about their company’s specific situation, not metrics that let you benchmark against others in meaningless ways.

Aligning Metrics with Executive Language

Before finalizing your metrics, recall the language executives use to voice their concerns related to the business function being investigated. Show them your proposed key results and ask: “Does this information provide value? Does it help us understand if we’re solving the identified problem?”

• If executives speak financially: Show metrics tied to margin, cash flow, insurance costs, or warranty expenses.

• If executives speak operationally: Show metrics tied to schedule performance, coordination efficiency, or resource utilization.

• If executives speak about people: Show metrics tied to retention, satisfaction, or career progression.

• If executives speak about clients: Show metrics tied to satisfaction scores, repeat business, or referrals.

If metrics don’t align with how executives think, you’ll have difficulty maintaining support. They won’t understand what you’re doing, so they can’t support you effectively.

The Stage 3 Metric That Matters Most

Here’s the metric that reveals whether you’re building competency or dependency:

Measure this with:

• Support requests per project over time: Should trend DOWN as competency rises.

• Time spent by support staff per project: Should trend DOWN as teams become self-sufficient.

• Staff-to-project ratio: Should improve (fewer staff supporting more projects).

• Training completion and competency assessments: Should trend UP.

Example:

• Year 1: Quality team spends 40 hours per $10M project on support and interventions.

• Year 2: Quality team spends 30 hours per $10M project (25% reduction).

• Year 3: Quality team spends 20 hours per $10M project (50% reduction from baseline).

This trend shows project teams are becoming more competent. The quality program is working by making itself less necessary. This is what Stage 3 competency looks like.

If the trend goes the other way or remains steady:

• Year 1: 40 hours per project

• Year 2: 50 hours per project

• Year 3: 60 hours per project

This is Stage 2 dependency. This is the honest metric I should have watched more carefully. Our quality team’s involvement per project stayed constant or increased over three years when steps were removed from the program and it was drastically simplified down to one page. We were creating dependency.

Reporting and Executive Support

In order for your executives to own the decision to invest, they must help make progress after approval.

• Be articulate about quarterly objectives. Don’t just report “we trained 50 people.” Report “we simplified 30 checklists and trained 50 superintendents, resulting in 40% faster inspection completion times.”

• Request tactical support from executives each time you meet. Don’t just present data. Say: “I need your help doing X to achieve this objective. Can you drive completion of the training by conducting it and being an active participant?”

Executives can’t be passive observers. They need to actively remove barriers, reinforce expectations, and hold peers accountable. For Stage 3, when the program moves to implementation, the business functional leader must set up the reporting system for executives to see how their actions drive the change, rather than the action of the functional business leader. This seems counterintuitive, but hierarchy matters. Even if executives are in the room, being a “voice” or “active supporter,” this is still passive. They need to directly demonstrate the behaviors that measure program success.

If executives approved your business case but won’t help during implementation, you’ll fail.

When Metrics Reveal Failure

I started measuring quality program “utilization”: How many projects were using our processes. That metric looked great. But it wasn’t measuring competency: Whether project teams could function without quality support. That metric would have shown dependency increasing, not competency. By the time I realized the problem, the dependency pattern was entrenched. The restructuring that eliminated my role was economically rational. We had built expensive overhead, not sustainable capability.

Choose metrics that reveal uncomfortable truths and force executives to act and drive the change.

Iterating on Metrics: The Ship-It Mentality

Remember: you won’t get metrics right the first time. Start measuring something. After a quarter or two, ask:

• Does this metric tell us whether behavior is changing?

• Does this metric reveal problems early enough to fix them?

• Does this metric align with what executives care about?

• Does this metric measure competency or just activity?

If any answer is no, change the metric. Don’t stubbornly stick with measurements that don’t serve the goal. Here’s an example iteration:

• Quarter 1 Metric: Number of quality inspections completed per project.

  • Problem: This measures activity, not quality outcomes. Could just mean more inspections of same work.

• Quarter 2 Metric: Defects identified per inspection.

  • Problem: Could incentivize finding trivial defects to hit numbers.

• Quarter 3 Metric: Percentage of defects caught before next trade starts work.

  • Better: This measures whether inspections are happening at the right time to prevent cascading problems.

• Quarter 4 Metric: Percentage of defects caught before next trade starts + time from defect identification to resolution.

  • Best: This measures both timing and effectiveness of the corrective process.

Each iteration got closer to measuring what actually matters: Preventing problems from propagating.

Be willing to iterate. The goal is truth, not consistency with the original plan. Ask:

If you can’t articulate how your metrics measure the transition from Stage 2 to Stage 3, the metrics need to be revised. Otherwise, you’ll optimize for the wrong outcome and not realize it until it’s too late.

Starter Questions

• How do you analyze input from across an entire organization?

• Should you use AI to help analyze the data?

• How do you develop the right plan for your company?

• What if the data tells you your idea won’t work?

Analyzing Conversational Feedback

When gathering feedback at scale, specific themes will have revealed themselves. Potential examples include:

• “I was never trained on the program.”

• “We need more templates to guide us.”

• “The checklists are too long.”

• “I don’t know who to call for help.”

• “We don’t have time for this.”

• “The process doesn’t match how we actually work.”

For each comment, develop a solution.

• Comment: ”I was never trained on the program.”

  • Solution: Provide regular training.

• Comment: “We need more templates to guide us.”

  • Solution: Create additional templates.

• Comment: “The checklists are too long.”

  • Solution: Simplify current documentation.

• Comment: “I don’t know who to call for help.”

  • Solution: Clarify support structure.

• Comment: “We don’t have time for this.”

  • Solution: Identify and remove redundant steps.

• Comment: “The process doesn’t match actual work.”

  • Solution: Redesign process with field input.

Continue this for all conversations. In my situation, roughly 600 comments from 300 interviews yielded 24 distinct solutions.

Quantifying the Trends

Sum up the number of times each solution appears across all interviews. Create a simple bar chart showing frequency.

Simplify current program: ████████████████████ 87 mentions
Provide regular training: ███████████████ 64 mentions
Create additional templates: ████████ 31 mentions
Clarify support structure: ██████ 23 mentions
Remove redundant steps: █████ 19 mentions

These solutions become the actions for the business case. However, you’ll need to identify which solutions to focus on first. You could choose the top five, or top ten. It depends on your capacity, your team’s capacity, and your organization’s capacity for change.

Addressing Executive Concerns Simultaneously

The solutions (actions) must address both:

• The most frequent concerns from user interviews

• The specific concerns executives raised

Example: One executive stated we can’t add any new tasks without removing two other steps (a constraint on complexity). Looking at our sample data above:

• “Simplify current program” was mentioned 87 times

• “Remove redundant steps” was mentioned 19 times

By simplifying the program and removing redundancy, we address both the superintendent feedback and the executive constraint. This makes approval far more likely.

Another example: An executive was concerned about training effectiveness. The data shows:

• “Provide regular training” mentioned 64 times

• “Simplify current program” mentioned 87 times

We can pose the following argument: “Simplifying the program makes training easier because there’s less to learn. Combined with regular training sessions, we solve both the competency gap and the complexity problem.”

When your actions solve problems at multiple levels simultaneously, approval becomes inevitable.

On the Use of AI: Why You Shouldn’t

Analyzing subjective feedback from conversations is difficult. There are more robust statistical methods than what I used, and AI tools could theoretically help. Why didn’t I just record these conversations in Microsoft Teams and load them into an AI, asking for a summary? That could have saved enormous time. Having said that, I encourage you not to use AI for this analysis (at least at first), except to validate your findings after you’ve done the thinking. A few things to consider:

1. You can’t defend AI-generated conclusions. When you present your business case, executives will ask hard questions: “Why should we approve this? Why these actions and not others? How do you know this will work?” If you used AI to analyze the data, your answer is: “Because the AI said so.” That’s not compelling. You’ll get demolished by follow-up questions.

2. You lose the context. AI can identify themes, but it can’t understand the emotion, frustration, or resignation in someone’s voice when they say: “We don’t have time for this.” That context matters when you’re deciding which problems to solve first.

3. You can’t articulate the nuance. When an executive says “But I’m very concerned about X,” and you need to respond with “I understand your concern. I talked with 150 people and that’s not what I discovered. Tell me more about your perspective,” you can only do that if you did the thinking, not the AI.

4. Critical thinking is the point. Building a business function isn’t about replicating data. It’s about demonstrating your critical thinking. Executives are betting on your judgment, not an AI’s analysis.

By analyzing the feedback yourself, you prepare for the challenging conversations that inevitably arise. You become the best-prepared person to lead the effort because you internalized all the context during analysis. This is how you become the right person with the right plan: Using data from your organization to develop actions for your business plan. You’ll have the context to back up your intentions and articulate them under pressure.

You can use AI to check your analysis for themes you missed, help format your presentation, validate your conclusions. But don’t outsource the thinking.

Prioritizing Actions

You’ve identified 10-24 potential solutions. You can’t do everything at once. How do you prioritize? Use these criteria:

1. Impact: Which actions solve the biggest problems? (Look at frequency in your data).

2. Executive Alignment: Which actions directly address executive concerns?

3. Dependencies: Which actions must happen before others can succeed?

4. Stage 3 thinking: Which actions raise competency vs. which create dependency?

To expand on the sample data above:

• Simplify current program (87 mentions) → HIGH impact, executive concern, enables training

• Provide regular training (64 mentions) → HIGH impact, depends on simplified program

• Create additional templates (31 mentions) → MEDIUM impact, quick win

• Clarify support structure (23 mentions) → MEDIUM impact, quick win

• Remove redundant steps (19 mentions) → Covered by #1 (simplification)

Priority 1: Simplify the program (enables everything else, addresses most concerns).

Priority 2: Provide training on simplified program (raises competency, not dependency).

Priority 3: Clarify support structure (quick win, prevents confusion during rollout).

Priority 4: Create templates as needed based on training feedback (iterative, not upfront).

This gives you a logical sequence that builds momentum while addressing root causes.

The Stage 2 vs. Stage 3 Lens

While analyzing solutions, ask for each one: “Does this raise competency or create dependency?”

• Raises Competency (Stage 3):

  • Simplify processes so people can use them

  • Train people to do the work themselves

  • Provide tools and templates as aids

  • Create clear standards and expectations

  • Hold people accountable for results

• Creates Dependency (Stage 2):

  • Hire staff to do work for project teams

  • Add support roles that take over tasks

  • Create processes so complex only SMEs can navigate them

  • Position the function as a service provided to projects instead of by projects

Every action should pass this test. If the data is full of dependency-creating solutions, you’re building expensive overhead that won’t scale.

Showing Your Work

When presenting the business case, it’s essential to be transparent about how you came to your conclusions.

• Summary data: Bar charts showing solution frequency

• Sample quotes: Anonymous representative comments (with role/tenure for context)

• Demographic coverage: Table showing you interviewed across regions, roles, tenure

• Analysis methodology: Brief explanation of how you coded and analyzed feedback

The act of preparing these materials forces you to ensure your analysis is actually rigorous, not just confirmation bias. Most executives won't want to see this detail, though asking ahead of time about their preferred level of depth can be helpful. Some will ask “How do you know this is right?” and you’ll need to show your work, or at least be able to briefly and effectively articulate it.

Data is the Truth

After analyzing 300+ comments and identifying 10-20 solutions, ask yourself:

If the honest answer is “more dependent,” you’re building a business case for expensive overhead. Either redesign your actions or admit you’re choosing the Stage 2 knowingly. If it’s “more competent,” you’re building a business case for sustainable capability. That’s what scales. The data tells you the truth. Your job is to listen and respond honestly, even if it contradicts what you wanted to build initially. Even if it creates tension at the leadership level. How the company navigates that tension will help the functional leader understand if the company will accept the direction the data is instructing them to go.

Starter Questions

• Do you know what to focus on first when creating a new business function?

• What does [quality/safety/scheduling/your function] mean to your employees?

• How will the new business function make everyone’s jobs easier?

Identifying Function Users and Stakeholders

After stakeholders and mobilizers are identified at the executive level, the functional business leader must then identify the future users of the program and those impacted by enhancing an existing one, and gather feedback at scale to analyze that data to form the plan for moving from Stage 1, then to 2, and finally to 3 (again, if the organization has the grit, discipline, and accountability to do so).

Executives often have theories about what’s wrong, and the users above will know exactly what’s not working. Both theories and concerns at the executive and production levels must be validated against one another as part of this feedback process.

For a typical construction or design organization, users include:

• Project Managers

• Design Managers

• Superintendents

• Directors of Construction / Principals

• Field Leaders / Assistant Superintendents

• Estimators (if preconstruction involvement)

• Project Architects (for design-build)

Data from the above conversations needs to address concerns at all levels, or constructively articulate why previous assumptions don’t match actual business operations.

Listening for Dependency and Competency Gaps

During interviews, pay attention to how they describe their needs. The language reveals whether there’s a training problem or a dependency culture (Stage 2).

Dependency Language (Stage 2):

• “I need a quality person on my project.”

• “We can’t do quality without support staff.”

• “The safety team should handle that.”

• “That’s what the scheduler is for.”

• “I don’t have time.”

Competency Gap (Moving to Stage 3; often resolved with training):

• “I was never trained on the quality process.”

• “I don’t understand what’s expected or what good looks like.”

• “The checklist is too complicated to use.”

The first indicates a cultural problem where people believe support functions do the work. The second indicates a solvable training, process, resource problem, or a lack of leadership discipline and accountability.

The new business function must solve the second while preventing the first.

Sample Size: How Many Interviews?

The actions in the functional business case are solutions that resolve aligned employee and executive concerns. Developing the correct solutions requires interviewing enough people to identify trends across a broad demographic.

• Too Few Interviews: The loudest voices and strongest opinions have unbalanced influence.

• Sufficient Interviews: Trends emerge clearly. There’s confidence that solutions will work across the demographic diversity of your organization.

The sample size is sufficient when new themes stop appearing (saturation), there’s broad demographic representation (multiple roles, departments, product types/sectors, tenure and geographies), and the trends are clear and consistent.

Within a 2,000-person organization, I interviewed roughly 300 people. I could have stopped at 200 - the trends were clear - but I didn’t have broad enough demographic coverage and needed more representation. At a smaller organization, 30 to 50 people may suffice. The percentage of the workforce matters more than absolute numbers.

However, one mistake I made was underestimating the multiplier that tenure has in an organization’s culture. Opinions, even when wrong, carry more weight when attached to someone with a lot of tenure. Discipline and accountability can help here, but it may not be an obstacle that one person can overcome. This is a timing issue: Is the company ready to go through with this change now? In my situation, even when the COO wanted the change, it was not enough to overcome the tenure multiplier. The functional leader will need to determine if the company is ready for the proposed change.

Sample Questions

If the leader is building a function from scratch:

• How would a [quality/safety/scheduling] program make your job easier?

• What do you think this program should look like?

• How would you structure it?

• What tools are we missing?

• How do you manage [this function] now without an established corporate program?

If enhancing an existing function:

• How familiar are you with the current [function] process?

• Is the current program used on your projects?

• What does [quality/safety/effective scheduling] mean to you?

• What changes would you make to the current program?

• Why don’t you use it (if they admit they don’t)?

Always close with: “Who should I talk to next to have a similar conversation?” This builds the support network and ensures you’re not just talking to people your supervisor thinks you should talk to.

Interview Strategy for Maximum Effectiveness

The following tactical details matter more than you think.

1. Get a lighter workload temporarily. Gathering feedback from 50-300 people is a full-time job. You need time for conducting interviews and analyzing the data. It took me 3 months to interview 300 people while maintaining partial regular duties. If your organization won’t reduce your workload for this effort, they’re not actually serious about the business case. Push back on this or you’ll burn out.

2. Schedule separate time blocks for interviewing and analysis. I used Cal Newport’s Deep Work principles: interviews in mornings, analysis in afternoons. This prevented me from drowning in unanalyzed data while maintaining focus during interviews. Context-switching between interviewing and analysis kills effectiveness. Block your calendar intentionally.

3. Include context and questions in the meeting invite. I had two sections in every invite:

   1. Context: Why I’m conducting this interview (to hear their ideas on making our program more effective).

   2. Agenda: The specific questions I intended to ask.

4. Send a separate email with the agenda. People accept calendar invites without reading them. Send the questions separately a few days before the meeting so they can prepare thoughtful responses.

5. Schedule invites at least 2 weeks in advance. Respect their time. Give them adequate notice and preparation time.

6. Schedule 30 minutes maximum. Be effective with your time. If you’re having a meaningful discussion and 30 minutes isn’t enough, schedule a follow-up rather than running long and throwing off your entire schedule. At 30 minutes per interview with 100 people, that’s 50 hours of interviewing alone, plus 50+ hours of analysis. Plan accordingly.

7. Keep discussions one-on-one. Do not interview groups, no matter how tempting. Group dynamics create groupthink. You want honest individual perspectives, not consensus opinions. One-on-one interviews let you dig deeper: “Tell me more about that. Why do you think that is? What would solve it?”

8. Be transparent about confidentiality. Tell each person: “This is a safe place. I’m asking for your genuine thoughts. I’ll be sharing titles and commentary with executives, but not names.” People won’t be honest if they fear repercussions. Protect them while gathering data you can use.

9. Follow the conversational cycle: listen, think, ask questions. You are the listener. These interviews are not the opportunity to tell others what you think the program should look like. Your opinion matters, but it cannot be the primary basis for your business case.

The best skill for many in the industry is keeping our thoughts to ourselves and actively listening for understanding when someone says something we disagree with.

The Feedback Goal: Make Hard Jobs Easier

The business case needs to streamline the roles with the most responsibility. This isn’t about one person’s job being “harder” than another. All roles in construction are difficult. But identify roles with the heaviest workload and show how your program reduces burden. By specifically streamlining the work of program users, you’ll gain their buy-in and the buy-in of executives who care about their people.

Example: If superintendents are your target role, your interviews might reveal:

• They spend 3 hours/week in coordination meetings.

• They fill out redundant paperwork for multiple tracking systems.

• They can’t find the current schedule or quality checklists.

• They’re called into the office for reports instead of staying on site.

Your business case should show how streamlining these specific pain points gives them 5+ hours back per week - hours they can spend managing the actual work instead of administrative overhead. That’s a business case that gets support from both superintendents and executives.

However, an additional note here about what I learned the hard way regarding simplification and streamlining. Most concerns I noted regarding the quality program were related to simplification. Most user groups thought the program was too complicated. I went through two versions of the quality program over 18 months and the feedback remained largely the same. I accept responsibility for not piloting the changes first before rolling out to the enterprise, yet there is a point where the lines cross. It becomes an accountability issue when the process becomes too simple to deliver what the business needs yet teams still believe it’s too complicated.

Interview Revelations

These interviews showcase far more than what do people think about the business function being discussed. They reveal:

1. Baseline Competency Levels

   1. Can PMs read specifications and extract quality requirements?

   2. Do superintendents understand inspection sequencing?

   3. Do field leaders know how to identify and document defects?

2. Process Barriers

   1. Are your processes too complicated?

   2. Do people lack access to tools they need?

   3. Are there redundant steps that waste time?

3. Cultural Dynamics

   1. Do people see [this function] as their responsibility or someone else’s job?

   2. Is there trust between field and corporate?

   3. Do people feel supported or micromanaged?

4. Resource Constraints

   1. Are people genuinely too busy, or is it a priority issue?

   2. Do they lack training, or do they lack time to apply training?

   3. Are they understaffed, or are they inefficient?

5. The Stage 2 Trap

   1. Are people asking for support staff to do work for them?

   2. Or are they asking for training so they can do it themselves?

Pay attention to this last one. If most feedback is “we need quality people on our projects,” there’s a dependency problem that a new program will make worse, not better. The data needs to discover the cultural accountability problem before implementing the business function.

Setting Up for Analysis

As you conduct interviews, create a simple system for capturing feedback.

• Record each distinct comment:

  • “I was never trained on the program.”

  • “We need more templates to guide us.”

  • “The checklists are too long and complicated.”

  • “I don’t know who to call when I have questions.”

• Don’t editorialize during interviews. Just capture what you hear. The analysis is only as good as the data you gather.

Building the Support Network

Throughout these interviews, you’re building something beyond data: A network of people who will support the implementation, where you’ll need:

• Early adopters who test new processes

• Influencers who encourage peers to adopt changes

• Champions who defend your program when others resist

The people who gave you thoughtful feedback during interviews are your candidates for these roles. Keep track of who showed genuine interest in improving things. They’re the implementation team.

The Honest Question

After 50, 100, or 300 interviews, ask:

If it’s overwhelmingly the former, the organization has a deeper problem that the business function won’t solve. There’s a competency crisis and dependency culture that requires leadership intervention (though it may be a result of leadership also). Building a Stage 2 support function to compensate for permanent incompetence is a career dead-end.

If it’s primarily the latter, the problem is solvable. Build the training, simplify the processes, provide the tools, hold people accountable. Building a Stage 2 function to temporarily establish standards while raising competency is legitimate change management.

Starter Questions

• Do you know what your executives’ real concerns are?

• Do your executives understand what this function means at your organization?

• What “language” do your executives speak—financial, operational, people, or clients?

• Are your executives thinking about Stage 2 Scaffolding or Stage 3 Competency?

Always Selling

Whether we acknowledge it or not, we all work in a sales role, selling our ideas daily, regardless of our title. Creating a business case for a support function or major organizational change is no different. We’re selling a strategic business decision to multiple stakeholders who all have veto power.

In The Challenger Customer, the authors note:

“More often than not, it’s purchase by committee. It’s collective consensus across a formal or informal group of senior employees, each with the ability to stop a deal if it fails to meet their particular needs or speak to their individual priorities.”

They found that the average B2B purchase involves 5.4 different people formally involved in the decision. Any business case faces the same dynamic. Even if one executive “owns” the decision, informal influencers throughout leadership will shape whether the proposal succeeds or dies quietly.

Identifying Executive Mobilizers

The same book introduces the concept of a “Mobilizer,” someone who mobilizes the organization to act, forges consensus, and champions change. Within any company, we must identify this group of informal decision-makers and understand their needs within the context of company strategy. The goal is to interview executives to understand their concerns and identify who will be the advocate (the Mobilizer).

Here’s the critical addition based on my experience: We need to understand which stage they’re thinking about.

When an executive says “We need to invest in quality,” are they envisioning:

• Stage 2 Thinking: “We need quality people to do quality work on our projects.”

• Stage 3 Thinking: “We need to raise our project teams’ baseline competency in quality.”

The first creates permanent overhead. The second creates scalable capability, which is why the interviews with executives matter. We need to clarify what they want - or educate them on what the company actually needs. Some executives won’t ever get to a place where they recognize what stage the company is in or what they are striving for. Stage 3 aspirations often look like Stage 2 results, which is why most companies never move beyond Stage 2.

Questions to Ask

Use these to understand both their concerns and their mental model:

Understanding Current Concerns:

• What are your concerns regarding our current [quality/safety/scheduling] program (or lack of one)?

• What is the root cause of most of our project delays?

• What projects are over budget? Why?

• When you walk onto one of our jobsites, how do you feel?

• What clients aren’t coming back? What are they saying about us?

Understanding Expectations:

• Are you open to the idea of a more robust [function] program? Why or why not?

• What value or ROI would you expect from this program? Financial? Operational? Cultural? Reputational?

• What does [quality/safety/effective scheduling] mean to you?

Understanding Barriers and Models:

• What is the barrier to further investment in [this function]?

• If we build this function, should it be centralized (corporate overhead available to all projects) or decentralized (embedded in project teams)?

• In three years, if this is successful, what does it look like? More staff supporting projects, or fewer staff needed because teams are more competent?

Building a Network:

• Who should I talk to next to have a similar conversation?

• Would you be willing to introduce me to them?

That last question is key. It identifies other decision-makers and creates awareness of the business case effort across leadership. Each introduction builds momentum.

Learning Their Language

Pay close attention to how executives answer these questions. Their language reveals what matters to them.

• Financial Language: ROI, margin improvement, risk reduction, insurance costs, warranty expenses, overhead ratios.

• Operational Language: Schedule certainty, coordination efficiency, rework reduction, punch list duration.

• People Language: Employee retention, team morale, career development, knowledge transfer.

• Client Language: Satisfaction scores, repeat business, referrals, competitive differentiation.

The final version of the business case must directly address their concerns using their language. An executive who thinks financially needs to hear: “This program will save $X per project by reducing rework from 5% to 2%.” An executive who thinks about people needs to hear: “This program will reduce superintendent turnover by making their jobs easier and more successful.”

The Stage 2 vs. Stage 3 Conversation

This is the most important discussion to be had, even if executives haven’t explicitly thought about it this way.

• “I want to make sure we’re aligned on the end goal. Many companies build [quality/safety/scheduling] as a centralized team that supports projects permanently, overhead that grows with project volume. Others build it as temporary support to raise baseline competency, then transition to minimal oversight. Which model makes sense for our business?”

Most executives will need time to think about this. They need to consider the economic implications of both. Most companies don’t have the stomach for pushing the cultural shift required to achieve Stage 3.

There are two different responses to this.

• Executive Stage 2: “We need a team to support our projects.”

  • Functional Leader: “Got it. How do we prevent that team from becoming a permanent dependency? What does competent project leadership look like so we’re not adding support staff proportionally forever?”

• Executive Stage 3: “We need our project teams to be better at this.”

  • Functional Leader: “Agreed. Do we need a temporary centralized function to establish standards and train teams, or can we get there through decentralized training and accountability?”

The honest answer for most organizations is: “We need Stage 2 temporarily to establish standards, with a clear plan to transition to Stage 3.” Make sure executives understand this from the beginning. Again, the main issue is most companies never achieve the leap from Stage 2 to Stage 3.

Example Critical Points

As I built the quality program over 4.5 years, I learned the following critical points.

1. Quantify the positive impact for the organization. How will investment in the business function help the company improve operationally? Will it win more work? Improve client relationships? Reduce risk? Increase margins? Make projects run smoother?

2. Make the hardest job easier. All roles are difficult, but identify the role with the most responsibility and show how the proposed business function saves them time and makes them more effective.

3. Organizations can only absorb so much change. Timing matters. Even a perfect business case fails if introduced during organizational change overload. Just like people, companies have limited capacity for simultaneous change initiatives. If the organization already has multiple major initiatives for the next year, your business case could get overshadowed or delayed.

4. The function definition must be extremely clear and tangible. The subjective nature (quality, safety, or “good scheduling”) must be made objective within the context of the organization. Vague definitions create vague programs.

5. The function must deliver to the bottom line. It may not be able to be completely quantified. Even though correlation may be impossible to prove definitively, the business case must outline how this function will increase organizational value.

The Non-Negotiable Foundation

Company leadership has to be fully behind it. Without leadership buy-in (genuine, active support - not passive approval) the business case will fail during implementation even if it gets approved on paper.

In my own experience, I could have been more explicit about what “executive support” actually looked like. It’s more than “banging the drum.” It needs to be clear and tactical. They need to be active participants in bringing the function to life. When executives are passively supporting - talking or preaching in presentations that teams need to utilize the function, for example - this keeps the company in Stage 2. When they utilize the business function themselves, they move to Stage 3.

To leverage another quality example: Reviewing warranty data.

• Stage 2 (passive leadership): Executives wait for the quality leader to provide warranty data, and the quality leader tells the executives what the company should focus on.

• Stage 3 (active leadership): Executives are able to review the data themselves and develop actions specific to their focus areas. The quality leader ensures the data is actionable, clear, and accurate, and that the reporting function is available.

The Uncomfortable Question

After these executive conversations, we need to honestly assess:

If executives are describing Stage 2 permanent overhead without understanding the economic implications, there are two choices:

1. Educate them on the Stage 2 trap before proceeding.

2. Accept that we’re building expensive overhead and the company may not have the cultural accountability or discipline to push onward to Stage 3.

I chose option 1. Looking back, I should have been more explicit about the economic reality. Executives approved the Stage 2 build without fully grasping the Stage 3 transition. When market conditions softened, the overhead became unsustainable.

Make the staging explicit in executive conversations before investing months in building a business case and implementing with passive support. Executive buy-in isn’t a checkbox. It’s the foundation everything else rests on.

• Are your support functions integrated into daily business operations?

• How does your company create value?

• How can you justify investment in functions that don’t directly bill clients?

Introduction

In operations, there are many functions to manage: quality, safety, scheduling, BIM/VDC, preconstruction, commissioning, engineering support. Each group requests more budget, presenting business cases that illustrate how their function is critical to success. Each believes they’re undervalued and under-resourced.

During budgeting season, we attempt to answer the difficult question: “Why are we spending $2M on these support functions when they don’t directly generate revenue?” Meanwhile, our project teams say: “These corporate groups create more work than they solve. We don’t have time for their processes.”

This is the central tension in design and construction operations. Support functions like quality or scheduling are necessary but often perceived as overhead burdens rather than value creators. The question isn’t whether we need them (we do), but how to structure, resource, and position them so they advance business objectives rather than exist in isolated silos.

Definitions of a Business Function

When we think about new business support functions, or enhancing an existing one, there are two distinct viewpoints:

• Function as a Process

• Function as a Result

Function as a Process

Many view business functions as processes, and most operate that way in isolation. Consider the following examples where each function is a department with a director serving as the executive process owner for their area.

• Quality: When a quality director exists, they become the “quality expert” in everyone’s minds. Quality knowledge flows through this single person rather than through company leadership and into daily operations. Quality becomes “something the quality team does” rather than “how we execute work.”

• Safety: The safety director becomes responsible for all safety outcomes. Field teams wait for the safety person to tell them what to do rather than owning safety themselves.

• Scheduling: The scheduling team creates beautiful CPM schedules (because field teams “don’t have time to create or update their schedules”) that project teams don’t use (because “the schedulers don’t understand the reality of the field”).

• BIM/VDC: The technology group develops sophisticated models that sit unused because estimating and preconstruction teams are “too busy building to deal with virtual construction”.

This structure is logical but creates unintended consequences. Discrete tasks and tools that stand alone from daily work. Quality programs, safety systems, and scheduling functions become “requirements” that project teams must comply with, like contract obligations or insurance mandates. When teams are under pressure, these process-based functions lose focus and become isolated. This isolation creates a predictable pattern:

1. Support function develops processes and tools

2. Project teams don’t use them (”we’re too busy”)

3. Support function blames projects for non-compliance

4. Projects blame support for creating irrelevant bureaucracy

5. Executives question ROI and consider cuts

6. The cycle repeats

From a project team’s perspective, these business functions become extra administrative work, perpetuating the feeling that “we don’t have time for quality” (or safety, or proper scheduling, or other process). And, when functional leaders (often Subject Matter Experts, or SMEs) pitch these processes to project teams, they set themselves up for failure. The teams think of it as something extra to do on top of everything else. Time is a real constraint on jobsites and in project offices, a constraint that must be respected.

Function as a Decision

A better view of these functions is to see them as decisions. Results of doing all the right things well. If we plan properly, allocate sufficient resources, communicate effectively, and execute with discipline, these management elements combine to produce the result (quality, safety, on-time delivery, etc.). When a business holds this view, the “function” isn’t a separate process, rather it’s embedded in how work gets done.

• Quality

  • As a Process: Inspection checklists, submittal reviews, testing protocols - seen as extra administrative work.

  • As a Decision: Zero punch list at substantial completion, no warranty callbacks, repeat clients, higher margins - seen as the outcome of excellent execution.

• Safety

  • As a Process: Toolbox talks, safety observations, JHAs - seen as compliance theater.

  • As a Decision: Everyone goes home healthy, lower insurance premiums, faster project approvals, better talent retention - seen as the outcome of a mature culture.

• Scheduling

  • As a Process: Updating the CPM, printing 3-week lookaheads, attending coordination meetings - seen as corporate reporting requirements.

  • As a Decision: Predictable delivery, optimized cash flow, efficient subcontractor utilization, premium fee recognition - seen as the outcome of disciplined planning.

Establishing a safety or quality function is a strategic business decision. The business decides where to allocate limited capital and overhead, how to structure it for a competitive advantage, how it will differentiate the company in the market, and which investments will compound over time versus providing one-time benefits.

When we see business functions as decisions rather than processes, we change the conversation from “Do we have time for this?” to “How do we achieve this outcome?” Establishing a business case means influencing this strategic business decision by planning the function into everyday operations, while creating a clear path that makes the function decentralized across the entire company and thus unnecessary.

Here’s how to align any business function with business strategy.

1. Identify company focus areas. These come from the strategic business plan.

   1. Enter new geographic markets

   2. Achieve X% year-over-year growth

   3. Improve employee retention by Y%

   4. Expand into new sectors (data centers, healthcare, etc.)

   5. Vertical integration of supply chain

   6. Improve project margin by Z basis points

2. Map business function focus areas. For each focus area, identify which support functions directly impact success.

   1. Focus Area: Enter healthcare market.

      1. Quality: Healthcare clients demand robust QA/QC programs with specific certifications.

      2. Safety: Healthcare work requires infection control protocols and occupied space expertise.

      3. Scheduling: Healthcare schedules are more complex due to phasing and operational constraints.

      4. Commissioning: Healthcare facilities have extensive systems requiring specialized commissioning.

   2. Focus Area: Improve project margins by 200 basis points.

      1. Preconstruction: Better estimating and scope definition prevents buyout gaps.

      2. Scheduling: Optimized schedules reduce general conditions and improve cash flow.

      3. Quality: Reduced rework directly improves margins.

      4. VDC: Clash detection prevents costly field coordination issues.

3. Interview department leaders. Each department has business objectives that should advance company focus areas. Interview these leaders, asking the following questions. Their answers will reveal whether they see the function as value-add or bureaucracy, what their real constraints and pain points are, how the function should be designed to solve actual problems, and what success metrics matter to them. Pay attention to their language. Financial leaders speak in margins, cash flows, and risk mitigation. Operations leaders speak in schedule certainty and subcontractor coordination. Business development leaders speak in win rates and client retention.

   1. How would an enhanced [function] capability help you achieve your departmental goals?

   2. What specific problems would a robust [function] solve for your team?

   3. What ROI would you expect from investing in [function]?

   4. How should this function be structured to actually help rather than create work?

4. Define the function clearly. Each function needs a clear, tactical definition that translates from executive level to field level.

   1. Quality

      1. Poor: “Quality is conformance to requirements” (too vague)

      2. Better: “Quality is zero punch list at substantial completion with first-time client satisfaction score >4.5/5.0” (measurable)

   2. Safety

      1. Poor: “Safety is our top priority” (meaningless platitude)

      2. Better: “Safety is zero recordable incidents, 100% foreman OSHA-30 certification, and proactive hazard identification that prevents incidents before they occur” (specific)

   3. Scheduling

      1. Poor: “Scheduling ensures on-time delivery” (circular)

      2. Better: “Scheduling is predictive planning that sequences work for optimal productivity, alerts teams to constraints 3 weeks in advance, and enables recovery when deviations occur” (actionable)

5. Establish function objectives. These are the specific actions the business function will take to advance business objectives. They must directly address departmental concerns, align with company focus areas, solve real problems (not theoretical ones), and are achievable with available resources.

   1. Quality: “Reduce punch list duration from 45 days to 15 days by implementing progressive inspections throughout construction, resulting in $X savings per project in general conditions.” This objective:

      1. Solves a real problem (slow closeouts)

      2. Has financial impact (reduced GCs)

      3. Advances a business goal (improved margins)

      4. Is measurable (45 days → 15 days)

   2. Safety: “Achieve prequalification for federal healthcare work by obtaining OSHA VPP certification, enabling pursuit of $500M in annual healthcare opportunities.”

   3. Scheduling: “Implement 3-week lookahead planning on all projects >$10M to reduce coordination delays by 30%, improving schedule certainty and subcontractor satisfaction scores.”

6. Define success metrics (Key Results). For each objective, establish metrics that prove value creation.

   1. Quality

      1. Punch list item count at substantial completion

      2. Days from substantial completion to final completion

      3. Client satisfaction scores

      4. Warranty callback frequency and cost

   2. Safety

      1. Total Recordable Incident Rate (TRIR)

      2. Experience Modification Rate (EMR)

      3. Near-miss reporting rate (leading indicator of culture)

      4. Safety observation completion rate

   3. Scheduling

      1. Percentage of milestones hit within 1 week of plan

      2. Average variance between forecasted and actual completion

      3. Subcontractor satisfaction with schedule communication

      4. Time spent in recovery planning vs. proactive planning

Application to Other Business Functions

This framework applies universally. Here’s how to adapt it.

• BIM/VDC

  • Focus Area: Reduce rework and coordination issues.

  • Stakeholder: Operations and project engineering leaders.

  • Definition: “VDC is clash-free coordination that prevents field issues, not just pretty models.”

  • Objectives: Achieve <50 field coordination issues per $10M of MEP scope.

  • Metrics: Field coordination issues per project, time saved in prefabrication, change order reduction

• Preconstruction

  • Focus Area: Improve win rate and project margin

  • Stakeholder: Business development and estimating leaders.

  • Definition: “Preconstruction is early engagement that optimizes design for constructability and cost certainty.”

  • Objectives: Increase design-build win rate from 25% to 35% through superior preconstruction.

  • Metrics: Win rate by delivery method, scope gap at buyout, client satisfaction with preconstruction.

• Commissioning

  • Focus Area: Enter healthcare and life sciences markets.

  • Stakeholder: Operations leaders and sector champions.

  • Definition: “Commissioning is systematic verification that all systems perform as designed.”

  • Objectives: Achieve 100% first-time commissioning pass rate, reducing closeout by 30 days.

  • Metrics: Commissioning deficiency rate, time from substantial to final completion, owner training effectiveness.

Unique Challenges

Unlike functional leaders who advocate for their single area, you’re managing the entire portfolio. This requires:

• Trade-off decisions: When quality needs investment but safety is understaffed, which gets priority? Framework: Which function has the most direct impact on your top business objective right now?

• Resource allocation: Should you centralize support functions (higher overhead, more expertise) or decentralize them (embedded in projects, more agile)? Framework: Depends on market complexity and talent availability. See my previous cost allocation article for detailed analysis.

• Scaling dynamics: In growth markets, centralized support can’t keep pace. In down markets, centralized overhead becomes unsustainable. Framework: Build hybrid models that flex with market conditions—small corporate core with decentralized execution.

• Preventing competition: When every support function claims to be most important, how do you prevent internal competition for resources? Framework: Measure each function against the same standard—contribution to strategic business objectives—not against each other.

Warning Signs Support Functions Are Isolated

You’ll know alignment is failing when:

• Project teams bypass support functions or comply minimally

• Support function leaders complain about “lack of buy-in”

• Executives question the ROI of support functions

• High turnover in support roles (people feel undervalued)

• Support functions compete for executive attention rather than collaborate

• Reporting focuses on activity (# of inspections, # of safety talks) rather than results (outcomes achieved)

Making Integration Real

Integration isn’t a one-time alignment exercise. It requires:

• Ongoing communication: Monthly reviews where support function leaders report on how their work advanced business objectives, not just completion of tasks.

• Cross-functional collaboration: Quality should inform safety investigations. Scheduling should inform preconstruction staffing. VDC should inform commissioning planning. Break down silos systematically.

• Shared accountability: When projects succeed or fail, support functions share credit or responsibility alongside project teams. This creates ownership rather than finger-pointing.

• Executive reinforcement: You must consistently message that support functions exist to advance business objectives, not to create compliance work. When you see isolated behavior, call it out.

Conclusion

This framework - mapping functions to strategy, interviewing stakeholders, defining clearly, establishing aligned objectives, and measuring results - works for any support function in any construction organization. Quality just happens to be an excellent case study because it’s universally misunderstood as “extra work” when it should be understood as “the outcome of excellent execution.” The same applies to safety, scheduling, BIM, commissioning, and every other support function you’re responsible for.

When support functions align with business strategy:

• They justify their costs through measurable contributions to business objectives

• Project teams use them because they solve real problems

• Executives support investment because ROI is clear

• The functions themselves attract better talent because the work matters

When support functions operate in isolation:

• They’re seen as overhead to cut in tough markets

• Project teams view them as bureaucratic obstacles

• Executives question their value

• The functions become demoralized and defensive

The difference isn’t the technical competence of the support function. It’s whether the function is positioned as a strategic enabler of business objectives or an isolated process.

Back in 2024, I wrote a series outlining how I created a business case for quality at a top 30 ENR general contractor.

1. Introduction: How to Build a Compelling Business Case for Quality

2. Integrate Quality and Business Strategy

3. Secure Executive Buy-In

4. Gather Feedback Across Your Organization

5. Establish the Business Case Actions

6. Identify Success Metrics and Reporting Needs

7. Present the Business Case

8. 5 Elements for Successful Implementation

It was intended to help anyone build a quality program or other business support function, such as scheduling, safety, commissioning, VDC, or operational excellence. At the time of the original writing, I was three years into the process. I interviewed several hundred people to gather data, developed a comprehensive business case, achieved executive buy-in (or so I thought), and trained on the enhanced process in a national rollout. Then, in an interesting turn of events, the quality team and my position were eliminated in a major restructuring in December of 2025.

I reviewed this series again and felt it needed to be revised to articulate what I learned during this career transition:

However, we need to understand the economic reality: If the business function grows linearly with project volume, it becomes expensive overhead rather than organizational capability. Finding this balance in transition is essential to effective business management.

I'm publishing this rewrite for two reasons: First, intellectual honesty demands I close the loop on my previous work. Second, the construction industry needs this economic argument. We continue building expensive centralized subject matter expertise structures without planning exits. If this helps one operations leader avoid that trap, it's worth sharing, even if it means admitting I got the original ending wrong.

This reflection isn’t about failure. It’s about discovering what happens when knowledge becomes overly centralized in a business.

Overly Centralized Knowledge

Picture a project manager or superintendent trying to manage a complex project, constantly calling five different subject matter expert (SME) groups to get the information or help they need:

• Scheduling (can’t build their own CPM)

• Safety (doesn’t know basics of hazard identification)

• Quality (relies on quality team for inspections and running meetings)

• Procurement (needs help with subcontract terms)

• MEP (can’t read an electrical one-line)

Each SME group gets overloaded supporting all the PMs and superintendents, thus more SMEs are hired. Those get overloaded. Hire more. Overhead grows while project leaders remain incompetent in the basics, constantly navigating change as the SME groups attempt to simplify their systems and processes. This cycle continues as project volume increases, then once the market softens, these functions are cut, along with that knowledge. The design equivalent is having brilliant designers who can’t use Revit, then a “Revit Department” is created to model for them.

The cost doesn’t scale. More project volume means more SME overhead. The business can’t ever get efficient or effective in this mode.

The Maturity Model

After experiencing this personally, I now see organizational development in three stages:

Stage 1: Chaos (No Program)

• No standards, everyone does their own thing

• Inconsistent execution, high risk

• Difficulty scaling beyond a handful of projects

• Leadership knows this is unsustainable

Stage 2: Centralized SME Program (Temporary Bridge)

• Establish standards, create consistency, prove value

• Necessary to get control and build momentum

• Overhead grows, dependency increases, knowledge fragments

Stage 3: Decentralized Competency (Target State)

• Knowledge embedded in project leaders

• Minimal central oversight (1 or 2 executive process owners)

• Scales with business growth naturally

• Support functions are strategic advisors, not doers

Most organizations need Stage 2 to get from Stage 1 to Stage 3. The mistake is building Stage 2 without planning the exit to Stage 3.

What I learned the hard way is that most organizations need centralized business functions to establish standards and create consistency. However, if we build Stage 2 without planning the exit to Stage 3 - decentralized competency – we unintentionally create an expensive problem. Using quality as an example:

• Year 1: Hire quality manager to establish standards. Project teams are grateful for help.

• Year 2: Hire 2 more quality staff to support growing project volume. Teams become increasingly dependent.

• Year 3: Hire 4 more because existing staff are overwhelmed. Teams now can’t function without quality support.

• Year 4: Quality staff overwhelmed supporting project teams. Hire more to support the supporters.

• Year 5: Executives ask: “Why does our quality overhead keep growing?”

Another great example of this is learning and development groups. Many organizations establish training departments to create materials to mentor their project managers and superintendents. I’m not disrespecting these teams, rather asking the hard question: What is the expense of this group costing the company, rather than holding project manager and superintendent team leaders responsible for producing the same materials? (I wrote about why leaders should train previously. You can read that article here.)

If the business function headcount grows proportionally with project volume, we haven’t built capability. Instead, we’ve created an expensive dependency. In the cycle above, the project team’s knowledge of the quality program decreases, becoming more centralized in the quality business function to a point where the lift is too much for the team to begin planning for quality, therefore they don’t do it.

Compare this to competency-based scaling.

• Year 1: Hire quality manager to develop standards and training program.

• Year 2: The quality manager trains all superintendents and project managers on quality basics. The quality manager mentors rather than doing the work.

• Year 3: Project teams manage quality themselves; quality manager provides strategic oversight only.

• Year 4: Same quality manager supports 3x the project volume because teams are competent.

• Year 5: Executives ask: “How does one person support so many projects?” Because the project teams and leaders are competent and the knowledge is decentralized.

However, this requires significant accountability and discipline at the middle management level and above, often far beyond what those leaders are comfortable exhibiting. This discomfort shows up as functional overhead, along with the unseen costs of cycling through growth (new employee onboarding, training, process improvement, scaling) then downsizing and restructuring (shifting and reorganizing workflows and business functions, overloading remaining departments and people).

The business case should explicitly target the second model – scaled, decentralized competency - even if the first mode is needed temporarily.

The Difficult Question

Before building a business case, we need to answer the tough question:

If it’s the latter, don’t build it. This creates expensive overhead that won’t scale. If it’s the former, the business case must explicitly state:

• What baseline competency looks like for project teams

• How we’ll measure competency growth over time

• When and how to transition from doing the work to teaching the work

• What “success” looks like if it means eventually needing fewer support staff

This is uncomfortable and ironic because business function leaders must plan to make their function smaller or obsolete. Build a bridge with a clear entry and exit rather than a monument. It’s the only economically sustainable path.

A New Framework for Creating a Business Function

With this new knowledge and experience, I’m revisiting my original business case series and expanding it to include what I learned over the past four years. This series will show you how to:

1. Align support functions with business strategy without creating isolated processes

2. Get executive buy-in by speaking their language and proving ROI

3. Gather feedback at scale (hundreds of interviews taught me this methodology)

4. Analyze feedback and develop actions without AI shortcuts robbing teams of their critical thinking

5. Define success metrics that measure competency growth, not SME activity

6. Present compelling business cases that get approved and funded

7. Implement successfully (navigating the long culture shift)

Each article uses quality management as the primary example because that’s what I lived. The principles apply to any support function or organizational change initiative. I’m aware of the irony here that I’m sharing the frameworks to build what I built while also saying it shouldn’t be completely centralized long-term.

Irony aside, this is the honest path. Most design and construction companies need the centralized bridge, but it can’t be done to a fault.

Who This Is For

This framework is for:

• COOs and operations leaders managing portfolios of support functions

• Directors building new programs (project management, quality, safety, scheduling, VDC, etc.)

• VPs trying to scale operations without proportionally scaling overhead

• Anyone tasked with organizational change who needs to build a compelling business case

The Elements of Success

Implementation of any support function or organizational change requires:

• Being the right person. To lead implementation, one must be enthusiastic, persistent, and resilient. An active listener who assumes positive intent, even in challenging conversations. Selfless when advocating for change that might eventually eliminate their own role.

• Having the right plan. The business case actions must address issues specific to the organization, not theoretical best practices or strong opinions. Gathering and analyzing feedback across the organization creates the right plan while accommodating the company’s unique context and culture.

• Implementing at the right time. Each organization has limited capacity for change. Don’t promote a business case when team members are already overburdened with other initiatives. Change fatigue kills even good ideas.

• Establishing a support network. Gathering feedback throughout the organization builds a support network. Functions need team members who believe in the vision and who can be called on for guidance when challenges arise.

• Creating value. The business case must clearly describe how this investment will help the organization create value. Not activity. Value. Not compliance, but competitive advantage.

• Planning for obsolescence. This is what I missed initially. The business case should explicitly state how success reduces the need for the function over time. If this can’t be described or achieved, the business case will create permanent overhead.

Forthcoming Challenges

There are three global obstacles to eliminate regardless of what function the business case is establishing or enhancing.

1. Short-term thinking. The job site atmosphere is constantly evolving, problem-solving and firefighting. Under normal project delivery pressures, urgent issues unconsciously get elevated to leadership, preventing strategic thinking. The business case must acknowledge this reality while making the case for long-term investment.

2. Perceived lack of time. This is especially acute when teams view the function as a process rather than a result. “We don’t have time for quality reviews,” or “Safety meetings take too long,” or “We’re too busy to update the schedule properly.” Navigating this obstacle requires active listening and reframing the function as a decision and a result, not additional tasks.

3. Unclear definition. If the organization can’t clearly define what the function means – what “quality” means, or what “good safety culture” looks like, or what “effective scheduling” produces – it is impossible to build or enhance it. Vague definitions create vague results.

This is an industry-wide problem, which is why organizations need clear, tactical definitions specific to the business. “Quality is conformance to requirements” is useless. “Zero punch list items at substantial completion with client satisfaction scores >4.5/5.0” is actionable.

A Note on My Evolution

I now lead project management at ThermalWorks, deploying mission-critical cooling systems for data centers globally. I’m responsible for project delivery, cross-functional coordination, and operational standards - all the things that would typically be separate SME functions in a traditionally structured company. My job is to build competent project managers who don’t need constant SME support. That’s the model that scales.

The quality program I built? It was good scaffolding. It established standards when we had chaos. But the exit strategy was always missing. This rewrite adds that missing piece.

A Brief Disclaimer

There are many paths to success. This framework is one approach based on my experience building and implementing business functions at a top 30 ENR construction company and a global real estate organization. It may not directly apply to your situation. Like any business framework, you must adapt it to your specific context. What worked for me won’t work identically at your organization. However, the core principles - align with strategy, get buy-in, gather feedback, analyze rigorously, measure what matters, present compellingly, implement systematically - are universal.

These are my ideas and opinions, and do not reflect the positions of my current or past employers or colleagues.

A few of you have asked about what’s coming this year, so here’s the plan.

I’ll be publishing two long series this year.

1. The Real Cost of Quality. Starting January 15th, I’m publishing a 9-part series on building support functions that actually work. I’m using my experience building and deconstructing a quality program as the case study, but the framework applies to any organizational change effort: Safety, scheduling, commissioning, process standardization. Articles in this series will post on the 15th of each month starting this month.

2. Creating Effective Checklists. The operational checklists series will continue posting on the 1st day of each month. (You can find the first one here.)

After the completion of the two series above, there’s no scheduled content. I’m focused on a new role and other fiction writing projects through the rest of 2026. I have a few ideas on where to take Deconstrategy in 2027, but I’m more interested in what you readers have to say. If you want to see more of something specific - or less of something - let me know. I’m genuinely curious.

Wishing you an awesome 2026, and thank you for reading.

I wrote previously:

The solution lies in refining how we capture, prioritize, and communicate Lessons Learned throughout the project lifecycle.

However, after more thought and research, my opinion shifted.

In my research for ASQ's CCQM certification (I’m helping write the Body of Knowledge), I came across this quote from Tim Howarth and David Greenwood's Construction Quality Management: Principles and Practice: "However, recent research into cross-project learning led Newell to conclude that 'there is accumulating evidence that the medium of capture and transfer through ICT (information and communications technologies) such as databases and corporate intranets is limited in terms of how far such technology can actually facilitate knowledge sharing" (148).

I believe this happens because the database doesn't teach anyone anything. Yes, it tells us something, but nothing is learned. Learning is evident when people's behavior changes from the last project to the next one. That change in behavior is what actually prevents the problem from happening again.

Instead of trying to track every Lesson Learned and figure out when and where it should go, what if we instead think about how we can change project team behavior for the better? The ideas surrounding planning presented in How Big Things Get Done are a great starting point. When we see "planning" as a behavior, how can we plan better?

My current opinion is that though these databases are well-intentioned and can serve a purpose, most are productivity graveyards. Executives should abandon Lessons Learned databases and focus on communication instead. I’m concerned not with the practical tasks, rather the entire strategic approach.

I’m also concerned with the amount of time companies invest to figure out how these databases should function. How should the teams access the data? What actually constitutes a “Lessons Learned”? How do we deliver it to the teams at the right place and time so they are not overwhelmed?

There’s an endless labyrinth of process gates to make something like this truly work as intended. There’s no combination that will solve the Lessons Learned problem, and no way to correlate its impact to KPIs.

Database Delusions, and the Uniqueness Paradox

The industry currently invests significantly in technology to transfer Lessons Learned that strips away the contextual intelligence that makes construction experience valuable. We’re reducing complex coordination challenges into database entries, eliminating the nuanced understanding that prevents future problems.

To expand on my concern further, databases are great at archiving information, but they don't change behavior. Learning only occurs when teams modify their approach based on previous experience. The other issue is that executives believe all projects are unique, which creates a paradox where we try to apply insights from unique projects to future projects that are completely different, expecting them to change behavior. This belief in “uniqueness” prevents organizations from recognizing profitable patterns, yet doesn’t provide space for a database of “unique” insights to be successful. To implement Lessons Learned, we must abandon the idea that projects are unique and instead think of them as unique assemblies of standard components.

Many supposedly "unique" challenges—weather delays, scope changes, coordination problems—occur repeatedly across project types. The strategic solution is organizing knowledge around these recurring patterns, not individual project documentation.

Categorical Trending

Organizations must track individual Lessons Learned by categories. This approach mirrors how experienced professionals naturally develop expertise and make decisions. I wrote previously that the Definable Feature of Work (DFOWs) provides the perfect framework for categorical trending. They're already how your teams organize operations—excavation, electrical, concrete, roofing, mechanical, HVAC.

DFOW-based categorization creates the following competitive advantages:

1. Strategic Pattern Recognition: Experienced executives develop decision models organized around building types, delivery methods, and complexity levels. They apply lessons from similar projects rather than trying to remember individual cases—categorical systems match this natural intelligence.

2. Probability-Based Competitive Positioning: When you aggregate historical performance data by DFOW category, you develop statistical distributions for cost, schedule, and risk outcomes. This enables more accurate bidding than competitors using bottom-up estimates based on presumed project uniqueness.

3. Resource Allocation Optimization: Rather than trying to incorporate every lesson from previous projects, teams focus resources on the highest-risk DFOWs for specific project types. This creates scalable competitive differentiation.

ROI of Structured Conversations

Effective construction knowledge transfer and sharing of Lessons Learned occurs through communities of practice and structured conversations rather than database systems. This is more than effective soft skills. It's competitive intelligence. Knowledge sharing preserves the social context and trust relationships that drive performance improvements. Conversational approaches capture tacit knowledge, enable real-time adaptation, and build the relationships that sustain competitive advantage. Psychological safety emerges as the critical success factor for ROI. When teams feel secure discussing failures and uncertainties, they share intelligence that prevents costly future problems.

High-ROI structured conversations include:

• Project Retrospectives Organized by DFOW: Instead of general "Lessons Learned" meetings, focus discussions on specific categories where problems occurred.

• Cross-Project Intelligence Sharing: Bring together teams who've delivered similar building types or used comparable delivery methods.

• Executive Mentorship Programs: Pair experienced leaders with emerging talent to transfer knowledge that databases cannot capture.

• Technical Communities of Practice: Create ongoing dialogue processes embedded in operational workflows.

The objective is making knowledge sharing feel valuable and natural, not administrative overhead.

Effective Data Management

Lessons Learned databases by themselves don’t solve the problem without flexible frameworks that force teams to talk. This requires:

• Centralized Accessibility: Cloud-based systems providing real-time access to current project intelligence without creating information silos.

• Quality Assurance: Automated validation to reduce manual errors, combined with human oversight and feedback loops.

• Workflow Integration: Data collection embedded in natural work processes rather than separate administrative requirements.

• Human-Centered Design: Technology that makes strategic conversations more productive by providing relevant context and historical patterns organized by meaningful categories.

Implementation Strategy

Here's how to transition from database-driven to conversation-driven Lessons Learned transfer:

1. Develop DFOW-based Categories: Create a standardized taxonomy of Definable Features of Work for your project portfolio. Limit to 10-15 categories maximum for strategic focus. If your teams are not comfortable with the DFOW terminology, find a different name that resonates within your organization but accomplishes the same objective: organizing all your projects by components and a common language that everyone can understand.

2. Implement Reference Class Forecasting: For each DFOW category, develop historical performance distributions for cost, schedule, and risk outcomes. Use this intelligence for competitive bidding and resource allocation. (You can read more about this in Bent Flyvberg’s work here.)

3. Establish Structured Dialogue Frameworks: Create regular knowledge sharing sessions organized around DFOW categories. Focus on strategic application and competitive intelligence rather than administrative documentation.

4. Build Technical Communities of Practice: Form cross-project teams around core competencies. Provide time and resources for regular meetings and insight development.

5. Deploy Supporting Technology: Use systems that facilitate knowledge sharing, such as collaboration tools, mobile access, searchable project histories organized by strategic categories.

The Strategic Imperative

The modern organization must transition from individual database tracking to categorical knowledge sharing and pattern-based competitive intelligence. Construction's knowledge and Lessons Learned crisis stems from strategic misalignment, implementation failures, and the belief that databases can solve our problems. Database systems fail because they cannot address the human factors that drive competitive learning. Categorical trending succeeds because it matches natural cognitive patterns and enables strategic application.

Databases support human-centered knowledge transfer. Stop building Lessons Learned databases. Start building knowledge sharing communities organized around the work that drives your competitive position. As with much of the industry change that’s needed, the executive mindset must shift to drive the enhancements we need.

Your competitive advantage is how well you can get your teams to communicate. The culture you build where there are no conversational boundaries or biases, where teams think critically and learn from one another. An environment where teams reach out for information rather than hopelessly wandering the company intranet for the “magic insight” to save them.

That magic insight is someone’s brain. Not an item in the database.

Dec 12, 2025 Update: A knowledge management professional noted inconsistencies in this article by noting: “Lessons learned are a component of knowledge management, but they aren’t synonyms.” I’ve made updates throughout to accommodate.

I started writing Deconstrategy in August 2024 to serve as an archive of what I’ve learned throughout my career, and to clearly articulate the leadership and organizational challenges holding us back. Most of it has been focused on quality and process, given my current role in quality, and I will expand beyond that in the coming months and years.

I had a general plan of what I intended to write, however I didn’t fully realize what the narrative arc would become between my first article, Legos and DFOWs: The Basic Building Blocks, and my most recent piece, The Data Center Stress Test: Two Halls and a 23-Degree Difference, a summary from my commissioning days of what I learned testing the chilled water system at a smaller data center back in 2012. Between those two articles, I wrote 48 articles totaling 90,000 words - roughly equivalent to a book manuscript. However, my metric isn’t word count. It’s whether I moved the conversation forward on how we think about our work in design and construction.

Key Reflections

I write to learn and reflect on what has worked and what hasn’t both in my own work and in what I’ve observed across the industry. Looking across my writing here, I noted ten major themes that reveal what needs to change in our industry.

1. Projects are not unique and we organize them poorly. Thinking that every project is unique prevents us from learning. If we organize our projects consistently from development to operations, we see that central plants, building envelopes, and site utilities are repeatable, and lessons learned become actionable. To address this, I enhanced the traditional Definable Feature of Work (DFOW) concept from a phased construction process into a comprehensive project organization framework that:

   1. Spans the entire project lifecycle (development → design → construction → operations).

   2. Creates a shared vocabulary across disciplines.

   3. Solves the “Lessons Learned Problem” by providing structure for knowledge transfer.

   4. Challenges the “uniqueness trap” in construction.

2. Quality begins with client intent, not specifications. Building per plan and spec is necessary but insufficient. Clients often can’t visualize what they’re buying until it’s built, and at that point the desired changes are expensive. We must develop better methods for capturing and translating what our clients want throughout the project lifecycle, making it explicit in ways that field teams can execute on. Quality is a result, not an isolated process. It cannot be inspected in. It must be planned in.

3. Simplify first, automate last. Stop buying software to fix broken processes. Automation amplifies whatever process exists. If the process is bloated, automation makes it bloat faster. Technology doesn’t solve process problems. It amplifies them. Ruthlessly simplify workflows before introducing technology. Often we discover that automation isn’t needed at all. Management owns the responsibility for improvement.

4. Defensive processes are killing our productivity. Defensive processes multiply during uncontrolled growth. Every time something goes wrong, we add a step or process to prevent recurrence. Over decades, quality and operational excellence programs become repositories of every failure, creating administrative nightmares. We need to regularly audit our processes and systems. If a step exists only because something went wrong once, remove it. Use data to identify what items and steps should be included, which are those that are most impactful to the business.

5. Checklists should have 5 to 9 items maximum, and be one page or less. There are exceptions to this rule, and you’ll have to investigate that within the context of your business. The main idea is long checklists don’t get used. They get pencil-whipped. Focus on “killer items,” the ones that will actually harm the project if missed. Everything else is either training, mentoring, or unnecessary.

   1. Two types: READ-DO (before work) vs. DO-CONFIRM (after work).

   2. 5-9 items maximum—focus on “killer items”.

   3. Not teaching tools, but reminders for experts.

   4. Meeting agendas are checklists for conversations.

   5. Must be field-tested with actual users.

6. Decentralize responsibility. Centralized programs don’t scale and don’t hold the right people accountable. For example, when you hire a quality manager to do all the quality work, you absolve everyone else of responsibility. Push responsibility to those actually doing the work—superintendents, project managers, trade partners. Make the quality professional a strategic advisor, not an inspector.

7. The “Lessons Learned Problem” is solvable. Lessons learned databases fail because we dump everything in them and expect people to search at the right time. Instead, organize your lessons learned by how you organize your projects (see #1), such as by Definable Feature of Work, and deliver them “just in time,” when teams are planning that specific work. Not all lessons are equally important. Use Pareto charts to focus on what actually costs money.

8. Time isn’t our problem. Prioritization is. Teams claim they “don’t have time for planning,” but we find all the time we need to process the changes later. For example, we often believe meetings are the problem. They aren’t. Ineffective meetings are. We have the power to choose what to work on and how to work on it. The question isn’t “Do we have time?” rather “Why are we choosing to work on the wrong things?” Slow down to plan, save time overall.

9. Design and construction must speak the same language. Every stakeholder speaks a different language (Developers ≠ designers ≠ contractors ≠ trade partners). “Design intent” means nothing to an electrician. Specifications alone don’t convey what matters to clients. Adopt a simple framework across both disciplines (again, see #1). When designers and builders organize projects identically, coordination problems disappear and client intent transfers cleanly.

10. Real cultural and business change takes 2 to 4 years minimum. Stop expecting quick wins. Cultural transformation requires a complete project portfolio turnover. Set executive expectations for multi-year commitments. Report quarterly progress, show incremental improvements, but never promise overnight transformation. Sustainable change is slow.

Tactics for Business

In my writing, I wanted to be very tactical. Below are some of the tools that dive deeper into the previous core ideas.

1. The Business Case Framework. This is perhaps my most tactical, actionable contribution: a 7-part methodology for building executive buy-in.

   1. Integration with business strategy.

   2. Executive mobilizers and “speaking their language”.

   3. Gathering feedback at scale.

   4. Data-driven action planning.

   5. Realistic timelines (2-4 years for culture change).

2. Growth as Strategy vs. Growth as Result.

   1. Growth for growth’s sake contaminates culture.

   2. Short-term profit focus destroys long-term value.

   3. Companies should optimize for client value, letting growth emerge naturally.

3. Leadership as Learning

   1. Leaders must think long-term (5-10 years).

   2. Be the collaborator, not the dictator.

   3. Conviction comes from study and reflection.

   4. Mentoring is more important and effective than robust training programs.

Top Articles

My top articles based on traffic were:

• Eric Morin: The Renaissance Problem Solver

• Why Leaders Should Train

• Clarity Versus Process

• Lori Chandler: The Construction-Minded Design Leader

• The Deconstrategy Manifesto: Principles for Industry Transformation

• Understanding the DFOW Flywheel

• Leadership Tactics: Mike Rodriguez

• Leadership Tactics: Tony Pellegrino

• The “Working With Me” Exercise, Processes, and Excellence

• On Definable Features of Work

• Book Notes: Edwards Deming’s “Out of the Crisis” (Ch 1 through 3)

• How to Build a Compelling Business Case for Quality

Closing Thoughts

I’m a huge fan of Peter Drucker. I believe he transformed how we think about management, shifting from “how to control workers” to “how to create conditions for people to contribute.” Our industry desperately needs a transformation. Who’s brave enough to let go of what’s always been done and embrace what could be? Who is open to thinking differently? To letting their teams try new ways of managing the work? To holding ourselves accountable to training and developing our people? To using technology and AI to improve our work instead of replacing our thinking?

Here’s to the collaborators, the long-term future thinkers, and those willing to do the hard work of simplifying complexity.

I’m extremely thankful to everyone who read my work and provided feedback on how to improve these ideas. Thank you for your contributions and for being an active reader of Deconstrategy.

Here’s to more in 2026. Let’s make it another great year.

A Unique Commissioning Opportunity

In commissioning, we rarely get the opportunity to test a data center’s infrastructure beyond its design capacity. Production environments carry too much risk and equipment availability windows are too short. Also, load banks capable of simulating multi-megawatt IT loads are expensive and difficult to coordinate.

However, back in the early 2010’s, during the commissioning of a smaller data center, I had a rare opportunity. This site had been acquired from a previous owner and retrofitted for new operations. We were conducting final UPS commissioning with dual load bank systems - an A path and B path. This setup allowed us to simulate the dual-corded power supplies typical of enterprise IT equipment and test automatic transfer scenarios under full load. We had load banks to simulate the future IT load for UPS transfer testing.

After completing UPS testing and preparing for L4 testing of the chilled water system, both us and our client were curious: How much could this chilled water plant actually handle? The facility was still in pre-production, and this would likely be the only opportunity to validate the plant’s true capacity before the facility entered production and became untouchable.

Engineering a Heat Load

Simulating a heat load in a controlled manner required creative commissioning. We used three heat sources:

• Load banks distributed across both data halls

• From building systems - we commandeered the hot water boilers and forced the air handlers serving the East data center into heating mode

• Residual building loads bringing total heat rejection

The existing legacy CRAC units in Data Hall 1 were pressed into service to transfer heat into the chilled water loop. Meanwhile, newer CRAC units in Data Hall 2 handled the remaining load.

This setup created an unintentional but revealing experiment in data center cooling design.

The Tale of Two Data Halls

The performance difference between the two data halls was stark and instructive.

Legacy Cooling Without Containment

Data Hall 1 ran older CRAC units with no hot aisle containment and no global controls coordination. Under load, we observed:

• Space temperatures reaching 97°F

• CRAC unit fans running at 100% speed even when cooling setpoints were satisfied

• Chilled water valves closing to 20% with no corresponding fan speed reduction

• Severe air mixing and hot spots throughout the space

We discovered the CRAC units’ internal humidity control was driving fan operation. This internal control at the CRAC unit was overriding commands from the building automation system. To prevent condensation inside the units, the control algorithms forced fans to 100% regardless of temperature setpoints. Without hot aisle containment, the units were fighting against massive air mixing and return air bypass.

This is a classic example of equipment operating as designed but producing suboptimal system-level performance. The individual CRAC units were protecting themselves while collectively failing to protect the IT equipment.

Modern Cooling With Containment

Data Hall 2 told a completely different story. With newer units, hot aisle containment and a global control system, we observed:

• Server cabinet inlet temperatures averaging 74°F

• Hot aisle temperatures reaching 115°F - exactly what containment is designed to achieve

• CRAC units operating in coordination, not competition

• Stable, predictable airflow patterns

The containment strategy fundamentally changed the thermal dynamics. By eliminating return air bypass and air mixing, the CRAC units could focus on their actual job: rejecting heat to the chilled water loop. The global control system coordinated fan speeds and cooling valve positions across all units, preventing the individual unit protection behaviors that plagued Data Hall 1.

The 23°F temperature difference between the two data halls, under identical heat loads, demonstrated the compound value of proper containment and coordinated controls.

The Chilled Water Plant Performance

The chilled water plant consisted of three chillers with primary and secondary pump arrangements serving the two separate data halls. While the CRAC performance differences were revealing, the primary objective was testing the chilled water plant capacity. The results exceeded expectations. The key metrics under the simulated IT load were:

• Calculated PUE: 1.25 (great for the early 2010’s)

• Chillers required: 2 of 3 (one remained offline as backup)

• Economizer system: Not utilized - demonstrating mechanical cooling capacity for worst-case summer conditions

The plant demonstrated it could cool more than six times the projected move-in IT load with one chiller in reserve and without economizer assistance.

Understanding What the Numbers Mean

A PUE of 1.25 at the simulated load is noteworthy for several reasons:.

1. It represents genuine worst-case performance. We intentionally avoided using the economizer system to validate mechanical cooling capacity alone. In real operation with economizer engagement during cooler months, PUE would improve substantially. This test established the performance floor, not the ceiling.

2. The plant operated with significant headroom. The chilled water plant limited the facility’s growth potential less than the electrical infrastructure did - unusual for data centers, where cooling often becomes the bottleneck first.

3. The cooling efficiency validated the design approach. It confirmed the plant was properly sized and operating as intended under extreme load conditions.

Growth Capacity Projections

Based on the test results, we could project future growth scenarios with unusual confidence.

1. Scenario 1: Maximum Cooling Capacity Utilization. If the facility deployed additional UPS systems and CRAC units to support more IT load, the existing chilled water plant could handle the additional load. The limiting factor would become the utility service, not the cooling infrastructure.

2. Scenario 2: Optimized Efficiency Approach. For near-term growth from the move-in load, the plant would operate in economizer mode for significant portions of the year. Combined with the demonstrated capacity margins, this facility could scale IT load incrementally while maintaining excellent PUE performance throughout the growth curve.

Important Lessons

This load test revealed insights that only become visible when we pushed the system beyond the comfort zone.

1. Containment and controls are not optional. The 23°F temperature difference between data halls under identical heat loads made the business case for containment impossible to ignore. Data Hall 1’s legacy approach wasn’t just inefficient - it was potentially dangerous. At 97°F, we were approaching temperatures where IT equipment starts thermal throttling or shutting down. More importantly, the data hall’s inability to manage setpoints even when cooling capacity existed demonstrated that having enough BTUs of cooling doesn’t guarantee adequate cooling delivery. Without proper airflow management and coordinated controls, the system just moves air inefficiently.

2. Design capacity is often conservative. Though the design philosophy may be different now, our test revealed how much margin existed. At more than double the design capacity with one chiller still offline, the plant demonstrated the conservative nature of critical infrastructure sizing. This doesn’t mean we should design tighter. It means when planning facility growth or evaluating M&A opportunities, understanding actual tested capacity versus nameplate capacity can fundamentally change ROI calculations.

3. Commissioning creates opportunities beyond compliance. Traditional commissioning focuses on verifying equipment operates per design documents. That’s important, but it’s the minimum. This load test exemplified what commissioning can be: using temporary conditions and available resources to answer questions about actual facility capability.

The cost to conduct this test was essentially zero - we already had the load banks on site and the personnel mobilized. The value was substantial: validated growth capacity, identified Data Hall 1’s cooling deficiencies before production loads arrived, and documented baseline performance metrics that would guide future capital decisions.

This information doesn’t come from equipment cutsheets or theoretical modeling. It comes from running equipment at the limits, being creative about how to work with the resources at hand to support the customer’s future business plans, and document what actually happens.

Why This Test Will Probably Never Be Repeated

As commissioning opportunities go, this one was unique. Consider what had to align:

• Pre-production facility with no live customer equipment at risk

• Load banks already mobilized for separate UPS testing

• Building systems available to contribute additional controlled heat load

• Client willingness to extend commissioning schedule and incur additional costs

• Weather conditions suitable for extended load testing

• Full team availability including commissioning agents, construction team members, operators, and engineers

Once a data center enters production, the risk calculus changes completely. We can’t take a live facility offline to stress test cooling infrastructure at double capacity. The business impact is too severe, the customer SLAs too strict, the liability too high.

This creates an irony: the time when we most want to know our facility’s true limits - when it’s running production loads and considering major expansions - is exactly when we can’t safely conduct the tests that would tell us.

The Value of Aggressive Commissioning

Most commissioning stops at verifying design compliance. Equipment runs, setpoints track, sequences execute. Check the boxes, generate the report, move to substantial completion. This approach misses opportunities. When resources are mobilized, systems available, and the window before production, we can answer questions that become unanswerable later:

• What is the actual capacity margin?

• How does the system perform at the extremes?

• Where are the weak points that nameplate data doesn’t reveal?

• What deficiencies exist that should be corrected before production?

This test revealed that Data Hall 1 needed immediate remediation - better containment, upgraded controls, possibly CRAC unit replacement. Without pushing the system, we might have discovered these issues only after customer equipment started overheating.

The test also gave the operations team confidence in the infrastructure that no amount of theoretical analysis could provide. They had seen the plant handle double capacity with headroom. They understood the thermal dynamics under extreme load. They knew which systems performed as expected and which needed attention.

That confidence changes how we operate a facility. Instead of being conservative to the point of inefficiency, we can optimize knowing our true boundaries.

Final Thoughts

Design documents tell us what equipment should do. Trending data shows what equipment is doing under current loads. But neither tells us what the system can do when pushed to its limits.

This commissioning test removed that uncertainty for one facility. We proved the chilled water plant could handle more load than designed with one chiller offline and no economizer assistance. We quantified the performance difference between legacy and modern cooling approaches. We identified deficiencies that needed correction before they became problems.

Most importantly, we established a baseline of actual performance data that would inform every future decision about the facility - from capital planning to emergency response procedures to growth strategy. That’s the real value of pushing systems beyond their comfort zones during commissioning: replacing assumptions with facts.

In critical infrastructure, facts are what keep the lights on.

• Leader Brief

• Introduction

• Leaderscape

• In Practice

• Reflection Questions

• Conclusion

• Transcript

LEADER BRIEF

• Professional: Architect and Design-Build Leader with expertise in collaborative project delivery and team development.

• Background: Notre Dame architecture graduate who transitioned from traditional design-bid-build to design-build methodology, leading industrial and commercial projects.

• Leadership Focus: Problem-solving through creativity and endurance, interpersonal skill development, and value-driven project delivery for owners.

• Notable Achievement: Successfully transformed from a technically-focused architect into a leader who balances analytical capabilities with strong interpersonal skills, building high-performing collaborative teams in the design-build environment.

INTRODUCTION

Architecture, at its core, is about solving problems. But as Eric Morin learned early in his career, being right isn't enough. Being effective requires a completely different skill set. Eric's journey from a technically-gifted architect to a seasoned leader demonstrates the power of self awareness - the prerequisite for transformation.

Eric chose architecture over engineering because it rewards being a "renaissance person" - someone who learns more and more about more and more, rather than specializing in an increasingly narrow field. This broad perspective, combined with what he calls "mental endurance," has shaped his approach to both project delivery and team leadership.

His philosophy centers on helping others discover solutions rather than simply providing them. (This aligns with what senior field leader Tony Pellegrino said in a previous Leadership Tactics article.) Drawing from Galileo's wisdom that "you cannot teach a man anything, you can only help him to discover it for himself," Eric has learned that walking others through solutions and understanding their motivations is far more effective than being self-righteously correct.

LEADERSCAPE

IN PRACTICE

Mental Endurance as a Leadership Skill

Eric identifies mental endurance as one of the most underrated skills in leadership and professional development.

“This mental endurance to just continue grinding, going the extra mile, staying focused; is something that is undervalued."

He applies this principle not just to project challenges, but to the ongoing work of developing interpersonal skills and leading teams through difficult situations.

Self-Reflection

Early in his leadership journey, Eric didn’t understand why others didn't immediately see the value of his solutions. To address this, he implemented a disciplined reflection practice.

"I kept a journal every week. I went through where I failed, and where I had successes. I did this for a year, every week, reflecting on how did I deal with this. The process of reflection is something that I use spiritually, and is part of what I do now, as a human."

This practice taught him that being right wasn't the right criteria for success - being effective was.

Understanding Motivations

Eric's approach to difficult conversations and problem-solving starts with understanding the other person's current state.

"You have to understand their motivations. It was, and sometimes is still hard to slow down. To spend more time, which starts with listening, asking questions: how is your day going? What's stressful in your world right now? What are you concerned about? And if they are stressed out, then we won't talk about this other thing I was concerned about because they have no capacity for it."

Design-Build as Value Creation

Eric's commitment to the design-build methodology stems from his focus on owner value rather than just project delivery.

"I'm totally hooked on design build because of it [focused on the owner]. I'd never go back. Design-Build is a better value for the owner. It doesn't make my life more interesting or easier, that's true - but fundamentally, it results in a better process and product."

Quality Through Experience and Accountability

Eric ensures quality through two key strategies:

1. Risk-Based Prioritization: When reviewing drawings, he focuses teams on three questions:

   1. What's the risk to the client?

   2. What's the risk to our company?

   3. What's my professional liability as an architect?

2. Direct Experience: He believes in empowering team members to experience the effects of their decisions directly rather than having managers buffer them from consequences.

"I focus on empowering the people on my team to experience the effects of their decisions directly. When a sub calls, 'I need this now, what is this,' or 'this hardware group is wrong and the owner is upset,' it changes the way you do things."

Redefining Success Beyond Money

Eric learned early that financial metrics, while important, shouldn't be the primary measure of success.

"I realized early in my career that money is easy to define, and too many people focus exclusively on it. If money were the only point, we'd be selling different things. There are other values. When we choose to define these other values and prioritize them, we can develop more complete conditions of success."

His definition of success centers on three elements:

• Internal team: Working with people you enjoy.

• External team: Sustainable client relationships.

• Project quality: Doing meaningful work.

REFLECTION QUESTIONS

1. How do you balance being technically correct with being interpersonally effective in your leadership approach?

2. What systems do you have in place for regular self-reflection and learning from both successes and failures?

3. Before presenting solutions to your team or clients, how well do you understand their current motivations and capacity for change?

4. How do you ensure your team members experience the direct consequences of their decisions rather than being buffered by management layers?

5. Beyond financial metrics, how do you define and measure success in your role and organization?

6. What practices do you have to create space for reflection and processing in your fast-paced work environment?

CONCLUSION

Eric Morin's evolution to an effective leader demonstrates the power of intentional skill development and self-reflection. His emphasis on mental endurance, understanding motivations, and creating value for owners provides a strong framework for leadership in the design and construction industry.

His journey illustrates that technical expertise alone isn't sufficient for leadership success. The ability to help others discover solutions, create accountability through direct experience, and maintain focus on broader value creation are equally important skills that can be developed through disciplined practice and reflection.

TRANSCRIPT

(Edited for clarity.)

What is the story of how you got into your current position?

In college, I was interested in engineering first, architecture second. This was the selection criteria for where I could go. I went to Notre Dame, took an introduction to both, leading to a huge workload. Halfway through I dropped Calculus, realizing architecture was the way for me. This was based on meeting with a few architects and engineers who my parents connected me with.

One thing that stood out is that architecture is one of the few professions where you are rewarded for being a renaissance person, and you learn more and more throughout your career. In engineering, you learn more and more about less and less. Your field narrows. I wanted the wide lens. I always wanted to learn more about anything and everything. At the core, it makes sense that I'm interested in both - architecture and engineering both involve heavy problem solving. But architecture is more visual and personal, versus engineering is more analytical. I prefer the relational and visual. Most people can't do both. People tend to be really strong in one or the other, there's a spectrum, and everyone is different in both.

What skills did you learn and develop that set you apart?

Our industry and profession is about solving problems. Every building is a business solution. It has to be a market driven business solution, or it doesn't exist. What you bring to that is creativity. I have this naturally; I’m curious and like to understand things. I also have a high degree of endurance. This is an underrated skill. This mental endurance to just continue to grind is something that is undervalued. You have to be able to engage with the challenge, whatever your mechanism is. Find a way to pivot to be positive. You have to find a way to just do it.

In my life - in sports, and other things - often times, the best coaches were not very good players. Maybe it’s because they received the most coaching. I have found that to be true for managers as well. People who are gifted socially and are maybe extroverted, it's so intuitive that they often don't know how to teach it. But management is about teaching these skills. Architects and engineers typically aren’t trained to teach. I had to learn the interpersonal side, which was not natural for me. The focus i continue to put on it helps me improve.

I graduated in 2008 in the recession and got a job with a firm doing all public work. I spent 4 years doing low bid contracting in the recession. This environment - where the drawings are a weapon to use against the contractor - is how I was trained. "Where is the arrow pointing and who is paying for it." That was not me. This wasn't the best value for the owner, and the combative nature was against my belief in how teams should work.

This drew me to Ryan Companies, seeking a better way. How do I give the owner the best value in a more collaborative approach? I'm totally hooked on Ryan’s design build approach. I'd never go back. It's a better value for the owner. It doesn't make my life more interesting or easier, that's true, but fundamentally, it results in a better process and product. My job as an architect is first for the better welfare of the community, then second is a fiduciary for the owner.

Early in my career, I was naturally creative and a good problem solver. I grew frustrated when others didn't see the value of my solution. I was often certain I was right, and even though I frequently was, right wasn't the right criteria. That's not how you are judged. You can be self-righteous or effective, pick one. I needed to learn different skills to be effective.

Walking others through the solution is a very important skill. Showing your work. One of the quotes I love, from Galileo: "You can teach a man nothing, you can only allow him to discover it for himself." That is something I revisit; my mantra over and over, especially if I'm struggling with a difficult solution where I haven't found a way for it to matter to the team yet. You have to understand motivations, so spending more time - which starts with listening and asking questions: “How is your day going? What's stressful in your world right now? What are you concerned about?” And if they are at a 10 already, then we won't talk about this other thing I was concerned about because they have no capacity for it.

No one is perfect at this, but it was hard learning. I kept a journal every week. I went through where I failed, and where I had successes. I did this for a year, every week, reflecting on how did I deal with this. That process of reflection is something that I use spiritually, and part of what I just do now, as a human. I do it with my family also. You can't learn if you don't make time to reflect. There are many methods, but the biggest thing is creating space to think and process. I recognized in the pandemic, we lost a lot of transition time. No commute, no walking between meetings. We lost the built-in buffers to reflect. One Webex to the next, all day. There was no space to absorb the information and process it, professionally and personally. We are still dealing with this as a norm.

How do you create this space at work? How do we reflect on what the client said?

I make it a point to start personally, and end personally, with conversations, as much as you can. I require my teams to at least check in with their teams for at least 30 minutes, not project specific. Personal life; a conversation that isn't about how we solve an immediate problem. Try to make space for this. I have a joke about architects versus engineers: Put 5 engineers in a room, you get 25 solutions. But 5 architects, you get 30 different problems. Architects need to be more focused. This reflection is inherent in our training and our process, that we challenge the assumptions. Give people permission to do what they are naturally going to do and find ways to make that productive.

What were major accomplishments which were turning points in your career?

There was a project I was working on where I was really struggling, working with a famous architect. I put in a ton of hours - 80 billable hours per week for months. We won the National Gold Medal for AIA, the design success was 12 out of 10. The client was thrilled, but team dynamic wasn't great (and Ryan lost money).

After that job, I started on a 2.5 year long 500,000 square foot office remodel. A completely different environment with new people and a difficult client. At some point, you're going to have your worst client. We had weekly design meetings for 2 years for a 2.5 year project. Looking back on it, I couldn't have asked for better medication. 2 years of eating humble pie taught me a lot.

Coming out of this, I had the opportunity to take on a small industrial team. What we were then is unrecognizable from what we are now. I was drawn to the opportunity to manage people and have more design control, after those 2 years of having little influence on it. I found out quickly it was a chance to reinvent myself. I had not been in a formal leadership role until then. We had very senior members of the team that I learned under in the transition. When I sat down with one of our senior architects, my approach was always: "I know you know far more about this than I do, my goal is to not get in your way, but to support you. So tell me what you don't want to do, and I will do that work for you."

As the business scaled, has this approach worked? Did you have to adjust?

I trusted my team's judgment, but I spent 2 or 3 years intentionally more in the project details than I wanted to be long-term so that I could really understand it - more than my role required. It was an intentional investment of my time and energy so that I understood it; so that I didn't just become a sales guy and manager. It was painful, lots of long hours, that's the endurance piece. If your client calls you, and you keep saying "I need to talk to someone who has that answer," they will stop calling. I'm a manager of managers now, that's a different thing than being a manager. It's different to coach coaches. I counsel them on the same—make sure you understand what's really going on. Don't be afraid of not being in the day-to-day, being the hub. If you're managing correctly, all the important and big challenges will come to you. You'll still hear about them. The stuff the team can solve, you won't hear about it, that's okay. Your team will come to you for the hard to solve stuff, so you will still grow and you will still learn.

What does success look like in your role? How do you measure it? What are other things besides the money that you think about to measure success?

I realized early in my career that money is easy to define, and too many people focus exclusively on it. If money were the only point, we’d be selling different things. There are other values. When we choose to define these other values and prioritize them, we can develop more complete conditions of success. For me, based on what I've seen, if we can do the work with people we enjoy working with, and can sustain the team, create the stability for your team, to have profitable careers for them, doing work that they enjoy, with people they enjoy working with, that's success.

Not every project will be a winner. We will do toilet room renovations. But if you do it with good people, and make a decent living doing it, you can get through these projects.

How do you ensure quality in design? What are two tactics for other designers?

When I'm reviewing a drawing set, I think about:

• What's the risk to the client?

• What's the risk to our company? Are we exposed financially, from a safety perspective, or something else?

I really focus on empowering the people on my team to experience the effects of their decisions directly. We should get rid of the architectural registration exam and require 4 years of CA (Construction Administration). If you've lived in the trailer and argued about what that line is, then you know what it is that you're trying to do. When a sub calls, "I need this now, what is this?” or "This hardware group is wrong and the owner is upset," it changes the way you do things, versus having your manager tell you that's a mistake or having them deal with it for you. (Lori Chandler also talked about this in her Leadership Tactics article.)

I create accountability within my teams. If we get an entry-level designer, we don't want them just picking up redlines. At a minimum, they have one sheet that is their responsibility. They need to have a system that's their responsibility. Assign them the dock equipment package where they need to know and learn everything about dock equipment. When the shops come in, they need to do it all. Learn one thing about this building. Don't give them everything, they can't do that. But give them discrete elements, they can learn from that. Have them understand the window system. Continue doing this over time, system by system.

(I wrote about this previously, stating: “We can’t focus on everything. As leaders, our job isn’t to demand teams cover it all, but to help them zero in on what truly moves the needle. You can read the full idea here.)

There's an element in design going back to creativity and problem solving. If we create design, it has to include something that's unexpected, a bit of wow in the design. Doesn't have to be a big neon sign or backlit canopy. Just something that's efficient, or neat. An element of joy, a bit of surprise, like "Oh, that's cool."

I’m super thankful for Eric’s vulnerability in this article. You can find ideas from other design and construction leaders here, or read them directly below:

Thank you for reading!

This is where most organizations struggle. They understand the concepts but can’t figure out how to operationalize them. They create some improved checklists, roll them out, and watch as adoption stalls because they haven’t thought through the system.

Checklist Guidelines: What Makes an Effective Checklist

Before we talk about managing a library, let’s establish rules for what makes an individual checklist effective. (These checklist goals come from Atul Gawande’s book, The Checklist Manifesto: How to Get Things Right).

1. Each checklist should focus on one Definable Feature of Work or unit of work. Remember from Part 2, a Definable Feature of Work is any work unit that requires special attention. Each should have its own separate corresponding Read-Do and Do-Confirm checklist.

2. Aim for 5-10 items maximum. Remember, we are in the field, in the heat of the battle, and a checklist could quickly become a distraction if it takes longer than 5 minutes. Time it. How long does it take, is it easy to navigate? Also, checklists are not teaching tools that cover every possible thing that could go wrong. They’re memory aids for competent people. If your checklist has more than 10 items, you’re trying to teach, not guide.

3. Items should be specific and measurable. Bad checklist item: “Verify quality.” Good checklist item: “All device locations match architect’s final floor plan, with no conflicts between trades.” See the difference? Specific items tell you exactly what to look for and when you’ve found it. Vague items create ambiguity and lead to inconsistent application.

4. Focus on “killer items” - things that cause the most pain. Based on your data strategy from Part 5, your checklist should include only items that prevent your most common and expensive problems. Everything else is noise.

5. Use the checklist as a guide during work, not just for inspection after.

   Remember from Part 3, checklists should be touchpoints and milestones. If your checklist is only useful after work is complete, you’re using it too late.

6. Test before rolling out. Don’t create a checklist in your office and mandate its use across the organization. Take it to the field, the floor, the actual work environment. Have someone use it in real conditions. Get feedback. How long did it take? Was anything confusing? Did we miss anything critical? Were there items that didn’t apply or weren’t useful?

   Iterate based on feedback before company-wide rollout.

The Two Models for Checklist Libraries

When we reviewed that stud wall checklist, we removed entire sections because they deserved special attention and thus their own checklists. We realized we needed 9 new checklists as a result.

This raises an important question: How do you manage your checklist library? Deciding how you will manage your checklist library is a critical component of your company philosophy from Part 1.

There are two models we can explore.

Model 1: Smaller Library, Longer Checklists

The first model is where we have a smaller library of checklists. Let’s say 100 for the sake of discussion. If we have fewer checklists, they will be longer. If checklists are longer, their utilization goes down, resulting in lower effectiveness. This model is where we have a corporate library that we expect our project teams to make specific to their project types. This isn’t a wrong way of doing it, but it’s more work on our teams when time is a serious limitation and when those teams alone can’t be made aware of all the potential risks. This means we have around 300 pages of checklists to maintain if each checklist is about 3 pages long.

Model 2: Larger Library, Shorter Checklists

The second model is where we have a larger library of checklists, but they are more focused and thus shorter. This means we have higher utilization, but the workload of developing those checklists goes to a corporate overhead function instead of the project teams. We have more checklists, but the overall amount of documentation is less.

It’s okay to have a larger library of checklists if they are effective, which is why I strongly prefer Model 2 for most organizations.

• Focused checklists get used. A 1-page, 10-item checklist takes 5 minutes to complete and teams will actually use it thoughtfully. A 3-page, 46-item checklist takes 20 minutes and becomes box-checking.

• Corporate overhead should create the library. This goes back to the question from Post #1: “Who should create checklists?”

• More checklists, less total documentation. This seems counterintuitive, but it’s true. 200 focused checklists at 1 page each is 200 pages. 100 comprehensive checklists at 3 pages each is 300 pages. You actually reduce total documentation by increasing granularity. Plus, teams only use the checklists relevant to their work. On a commercial building project, you might use 40 of those 200 checklists. On a healthcare project, maybe 60 different ones. Each project uses what it needs.

How to Build Your Library

Here’s the practical process:

Step 1: Start with your Definable Features of Work

From Part 2, you identified work units that require special attention based on four sources:

• Critical path activities

• Specifications and requirements

• Experience and lessons learned

• Client or stakeholder intent

List them all. You’ll probably have 50-300 depending on your industry and complexity.

Step 2: For each DFOW, create both Read-Do and Do-Confirm checklists

From Part 3, you learned that effective checklist use requires both types:

• Read-Do: Used before work starts in preparatory meetings and coordination sessions

• Do-Confirm: Used during/after work for verification and quality control

Not every DFOW needs both. Some might only need Read-Do (design reviews, planning sessions). Some might only need Do-Confirm (final inspections, regulatory checks). But most critical work benefits from both.

Step 3: Populate with “global killer” items only

From Part 5, use your data strategy to identify what actually goes on each checklist. Only include items that:

• Occur frequently across projects/locations (above your defined threshold)

• Have meaningful consequences when missed

• Can be prevented or caught at this touchpoint

Start with 3-5 items per checklist. Add more only if data supports it. Never exceed 10.

Step 4: Test and iterate

Before rolling out the full library:

• Pick 10-15 representative checklists

• Have actual teams use them in real work conditions for 30-60 days

• Gather feedback: What worked? What didn’t? What’s missing?

• Refine based on feedback

• Then roll out the full library

Step 5: Create a maintenance schedule

Checklists are living documents. Schedule quarterly reviews:

• What items can be removed because we solved those problems?

• What new global killers have emerged that should be added?

• Which checklists are being used most/least? Why?

• Are there new DFOWs that need checklists?

Assign ownership for this maintenance. It can’t be “someone in corporate will handle it.” It needs a specific person or team responsible for keeping the library current.

The Ownership Question

This brings us back to a critical question from Part 4: Who creates checklists?

In my article Why Leaders Should Train, I explored the idea that managers should create their own processes and train their teams. This forces those documents to remain simple and clear per the concepts explored throughout this series. Those closest to the work should be authoring the checklists, using data provided from the quality or analytics department. Operations should maintain the baseline checklist library based on enterprise-wide data. Then project teams adapt as needed for their specific context.

• Corporate creates the baseline library. They have the data, the cross-project visibility, and the resources to maintain consistency. This library represents your organizational knowledge about what prevents common problems.

• Project/operational leaders own adaptation. They take the baseline checklists and adapt them for their specific context. They might add items relevant to their region, client, or product type. They might remove items that don’t apply.

• Frontline teams own implementation. They’re the ones actually using the checklists. They provide feedback on what works and what doesn’t. They identify when checklists need updating.

• Everyone owns training. Managers should train their teams on how to use checklists effectively. Not just “fill this out,” but “here’s why this matters and what we’re trying to prevent.”

Change Your Incentive Programs

Here’s something critical that most organizations miss: You cannot incentivize checklist completion. Many organizations tie bonuses or performance reviews to checklist compliance. “You must complete 95% of required checklists to get your bonus.”

What happens? Teams complete checklists. They check every box. Compliance goes up. But quality doesn’t improve because teams are focused on completion of the checklist rather than the goal of delivering quality work.

Get comfortable with the idea that with the right leadership and philosophy on checklists - and the right people in the right seats on the bus - you won’t have to force people to use them. With simple rules and clear destination, they work.

Instead, incentivize the outcomes checklists are designed to achieve:

• Reduction in rework and defects

• Fewer schedule delays due to quality issues

• Lower warranty costs

• Improved customer satisfaction

• Decreased safety incidents

When teams see the connection between using checklists thoughtfully and achieving these outcomes, they use checklists because they’re useful, not because they’re required. Show teams the data so they know what they are trying to address through the checklist. When you can say “Since we implemented focused checklists on device locations, our rework on electrical has dropped 60% and we’re saving 3 days per project,” teams want to use those checklists.

Set Up a Library of Effective Checklists

Instead of having a thousand items per checklist, have more checklists that are actually effective.

Here’s what your implementation roadmap should look like:

Month 1-2: Foundation

• Establish company philosophy on checklists (Part 1)

• Identify Definable Features of Work (Part 2)

• Set up data tracking for failures (Part 4)

Month 3-4: Library Development

• Create baseline checklist library

• Develop both Read-Do and Do-Confirm for critical DFOWs (Part 3)

• Use data to populate with global killer items only (Part 4)

Month 5-6: Pilot Testing

• Select 2-3 projects/locations for pilot

• Test 10-15 representative checklists

• Gather feedback and iterate

• Measure outcomes vs. control projects

Month 7-8: Rollout

• Train leaders on checklist philosophy and use

• Deploy full library with adaptation guidance

• Set up maintenance schedule and ownership

Month 9-12: Refinement

• Quarterly reviews of usage and effectiveness

• Update based on new data

• Remove solved problems, add emerging issues

• Adjust incentive structures to focus on outcomes

Managing Observations, Not Checklists

Here’s a subtle but important shift in how you think about this: Manage observations, not checklists. The point of checklists is to capture observations about work quality, coordination, and execution. The observations are what matter. The checklist is just the tool.

Too many organizations manage to checklist completion metrics: “We completed 847 checklists this month!” So what? Did quality improve? Did problems decrease? Did teams coordinate better?

Better metrics are:

• “We identified 34 coordination conflicts before work started using Read-Do checklists, preventing an estimated 12 days of rework.”

• “Do-Confirm checklists caught 89 issues before they propagated downstream, saving $143K in rework costs.”

• “Zero device location errors this quarter on projects using the focused 10-item checklist vs. 23 errors on projects using old 46-item checklist.”

The observations drive improvement. The checklists are just how you capture them systematically.

Closing Thoughts

Inspections and checklists are more than inspecting the work. They are also protocols for when communication about the work needs to happen.

Accept the fact that we are not capable of doing the work without checklists. Our work is too complex to do it by ourselves. Yet checklists can’t be the only tool to help us get it right. They need to be used in balance with other tools – the preparatory meeting, your team members and their expertise, your mentors, your trade partners, your stakeholders’ input.

Checklist is not another piece of documentation. It’s a guide to help you be successful. To support your teams’ experience and expertise.

This is why I find checklists so fascinating. When used effectively as we discussed in this series, checklists can produce measurable results, but only if you solve the five fundamental problems:

1. Establish a company philosophy so everyone understands why checklists exist and what they’re meant to achieve.

2. Organize by work units that matter so checklists drive coordination instead of creating documentation burden.

3. Use them at the right time as both prevention tools (Read-Do) and verification tools (Do-Confirm).

4. Make items clear and tactical so users know exactly what to do both before and after the work starts.

5. Maintain them with data so they stay focused on actual problems instead of becoming museums of failure.

If you’re ready to implement this in your organization:

• Test your checklists before rolling them out. Don’t mandate from corporate without validation from the field.

• Leverage the combination of Read-Do and Do-Confirm between QA and QC and organize your checklist content accordingly. This combination before, during, and after the work starts is how you leverage checklists effectively to improve your execution.

• Set up a library of effective checklists that’s maintained based on data, not opinion.

• Change your incentive programs to focus on outcomes, not compliance.

And most importantly: Remember that we’re shifting from compliance to competence. Instead of asking “Did you follow the process?” ask “Did you achieve the outcome?” Get these right, and checklists transform from compliance mandates into operational excellence tools.”

Think about what happens when something goes wrong on a project and we wonder how we can keep it from happening on the next project. “Add it to a checklist.” Over time, the checklist becomes a list of everything that has ever gone wrong. They are multiple pages and incredibly detailed with every possible risk that should be checked regarding that specific element of the work.

This is exactly how an ineffective checklist is created. It makes us turn our brains off and difficult to make it specific to the project, and difficult for a company to manage corporately. Leveraging our previous stud wall example from Part 4, it was 3 pages long with 46 items. Forty-six things to check before installing drywall on a stud wall. Each item has a valid story. Someone, somewhere, had a problem. Electrical boxes in wrong locations. Insulation missing. Wrong stud spacing. Anchor bolts not to spec. Each time a problem occurred, someone said “We need to add that to the checklist so it doesn’t happen again.”

Noble intent. Terrible execution.

In reality, what happens is no one uses the checklist because it becomes so long and detailed that it takes longer to complete than the actual work. Teams start checking boxes without thinking. The checklist becomes a compliance exercise instead of an effective tool.

The more items you add to prevent problems, the less effective the checklist becomes.

Checklists Are Not Teaching Tools

Checklists have become teaching tools. They try to educate workers about everything that could possibly go wrong. If someone doesn’t know how to install a stud wall correctly, the solution is training and mentoring, not a 46-item checklist. If they don’t understand why insulation matters, the solution is explanation, not adding more line items.

Checklists are memory aids and coordination tools for competent people doing complex work. They’re not instruction manuals for incompetent people. Atul Gawande wrote about this in The Checklist Manifesto: How to Get Things Right. He studied aviation. Pilots are highly trained professionals. They don’t need checklists to teach them how to fly. They need checklists to ensure they don’t forget critical steps in high-pressure situations.

That’s what checklists should be in your organization.

The Solution: Establish a Data Strategy

The solution is not to stop capturing lessons learned, rather to capture them strategically using data, not opinions.

Step 1: Capture your failures systematically.

You need to figure out how to capture and organize your data from whatever project management software you’re using. (For this exercise, we will assume everyone here is using some kind of system where this information is available.) Think about the problems you want checklists to prevent. Where do they come from?

• Deficiencies and rework

• Schedule impacts

• Warranty spend

• Customer complaints

• Safety incidents

• Cost overruns

Whatever system you use - Procore, Jira, ServiceNow, your ERP - you should be tracking these failures already. If you’re not, start there.

Step 2: Analyze the data with Pareto charts.

If you aren’t familiar with a Pareto chart, it’s a great tool to help identify the top issues. The principle is simple: roughly 80% of problems come from 20% of causes.

Let me show you an example in Figure 1. We’re looking at the top issues encountered in 2023 related to stud walls:

1. Outlets in wrong location - 347 instances

2. Layout conflicts - 254 instances

3. Incorrect stud spacing - 143 instances

4. Piping not insulated - 73 instances

5. Missing diffuser - 72 instances

6. Ductwork conflict - 68 instances

7. Missing electrical - 47 instances

8. 15 other issues with 1-3 instances each (not shown in Figure 1)

Lots of outlets in the wrong location. Layout problems also, and the wrong stud spacing. Notice something? The top three issues account for 744 instances out of 1,004 total - that’s 74% of all stud wall problems coming from just three causes. This is the Pareto principle in action.

Once we dig into this data, we realize the top three are national problems across all our projects. But these other HVAC items are only regional and related to one project where we had a new mechanical subcontractor who didn’t understand our process.

Notice how the data directly informs both our Read-Do items (discussed before work starts) and our Do-Confirm items (verified after completion). The most common problems become the focus of both types of checklists.

Step 3: Put only the “global killers” on checklists.

What do we really want our teams to focus on? Having the data set up like this helps us decide what the “global killer” issues are - those are what should go into the checklists. In this example, the stud wall checklist should focus on:

• Device location verification

• Layout accuracy

• Stud spacing per specifications

The HVAC coordination problem? That’s not a checklist item. That’s a training issue with one subcontractor. Handle it directly with that sub, don’t burden every project nationwide with an extra checklist item they don’t need. This applies for both Read-Do in quality assurance (Preparatory Meetings, for example) and Do-Confirm in quality control. You need to put the items in the right checklist to be effective.

What This Looks Like Across Industries

This data-driven approach works in any industry:

• Healthcare Example: Don’t add every medication error to your medication administration checklist. Analyze your errors by type. If 60% of medication errors involve sound-alike drug names, that’s what goes on the checklist: “Verify correct medication - high alert for sound-alike drugs.” The one-off error where a nurse grabbed the wrong vial because she was distracted? That’s a coaching conversation, not a checklist item.

• Software Example: Don’t add every bug to your deployment checklist. Analyze your production incidents. If 70% of incidents involve database migrations, that’s what goes on the checklist: “Verify migration rollback plan tested.” The one-off incident where someone deployed to production instead of staging? That’s a process improvement (maybe better naming conventions), not a checklist item.

• Manufacturing Example: Don’t add every quality escape to your line checklist. Analyze your scrap and rework. If 65% comes from incorrect tool offsets after changeovers, that’s what goes on the checklist: “Verify tool offsets match work order for critical dimensions.” The one-off escape because a new operator didn’t know the process? That’s training, not a checklist item.

How to Measure Success

How do we know this will work? We have to test it and monitor the trends over time.

Let’s look at a comparison of 2023 and a theoretical 2024. We see that we have a decrease in issues overall from implementing focused checklists. But these remaining issues are now all national problems.

This is the next thing to remember about checklists: they need to be maintained, updated, and tested. As your operations improve, your checklist should shrink, not grow. If your checklist is getting longer over time, something is wrong.

Every quarter, review your failure data again:

• Are the items on your checklist still the top causes of problems?

• Have you solved some problems completely and can remove those items?

• Have new systemic problems emerged that should be added?

A living checklist based on data stays relevant. A static checklist based on cumulative history becomes a museum of past failures.

The Mindset Shift

Here’s the fundamental shift required:

• Stop asking: “What could go wrong?” That question leads to 46-item checklists that try to cover everything.

• Start asking: “What consistently goes wrong, and what’s the smallest intervention that would prevent it?” That question leads to focused checklists that actually prevent problems.

This is hard for organizations to accept. We want comprehensive documentation. We want to be able to say “We thought of everything.” We want to protect ourselves from liability. However, comprehensive doesn’t mean effective. Often it means the opposite.

The legal protection you think you’re getting from a 46-item checklist is an illusion. If someone checks all 46 boxes without thinking, and a problem still occurs, the checklist didn’t protect you. It just created documentation of compliance without achieving the underlying goal. Better to have a 10-item checklist that people actually use thoughtfully than a 46-item checklist that becomes meaningless box-checking.

In Practice

Here’s how to implement a data strategy for your checklists:

1. Set up tracking for failures you care about. Pick 3-5 categories that matter to your operations: rework, schedule delays, safety incidents, customer complaints, warranty issues, whatever is most expensive or painful.

2. Analyze monthly or quarterly. Create Pareto charts showing the top causes in each category. Look for patterns across projects, locations, or product lines.

3. Define “global killer” threshold. For example: “Any issue that occurs on more than 20% of projects or more than 10 times per year is a global killer.” Adjust the threshold based on your volume.

4. Update checklists based on global killers only. If it’s not a global killer, don’t add it to your checklist. Handle it through training, process improvement, or direct coaching.

5. Remove items that are no longer problems. If an issue that was once a global killer drops below your threshold for two consecutive periods, remove it from the checklist. You solved that problem. Don’t keep checking for it forever.

6. Test new checklists before rollout. Time it. How long does it take? Can it be completed in 5 minutes or less? Is it easy to navigate? Get feedback from the people who will actually use it.

A Note on Regional vs. Global Issues

One of the biggest challenges with checklists is balancing corporate consistency with local relevance. The data strategy helps solve this. Global killers go on corporate checklists used everywhere. Regional issues can be added to project-specific checklists used only where relevant. In our stud wall example, the HVAC coordination problem was regional. The solution? That region adds it to their project-specific checklist. Other regions don’t need it. After a few months, if the problem is solved, that region removes it.

This keeps checklists lean while still allowing for local adaptation. More importantly, it prevents one region’s problem from becoming every region’s documentation burden.

The Goal: Competence, Not Compliance

Use of checklists and inspections is not the ultimate goal. Reduction of errors is the goal. In research I conducted, I found that projects that performed substantially more inspections tended to have lower profits. Those teams are complying with procedures at the expense of the goal, which is reduction of errors. They are using checklists because they have to in order to get their bonus, or it’s company policy to do so.

The main goal is voluntary utilization - teams choosing to use checklists because they’re valuable, not because they’re required. That’s when you know the checklist is beneficial. You can show data to your teams to show the benefits. Showing the data helps show the benefits. When teams see “We had 47 instances of outlets in wrong locations last year, we focused our checklist on device location verification, and now we’re down to 8 instances this year,” they believe in the checklist. They want to use it.

When teams are told “Corporate requires you to complete this 46-item checklist,” they resent it. They find ways to comply without actually improving.

Data transforms checklists from compliance into improvement tools.

In Part 6, we’ll bring everything together: how to build and manage an effective checklist library, how to balance having enough checklists versus too many, and how to create a culture where checklists are actually valued and used.

We’ve talked about why you need checklists (Part 1), how to organize them (Part 2), and when to use them (Part 3). Now let’s talk about the mechanics of writing a checklist with items that actually work.

This is where I’ll address that unsealed ductwork from the introduction.

The checklist said “Air seal ventilation ductwork.” The wording was vague. It didn’t tell anyone when to seal it, who was responsible, or how to verify it was done.

There are three principles for writing effective checklist items:

Principle 1: Use Clear, Action-Oriented Language

Let me show you what I mean using an actual stud wall checklist.

The original electrical section had one item noting: “Party / Demising walls, outlets are not installed back to back.” What does this actually tell you to do? It’s describing a condition, not an action. When should you check this? What exactly are you looking for? How do you verify it? This item deserves its own checklist because demising walls are their own separate work unit (or Definable Feature of Work).

The next item indicated: “Outlets/switches putty packs installed correctly (back to back boxes within 24’’ or in same stud cavity).” The problem here is the item, as it’s worded, describes the incorrect condition. Outlets should not be installed in the same stud cavity - and if they are, they need putty packs. The wording needs to be updated to clearly indicate what to inspect for.

Notice the difference? The new version tells you:

• What to look for

• What the standard is

• How to verify

Returning to our original ductwork example, the original line item was: “Air seal ventilation ductwork.” That’s passive language. It doesn’t tell you when, who, or how. We can improve this language better as a Read-Do item (before work): “Confirm temporary duct end caps are installed before framing inspection.” For a Do-Confirm item (after work): “All ductwork openings sealed with approved caps or tape. No visible dust or debris inside ducts.”

Same underlying concern, but now it’s clear about timing, responsibility, and verification.

Let’s look at another example: warped studs.

Warped Studs

The original item, “Check for warped or bowed studs and replace.” already assumes the problem exists. We need to use Read-Do checklists (from Part 3), to prevent this problem. To make this a Read-Do checklist, we can update the item to say: “Crew should know not to install warped studs.” This goes in your pre-work meeting agenda. You’re setting the expectation before work starts. For the inspection itself as a Do-Confirm: “No warped or bowed studs installed.” Simple verification after work is done.

Another example notes the layout of the walls. The Read-Do must identify what standard to install the layout to (architectural drawings or the approved shop drawings) while the Do-Confirm must confirm that it was actually installed as discussed.

The final example of demising walls must be given its own checklist because it requires special attention as its own work unit. This is trying to handle a special case (demising walls) within a general checklist. The problem? Most walls aren’t demising walls.

Here’s the pattern to recognize:

• Effective checklist items:

  • Use active verbs (verify, confirm, check, ensure)

  • Specify the standard or expectation

  • Make verification obvious

  • Tell you when the check happens (before or after work)

• Ineffective checklist items:

  • Describe conditions passively

  • Leave timing ambiguous

  • Don’t specify what “correct” looks like

  • Make you guess what action to take

Principle 2: Consolidate Related Items

The second problem with most checklists is they’re overly specific to the point of being inefficient.

In the stud wall example, the checklist itself can be reduced from 46 items to 30 by giving sections of the checklist that are unique work units or DFOWs their own checklists, and by consolidating other items with clearer language.

• Pocket Door Installation Checklist (its own DFOW)

• Bathroom Rough-In Checklist (its own DFOW)

Now when I’m working on a pocket door, I use that specific checklist. When I’m working on a bathroom, I use that specific checklist.

For the “Wood Backing / Blocking” section, if I’m inspecting a wall without a sliding door, I mark “N/A” on the first item. I’m turning my brain off. I’m not thinking about what blocking might actually be needed for this specific wall. If the item has to be marked as “N/A,” it should not be on the checklist. These items can be removed from this general stud wall checklist.

I’m never marking “N/A” because the checklist is specific to the work I’m actually doing.

Don’t try to make one checklist cover every possible variation. Instead:

• Keep general checklists short and focused on common items

• Create separate checklists for special conditions

• Let teams use only the checklists relevant to their specific work

This is exactly what we discussed in Part 2 about organizing by Definable Features of Work or work unit. Each special condition deserves its own checklist if it requires enough special attention.

Principle 3: One Checklist Per Work Unit

This brings us to the third principle, which ties everything together.

Look at what happened when we applied these principles to our stud wall checklist. We started with one checklist that had multiple sections:

• Exterior Wall Studs

• Interior Studs

• Wood Blocking/Backing

• Electrical

• Plumbing/HVAC

• Fire Sprinkler

• Windows

• Sliding Doors

• Insulation

This was trying to be everything for everyone. 46 items across multiple pages. This means:

• When I’m inspecting an interior wall, I mark “N/A” on the entire exterior wall section. Brain off.

• When I’m inspecting a wall without windows, I mark “N/A” on the windows section. Brain off.

• When I’m inspecting a wall that’s not in a bathroom, I mark “N/A” on multiple blocking items. Brain off.

The checklist is making me check things that don’t apply, which trains me to stop thinking critically about what actually matters.

The Solution: Break It Apart

We removed entire sections and created separate checklists:

• Exterior Wall Studs → Its own checklist

• Windows → Its own checklist

• Sliding Doors → Its own checklist

• Pocket Doors → Its own checklist (removed from blocking section)

• Bathroom Blocking → Its own checklist (removed from blocking section)

• Demising Walls → Its own checklist (removed from interior studs)

The original 46-item checklist became a shorter, focused “Interior Stud Wall” checklist with new specialized checklists for specific conditions.

The Math:

• Original approach: 1 checklist, 46 items, ~3 pages

• New approach: 7 checklists, averaging 10 items each, ~1 page each

Total documentation went from 3 pages to 7 pages. On any given wall, you’re only using 1-2 of those checklists, not all 7. Instead of working through 46 items (marking half as N/A), you’re working through 10-20 items that all actually apply to what you’re building.

Cross-Industry Application:

This same principle applies everywhere.

• Healthcare: Don’t have one “Patient Care” checklist that covers admission, medication administration, discharge, and everything in between. Create separate checklists for each phase of patient care.

• Software: Don’t have one “Deployment” checklist that covers front-end, back-end, database, and infrastructure. Create separate checklists for each system component.

• Manufacturing: Don’t have one “Quality Check” checklist that covers setup, production, and teardown. Create separate checklists for each phase of the operation.

Putting It All Together

When you’re reviewing your checklists, ask these three questions:

1. Is the wording clear and action-oriented? Can someone read this item and know exactly what to check? Does it specify when to check (Read-Do or Do-Confirm)? Is the standard or expectation clear?

2. Are related items consolidated appropriately? Am I being overly specific about things that could be combined? Or am I trying to handle special cases in a general checklist? Should this be its own separate checklist instead?

3. Does this checklist cover one work unit or multiple? Am I marking “N/A” on entire sections regularly? Could this be broken into more focused checklists? Would teams benefit from more specific checklists for special conditions?

These three principles - clear wording, appropriate consolidation, and one checklist per work unit - will transform your checklists from bloated compliance documents into focused operational guides.

But there’s still one question: How do you decide which items belong on a checklist in the first place? In Part 5, we’ll discuss how to use data to prevent your checklists from becoming repositories of every past failure.

When I was a project manager, I used checklists all the time as part of my inspections, thinking that I was ensuring quality. Then I read this from Deming’s Out of the Crisis:

“You cannot inspect quality into a product.” (pg 29)

I didn’t understand it when I first read it. It wasn’t until I dug more into the difference between Quality Assurance and Quality Control that I understood what Deming was talking about.

Checklists aren’t useful until the work is already installed incorrectly. Once that happens, yes, we caught it, but rework, cost and schedule issues have already been incurred. Yes, the checklist caught it and saved us even more money and time than if we continued and had to correct subsequent work, but the checklist didn’t prevent it.

Most organizations use checklists only for inspections - after the work is completed. This is what Deming meant, that no amount of inspection will ensure a quality product.

To understand this, we need to discuss the difference between quality assurance and quality control.

Quality Assurance vs. Quality Control

Within any quality program, there are elements of quality assurance and quality control. For this discussion, we are focused specifically on the physical elements of the work - not the contractual responsibilities of each party. Many use assurance and control interchangeably. The difference between them is the start of the work.

• Quality Assurance is defining expectations before the work starts. What is a level 5 finish? What does “functional” mean? The goal is preventing the occurrence of a problem. Examples include:

  • Preparatory work sessions or pre-installation meetings

  • Discussions with your client about their expectations and their intent

  • Budgeting for quality tasks like mockups

  • Design reviews before fabrication starts

  • Onboarding processes that establish standards

  • Training on how work should be performed

• Quality Control is validating those expectations after the work is completed. Quality Control is preventing the recurrence of a problem. Examples include:

  • Inspections

  • Commissioning

  • Drawing reviews (if we are thinking about design work)

  • Final verification before delivery

  • Testing and quality checks

  • Audits of completed work

Most checklists live exclusively in Quality Control as inspection tools used after work is done to verify it was done correctly. The traditional way we think about checklists now only allows them to catch problems that should never have occurred.

But what if the team didn’t understand the expectation correctly? What if there was ambiguity in the specification? What if coordination between trades wasn’t clear?

The Solution: Change Your Mind About Checklists

The solution is getting the information, or checklist content, from quality control up to quality assurance. Checklists are not inspections. They are touchpoints and milestones.

Let me introduce you to two types of checklists that most organizations don’t differentiate. (These types are from Atul Gawande’s book, The Checklist Manifesto: How to Get Things Right.)

• Read-Do Checklists: Reading the checklist before the work is completed. These are quality assurance tools. They’re used in preparatory meetings, pre-installation discussions, or coordination sessions before work starts.

• Do-Confirm Checklists: Doing the work, then checking to see if it’s correct prior to moving on. These are quality control tools. They’re used for inspection and verification after work is complete but before the next phase begins.

Read-Do’s are great for discussion and coordination, checkpoints, such as your preparatory / pre-installation meetings. Most organizations only use Do-Confirm checklists. They inspect after work is done. But the most effective organizations use Read-Do checklists to prevent problems before they occur.

In Practice

Let’s discuss this idea for different industries.

Construction Example

• Traditional Approach (Do-Confirm only): Superintendent inspects stud wall after installation, discovers electrical boxes are in wrong locations, requires rework.

• Better Approach (Read-Do + Do-Confirm): Before drywall installation, team reviews Read-Do checklist in preparatory meeting: “Verify all device locations with architect’s final floor plan. Confirm no conflicts with HVAC, plumbing, or structure. Document any field changes.” Then after installation, use Do-Confirm checklist to verify work matches what was discussed.

Healthcare Example:

• Traditional Approach (Do-Confirm only): Nurse verifies medication administration after preparation, discovers wrong dosage was prepared, must dispose and restart.

• Better Approach (Read-Do + Do-Confirm): Before preparing medications for patient, nurse and pharmacist review Read-Do checklist together: “Verify patient weight-based dosing. Confirm no drug interactions. Check allergy status.” Then use Do-Confirm checklist during administration.

Software Example:

• Traditional Approach (Do-Confirm only): QA tests feature after development is complete, discovers it doesn’t meet requirements, requires significant rework.

• Better Approach (Read-Do + Do-Confirm): Before development starts, team reviews Read-Do checklist: “Confirm acceptance criteria with product owner. Verify API contracts with backend team. Identify edge cases and error states.” Then use Do-Confirm checklist during code review and testing.

Manufacturing Example:

• Traditional Approach (Do-Confirm only): Quality inspector checks first article after line changeover, discovers tooling setup is incorrect, requires line shutdown and restart.

• Better Approach (Read-Do + Do-Confirm): Before changeover begins, operations and quality review Read-Do checklist together: “Verify correct tooling package. Confirm setup parameters match work order. Review critical dimensions.” Then use Do-Confirm checklist to verify first article.

Notice the pattern? Read-Do checklists force conversation and coordination before work starts. Do-Confirm checklists verify the work matches what was agreed upon.

Why This Matters

Here’s the fundamental insight: Checklists are not just documentation tools. They are protocols for when communication about the work needs to happen. If you only use checklists for inspection, you’ve missed the entire point. You’re documenting problems instead of preventing them. The most powerful use of checklists is as communication guides. They tell teams: “These are the conversations you must have before starting work. These are the coordination points that prevent expensive mistakes.”

This was my idea behind the design of many quality programs I’ve built in my career: to get teams to talk. To facilitate the exchange of knowledge, making the tacit explicit. Checklists should contain only the most critical explicit information that triggers tacit knowledge to be shared. Read-Do checklists turn into meeting agendas. Before critical work starts, the team gathers and goes through the Read-Do checklist together:

• What are we building?

• What does “done right” look like?

• What coordination is required?

• What are the common failure modes?

• Who’s responsible for what?

This 15-minute conversation prevents hours of rework.

But most organizations don’t do this because they don’t think of checklists as communication tools. They think of checklists as inspection tools.

How to Implement Read-Do Checklists

Here’s how to shift your checklists:

1. Take your existing Do-Confirm checklists. Don’t throw them away. They’re still useful for verification.

2. For each Definable Feature of Work (or work unit), create a Read-Do version. (You can read more about this in Part 2 here.) Ask: “What would the team need to discuss before starting this work to prevent the problems this checklist is designed to catch?”

3. Use Read-Do checklists as meeting agendas. Schedule a 15-30 minute preparatory session before critical work begins. Walk through the Read-Do checklist as a team.

4. Document decisions, not just completion. The output of a Read-Do checklist isn’t checkmarks. It’s documented agreements: “We confirmed with architect that wall height is 10’-0” to underside of structure, not finished ceiling.” “We agreed electrical will rough-in before plumbing to avoid conflicts.”

5. Then use Do-Confirm for verification. After work is complete, use your Do-Confirm checklist to verify the work matches what was discussed in the Read-Do session.

The Timing Question

Someone always asks: “When exactly should we use Read-Do vs. Do-Confirm?” Here’s a simple framework:

• Read-Do happens at these moments:

  • Before starting a new phase of work

  • When multiple disciplines must coordinate

  • When there’s ambiguity in specifications or requirements

  • When past projects have had problems with this type of work

  • When the cost of rework is high

• Do-Confirm happens at these moments:

  • After completing a phase of work but before the next phase covers it up

  • At quality control points specified by regulations or contracts

  • When verification by multiple parties is required

  • Before client inspections or handoffs

Both happen for work that matters. Not everything needs Read-Do and Do-Confirm. Remember your company philosophy from Part 1. Only use checklists for work units that require special attention.

A Warning About Inspection Culture

Organizations that rely solely on Do-Confirm checklists create an inspection culture. Teams know their work will be checked, so they wait for the inspection to catch mistakes rather than getting it right the first time. Organizations that use Read-Do checklists create a prevention culture. Teams take ownership because they participated in defining what “done right” looks like before they started.

Which culture do you want?

Accept the fact that we are not capable of doing the work without checklists. Our work is too complex to do it by ourselves. Yet checklists can’t be the only tool to help us get it right. They need to be used in balance with other tools: the preparatory meeting, your team members and their expertise, your mentors, your trade partners, the designers’ input.

Closing Thoughts

The most effective approach uses both types for critical work. The Read-Do checklist becomes your pre-work coordination agenda. The Do-Confirm checklist becomes your verification tool. Same work unit, two different moments, two different purposes.

The checklist is not another piece of documentation. It’s a guide to help you be successful. To support your team’s experience and expertise.

In Part 4, we’ll discuss why checklists become failure repositories, cataloging everything that has ever gone wrong instead of focusing on what actually prevents problems.

A common criticism of quality, safety, or other overhead program is the amount of work and documentation required. This leads us to our second problem with checklists: they are not organized strategically within a project to be well-managed. There’s just a “list of stuff” that needs to get done.

If we look at checklists, specifically around inspections, it’s a mass of tasks we need to manage that aren’t organized in a way that’s easy to understand. Here’s a construction example that illustrates a universal problem.

We often try to organize our checklists by scope of work. For example, let’s say we have a stud wall. We have three scopes of work: Mechanical, Electrical, and Low Voltage. Each must do an inspection prior to drywall. If we set up an inspection by scope of work, we have three line items in that inspection checklist - or three separate inspection checklists for one stud wall - checking device locations for each scope of work.

This makes the checklist longer than it needs to be and separates the coordination of the trades. This is a huge inefficiency, making checklists long and unfocused.

Think about your own operations. How are your checklists organized? By department? By function? By the org chart? By whoever happened to create them first?

A hospital might have separate checklists for nursing, pharmacy, and lab work - even when they’re all working on the same patient admission. A software deployment might have separate checklists for front-end, back-end, and infrastructure - even though they’re deploying one integrated system. A restaurant might have separate opening checklists for kitchen, bar, and front-of-house - even though they all need to be ready for the same service. When checklists are organized by department instead of work outcome, here’s what happens:

• Coordination becomes a separate activity instead of happening naturally

• Items fall through gaps between checklists

• Teams duplicate effort checking the same thing from different angles

• Nobody owns the complete work unit, just their departmental piece

The Solution: Organize by “Units” of Work

In construction, teams often use the “Definable Features of Work” (DFOW) for organizing their work for quality and meetings. Here’s the definition from the US Army Corps of Engineers:

A Definable Feature of Work is a task or group of tasks which is separate and distinct from other features of work and is usually identified by different trades or crews performing the work at different times or locations.

When I was building quality programs, I needed a better way to articulate this not only to myself, but to our project teams. Because we didn’t have dedicated quality managers on most of our project sites, the teams needed to build this list themselves based on the needs of their project. I came to a simple way of communicating it:

Let me translate this out of construction language for a moment.

Not everything requires a checklist. Most work doesn’t. But certain work units - because of their complexity, their risk, their cost of failure, or their impact on downstream work - require special attention. In construction, that’s structural elements, mechanical systems, coordination between trades. In healthcare, that’s patient handoffs, medication administration, surgical procedures. In software, that’s deployments, data migrations, security implementations. In manufacturing, that’s quality control points, changeovers, preventive maintenance.

How to Identify Your Definable Features of Work

There are four sources to identify what requires special attention in your operations:

1. Specifications and Requirements. What work has explicit quality standards or regulatory requirements? In construction, that’s anything with building codes, LEED requirements, or contract specifications. In healthcare, that’s anything with Joint Commission standards or CMS requirements. In food service, that’s anything with health department regulations. If there’s a spec that matters, that’s a Definable Feature of Work.

2. Critical Path Activities. What work, if delayed or done incorrectly, impacts your entire timeline? In construction, that’s foundation work, structural steel, or long-lead equipment installations. In software, that’s architecture decisions or third-party integrations. In manufacturing, that’s bottleneck operations or setup-intensive processes. If it’s on your critical path, it probably deserves its own focused checklist.

3. Experience and Lessons Learned. What work has caused problems in the past? Where have you experienced rework, warranty claims, customer complaints, or safety incidents? One important thing to understand about checklists is they should capture lessons learned. (Without adding too much. We’ll dive into this later in Part 4.) There may be a task we need to do better on the next project that isn’t in the specifications but cost us money or impacted our schedule. If you keep making the same mistake, that work unit needs special attention.

4. Client or Stakeholder Intent. This one took me a while to figure out. I thought about each time I completed a project and during punch list the client said “That’s not what I wanted,” even though we built it exactly per plan. Why did that happen? Because we didn’t understand their intent. We followed the specification but missed what they were trying to achieve. If there’s ambiguity in what “done right” looks like, that’s a Definable Feature of Work. You need a checklist not just to verify completion, but to verify you understood the intent correctly before you started.

Organizing Your Checklist Library

Once you’ve identified your Definable Features of Work, here’s how to organize them:

• One checklist per Definable Feature of Work. In the stud wall example, the solution is to organize your checklists under Definable Features of Work rather than by trade or scope. The stud wall becomes the Definable Feature, and we would have one item for “devices,” that would cover electrical, mechanical, and low voltage. We’ve now simplified the checklist by organizing our project by Definable Feature, reducing the number of line items from 3 to 1. This approach forces coordination. If mechanical, electrical, and low voltage all need to check their work before drywall, they do it together using one checklist focused on that stud wall.

Let me give you examples from other industries:

• Healthcare - Patient Admission. Instead of separate checklists for nursing assessment, pharmacy verification, and lab orders, create one “Patient Admission” checklist organized by the patient journey. Each discipline contributes to the same checklist, ensuring nothing falls through handoff gaps.

• Software - Feature Deployment. Instead of separate checklists for code review, testing, and infrastructure, create one “Feature Deployment” checklist organized by the user-facing functionality. Front-end, back-end, and DevOps all verify their portions of the same integrated feature.

• Manufacturing - Line Changeover. Instead of separate checklists for mechanical setup, quality verification, and first article inspection, create one “Line Changeover” checklist organized by the production sequence. Operations, quality, and maintenance coordinate through one shared verification process.

• Restaurant - Service Opening. Instead of separate checklists for kitchen prep, bar setup, and dining room, create one “Service Opening” checklist organized by what the guest experiences. Kitchen, bar, and front-of-house verify readiness together.

The Efficiency Gain

Here’s what happens when you organize this way:

• Fewer checklists overall. Instead of multiple checklists per work unit (one for each department or trade), you have one checklist per work unit that matters.

• Forced coordination. When multiple disciplines must use the same checklist, they have to talk to each other. Coordination happens naturally instead of being a separate meeting.

• Clearer ownership. Each Definable Feature of Work has a clear owner. In construction, that’s often the superintendent responsible for that area. In software, that’s the feature owner. In manufacturing, that’s the line lead. In healthcare, that’s the attending physician or charge nurse.

• Easier to manage. It’s much easier to ask “Did we verify the patient admission checklist?” than to track down three separate departmental checklists and cross-reference them.

A Warning About Over-Organization

When I first proposed this idea in construction, I got a lot of negative feedback: “This sounds like more work, not less. Now I have to figure out what constitutes a Definable Feature of Work?” This is where the company philosophy from Part 1 becomes critical.

• If your philosophy is “checklists prevent the three failure modes that cause 80% of our problems,” then your Definable Features of Work are limited to those three failure modes. You might only have 50-100 corporate checklists total.

• If your philosophy is “checklists ensure we discuss critical decisions,” then your Definable Features of Work are decision points. You might only have 20-30 checklists.

• If your philosophy is unclear, you’ll create Definable Features of Work for everything, and you’ll end up with 1,000 checklists that nobody uses.

The point is not to create more categories. The point is to organize around work units that actually matter, so teams can focus on what prevents problems rather than drowning in documentation.

In Practice

Here’s how to implement this in your organization:

1. List your current checklists. Just write them all down.

2. Ask for each one: What work unit is this trying to protect? Not what department owns it. What actual work outcome matters?

3. Consolidate checklists that protect the same work unit. If three departments are checking different aspects of the same work, combine them into one checklist with three sections.

4. Eliminate checklists that don’t map to a Definable Feature of Work. If you can’t articulate why this work unit requires special attention, you probably don’t need a checklist for it.

5. Name each checklist after the work unit, not the department. “Patient Admission” not “Nursing Assessment.” “Line Changeover” not “Quality Verification.” “Feature Deployment” not “Code Review.”

We often organize our projects by division or contracted scope of work. There’s nothing wrong with this, however it creates additional meetings and coordination effort between the scopes of work. If two scopes are working together on the same element of the building, and our checklists are not organized by that building element (instead by scope of work or division), those checklists are not going to be effective.

In the next post, we’ll tackle Problem #3: Using checklists at the wrong time. This is where most organizations fundamentally misunderstand what checklists are actually for.

A superintendent I worked with had a radical and valid point: “Why do we need checklists? If we just looked at the drawings, we wouldn’t need checklists.” Why do we need a separate document to tell teams to look at the drawings, or to inform them of something they should already know?

When I was working in design and construction quality, one of our initiatives was simplifying our quality control checklists and making them more effective. I was determined to cut out unnecessary items to streamline them for our project teams and save them time. However, I ran into a huge problem: We couldn’t simplify anything. As I dug into the first checklist and discussed it with our steering committee, we kept asking ourselves:

“Why is this item on here? What are we trying to prevent?”

The conversation became more philosophical: “Why do we use checklists in the first place?” I realized we couldn’t simplify our checklists because as a company, we couldn’t agree on why we needed them. Some thought they were to be used as teaching tools. Others suggested as reference guides. Others wanted to ensure accountability. To track that their teams checked the work.

This problem isn’t unique to construction. A hospital system implements surgical checklists because they were instructed to do so. (Atul Gawande documents this phenomenon in his book, The Checklist Manifesto: How to Get Things Right.) A software team uses deployment checklists because “that’s what DevOps does.” A restaurant has opening and closing checklists because the corporate office mandated them. When we think about why, we hear:

• “To prevent mistakes.”

• “For quality.”

• “It’s policy.”

The Solution: Establish a Company Philosophy on Checklists

Before you can have effective checklists, you need to answer these questions for your own organization:

1. Why does your company use them? Are you trying to achieve zero rework? Error-free execution? Prevent safety incidents? Ensure consistent customer experience? You need to be specific. “Improve quality” is not specific enough.

2. Who uses checklists? Is it everyone? Just new employees? Specific roles? In construction, we often think checklists are for field teams. But what about estimators? Designers? Project managers? In a hospital, is it just surgical teams, or do admissions, pharmacy, and discharge all need checklists?

3. Who should create them? This is critical. Is it a corporate function creating checklists for everyone? Or do teams create their own? I’ll argue later that this distinction determines whether your checklists will be used or ignored.

4. When should they be used? Before work starts? During execution? After completion? Most companies use checklists only for inspection after the work is done. That’s too late. (See Part 3 for more on this.)

5. How many should be used? Should you have 50 checklists? 500? What determines if something deserves its own checklist versus being a line item in another checklist?

6. What type of checklists are utilized? Are they inspection tools? Communication guides? Training materials? Decision aids? The answer to this question fundamentally changes how you design and use them.

These questions can serve as a framework to create a culture that allows checklists to be successful.

Here’s what this looks like in practice when there’s a clear philosophy on checklists (or other element of business documentation):

• A manufacturing plant says: “We use checklists to prevent the three failure modes that cause 80% of our warranty claims. Every checklist must tie back to preventing these failures. If an item on a checklist doesn’t prevent one of these three things, it shouldn’t be on the checklist.”

• A software company says: “Checklists are communication tools, not compliance documents. They exist to ensure all stakeholders have discussed critical decisions before deployment. If a checklist item doesn’t require a conversation, it should be automated instead.”

• A restaurant group says: “Checklists ensure consistent guest experience across locations. Every item must be something a guest would notice if done incorrectly. If it’s invisible to guests, it goes in a different system.”

Notice the specificity, how each philosophy immediately tells you what belongs on a checklist and what doesn’t.

Without a clear company philosophy, here’s what happens:

• Teams complete checklists for compliance, not because they are useful. “I filled it out, so I’m covered” becomes the goal instead of preventing problems.

• Checklists become bloated. Every time something goes wrong, someone adds an item to a checklist. Over time, they become unwieldy documents that take longer to complete than the actual work.

• Utilization drops. When checklists are too long or unclear in purpose, people stop using them. Then management adds more enforcement, which creates resentment, which decreases quality of completion, which defeats the entire purpose.

• “Corporate” and “operations” work against each other. Corporate teams try to create one-size-fits-all checklists. Operations teams complain they don’t work for their specific situation. Both are right, and both are wrong, because nobody has agreed on what checklists are supposed to accomplish.

How to Start

If you’re a leader responsible for operational execution - whether you’re a COO, plant manager, director of operations, or project executive - this is your job. You can’t delegate defining what checklists mean in your organization to a quality department or training function. Start by gathering your leadership team and honestly answering those six questions above. Don’t move forward until you have clarity.

Once you have that philosophy, everything else becomes easier. The next three problems with checklists - and their solutions - all depend on having this foundation in place.

In the next post, we’ll tackle Problem #2: Checklists are not organized strategically within operations, which makes them nearly impossible to manage effectively.