The Difference Between Being Busy and Making Real Project Progress

If you work in manufacturing or R&D, you already know the special flavor of “busy” that comes with developing real products:

• The CAD model changed again.

• Purchasing needs a spec you don’t have yet.

• The supplier lead time just doubled.

• Quality is asking for an updated control plan.

• Sales wants to promise a ship date today.

• And you just know someone, somewhere, is making a slide deck called “Program Health – FINAL_FINAL_USE THIS ONE_v12.”

You can spend an entire week sprinting and still end up in the same place: the launch date didn’t move, the risk didn’t shrink, and the team’s confidence didn’t go up. That’s the difference between being busy and making project progress. Busy is motion. Progress is traction. Busy creates noise. Progress reduces uncertainty.

And for SMEs, where a handful of people are the entire product engine, confusing the two is expensive. Busy is “work about work.” Progress is “work that changes reality.”

The uncomfortable truth we don't want to face is a lot of what feels like “project work” is actually coordination overhead. Asana’s research found that 60% of people’s time is spent on “work about work”. Things like status updates, chasing information, duplicating effort, and unnecessary meetings. They also quantify it in a way that stings: the average knowledge worker spends 103 hours/year in unnecessary meetings, 209 hours/year on duplicative work, and 352 hours/year just talking about work. That’s almost 35% of their time in the year not spent moving projects forward.

In manufacturing/R&D, “work about work” shows up in several ways as well:

• Rewriting specs because the last version lived in someone’s inbox

• “Quick syncs” to interpret what a requirement really means

• ECO/ECR ping-pong (routing, approvals, “can you just…?”)

• Debating priorities because the roadmap has three “top” items

• Hunting for the latest BOM, drawing, test report, or supplier quote

Progress, on the other hand, is anything that closes a decision, retires a risk, or produces an artifact that unlocks the next step.

If nothing got decided, de-risked, built, tested, approved, or shipped… you might have been busy, but you didn’t move the project forward.

The hidden tax: task switching and context fragmentation

Product development isn’t one job, it’s 30 jobs braided together: mechanical, electrical, firmware, packaging, compliance, sourcing, tooling, quality, manufacturing engineering, test, documentation… plus the customer-facing stuff if you’re B2B.

That makes you especially vulnerable to the cost of interruptions.

The American Psychological Association notes that even brief mental blocks from switching between tasks can cost up to 40% of someone’s productive time.  So when your best engineer is answering Teams messages, jumping into “just 10 minutes” calls, reviewing drawings mid-design, and trying to write a test plan in the cracks…you’re not just paying for the time spent. You’re paying the restart cost again and again.

This is exactly how a team can feel crushed and still not get meaningful throughput.

Why “busy” is extra dangerous in manufacturing and R&D?

In software, shipping late can hurt. In physical product, shipping late can hurt and you’re stuck with inventory, tooling, MOQs, compliance lead times, and supplier schedules.

Here’s two stats for you to consider:

1. Gartner reported that only 55% of product launches happen on schedule and 45% of the remainder are delayed by at least one month. For the launches that are delayed, 20% (on average) fail to meet their internal targets. 

2. The PMI found that 11.4% of investment is wasted due to poor project performance. 

As an SME, you don’t have an infinite runway for launch delays or wasted spend. If your team confuses activity with progress, you don’t just lose time—you lose margin, credibility, and sometimes the window of the market.

The project progress illusion: “We did a ton this week” (but what actually changed?)

Here’s the acid test I like to use with teams: At the end of the week, can you answer these four questions in plain English?

1. What is different now than last week? (A prototype built? A supplier selected? A key risk retired?)

2. What decisions were made—and by whom? (And are they documented where the team can find them?)

3. What got to ‘done-done’? Not “in review.” Not “basically done.” Done-done.

4. What got less risky? (Compliance confirmed, tolerance stack validated, DFMEA risk reduced, test passed, critical path lead time secured.)

If these questions produce a fog of “we’re working on it,” you’ve got busyness masquerading as delivery.

Busy metrics vs progress metrics (what SMEs should track instead)

A lot of teams accidentally build a system where the appearance of activity is rewarded. The result is more starting, more updating, more meeting… less finishing.

Busy metrics (tempting, but misleading)

• Number of meetings

• Number of tasks “in progress”

• Hours booked / utilization

• Messages sent / response speed

• Percentage “complete” (with fuzzy definitions)

Fortunately you can improve these metrics with a few simple changes.

• Progress metrics (boring, but powerful)

