‘If you ever wanted an example of Heisenberg’s Uncertainty Principle applied to software, estimation would be it’
Nearly every software development project starts with one question: how much effort is this going to take in terms of time and money? Or simply put, ‘What’s the damage?’.
Now, that’s a question easier asked than answered. Regardless of experience in software development, answering it ‘off the cuff’ is hardly ever possible. And here is what happens behind the scenes when you ask us for a quote.
Initially, what we can base our estimation on is just an outline of a project, minus specifics. You, as a client, will obviously be looking for the best bid. And so, to secure this bid, we, as a provider, will bid to win. No matter how unethical it may sound, ‘pricing to win’ is a common practice. Managers need to understand the probable price range before they decide on profitability of such an investment and have a budget approved for the project. Thus when you ask for a quote, you receive a ballpark estimate.
It’s a document including:
- List of features
- Rough order of magnitude estimate
- Evaluation of technical feasibility
It is free, part of a Presale stage of our collaboration with a client, and may take as long as a week.
How to calculate a ballpark estimate
The initial estimate is conducted by programming experts, based on whatever data is available at the start – business requirements, specification, project description or other. It is done mainly intuitively or by analogy with similar projects. Calculation of cost is just one aspect within the scope-effort-schedule-staff-cost correlation.
As originally we mostly operate with unknowns, it’s important to keep balance, because both underestimating and overestimating are equally undesirable. The former leads to cost overrun, staff burndown, low quality deliverables, and loss of credibility, if deadlines are missed. The latter makes the project too expensive and uneconomical with regard to resources (consider Parkinson’s Law: ‘Work expands so as to fill the time available for completion’) or may result in lost opportunities if extended over a longer timespan – both factors are likely to eat up a vendor’s profit.
Why is it always a range of values
You cannot expect it to be accurate by default. It’s more about setting expectations for a project. Thus a ballpark estimate is an order-of-magnitude figure ranging from the most optimistic to the most pessimistic guess. And the actual cost is not necessarily the happy mean.
Such a span is not a figment of developers’ imagination or a whim, but has a scientific basis. The ‘Cone of uncertainty’ will narrow with time when requirements become clearer, more precise and detailed. But the maximum and minimum cost figures will converge only at the finish. The cone of uncertainty is equally applicable to estimation of costs, resources, time, effort, and scope.
Picture 1. The Cone of Uncertainty (from Steve McConnell’s ‘Software Estimation: Demystifying the Black Art’)
How inaccurate is a ballpark estimate
Even though the inaccuracy is received as a result of the most precise estimation conducted by technical experts, the initial estimate can be off as much as 400% on the high or low side. That only narrows to +∕−200% after product definition is approved and to about +∕−150% after requirements are completed. As you see, uncertainty is unavoidable and the initial range can be narrowed considerably no sooner than a third of a project has been accomplished.
Picture 2. The Cone of Uncertainty in calendar representation
That is why with fixed-price contracts a detailed estimate calculation takes so much effort, and still does not guarantee 100% accuracy. In case of Time and Materials model, where Agile methodology is implemented, there is no need to secure the price variable at the start. Thus initial rough estimation can be honed ‘on the go’ and there is a chance to adopt the most appropriate and economical direction anytime.
Do I need a ballpark estimate
Well, that’s what you asked for, isn’t it? And it’s the most we can do for you at the beginning. The purpose of a ballpark estimate is to give our client an approximation of cost within a range of required functionality. This document serves for information purposes only.
This one comes later on, in case you agree that the project is within budget and fit for a Fixed-price model of engagement. It is a costly project in itself that comprises thorough analysis of business and technological aspects and risks, elaboration of a detailed specification, and complex algorithmic computations along the lines of five parameters mentioned above. A detailed estimate is provided as part of a Work Order together with a project plan, technical requirements and acceptance criteria at the end of Pre-Production Stage (Stage 1) of software development process.
How detailed is a detailed estimate
This estimate contains a more elaborate description of cost of deliverables and services. It’s detailed enough to result in greater precision so that both sides have a common understanding of the project’s objectives and the product’s values. To give you an idea of the scale, let’s look at how technicians break down the development scope. They use hours as units of measure. Every item must be less than or equal to 16 hours (2 days) of development. We make a special point of this requirement as planning over longer periods yields less certainty. By doing this, we can guarantee greater precision of our expert estimates.
As we have shown above, the cone of uncertainty narrows considerably by the time a detailed specification is ready. Still the following three categories of items remain:
- known unknowns
- unknown unknowns
Just a glimpse at technicalities
The Excel spreadsheet, where the total of the foreseeable effort is priced, includes the following categories of items:
- Requirements analysis
- Stabilization and Delivery
- Management and Communication
These further break up into subcategories of features and services descriptions.
- Requirements analysis comprises the effort of creating SRS, calculating the project’s cost and measuring other parameters. All the items are estimated in hours put in by professionals involved.
- Depending on a project, construction may include particulars of web/mobile/HTML development, estimated by corresponding experts in hourly rates.
- Stabilization and Delivery is a broad category that may cover a range of subcategories and activities, typically testing (creating manual/automated test cases), code stabilization (bug-fixing, refactoring), and deployment (to staging – UAT; to production). Measuring the scope of these activities may involve expert estimation. However, our practice has proven that an average effort of this category equals to about 30 – 40% of the construction cost. So we may just as well add this sum for stabilization.
- Management and Communication activities involve organizing dev meetings, creating status reports, change requests and other routine activities. These normally add another 30% to the project’s cost. Every single item of the Excel document is assigned to a person accountable; it’s also estimated, rated and priced. If the risks are high and change requests are undesirable, we include a contingency fund. Sometimes, the contract may stipulate that the contingency fund should be returned if not used.
With Agile projects we normally give a ballpark estimate, but not a detailed one. Why? Because Agile estimation is not about striving for precision and accuracy in measuring the unknown and then struggling to hit the targeted dates and sums. It’s is about efficiency, quality, and delivering business value early.
What’s the point of Agile estimating
At first glance, Agile software project estimation may seem redundant, since the cost variable is not frozen from the start. Indeed, compared to the traditional waterfall project valuation, agile estimates do not aim at calculating the ideal trajectory of hitting the cost/time target up front. However, they serve as a starting point – to discover best solutions and make adjustments on the go. The focus is not on how to deliver on time and budget, but how to use the finite resources efficiently to deliver value. Thus it’s enough to roughly understand a project’s size and the team’s velocity to make assumptions about the time and cost. As soon as the team reaches a reasonably consistent velocity (which usually happens after the first few sprints), we can conclude how much time the project will take. As Agile development follows a T&M model of collaboration, its timeline directly impacts the cost.
Want to learn more about our software project estimation techniques? Do not hesitate to ask us directly.