Hacker News Reader

Comment by crispyambulance | Hacker News Reader

Well put.

Deadlines often slip. It happens ALL THE TIME, regardless of elaborate and sophisticated project management techniques and skilled contributors. Deadline slippage is also RARELY FATAL, but yeah, leads/PM's can absolutely get themselves metaphorically shot by bearing bad news to the wrong people at the wrong time.

Some orgs hire a ridiculous number of PMP's who pretend like they're making a difference but are really just practicing an elaborate dance of goal-post-moving to appease the deadline-gods. People in such orgs often bullshit about a "track record" of being "always on time and under budget".

Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.

View on HN

I've been in organizations where people know projects slip and are mature about it but I've also been in places where projects absolutely do not miss their go-live dates without a major impact for the relevant managers and teams.

Always wise to know what the corporate culture is around these kinds of things.

Agreed, especially when you're dealing with external clients. I've been in situations where internally we've been fine with a slipped go-live date, only for a CEO at a client to send an email at 4:50pm putting everyone on blast and demanding that all developers stay at the office until it is live, or else (no lie, literally had that email, quote for quote, in my inbox less than a year ago).

Corporate culture includes everyone involved in a project. You can't be calm if you have someone outside of your office going mental over something being a day or a week late.

> practicing an elaborate dance of goal-post-moving to appease the deadline-gods

I've seen this so many times, it's like why even bother attempting to describe what we'll deliver. Just put the date down.

> Best thing OP can do is learn from the mistakes and speak up next time during planning phases, well before deadlines slip.

How do you know deadlines are going to slip when planning the project? Makes no sense.

After you gain experience from previous slipped deadlines, you can see patterns that lead to slippage and, more importantly, get wise to the smell of unrealistic expectations. That's how you know that deadlines are going to slip.

you're assuming that deadlines are set based on the amount of time the work requires. Not often true. Generally deadlines are set before anyone knows how much work is required.

That's one of the patterns.

How to do you know? Because they almost always slip. Take the original estimate, which is always optimistic, double it, add another 50% "just in case", and you're a lot closer.

Take your estimation of the work to do, multiply it by 2.

Surprisingly, it works relatively well to estimate how long the project will actually take.

Those multiply by whatever factor estimates are perhaps defensible if you're talking about a few person-hours for a small no-bid project.

It falls apart if you're talking about 10's to 100's of people working for weeks/months/years, or wherever you need to compete with other vendors for the contract.

For those projects, everybody is over-optimistic in their respective bids (some could say they are basically lying...). But that's part of the game unfortunately.

However sometimes, it can be a calculated risk, for most projects, something is provided by the client, and generally they are also late on their parts. If played correctly it can hide delays on your side.

Also, being over-optimistic in a bid doesn't mean you have to be over-optimistic internally, you could set realistic expectations internally and "manage" properly the delays on the customer front.

Just to be clear, this is a cynic view of things. Every time I see something like that, I cringe inside (and even outside).

However the 2x rule can be quite limited in big projects as it doesn't account for the overhead induced by the size. In a team of hundreds, 30, 40 or 50% of the efforts can be lost due to difficulties in communication, management layers, heterogeneous set of competencies and skills, etc. It's harder to identify what this overhead could be. They can be huge differences between relatively well integrated teams and a complete mess.

My business sponsor claimed to always take my estimate, double it and bump the units.

3 hrs => 6 days

2 days => 4 weeks

So how would he estimate 1 year project?

2 decades

"Never"

Hopefully no one is looking at a project and saying "that will take a year". You estimate tasks and that gives you a project timeline. Those tasks get the double and bump.

Or say 2 decades and get all the praise when you come in under time and budget.

Reply on news.ycombinator.com