Imagine for a second that you are driving cross
-country. Oh, like a massive road trip. New York,
LA, that kind of thing. Yeah, exactly. You're
embarking on this massive, ambitious journey.
But in this specific scenario, someone has gone
ahead and removed every single rose sign on the
highway. Wow. OK, that's already a nightmare.
Right. And not only that, but they've actually
reached into your dashboard and ripped out your
gas gauge, your speedometer, and your GPS. Oh,
man. So you're just driving completely blind.
Completely blind. I mean, you have your hands
on the wheel. You can hear the engine roaring.
You are definitely burning fuel. And you're undeniably
moving forward. Yeah, but you don't know where.
Exactly. You have absolutely no idea if you are
actually getting closer to your destination or
if you're just driving in circles in the middle
of the desert. The anxiety of that kind of journey
would just be completely paralyzing. I mean,
you would have zero frame of reference for your
own effort. And that blind, terrifying road trip?
That is exactly what this is like to execute
a massive project without milestones. It really
is. It's just motion without direction. Yeah.
So our mission for this deep dive is to uncover
how we actually track progress and why meeting
a goal might sometimes be a complete illusion.
Which is such a wild concept to wrap your head
around. It is. And we'll also get into how a
remarkably simple software notation dictates
the flow of time and money in the modern working
world. Yeah, the literal architecture of how
we work. Exactly. And we are pulling our insights
today from a really foundational article on project
management, which draws pretty heavily from core
industry texts, like the fast -forward MBA in
project management. It's a dense read, but there
is so much gold in there. There really is. OK,
let's unpack this. Because when you open up any
professional project management software, a milestone
isn't just a regular task on your to -do list.
Right. It's not like buy milk or draft an email.
No. It is defined by a concept that feels honestly
totally counterintuitive at first glance. It
is defined as a zero time task. A zero time task.
Yeah, that phrase usually stops people in their
tracks the first time they encounter it. Right.
Because it sounds impossible. It does. Because
we are so profoundly conditioned to think of
work strictly in terms of duration. I mean, if
someone asks you about a task, your brain immediately
assigns a time value to it. Oh, 100%. Like, oh,
that'll take an hour. Exactly. You think. Writing
that report takes three days or compiling that
data takes two hours. We just default to duration.
Pinking a living room takes an afternoon. everything
takes time, but then you encounter this specific
entity in the software schedule that literally
takes zero minutes and zero seconds to complete.
Yeah, and visually it's represented by a very
special notation on the got chart. The black
diamond. The black diamond. It's just a solid
black diamond that sits there on the timeline.
It does not impact the project duration itself,
it just acts as a specific point in space and
time. Like an anchor. Exactly, an anchor. Like
the official start date or the end date of a
major phase. The visual of the Black Diamond
is incredibly fitting actually because it's hard,
it's fixed, and it doesn't stretch or compress.
Right. Not the way a standard bar chart does
when you're representing, like, a two -week task.
It's just a point. To make sense of the zero
-time concept for you, think of it like the flash
of a camera at the finish line of a marathon.
Oh, that's a great way to look at it. Yeah, the
flash itself doesn't take time. It doesn't add
to the runner's speed. It doesn't take away from
their speed. And it certainly doesn't require
the runner to stop and perform an activity called
get flashed by camera. Right. They just keep
running. Yeah. It simply marks that a specific
anchor point, the finish line has been achieved.
So the physical running was the task, but the
flash, that is the milestone. What's fascinating
here is the psychological shift that zero -time
tasks force upon an entire organization. How
so? Well, when you separate the duration of the
work from the achievement of the mark, you are
conceptually forcing a major shift in focus.
You are demanding that the team move their attention
away from the state of just being busy and place
it entirely on Achieving success. Oh wow Being
busy versus achieving success. That is a massive
distinction It is the absolute core of effective
management because you know, you can easily have
a team that is incredibly busy For six solid
months. Oh, yeah Working weekends, drinking way
too much coffee. Exactly. They are billing overtime
hours. They are typing thousands of lines of
code. They are pouring literal tons of concrete.
The duration tasks are actively being executed.
They're doing the work. Right. But if they haven't
crossed a black diamond, if they haven't triggered
that zero time event that officially declares
phase one complete, then all that busyness has
not translated into an achieved anchor. That
makes so much sense. The milestone forces everyone
to acknowledge that raw effort is just not the
same thing as a tangible outcome. It kind of
strips away all the excuses, doesn't it? Like
you can't just sit in the meeting and say, well,
we worked really hard this month. Yeah, the Black
Diamond does not care how hard you worked. Right.
The camera flash either goes off because you
crossed the line or it sits there in silence
because you didn't. Exactly. And, you know, a
single camera flash at the end of a race is simple
enough to grasp. But when we scale this up to
say building a skyscraper or launching a massive
new software platform or coordinating a global
supply chain, you don't just have one finish
line. No, you have thousands of them. Right.
You have this sprawling multi -year project that
requires a meticulously planned series of these
flashes. So we really have to look at how these
black diamonds are mapped out over the architecture
of time. Right. And the sources describe these
mapped out milestones as functioning like dashboard
reviews. to check the overall health of a project.
Dashboard reviews, yeah. They basically allow
managers to review the real world status of activities
against the timeline that was planned way back
at the very beginning of the project. When everyone
was feeling very optimistic. Exactly. But it
gets highly technical when you start combining
these dashboard reviews with specific scheduling
methodologies. And the text calls out two heavy
hitters here. the program evaluation and review
technique, which is usually just called PEERD,
and the critical path method. Oh, yeah. These
two methodologies are the bedrock of modern project
management. They are where those zero -time milestones
begin to add massive, quantifiable value. Let's
start with PERT. Where did that even come from?
So PERT was originally developed by the U .S.
Navy in the 1950s. In 1950s? Oh, wow. Yeah, for
the Polaris submarine project. It is specifically
designed to handle uncertainty. Because normally
you might just guess that a task will take four
weeks, right? Right, which is usually a terrible
guess. Always a terrible guess. So PERT forces
you to calculate probabilistic time estimates.
You calculate the optimistic time, the pessimistic
worst case scenario time, and the most likely
time. Because humans are notoriously terrible
at estimating how long things actually take.
We always assume the optimistic time is the reality.
Always. Oh, it'll only take a day. It never takes
a day. So PERT uses a weighted average of those
three. estimate to give you a much more statistically
realistic timeline. OK, so that's Tert. Handling
the uncertainty of how long a task takes. Right.
And then running parallel to that, you have the
critical path method, or CPM. And CPM is deterministic.
Deterministic meaning it's fixed. Exactly. When
you use the critical path method, you are mapping
out the longest continuous sequence of dependent
tasks in a project. Dependent tasks meaning things
that have to happen in a specific order. Like,
you cannot frame the roof of a house until you
have poured the foundation and built the walls.
Precisely. That chain of dependent tasks dictates
the absolute minimum time it will take to finish
the entire project. That sequence is your critical
path. So it's the bottleneck. It is the ultimate
bottleneck. If any single task on that critical
path is delayed by even one day, the ultimate
end date of the entire project is delayed by
one day. There is zero wiggle room. OK, so how
do the Black Diamonds fit into that? I mean,
if the critical path is just the longest chain
of events, where do the milestones actually go?
Well, by strategic By strategically placing these
zero -time black diamonds throughout the schedule,
you can constrain the dates associated with them.
Meaning you set hard deadlines for specific chunks
of the project. Exactly. You are taking a massive
daunting five -year timeline and breaking it
down into smaller manageable intervals. When
you do that, you can determine the critical path
for major schedule intervals rather than just
waiting to see if the entire five -year project
is off track. I see. So instead of just knowing
the critical path for the final launch in, you
know, 2030, you know, the exact critical path
required just to get to next month's Black Diamond.
Yes, exactly. And this interval segmentation
allows managers to calculate something vital
called float, which is also commonly referred
to as slack on each specific schedule interval.
OK, let's put float and slack into plain English
for you. Imagine you're renovating a house. The
task of painting the living room takes three
days. But the milestone, the black diamond for
living room complete, isn't scheduled for five
days. Right. That means you have two days of
slack. You can start painting on Monday. Or you
can delay the start until Wednesday and you will
still hit the black diamond on time. Yep, you
have a buffer. Right. But if a task has zero
days of slack, it means it is officially sitting
on the critical path. And by measuring this slack
interval by interval, managers get an incredibly
early indication of schedule problems. It gives
them a crystal clear view into which activities
are absolutely critical to finish on time before
the next dashboard review. So what does this
all mean? I mean, I have to push back on this
architecture a little bit. Go for it. I hear
terms like interval segmentation, calculating
slack and early indication of schedule problems.
And on a spreadsheet, that sounds incredibly
efficient. Sure. But humanly, doesn't constantly
segmenting a project and calculating your daily
slack just create a never -ending series of high
-stress mini deadlines. It definitely can. It
feels like you are taking a marathon. which naturally
requires pacing and endurance. And you are artificially
turning into a series of frantic sprints. Every
single month, the team is staring at an impending
black diamond, sweating over their diminishing
slack. It can absolutely feel that way. And honestly,
burnout is a really real risk here. But you have
to look at the alternative. Why do we impose
the structure in the first place? Because we
need things to get done. Well, yeah, without
those constrained sprint intervals, you fall
victim to the 90 -90 rule of project management.
Oh, right. The idea that the first 90 % of the
code accounts for the first 90 % of the development
time, and the remaining 10 % of the code accounts
for the other 90 % of the time. Yeah, it is a
very dark joke in software engineering, but it
is incredibly accurate across pretty much all
industries. It really is. Without milestones,
complex projects just drift endlessly. I mean,
Parkinson's law dictates that work expands to
fill the time allotted for its completion. Oh,
definitely. If you have a month to do something,
it takes a month. Exactly. So the milestones,
those black diamonds, they prevent that endless
drift by creating hard walls, even if they do
introduce stress into the daily workflow. But
this internal stress over slack doesn't happen
in a vacuum. A project manager isn't sweating
over a black diamond just for their own internal
tried, or because they want the software to show
a nice little green check mark. No, not at all.
They are sweating because that diamond is tied
directly to external forces. It is tied to the
mission of the business, and frankly, it is tied
to hard cash. Yes. This is where we transition
from the mathematical theory of Pert and CPM
into the brutal reality of business operations.
Because between clients and contractors, milestones
are the universal language. Right. Our sources
highlight that milestones are used to signal
the need for external review or external input.
They trigger vital budget checks. Which is huge!
Yeah. In product contracts, hitting these specific
points often triggers what is called a milestone
fee. This is a massive infusion of money that
is paid out by the client only when certain specific
points are achieved and verified. It's all about
deliverables and benchmarking. Exactly. It's
intrinsically tied to those concepts. And if
we connect this to the bigger picture, you can
see why the milestone fee changes the entire
psychological and financial landscape of a project.
I mean, a contracting firm building a $50 million
bridge doesn't just have $50 million sitting
in a checking account to flip the costs for three
years. No, they would go bankrupt trying to fund
that themselves. To make this relatable, think
about playing a really intense, incredibly difficult
video game. You are exploring this massive level,
you are battling enemies, and your health bar
is getting lower and lower. Oh, I know this feeling.
You are running out of resources, your armor
is broken, your potions are completely depleted,
and you are just barely hanging on. Then finally,
up ahead in the distance, you see it. The glowing
save point. A black diamond. A black diamond.
You know that if you can just drag your battered
character to that save point, your health will
be replenished, your resources will be restocked,
and your progress will be locked in. That is
a perfect analogy. That is exactly what a milestone
fee is for a contracting company. You are burning
through your operational budget. You are picking
hundreds of salaries. You are buying raw materials
and your financial health bar is draining fast.
You're in the red. Yeah. You are just trying
to survive the level until you hit that specific
marker because that is the exact moment the client
opens the checkbook and replenishes your operational
health. Because the client won't just hand over
cash on a random Tuesday just because the calendar
turned over. Right. They want proof. They want
tangible, verified proof of progress before they
wire the next 10 million dollars. So the milestone
acts as the necessary bridge. It bridges the
gap between the highly abstract mathematical
health of a project and the tangible concrete
business deliverables. It's a translation layer.
Exactly. It is the vital translation layer between
the engineers doing the complex work and the
executives paying for it. I mean, engineers speak
in task dependencies and duration. The executives
speak in risk management and capital deployment.
And they don't always understand each other.
Often they don't. But the milestone, that zero
-time event that triggers the fee, is the one
concept they both completely understand. It is
the ultimate handshake between the work and the
money. But we all know that whenever you tie
money, survival, and external judgment to a specific
metric, Whenever a dashboard review stands between
an entire company and its ability to make payroll,
human nature is going to step in. Oh, absolutely.
And human nature has a way of complicating even
the most elegant mathematical models. When the
stakes are that high, the system will absolutely
be tested because project managers will optimize
for survival. Which brings us to the inherent
flaws of the milestone system. or what we could
call the dark side of the diamond. The dark side.
Yeah. Because hitting that point guarantees the
milestone fee and a positive dashboard review,
we really have to look at the unintended consequences
of this architecture. And the source text is
surprisingly blunt about this. It is. It states
clearly that there are severe limitations to
the effectiveness of milestones as a pure measure
of project health. And this is where the illusion
of progress begins to take shape, because the
fundamental flaw is that milestones, by their
very nature, typically only show progress on
the critical path. Just the critical path. Just
the critical path. They completely ignore the
status of non -critical activities. Here's where
it gets really interesting. Because the milestone
must be met to get the fee and pass the review,
managers commonly do something very specific
and very dangerous. Oh yeah. They move resources
away from noncritical activities and dump them
entirely into the critical activities. They cannibalize
the rest of the project to feed the critical
path. Right. And I have to push back hard against
the entire methodology here. If managers are
just cannibalizing their teams, if they're taking
the engineers who are supposed to be building
the long -term safety features or, you know,
writing the user manuals or doing the foundational
quality assurance and throwing them all onto
the critical path just to force that black diamond
to trigger. It's a recipe for disaster. It is.
Then the milestone isn't a true measure of health
at all. It's like taking the structural support
beams out of the second floor. just so you have
enough wood to finish the roof before the building
inspector arrives. That's a terrifying image,
but it's so accurate. Right. The inspector looks
at the roof, ticks the box on his clipboard,
and hands over the check. The house looks done
from the outside, but it's fundamentally compromised.
This raises an important question about the psychology
of metrics, because it is a classic example of
Goodhart's law. Remind us what that is again.
Goodhart's law states that when a measure becomes
a target, it ceases to be a good measure. By
making the milestone the ultimate target tied
to financial survival, you inevitably incentivize
managers to game the system. You literally pay
them to ignore the big picture and focus only
on the roof. Yes. And what is so dangerous is
that the project manager might not even realize
they are destroying the integrity of the project
in the long run. They aren't trying to be malicious.
No, they aren't acting maliciously at all. They
are reacting to the immediate stress of the impending
dashboard review. They look at the critical path,
they see a delay, they know the company needs
the milestone fee to survive the quarter, so
they make a rational short -term survival decision.
Right, they shift the resources away from the
invisible work. They tell themselves, we'll catch
up on the long critical stuff later. We just
need to get past this review. But later rarely
comes. What happens when you execute that survival
strategy month after month? It compounds. It
compounds massively. The non -critical tasks
pile up. Technical debt accumulates. The unwritten
manuals. The untested code. The unreviewed safety
protocols. They form this massive invisible mountain
of ignored work. Just waiting to collapse. Right.
And eventually a non -critical task becomes so
heavily delayed that its float drops to zero.
Oh, wow. So it shifts. Yes. It suddenly shifts
onto the critical path, usually late in the project
timeline, and the entire endeavor violently derails.
The illusion shatters. The green lights on the
dashboard were a lie all along. The roof was
finished, but the second floor finally caved
in. Yep. It is a terrifying operational trap.
And honestly, it's an illusion of progress that
anyone can fall into if they aren't looking at
the whole board. It happens all the time. So
let's distill the journey we've taken you on
today. Milestones, in the realm of project management,
are those zero -time black diamonds sitting on
a timeline. They don't take time. They represent
the achievement of an anchor. They're incredibly
powerful, necessary tools. They allow managers
to conduct dashboard reviews. They allow for
the calculation of float and slack within the
critical path method. And they act as the essential
trigger for milestone fees that keep companies
financially alive. But there's a catch. A huge
catch. As we just explored, they are also potentially
dangerous mirages. They can trick us and our
clients into a false sense of security, incentivizing
us to cannibalize our own foundations and ignore
non -critical work just to keep up appearances
and hit a visible target. And I really want to
turn this directly to you listening to this right
now. Look closely at the projects you are currently
managing in your own work. Yeah, think about
your own day to day. Whether you are building
complex software, organizing a massive event,
or simply managing a small team, are you genuinely
on schedule? Is the underlying foundation actually
healthy? Or are you secretly robbing resources
from tomorrow's invisible work just to ensure
you hit today's visible black diamond? That's
a tough question. It is a deeply uncomfortable
question to ask yourself, but it is absolutely
essential for true sustainable success. It is
essential. And I want to leave you with one final
thought to mull over. We have spent this entire
deep dive talking about software methodologies,
corporate budgets, and dashboard reviews. But
human psychology doesn't just clock out at 5
p .m. No, it definitely doesn't. If project milestones
naturally incentivize us to neglect the non -critical
tasks just to hit a visible, rewarded target,
What does that say about how we measure personal
success in our own lives? Oh, wow. That's a really
interesting point. Think about the Black Diamond
Society sets up for us, right? Getting the major
promotion, buying the house, hitting a specific
salary bracket by a certain age. Those are our
highly visible, culturally rewarded milestones.
The things you put on your resume or tell your
family about. Exactly. But in the frantic, stressful
sprint to trigger those external dashboard reviews,
do we end up cannibalizing the invisible, non
-critical foundations of our own lives? The things
that don't get a green checkmark. Right. Do we
sacrifice our physical health, our fundamental
need for rest, or our deep personal relationships
just to have enough structural wood to finish
the roof for everyone else to see? Yeah. The
illusion of progress isn't just a corporate problem.
It's a human problem. If you are driving cross
-country, like we talked about at the start,
the road signs are incredibly important to tell
you where you are. But if you fixate entirely
on hitting the signs on schedule and forget to
stop and check the oil, eventually the engine
is going to fail. You're going to break down
on the side of the highway. Exactly. Make sure
you aren't just hitting your milestones while
the vehicle completely falls apart underneath
you. Thanks for joining us on this deep dive.
We will catch you next time.