
Ask HN: How often do your projects miss deadline - darepublic
I just missed another deadline on a project.  I think over the course of a ten year career this has happened basically EVERY single project I&#x27;ve been on.  I am feeling particularly bad about it right now so I want to ask the general hacking public: how does this compare with your experience?  Are your projects usually delivered on time neatly wrapped in a bow, or like me are they usually late.
======
codegeek
In 16 years of professional software experience, I would say Deadlines are
like Promises. They are meant to be broken, almost always.

The reason is simple. The ability to define and specify scope/requirements is
a really hard problem. Stakeholders change all the time, they change
priorities all the time, scope items themselves can be too vague or
requirements poorly drafted or the requirements completely change during the
lifecycle etc etc.

Deadlines are missed mostly because they are not realistic. It doesn't mean we
shouldn't have deadlines but we should use them as a ballpark/placeholder to
measure output.

PS: I have only met deadlines in my projects when I was the stakeholder myself
:). Every other time, it is technically a miss or "extension". Fun fact: I
have worked on many 4 week deadline projects that went for months, may times.
I have worked on 6 months project that went for years (looking at you major
investment banks :)). Not just because of me but because of incorrect
expectations, scoping and assumptions from the stakeholders. Our job is to
obviously setup the right expectations and lock down scope as much as possible
but in real world, it is frikin hard.

------
jcpst
Our shop is probably ~700 devs. I lead one little team as a dev.

Here’s what the late projects look like:

No project kickoff with the business and architecture. High visibility.
Deadlines coming from people outside my hierarchy, with no explanation around
who did it or why. Massive, massive scope increases. Estimates turned into
“commitments” by my manager. Stress and pressure put down onto to team. The
c-levels peering in. The team stressing out about the pressure. Managers
creating more stress while I’m trying to promote can-do comrade and keep the
morale up, even though I stress-drink at night.

We missed our deadline today too. The business is in an arm wrestle to operate
more like them, which we would call waterfall.

But like my therapist said, who used to work in IT: “A deadline is missed. A
cloud passes by. A squirrel climbes up a tree.”

I need to keep with my chill self, know for myself personally that I bust ass,
and gladly accept that corporate compensation.

~~~
greenyoda
> _But like my therapist said, who used to work in IT: “A deadline is missed.
> A cloud passes by. A squirrel climbs up a tree.”_

1\. Reminds me of a guy whose blog I used to read. He's a former lawyer,
turned therapist, who has a lot of patients who are lawyers. (His blog is
[https://thepeoplestherapist.com](https://thepeoplestherapist.com) \- but it
doesn't seem to be active anymore.)

2\. Based on that memorable quote, your therapist may also be a Zen master.

------
thehappypm
I'm a product manager. Deadlines are 100% my responsibility and I would never
blame an engineer for missing one.

If someone on my team misses a deadline it means that I wasn't able to predict
the level of effort properly. It means I changed the spec too much and caused
chaos. It means I didn't communicate with the engineer well enough to chart
out their progress and anticipate the delivery date. It means I wasn't keeping
a close enough eye. It means I didn't parallelize the task properly.

------
op03
This will help -
[https://dilbert.com/search_results?terms=Deadline](https://dilbert.com/search_results?terms=Deadline)

------
tucaz
In the past 4 years I have been working for the same company and my team
delivered around 20 or so projects and didn’t miss a single deadline.

Before that, in previous companies, the same thing happened. Lots of projects
and no missed deadlines.

I believe it’s due to a simple thing: expectations.

Project expectations must not be around specific implementations or features,
but around problems solved.

That gives the project team room to learn and adapt to changing conditions
which is especially valuable when you are doing something for the first time.

For the customer, that is having his problem solved, it doesn’t matter if a
button is white or blue or if it is actually a button. It matters that a
specific problem gets solved when it needs solving.

Everything in addition to that is waste.

~~~
HeroOfAges
Yes, but don't you solve problems by implementing features?

~~~
throwawaymsft
Not always. The best code is no code. Sometimes you can clarify requirements
(and realize the request is redundant with existing capabilities), adapt
workflows, combine existing features, etc.

If someone has a request, the first instinct shouldn't be to write more code,
it's to clarify what they are trying to accomplish.

"How do I get the last 3 letters of a file? I need a feature for that."

"Are you trying to get the file extension? We have that in the metadata."

------
rs23296008n1
Any one of these is a bad sign and things get exponentially bad the more you
have: Poor expectations management, poor milestone creation/definition,
inflexibility, poor specification, poor testing. Plenty more.

Wordplay for profit: Have "due dates" and "milestones" instead of "deadlines".
"Due dates" imply on the day after that something new has arrived and needs to
be supported.

We've found most late projects were actually late _before they started_. The
slippage was just a symptom of underlying issues within the team, local
environment or external ecosystem.

------
CM30
About 40-50% of the time I guess. And presumably another so many percent of
projects end up completed long before the deadline instead.

Either way, the reasons are as follows:

1\. The timeframe provided for the project has no correlation to reality, and
either under or overestimates the time needed.

2\. The client/customer needs to do something... then puts it off a few
days/weeks/months.

3\. Feature/scope creep kicks in.

That's just the work related ones. Personal projects get sidetracked all the
time.

------
wowandflutter
On time. Business pushes unfinished and partially tested features out all the
time. And they get concerned when there are production support issues. It’s a
compounding issue, to the point everything is a rush and an emergency. Pure
chaos every single day.

------
maddynator
I read that most govt projects are always ~40%late and over budget. This is
because bad deadlines makes project manager look attractive and then you can
always blame skipped deadline on change in requirement. And requirement always
changes

------
non-entity
At work I've had a number of projects delayed mostly because of ambiguous
business requirements constantly redefined or accidentally discovered and
feature creep pushing back and slowing testing time.

~~~
jasonv
I'll add another one, borne painfully of recent experience: projects are often
delayed because people aren't interested/capable of providing meaningful input
on things until the critical moment is imminent, and that's usually late in a
project, and then you have a pile-up of critical moments yielding real input.

Moreso in bigger organizations where you have very little influence on the
participation and quality of input by cross-domain team members.

------
kaushikt
As a small startup, we never miss deadlines.

When I was in a small team at a larger org, we always missed deadlines.

