When sponsors or clients ask you to estimate a project, they, in fact, want to know how much money the project will cost and how long it will take. Why do they need this information? Well, the answer is that business as a whole tries to make a decision about how to spend money effectively. Businesses need certainty about what they will get and when. Unfortunately, the certainty is a very rare thing, when it comes to software development and design. So, what are we going to tell our stakeholders when they ask how long the project will take and how much it will cost? In this case some project estimation techniques will come to our rescue.
First, we should understand that if we want to provide a realistic project estimate to our client, we need to have some pre-conditions.
The first pre-condition is a detailed project specification, or functional and non-functional requirements. For the projects that imply some user interface it is desirable to have a wireframe – a drawn project prototype. Unfortunately, it’s often quite difficult to convince the client to spend money on UX designer even before the project is signed off. But if you have managed to do this, the chance of your project success will significantly increase.
The next pre-condition is a seasoned team of professionals. You need to have a team of good specialists in the technologies you`re going to use on the project and, preferably, in the project`s business domain. If you don’t have such people in your team or your team even is not formed yet, try to involve some side experts on a temporary basis, just for the estimation activity. But better never start estimation with the people who know nothing about the technical stack of the project.
Well, let’s assume that you already have more or less detailed project requirements and a team of people who are capable to estimate the project. Now and then you`re ready to start with applying some project estimation techniques.
The first thing that I recommend to do, is to get the team together in a workshop and, based on the project specification, make a list of all the activities that they have to perform during the project. After that ask them as a group to figure out what the most pessimistic and the most optimistic estimates for achieving any particular task are (this is called PERT or three-point estimation technique). For a long-term projects with a high-level project specification we usually estimate task duration in a number of days needed to complete a particular task.
You should explain the team that while giving the optimistic estimate they should assume that everything will go absolutely smoothly, that there will be no surprises, no external impacts, etc. But don`t forget to ask about all the things and the dependencies required to achieve that optimistic estimate, and then take a note of them.
Accordingly, while the team is giving the pessimistic estimate they should assume that everything will go wrong and all the foreseen risks will get materialised. Here you definitely have to take a note of all the foreseen risks that the team see for the moment. After you list out these risks, you should add them to Risk Register and make sure that you have mitigation strategies for all these items.
Once you have the optimistic and the pessimistic effort estimates, ask the team what their best guess is for the most likely time needed to complete any particular task. When you get this most likely estimate, you may start working on calculating the expected time for the whole project duration.
But there is a couple of things that you have to get from your team, before you start these calculations. Show them the list of the tasks you`ve just elaborated, and ask them to define dependencies between the tasks (the consequence of the tasks), possibilities to do some tasks in parallel and possibilities to swarm on the tasks (when several people are working on the same task simultaneously). After you got and noted this info, you may eventually start creating your project plan.
If you have never practiced PERT estimation technique before, you might think that the most easy and correct way to calculate the expected project duration time is to take an average of the three estimates mentioned above. But, in fact, it’s not correct. I don’t want to go into the details but just say that in order to calculate the expected tasks durations more precisely, you need to use the beta statistical distribution formula. This basically means that you should get a weighted average to calculate the expected time required for any task completion. The formula for this is the following:
To calculate this quickly for each task you may use a spreadsheet like Excel.
After you calculated the expected time for each activity, you can go on and calculate the duration of the whole project, using a technique of a critical path – the longest time it takes you to get from the starting point to the end point according to your activities dependencies. For this purpose you may use Microsoft Project software or something similar to it, for example, Project Libre or Gantter.
What you have to do is to create a new project in Microsoft Project (or similar program) with the start date you expect. Then just list all your tasks sequentially, put dependencies, assign resources, but don`t put estimates for each task yet. Let me explain why.
The matter is that the estimates you have got from the team are not quite correct. They`re incorrect not because of unavoidable inaccuracy, but because your team didn’t take into account something important when estimating tasks.
You should consider that working on a project as a team requires a lot of communication and collaboration, which is realized mostly through the meetings. These meetings and other activities which facilitate team collaboration are called focus factor index and should be taken into account while estimating activities` durations.
The focus factor index shows how much of declared task completion time will be spent directly for task implementation. Traditionally, it is accepted that the focus factor index for a new team is 50% – 70%. It means that if the team estimates the task in one day, they make an assumption that they will work on this task 8 working hours without any distractions. But, in fact, only half of the estimated time in case of a large team and 70% of the time in case of a smaller team will be dedicated to the task itself. The rest of the estimated time will be spent on some clarifications, communication and meetings. This is definitely an approximate index which may vary from day to day, but you should take it into account in your estimates if you don’t want to fuck up the project. Frankly speaking, I personally find these index figures a bit overstated, but, as experience shows, it is better to go higher with them because in case of some unforeseen risks this extra buffer will come to your rescue.
The next thing you should do is to recalculate all the expected estimates for each task got after the first session of calculations, taking into account your team`s focus factor index. The formula is the following:
After you get adjusted estimates, you may put them into your project plan and get an expected project time completion.
But wait, it’s still not the end 🙂 What about holidays, vacations and sick leaves? Have you taken them into account in your timeline? It is something you must not miss in your project plan.
From my experience I just add 10% of the project duration to the project timeline for all types of leaves (and I bet that 10% is approximately what you will get if you decide to do all necessary calculations with the calendar and the vacation plan).
The finish date that you will get from MS Project program after all the changes may be considered as an approximate delivery date for your project. Add to this, for software development projects, where the main costs are the human resources, the project time estimation is the main basis for the project cost calculation, because all you need in order to get the budget is to apply people’s rates to the project tasks duration (click on the image below to see a sample of a IT projet plan in Gantter below).
Before presenting the project estimate to your sponsor it is also recommended to ask some expert to validate your estimates and the project plan. If you have a person who has enough experience in your field in order to perform this validation, you`re a lucky one.
Well, now I think you`re ready to estimate your projects and present the results to the stakeholders. Go and get their approval!
P.S. If you’d like to share some estimation techniques that you use in your work, please, welcome to the comments.