The estimate. It's the primary piece of information that you desire as a entrepreneur and Product Owner. It's also the one thing that most developers and consultancies are reluctant to provide. The reason is because once a number is stated, despite the multitude of caveats and disclaimers, that number sets expectations for the rest of the project.
So what’s the problem? Well, combine this with the fact that fundamentally, humans are terrible at estimating and you have a recipe for disaster (or at least a painful experience). Don’t get me wrong, developers and teams can refine their degree of accuracy through constant and thorough reflective analysis (burndowns, retrospectives, etc.), but at the end of the day we are all still subject to the subtle nuances of human psychology.
Inherently, individuals will estimate the effort for any task based on his or her conscious and subconscious opinions about the project, team, and environment. The most common example of this is often known as the ‘Planning Fallacy.’
The planning fallacy is “the tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions. According to this definition, the planning fallacy results in not only time overruns, but also cost overruns and benefit shortfalls - Wikipedia Entry for ‘Planning Fallacy’.
The explanation for this effect is attributed to everything from wishful thinking to self-serving bias (quick tasks are because I am good, long tasks are because others are bad) from framing (the way tasks are presented) to anchoring (past experience dictates effort). I personally feel that hyper-focus on the project's tasks is one of the primary underlying factors. The plan usually only takes into account development / design hours but not extraneous events such as sickness, vacations, and even lunch breaks. This is why when Neon Roots estimates effort, we account for only six (6) productive hours in each day vs. the typical eight (8). Regardless of the reason, the fact remains, estimates are nothing more than a rough guess (or guesstimate if you will).
Sure, this seems like common sense. But that doesn't mean that these guesstimates don’t influence goals or set expectations. In fact, in Neon Roots’ experience, the moment a number is put forth related to effort or cost, that number typically guides the expectations of the client from there on out.
As developers, we need to be careful when issuing estimates in order to properly set these expectations. The easiest way is to avoid issuing hard numbers or working on fixed bid projects. Of course, we know this is not always possible and largely depends on the complexity of the project. The agile process is designed to help alleviate some of these pains. The estimate acts as a guide, while each sprint and the product backlog act as your real-time monitor into the actual progress and velocity of a project. Development projects need to remain as flexible and organic as the technology that powers them, evolving as quickly as their market and user tastes.
As clients, we need to be mindful about the ‘reality’ of estimates. We may be raising money or need to communicate to strategic partners the expected timeline and cost of our project. That said, it is our responsibility to properly communicate that reality and ensure the expectations are properly set down the line. It is also important for Product Owners to evaluate the value of the agile process and its benefits. The existence and continued support for the Agile / Scrum process is due to its success in facilitating process on complex projects. Often times, a strong development team with a successful track record working in agile will exceed expectations in both development time and efficiency (cost savings). When estimating a fixed scope / fixed cost project, developers and consultancies inherently add in ~20% padding to account for unknowns. Under a fixed engagement, this is a cost that you will pay for regardless of the efficiency of your team. If you trust your team, definitely consider an agile development and management process.
So the next time you are asked for / receive an estimate, be mindful that the number that you provide / hear may be setting the (potentially wrong) course for the rest of your project.