as usual, it all depends

When a customer wants changes to parts that have already been developed, we look at what it’ll cost and how much budget we have left. If we still have enough left to do the change without impacting what still needs to be developed, then we just do it. If there’s not enough left, we either take the hit and do it anyway or propose to do it a future phase… Obviously, this depends on a few factors

If requirements change of parts that we haven’t developed yet, estimates are basically adjusted according to the changes. If that turns out to put us over budget, we again see whether we’ll take the hit or propose it for a future change. If the changes end up giving us more budget flexibility, then that’s obviously good for other future changes that might be requested.

Generally speaking, we’re very flexible as long as the budget allows it. Once we go over budget, it sorta depends

Priorities can be changed as well… if the priority of a task or a set of tasks is moved up, we just need to make sure that all tasks that the newly-moved-up tasks are dependent on are moved up as well. This typically doesn’t influence task-level estimates though, unless a temporary solution is introduced somewhere to be replaced by a final solution later on in the project. And again, then it all depends

“The problem with any kind of estimate is that they’re mistaken for the truth, whether it’s a customer or management, and that success or failure is often measured according to these estimates which is just nuts.”

I fully agree that it definitely should not be a measure of success or failure

“A link can also be made with ‘fixed-price’ projects which is the sad reality of our industry today, as this is often (according to my experience) a lose-lose deal. ”

Well, that depends on how well you (as an organization) have learned to estimate. For instance, we keep track of time spent on each task and we can compare them to the original estimates. We also know how much overhead (both technical and project management) we typically need to estimate for a given workload based on our historic figures. With that data, we’re in a position were we can usually make a reasonably accurate estimate for fixed-price projects, and in fact, we prefer to do projects that way. Of course, that does mean that we have to make sure that our task-level estimates are reasonably accurate and when they aren’t (give or take… certainly doesn’t have to be 100% all the time since that’s impossible), we need to figure out why there was a big difference so we can prevent that from happening in the future.

But yeah, if you don’t do any of those things then you’d be stupid to do fixed-price

and no worries, it is indeed an interesting discussion

As usual I’m ruining the conversation by bending it from short-term to long-term estimates , but it’s a very interesting discussion nonetheless.

Those long-term estimates are still important, if only to get an idea on how much money will be required to do the whole thing, or to get an idea of what can be done for a certain price. They’ll never be 100% correct, but it shouldn’t be that far from reality either. Even if you do follow the agile-mindset, there will (in almost all cases anyway) be a total estimate and the closer it turns out to be to reality, the better for everyone.

Also, the company you work for does software to support its core business, but software is not its core business. There really is a big difference in how projects, budgets and schedules are handled between companies whose development supports core business, versus companies where development _is_ the core business.

But this post was more about possible dangers of short-term estimates anyway

I realize however why estimates are important for customers and management because it’s about the money. But what I don’t understand is why they are holding on to ‘gambles’ as the sole criteria for executing/evaluating a project. I don’t see estimates being that important to the software industry either. Most win-win projects I have ever been a part of didn’t need estimates, but they fully employed the agile mind-set which was enough for these customers to go with it and mark it as a success afterwards because they added business value instead of merely making an arbitrary deadline. But I don’t have to preach to you why agile works.

My apologies for the long reply.