Art Yerkes

If the person who wants these things doesn't have an answer and that answer isn't 100% credible, then planning and tracking go into phony overhead territory right away. This is part of why we feel that they're arbitrary and an impediment; ultimately, tracking isn't actionable.

If we have a roadmap where everything is required, a product vision that includes 100% necessary content, then what does planning the time and tracking it actually _do_? It doesn't inform the plan, you can't change the plan and the decision about when to pull the plug comes later

Here's my idea of a remedy: set a stop early; say "if at any point this project is 10% over its budgeted time to a given burndown point, then we abort the project. one week in, 10 or 100".

Note that aborting it doesn't necessarily mean deleting the code and closing the company, just that the project as conceived, based on actionable information reached some threshold and we decided beforehand that we'd make choices when that happens (beforehand is important).

So this has an interesting effect: you _can't_ skate on an underbudgeted project for long. There's no way anything like today's projects with razor thin margins would survive for long, but luckily you could use this decision time for negotiation.

People fool themselves into believing that when you've made a plan with a short timeline that you tricked the universe or did something clever. Very often the presented budget is much less than what you'd actually be willing to spend, which is why software projects overrun.

Lots of budget negotiations aren't sincere in this way because the stakes are too low. We know we can benefit by lowballing and we know the organization can and will spend more when the project overruns. It's a shadow negotiation where we estimate tolerance outside the process.

Imagine a project where everyone stops working and (at least temporarily) walks away when the budgeted stop point is met. You've got a much different risk profile. Underbudgeting itself can cause delays, and either way the project will need to be restarted w/new budget.

OTOH, there's a clear use case for tracking, and planning, and it's clear what their role is. Rather than a "we're behind" sinking feeling, but giving nothing else, as a programmer, you know that there's an end to a deathmarch regardless of whether it was entered into sincerely.