Most people think of estimation as the worst part of project management. The reasons for this are both obvious and understandable. Project estimation involves so many variables, nearly all of which can and do change as the project develops.
The slightest unforeseen problem or change could result in severe delays and cost overruns that can doom entire projects. And this is not a problem that only affects those people new to software development, even the most experienced developers never get it totally right. So why do project managers still insist on these estimations and what can we do about getting them right?
In this article, I aim to give a general overview of project estimation, including the best software project cost estimation methods, how to deal with errors or unforeseen problems, some fail-safes to build into your estimation to allow for errors, as well several other key factors, which if implemented, will ensure you end up with the best possible project estimation.
What is project estimation?
“The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic to allow the project to be controlled to meet them”- Steve McConnell (Leading author on software engineering).
Do we overvalue the importance of project estimation?
The simple answer to this question is a resounding no. Project estimation is one of the most important aspects of the project. Without it, developers and companies would effectively be going in blind, with very little in the way of expectations, timelines, costing or goals to guide them.
Main reasons why we need to estimate projects:
- To understand what the project is
- To build a clear understanding of the project requirements
- Establish timeframes to completion
- Effectively budget the project
- Allow clients to give developers clear targets
- Allow developers to give clients clear expectations
- Ensure staffing is adequate and that staff are all working on the same page
- To ensure all the necessary resources are on hand to complete the project
- Risk assessments and to help to plan for problems
- Sets up realistic expectations with management/client
The real question is not whether we overvalue the importance of project estimation, but rather is why can’t project estimations be more accurate? Projects that are seen to run grossly over budget effect both outside perceptions relating to the professionalism of a company or organization, while also causing budgetary problems that in the past have actually destroyed companies.
The list of projects that have ended up killing their parent company, or at least putting them heavily into debt, is endless. Since companies are more accountable for their failures which can result in them going out of business, being taken over, or at least operating at a loss, we tend to focus our frustrations on government projects that vastly overrun their budgets, particularly as they are wasting enormous sums of tax payers’ money rather than their own. One only needs to think of the new F35 project, where according to Time Magazine, total costs are now estimated as being “$395.7 billion, an increase of $117.2 billion (42 percent) from the prior 2007 baseline”. To put this underestimation in perspective, $400 is around 3% of the U.S’s GDP, which works out to about $1150 per person in the country. Feel slightly annoyed? I do!
How to create an accurate project estimation:
1. Use a basic project planning template to outline a description of your project
Someone once said to me “an idea is worth nothing, it’s making it happen that turns it into gold”. It might seem strange to have to sit down to write out a detailed description of what your project is and how it will work, but this is the first important step in ensuring the project’s success.
I can’t tell you how many times I’ve been involved in a new project when I’ve asked a simple question like, “what is your target demographic?”, for example, only to receive a baffled look from the client. The answer to this question will affect everything from the interface design to marketing strategy, so needs to be considered when writing the project description. This basic plan should allow you to visualize the software in three-dimensions, including the types of people using it, potential revenue streams, staffing, etc.
If you are still unsure and need a good project planning template then you can contact our support team to request one free of charge!
2. Evaluate your team’s expertise
This is one of the most overlooked aspects of project planning. If your team doesn’t have sufficient experience/expertise, or is understaffed, for example, then your project is almost certainly going to run into problems that will lead to overruns etc. Your team should include developers who have enough experience that they are able to look at your project’s features and be able to accurately evaluate time-frames, costs and potential problems etc. Experienced developers will have the added bonus of being able to refer to past projects where they have developed similar features, therefore making their estimates more accurate. If you don’t have the experienced in-house staff your project requires then you should employ the help of an outside developer.
3.Communication is the key to the entire project’s success
Project estimation is a collaborative effort. When estimating a project, it really pays to involve each member of the team (where their skills might be relevant). This includes asking for the same information from several different team members at once. Not only will this ensure the accuracy of the information but it will also initiate a healthy communication process within the team too.
As part of DevTeamSpace’s refined project development methodology, we employ numerous tools to encourage a good level of communication between team members. We use dashboards, open project conversations through Slack, and hold regular standup calls to update and involve team members more thoroughly.
Remember that full team collaboration is essential to avoid those ‘I thought you were doing that’ moments that cause project delays. Finally, no team member should ever be made to feel afraid of coming forward with a query or problem. Problem reporting is one of the key aspects of damage control and should be dealt with quickly and efficiently.
4. Employ a Work Breakdown Structure (WBS)
The easiest way to estimate time-frames, man-hours, and costing etc. is to break the project into smaller pieces, otherwise known as a work breakdown structure. So let’s say your project has a complex interface, a payment system, and a member’s section, then these can be estimated separately to make the task more manageable. You will need to take into account how your project fits together, however, as these functions will inevitably overlap in some way.
During this process, you should clearly define what hardware, software, human resources, and money needs to be allocated to each stage. The work breakdown structure approach allows for far more detail to be developed from the initial plan by facilitating a question/answer cycle that gives a far more in-depth understanding of the project. For more information on different approaches to product estimation, you can read this article.
5. Build in room for adjustments/overruns
When estimating your project it pays to build in safety margins for unforeseen problems. Understandably, most developers want to give a low cost/time estimate (particularity if they are an outside company trying to win the contract), but this is wrong.
Personally, I build in a 10% to 20% safety margin for both cost and the timeframe for completion. This allows for problems to be easily dealt with within the agreed timeframe and budget, and in most cases, saves those awkward moments when you must ask your managers/client for more time and money.
6. Use clear tables/flow diagrams/illustrations when finalizing your project estimate
The final version of your project estimate should be clear and easy to understand. Again, this seems obvious but you would be amazed how many poorly presented estimates I’ve seen in my time. Visual aids are key to any presentation and project estimates are no different.
Cost breakdowns should be presented in a way similar as the following example document (with obvious adjustments to suit your project specifics):
IT project cost estimation template sample
The final stage of the (non-revised) project estimate is to present it to the management/client in a clear understandable manner that sets up realistic expectations. Management should be guided through each step of the development so that they have a good understanding of the whole process. A few things are vital when presenting the estimate; firstly they should be made aware that this is only a provisional estimate as the project is likely to evolve as it goes on. Secondly, they should be made aware that the costing/timeline to completion includes a 10-20% overhead to factor in potential overruns.
It is during this time that you should agree with them a set of procedures in the case that circumstances should change. Key questions such as “how much do they want to know about project revisions?”, “when do they want to know it?”, and “how involved in the decision-making process do they want to be?” etc. should all be answered before the project begins.
Key project estimation techniques points to remember:
- No estimation is set in stone, things can and will change
- Be flexible
- Use a suitable project planning template that includes a clear description, project objectives, screens and features list, etc.
- Break project down into sizable sprints/stages
- Allow for testing time with suitable resources after every sprint
- Ensure all steps/processes are discussed and agreed with client
- Overestimate the project’s budget by roughly 10 – 20% (depending on complexity) and tell client the reasons you have done so
- Don’t fall into the trap of thinking that an overestimation will make you look incompetent
- Ensure good communication with client regarding the project’s progress
- Always get second opinions including getting an independent party to review your estimate
- After commencing the project, remember to refine estimates as soon as new information is available
The way that all professionals go about producing a project estimation should be fundamentally the same. While it is certainly the case that developers who have lots of experience will be able to produce one in a much quicker time, without compromising accuracy, the key is not to overlook the importance of a good project estimation.
I deliberately didn’t cover some aspects of the theory regarding project estimation, simply because it is available from so many other sources. As always, Wikipedia is a great place to start, including this good summary on Software Development Effort Estimation. Two further pieces that get to the guts of good project estimation are The Dark Art of Project Estimation and Software Project Estimation by Kathleen Peters.