Estimating
Project managers, product developers and software engineers know that estimating is demanded by many external and internal stakeholders. Forecasting the time it takes to develop specific functionalities is pretty hard, therefore estimating is a debatable topic nowadays.
Advantages and disadvantages of estimating
There are fundamental reasons managers and developers started estimating at first. They include, but are not limited to:
- If accurate it helps to prioritize the tasks;
- If accurate it helps to set up objective and fair pricing;
- If accurate it helps coordinate the whole project. It’s one of the major 3 cornerstones of management: time, quality and money.
Please, notice the emphasis on the conditional clause – “if accurate”. That sets up the basis for the greatest disadvantages of this practice:
- Is very difficult to execute accurately and often fails;
- High risks and severe implications for inaccurate estimating – underpriced projects and development costs not covered;
- Demotivating the team;
- Lack of flexibility;
- Other agile (scrum) development related reasons.
The reason for bad estimating
There are different reasons for inaccurate estimating, yet the most important ones include:
- Lack of experience in developing in a specific industry. Each market has its own peculiarities and usually only hands-on approach gives the skill to predict well.
- Lack of experience in working with a specific technology.
- Lack of experience working with a specific client. Its responsiveness affects the duration of the development.
- Team members do not know each other well enough and cannot predict each other’s performance.
- Software engineers and project managers might not be motivated to put effort into estimating as they might not believe in its accuracy and general sense.
- The nature of the future development is uncertain and therefore doomed to inaccuracies.
Not surprisingly the reasons above suggest experience as being the key driver for accurate estimating. So for example if you demand projections from a web development team, first of all make sure you’ve selected an experienced one. On the other hand, if estimating is flawed by meaningful deviations, maybe it’s worth substituting it with a more reasonable alternative like Agile?
When you burn the estimates start Budgeting
In a nutshell, Agile and its derivatives like Scrum suggest working in small batches (sprints), delivering and reflecting on the results without long-term planning and estimating. Yet, sometimes a team might still be forced to plan. In those cases, budgeting can be a great alternative.
As opposed to trying to guess how much it will take to make for example a sophisticated web app, an agile based software development team might ask how much time it or the client himself is actually willing to dedicate for that web project. The time the team is planning to spend on the project is the actual estimate. As soon as it’s over, the developers will stop working on it. It’s done when it’s done as they say. Mike Cogn – a consultant from Mountain Goat Software is the one to also express this thought.
Such budgets can be regarded as sprints in the Scrum methodology and drag the software development team as well as external stakeholders into this approach. It helps to manage expectations better, focus on key deliverables and set-up fair pricing. It shifts your mind from the external (external goal to reach) to internal (let’s build the most from what we have) view. The latter is often considered as resource-based strategy approach.
Tips
Even though each company is suggested to find the best what works for it, there are some patterns of dealing with estimates we could spot among our successful companies.
First of all, they work agile. Easy to say.
Experienced Web development companies at our network, put much effort into aligning all the stakeholders and educating them about the benefits of agile approach and MVPs. To manage expectations well, they strongly recommend less focus on estimates and more emphasis on sprints, product value and customer feedback.
They focus on the vision and the client value as opposed to a mere features roadmap. Sure, vision as a concept is even less precise and more difficult to predict, but this difficulty to forecast actually leads to teams focusing on building something small, but tangible and less emphasis on mid-term plans like the whole product roadmap, which in many cases is doomed to change.
They have strong internal discussions, much communication and clarification happening. Yet, in the end they always deliver a tangible product, MVP or a feature. Constant evidence of tangible results increases client’s trust in a team and sometimes provides with more autonomy.
Finally, what separates great software development companies or teams from the average ones is this passion for building quality products and setting the highest standards. Please, do not misunderstand – quality does not mean feature-abundant or over-detailed, which is against the whole Scrum and Lean approaches. Quality is delivering the best reasonable outcome from a given situation. Developing team’s culture, which is passionate for high development standards should be one of the goals for many development teams.
To sum up, estimating software development is often inaccurate due to in-experience. Therefore it’s highly recommended to deal with the ones, which have already done it before. An even better alternative is to develop software in an agile way and simply budgeting the time you want to allocate to the project and try getting the most out of it. Once again an experienced team would be able to guide you about reasonable scope. Successful software development companies focus on vision and customer value, engage and educate all stakeholders, communicate much and have enormous passion for high performance and quality products.
So #Burntheestimates, stay agile and build #stunningproducts.
