In my last post There's No Third Option I wrote about the inherent problem of estimating software projects. A friend of mine brought up the #NoEstimation movement which I had learned of some while ago.
Related articles for reference:
- 'No Estimates' in Action: 5 Ways to Rethink Software Projects (CIO Magazine)
- Why Agile Estimates Don't Work, Part 2 (see also part 1)
Some thoughts, in no particular order...
I do believe that placing a great deal of pre-project emphasis on an estimation is not helpful. Though in reality there will always be the "how long will it take?" question that, for some people, requires a response.
In my company today, upon request we can create a ballpark estimate before the project commences. Within roughly one hour's worth of time, we map out the major features the client needs, and apply hours for UX and development as you might expect, and add them up for a total hours and total cost. It's our best guess with the information we have, with no padding. As such, we always emphasize (in writing) that it's only for rough budgeting purposes, and will assuredly change as the project progresses. If the client wants a refined estimate after user story development has progressed, we can do that...which we anticipate to be more honed. Since we work on a time & materials basis, any estimation work (beyond that initial ballpark estimate) are billable hours. It's been a good, balanced solution that provides clients with information without unfairly asking us to work for free doing lengthy estimation exercises before the project begins.
Clients sometimes mistake time estimations for a price tag that can be shopped around, as you might do when purchasing a car. As my company works on time & materials, we estimate based on the hours we believe will be required to create the solution. Clients can easily misinterpret that hours estimate as a variable that can be reduced (without reducing scope) by shopping it around to other dev shops.
However, a software timeline estimation is better compared to the time estimate to build a custom home: if you want it faster, something's gotta give - quality, or that third living room. Trying to get a better deal elsewhere means you're really after a scope reduction or a quality (price) reduction. It takes what it takes, and there's no free lunch.
To the lay client, software development is magic. However, it's important to emphasize that developing software is the easy part. The hard part is having the UX and developer teams already assembled with a history of successes under their belts, the Agile mindset and best practices adopted by everyone, and the tools and processes in place for teams to collaborate and work effectively. That's what clients are buying. Anyone can hire a bunch of software developers, but getting them to work together as a team to efficiently produce great solutions takes time. Throwing larger wads of cash at that problem will not help.
This is why the estimation conversation is the wrong conversation. When you hire the right team, they're going to do the best job possible for you. Pressing the team on the timeline for a given scope is asking them to compromise on quality. Instead, consider building less, or releasing in stages. That's the better conversation and path to a successful partnership.