As a project manager, it sounds like you're making excuses. Just give me a number, trust your gut!

We have a fundamental failure to communicate, what we're doing. The game project managers and finance believe we're all playing is a regression towards the mean, where everything is additive and rounds up to nice consistent formulaic sums. Whereas software development follows power law distributions. A good piece of software can deliver 10x, 100x, or 1000x the cost to produce it (ex: distribution, cost of delivering another copy of software is near 0 once written). You don't get that sort of upside with many other investments. Finance is happy with an NPV 8% above what they invest in. This means that when software people talk, everything they say sounds foreign, and everyone assumes it's because of jargon. It's not. The fish don't know they're swimming in water. When the fisherman comes, everyone is caught off guard.

So we get what the author talks about

> The estimates stopped being estimates. They became safety railings against being held accountable for unreasonable expectations.

We. Pad. Like. Crazy. Yes this is inefficient. Some project managers recognize this. We get theory of constraints. But rather than cull the layers of hierarchy that lead to the padding in the first place, all the blame for failure goes back to developers. Get hit on the head enough and you will stop acting in good faith and pad to save your ability to feed and cloth yourself.

▲

joombaga a day ago | parent | next [-]

It's not obvious to me that we should avoid padding, or why it's seen as undesirable.

▲

vegetablepotpie a day ago | parent [-]

Padding ties up capital, it reduces credibility, it delays deployment, it adds costs through delay. It is bad for organizations. However, it is a great solution if you're a worker in a bureaucratic environment that can tolerate large costs, but is intolerant of 1-day of schedule slips. It's a great solution for complacent management, who are confused about the game they're playing and wants to report that they're "on track", which means "not late".

The agile solution of incremental value delivery is a compromise, and can produce good outcomes for functional changes. But agile has unacceptable failure modes when working on infrastructure and satisfying system constraints. Agile can work okay for programmers, but it's not a solution for engineers. Acknowledging, owning, and managing risk is more scalable, but you have to have leaders who acknowledge that they exist and have the maturity to take on that responsibility.

	▲	ryan_lane an hour ago \| parent [-]
		> Padding ties up capital, it reduces credibility, it delays deployment, it adds costs through delay. Well done timelines are a negotiation between the stakeholders and engineers. The stakeholders need something done for the business, the engineers give a timeline. If that timeline works for everyone, great. If it doesn't, then the stakeholders will ask if it can be done in a faster time. A timeline that lands on time, or early, is good. The point of timelines is that teams outside of engineering are resourcing their projects based on your timelines. They may have made outside commitments to customers, they may be lining up marketing, they may have embargoed PR, it may be delivered by someone at a conference, etc. A project running late can be catastrophic. Bad customer relations, wasted marketing spend, pulling back stories from PR, delays for dependent teams, etc. You pad to make sure your timelines aren't overly optimistic, because we're all bad at estimating, and it's possible our dependencies are too. By padding, when it comes time to negotiate for shorter timelines, you also have some wiggle room. Bureaucratic environments tend to be larger companies and they care about schedule slips, because they have more teams being impacted, and those teams are handling larger numbers of overall projects. Schedule slips can lead to cascading failures.

▲

Trasmatta a day ago | parent | prev [-]

> As a project manager, it sounds like you're making excuses. Just give me a number, trust your gut!

If we're just making up numbers, why don't you just make it up yourself and save the developers the trouble?

▲

vegetablepotpie a day ago | parent [-]

Ah! But I want you to own it. If you say it first... you own it. And I do not have to get you to agree to it.

	▲	Trasmatta a day ago \| parent \| next [-]
		This is usually how I get tricked into setting deadlines. I get asked for a "rough estimate", then it magically becomes a deadline.
	▲	a day ago \| parent \| prev [-]
		[deleted]