I can relate to these (anti)patterns of behavior. However, executives make those decisions because they have no way to evaluate (objectively) the impact of their decisions on the project. The software engineering community has been trying to solve this by adding more (and more, and more) complex estimation processes to software engineering. Only to discover that estimation fails very consistenly (I tackle that here: https://vimeo.com/111100275 / video from Oredev/2014).
Because estimation is such a bad method to know the impact of decisions, the behaviors you describe have horrible consequences (I mean, how hard can it be, we are just asking you to change a field in a form....).
We need a much better alternative to make project-schedule relevant decisions. I propose rolling wave forecasting, which builds on continuous and incremental releases that the Agile community has been advocating since the early 2000's. It is possible to make consequences visible, if we are just ready to accept that estimates are not the right approach to answering project critical questions.
Making the cost of changes visible (or painful) is one way to make decision-makers in the future consider the cost. However it still does not answer the question "when will we be done". I've been using (rolling wave) forecasting to make that clear. For example: it may be expensive to re-analyze one portion of the project requirements, but what will be the impact on the release date? You know, by Xmas we must be out or we will lose one-third of the yearly sales...
Forecasting continuously, and removing/adding/changing scope in the project allow you to manage your release date on your own terms. Without spending time "guessing" how long something will take, and constantly adjusting the project content to be able to meet your business goals.
Why estimate that way at all? If you have been working on a project for 6 weeks you already know the "real" capacity (throughput) of the project. Just take the velocity from the last 6 weeks (how many requirements/user stories) did you deliver to a production-like environment, and divide the remaining stories / requirements by that number. This will give you the number of weeks (take the average velocity/Week) that the project requires to be completed (if no requirements/stories are added;)
Me and many others have been working this way for many years (I started in 2005) and with great success...
Slashdot Mirror
I can relate to these (anti)patterns of behavior. However, executives make those decisions because they have no way to evaluate (objectively) the impact of their decisions on the project. The software engineering community has been trying to solve this by adding more (and more, and more) complex estimation processes to software engineering. Only to discover that estimation fails very consistenly (I tackle that here: https://vimeo.com/111100275 / video from Oredev/2014). Because estimation is such a bad method to know the impact of decisions, the behaviors you describe have horrible consequences (I mean, how hard can it be, we are just asking you to change a field in a form....). We need a much better alternative to make project-schedule relevant decisions. I propose rolling wave forecasting, which builds on continuous and incremental releases that the Agile community has been advocating since the early 2000's. It is possible to make consequences visible, if we are just ready to accept that estimates are not the right approach to answering project critical questions.
Making the cost of changes visible (or painful) is one way to make decision-makers in the future consider the cost. However it still does not answer the question "when will we be done". I've been using (rolling wave) forecasting to make that clear. For example: it may be expensive to re-analyze one portion of the project requirements, but what will be the impact on the release date? You know, by Xmas we must be out or we will lose one-third of the yearly sales... Forecasting continuously, and removing/adding/changing scope in the project allow you to manage your release date on your own terms. Without spending time "guessing" how long something will take, and constantly adjusting the project content to be able to meet your business goals.
Why estimate that way at all? If you have been working on a project for 6 weeks you already know the "real" capacity (throughput) of the project. Just take the velocity from the last 6 weeks (how many requirements/user stories) did you deliver to a production-like environment, and divide the remaining stories / requirements by that number. This will give you the number of weeks (take the average velocity/Week) that the project requires to be completed (if no requirements/stories are added ;)
Me and many others have been working this way for many years (I started in 2005) and with great success...