Project Management

Please login or join to subscribe to this thread

When Better Visibility Changes the Meaning of Progress

linkedin twitter facebook   Benefits Realization   Governance   Leadership  
avatar
Bruce Buryo
Community Champion

Lately, I have been thinking about something that has emerged from a project I am working on.

Like many projects, we track progress through targets, completion numbers and what is still pending. Recently, however, I have been working on improving how we validate and understand that progress.

And something interesting happened.

The more visibility we gained, the more we started questioning what “done” actually meant.

A number can tell us that work has been completed. But better visibility can reveal another question: was the right work completed, in the right way, and does the result still represent what we intended to achieve?

Sometimes this creates an uncomfortable situation. A project can actually look worse as its controls improve.

More exceptions appear. More things require verification. Numbers that previously looked straightforward suddenly need context.

But perhaps that isn’t declining performance.

Perhaps we simply understand the project better than we did before.

This has also changed how I think about automation. We often talk about automation as a way of doing the same work faster. In my experience, its greater value may be that it allows us to ask questions that were previously too difficult to answer consistently.

So maybe the progression isn’t simply:

Are we busy? Are we delivering?

It is also:

Are we delivering? Is it correct? Does “done” still mean what we think it means?

That leaves me with a question for other project professionals:

Have you ever improved visibility on a project only to discover that your previous picture of progress was incomplete?

Sort By:
avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal
This is a pattern I recognize, Bruce: stronger controls and better validation can make a project appear to be performing worse precisely because they reveal what previous reporting did not capture.

That is why I find it useful to distinguish progress from our measurement of progress.
When better visibility reveals more exceptions, performance may genuinely have changed, but it may also be that our understanding of the existing reality has become more accurate.

There is a further distinction when visibility leads us to question what “done” means.
If the definition itself changes, we are no longer only improving measurement.
We are changing the criteria by which progress is evaluated, and that change should be explicit if comparisons over time are to remain meaningful.

I also agree with your point about automation.
Its value can extend well beyond efficiency by making previously difficult questions consistently observable.
But consistency does not guarantee validity. We can automate the wrong measure just as efficiently as the right one.

So, yes, better visibility can reveal that our previous picture of progress was incomplete.
Its real value is not simply that we see more, but that we can understand more accurately what the project is actually achieving and whether the measures we rely on still represent what matters.
avatar
Keith Novak Tukwila, Wa, United States

Improved visibility can often reveal gaps especially between the expectations of different stakeholders. That's part of the reason for design reviews. People come in with various perspectives and question whether their critical items were adequately addressed.

That is a reason I am very pointed about using certain language in specific ways. I don't want different people to interpret my words in different ways. One classic example I see is in electronic systems where the terms Power On and Power Up sound the same, but mean importantly different things. One is turning on and checking the power supply for all the host systems. The other is turning on all the host systems after they're plugged in which requires a lot more hardware and software. Visibility of the detail level schedule might be noticed that someone's black box isn't shown on the procurement plan which reveals that the customer thinks done is Power Up, while the supplier is only planning for Power On.

avatar
Eduard Hernandez
Community Champion
Corporate Project Manager - Tech Transfer| Neuraxpharm Barcelona, Cataluña, Spain
This really resonates. In my experience, "done" is often built on unspoken assumptions, and those assumptions rarely match across stakeholders. One team assumes "done" means one thing, another assumes something entirely different, and that mismatch quietly generates rework, wasted effort, and misaligned expectations before anyone notices.

A good example comes from life sciences: regulatory approval to release a product. When that approval lands, it's tempting to call the project "done": everyone celebrates, the milestone is hit. But that's rarely the full picture. There's still the entire operational and launch phase ahead, and "done" for regulatory affairs is not the same as "done" in terms of realizing actual business value or revenue. The product being approved and the business outcome being achieved are two very different finish lines.

This is why defining "done" (and recognizing that there may be more than one "done") is so critical. It could mean a distinct definition at each project gate, each tied to a different function or milestone. What matters isn't eliminating multiplicity, but making sure everyone understands *which* done they're talking about, and when.
avatar
Robert Snyder Founder & President| Innovation Elegance, LLC Chicago, Il, United States
The topics of "progress" and done" hint at many teams' lack of distinction between activity and productivity. Moreso, many teams wallow in Infinite Activity and have a deer-in-the-headlights reaction to Finite Productivity, a.k.a. "done."

What is under the umbrella of Activity: meetings, meeting minutes, action items, emails, status reports.

What is under the umbrella of Infinite Productivity: decisions, code, alignments, agreements, expectations.

What is under the umbrella of Finite Productivity: deliverables, Decision Bundles.

I see the concept / construct of Decision Bundles as vital to define "done."
And to convert from a culture of Decision Traffic Jams into a culture of Decision Symphonies.

I can count and defend 54 decision bundles for a typical "Innovation Ensemble."
I can orchestrate these with a finite number of verbs (not the finite number of adjectives in RACI).

I can defend a Finite Productivity of 54 x 4 = 216. Armed with that number, anyone can disagree and calculate their own Finite Productivity. Every lessons learned tunes the metric of Finite Productivity.

This metric makes untrustworthy executives nervous, because it fuses together authority and accountability. Untrustworthy executives LOVE RACI because it decouples authority and accountability.

I would have loved PMs and humans to orchestrate "Finite Productivity" on our terms, but I think it's too late. Orchestration is an AI buzzword. AI will orchestrate agent productivity on its terms. Orchestration (low waiting) is very financially attractive, but it demands discipline and humility that humans don't have (unless you're sitting literally inside a symphony). Technology executives love Sprints not Symphonies.
avatar
Sandeep Kashyap CEO| ProofHub India
This is an important distinction. Sometimes a project looks healthier simply because we aren’t seeing enough of it.

As visibility improves, the numbers can get messier. More exceptions show up, more questions are asked, and “completed” gets challenged. But I’d take that over having clean numbers that give everyone a false sense of progress.

Good visibility doesn’t just tell us more. It makes us question what we thought we already knew.

Please login or join to reply

Content ID:
ADVERTISEMENTS

I'd rather be a failure at something I love, than a success at something I hate.

- George Burns

ADVERTISEMENT

Sponsors