• For manufacturing and R&D, focus on metrics that represent real movement:

• Cycle time to decision (how long a decision takes from “we need it” to “it’s locked”)

• Prototype/test throughput (how many builds/tests reach completion per week)

• Blocked time on the critical path (supplier delays, missing specs, lab availability)

• Rework rate (how often designs bounce back because of late discoveries)

• First-pass yield / defect escape rate (where applicable)

Also, quality costs are a giant “busy vs progress” signal.

ASQ notes that costs of poor quality can be about 10–15% of operations as a rule of thumb, and in some organizations quality-related costs can reach 15–20% of sales revenue (or higher). If COPQ is high, you’re doing a lot of work… just not the kind that produces reliable outcomes. In product development, progress is mostly about shrinking the cost of change. There’s a reason experienced product teams obsess over early validation: changes get dramatically more expensive later.

A common heuristic in Design for Manufacturing is the “Rule of 10”—fixing a defect costs roughly 10x more at each successive stage (sub-assembly, final assembly, distribution, customer). 

Whether your organisatoin uses that exact heuristic or not, the principle is rock solid:

Progress isn’t “we’re busy.” Progress is “we’re finding problems early, when they’re cheap.”

That’s why a team can look quieter (fewer meetings, fewer messages) and still be massively more effective.

What progress actually looks like in manufacturing/R&D

Let’s make this concrete. Here are “busy” activities and what “progress” looks like instead.

1) Specs and requirements

Busy: debating requirements in email threads

Progress: requirements are versioned, agreed, and testable (with acceptance criteria)

Progress artifact: a single source of truth spec + a test/verification map

2) Supplier and lead time risk

Busy: “following up” with suppliers

Progress: supplier chosen, quote locked, lead time confirmed, alternates identified

Progress artifact: sourcing decision log + critical path lead time plan

3) Prototype builds

Busy: endless “almost ready” builds

Progress: build plan, freeze window, clear pass/fail criteria, test executed, results reviewed

Progress artifact: build report + decisions triggered by test outcomes

4) Engineering changes

Busy: lots of ECOs moving around without resolving root causes

Progress: fewer ECOs, faster ECO cycle time, and clear change impact analysis

Progress artifact: ECO with impact summary (cost, schedule, risk) + decision recorded

5) Launch readiness

Busy: big checklists that get updated weekly

Progress: critical path items are unblocked (tooling, compliance testing slots, packaging approvals)

Progress artifact: risk burndown + readiness gates with actual evidence

The SME playbook: how to turn “busy” into “progress” without adding headcount

1) Decide what “done” means—like you mean it. For physical product work, “done” is not “designed.” It’s usually reviewed, released, and usable by the next function (procurement, manufacturing engineering, quality, etc.)

If “done” doesn’t include who consumes it next, you’ll keep generating half-finished work that creates more coordination later.

2) Replace status meetings with decision meetings. A status meeting is often a verbal spreadsheet. A decision meeting has one job, lock something down.

Use a simple agenda:

• Decision needed

• Options

• Trade-offs (cost/schedule/risk)

• Who decides

• What’s the date of record + where it’s stored

Bonus: fewer meetings, more real movement.

3) Put a hard cap on WIP (especially in R&D). Most product orgs don’t have a time problem—they have a too-many-open-loops problem. Cap WIP like this.

Per person: 1–2 active deliverables max

Per team: a small number of items can be “in progress,” everything else is “not started” or “blocked”

You’ll feel “less busy” in the moment… and ship faster overall.

4) Treat “blocked” as a fire, not a parking lot. If an item is blocked on the critical path, that’s not a note—it’s an escalation. Make blockers visible:

• what’s blocked?

• why?

• owner to unblock?

• target unblock date?

If you don’t operationalize unblocking, your team will stay busy doing everything except the thing that matters.

5) Track risk like a deliverable. For manufacturing and B2B, risk is often the real work and comes in many forms:

compliance

supplier capacity

test coverage

reliability

manufacturability

serviceability

documentation completeness

Your weekly question shouldn’t be “what did we do?” but “what risk got smaller?”

Here’s a quick gut-check you can run on Monday (If you only steal one thing from this post, steal this):

Ask your team to name the three risks most likely to delay launch or derail delivery.

Then ask:

What evidence will retire each risk?

What’s the next action that creates that evidence?

Who owns it?

By when?

If you can’t answer those quickly, you’re probably managing activity instead of progress.

If you can answer them, you’re already ahead of most teams—because you’re doing the thing that matters: turning uncertainty into certainty.