While reading an article about Agile ("Agile grows up and new challenges emerge") I found this quote:
Agile thinking requires us to recognize that we cannot plan further than we can see, and that predictions and estimates become hazier the further into the future we try to project. This recognition makes the traditional concepts of carved-in-stone estimates, schedules, and even corporate strategies untenable. If we can’t know what the marketplace will look like in three years, much less how our teams will choose to respond to the new realities, what’s the point in planting stakes in the ground?
I really like the quote. It’s something that anyone who has had to run a project should know only too well, and it’s a feeling that I’ve often encountered when talking to customers when it’s clear that their requirements aren’t too well defined (whether they know that or not).
So, how do you price/quote/estimate for these projects? What do you do when you want to run a development project in an agile manner, however the end customer demands a fixed price affair? Are these two things simply incompatible or are there approaches you can take to get the best of both worlds here?
On my part, some research is required here to see what’s out there – however my gut feel is that a set of simple info graphics or charts would be helpful to explain some of the salient points to customers quickly and easily, without requiring them to have a degree in software engineering to understand your quote/estimate. Failing that another approach could be to focus on debunking the myth that any software project (web, client, whatever) is ever really '”finished”. So rather than talking about a fixed price you could be talking about the fixed price budget for the next x months or years, and then focus on ensuring the appropriate features are prioritised in sprints.
This sort of thing seems like something that people must be talking about somewhere. If anyone has any links or resources to point me in the right direction they'd be most appreciated.