Ask HN: How often do your projects miss deadline
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'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.
17 comments
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.
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.
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.
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.
> 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 - but it doesn't seem to be active anymore.)
2. Based on that memorable quote, your therapist may also be a Zen master.
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 - but it doesn't seem to be active anymore.)
2. Based on that memorable quote, your therapist may also be a Zen master.
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.
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.
This will help - https://dilbert.com/search_results?terms=Deadline
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.
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.
Yes, but don't you solve problems by implementing features?
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."
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."
Yes you do, but there are thousands of ways you can skin a cat.
Sometimes that automated something you thought was really important but super hard to do might not be as useful as one would think and the user requested it because he could.
The trick is to have a flexible scope based on what problem you are trying to solve and not around a specific feature/solution.
Sometimes that automated something you thought was really important but super hard to do might not be as useful as one would think and the user requested it because he could.
The trick is to have a flexible scope based on what problem you are trying to solve and not around a specific feature/solution.
I have also created many problems by implementing features - usually by weighing down a system with extra complexity that turns out to be of very limited value to users. From this extra complexity are born future bugs.
Some features are best left unimplemented.
Some features are best left unimplemented.
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.
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.
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.
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.
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.
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
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.
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.
Moreso in bigger organizations where you have very little influence on the participation and quality of input by cross-domain team members.
As a small startup, we never miss deadlines.
When I was in a small team at a larger org, we always missed deadlines.
When I was in a small team at a larger org, we always missed deadlines.