[marcosdumay]

I've seen competent project managers work very hard to achieve that neutral-value proposition. I haven't yet seen any one succeed.

In my experience, as soon as you decide your projects will be formal and managed, you are already doomed to that negative value.

[midasuni]

Sometimes you need a formal project. We’re kitting out a new office over the next couple of years, it’s a major programme of multiple projects, all which interact. At the end of it though we have a building fit for purposes following the plans currently set. I’m sure those plans will adjust a little, but the end date is January 2025, or July, or something - I’m sure the date will slip.

You can’t build a £20m facility with a series of sprints.

[marcosdumay]

Well, the Empire State Building was famously built as a series of sprints...

You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.

Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.

[trog]

Think of the "formal project" is the API by which executing the design can be understood by all stakeholders.

It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.

If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.

But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).

[marcosdumay]

> If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.

How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?

> But pretending planning ahead on large projects that is something that will just happen by osmosis

I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.

[trog]

If they are good project managers, they plan for non-routine delays and account for them in the project schedule. Before people are allowed to commit to schedule, the project managers make sure that these people have properly scoped and estimated their part of the work, by asking pointed questions, using their domain expertise and general experience to figure out if they're being bullshitted or not.

If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.

It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.

It sounds like you just might not have been lucky enough to work with really great project managers!