I know, saying “Yes it will take 3 days” or saying “Yes, we understand what you need” is not something you can do.
It seems impossible and it is, to some extent.
You see, trying to manage a project without a robust project estimation plan is not possible at all.
By default, there is a magical view and prediction of how processes will go forward. One after one another with complete client satisfaction, the project delivered on time.
To even remotely get close to this, it requires lots and lots of preemptive planning.
I want to introduce you to some of the mistakes that we’ve seen in projects worth 2k to projects worth 2.5million. Notice that a bigger budget does not always equal a better-managed project.
Knowing these mistakes and how to fix them will result in:
- happy internal teams
- happy clients
- happy end-users
Don’t we all want that?
Mistake #1: Believing that your project estimation will always be right.
You’re thinking then what is the point of me reading this if it’s going to be always wrong? Well, sadly I’m not Nostradamus and this isn’t the Les Prophéties — nobody can predict the future. Estimations can be, will be and are wrong across many projects in many sectors. It’s just bad luck that this problem is more widespread within the software industry.
The question is why? The answer is invisible factors.
The software industry has a ton of visible, and invisible factors behind the scenes. Stakeholders can make decisions that are out of your control. Sudden budget changes can surprise you & random company hierarchical changes can also happen. Or, Bob the client can decide to take a well-deserved break to the Maldives.
One thing is clear – our industry seems to be able to expect 0 repercussions from anything that can happen.
So don’t be optimistic because you’ll play down the project duration and not deliver on your promises. And nobody likes someone that doesn’t stay on their word so you’ll lose out on business.
Being pessimistic doesn’t help either. Adding in a massive safety net will only make you lose out on high reward projects with tight deadlines.
Be realistic. Not only should you be realistic but it is also your job to ensure that expectations are set forth clearly. That the client is aware of possible pitfalls and how you are planning to mitigate them if they happen. Again, nobody can predict the future but you sure can expect it.
Mistake #2: Assuming that 1 person can do project estimation.
You need a team.
Accurate estimations for how long tasks are going to take will only come from the person going to be doing it. Duh, it only seems to reasonable to ask the person doing it, how long it’s going to take them to do it.
In other words, the best person to give you estimations is a person with either:
- full subject knowledge on how to perform the task at hand
- previous experience completing work like it.
This also means that if any of the 2 points above don’t apply to the person, the person should not have this task assigned.
Someone else needs to undertake this task.
A “project estimator” will not be effective in the long run as they will gradually lose their ability. Why? Because they will become more & more separated from the work process. After all, they are not the one coding/designing/developing.
Who has to do project estimation then?
Everyone. Designers, developers and testers. They all have to produce their own estimates and feed them back to their leads for them to be aggregated. The leads then should take this information and feed it back to the project manager.
The project manager must guide the project in the right direction by:
- Ensuring current estimates are delivered on
- Documenting and maintaining a list of previous and current estimates for projects
They should do this for two reasons:
- Confirm that work is being done
- Make sure that future work estimates are reasonable and justified
Documentation is key, as a project tallies invaluable experience for every member. Make sure you store this information for project retrospectives right at the end.
Mistake #3: Imagining the project’s entire size, all at the beginning.
In the early starting stages of the project, you’ll quickly realise that aspects will be unclear. This is a fact.
A few examples:
- The goal of the project
- 3rd party platforms to be used & how they will be used
- Frameworks to use
- Programming language(s) to be used
- Test coverage
- NFR and FR (non-functional & functional requirements)
It is also a fact that some will be clear. As the project matures, this some will turn into most and then eventually into all.
For the best chance at quickly turning that some into all, choose 1 of the 6 methods below for estimating a project.
Warning: we recommend method 1 to 4 — please only try method 5 & 6 at home.
- The bottom-up approach: Use decomposition to break work down into smaller, separate components. Estimate relative numbers for each part and then combine them.
- Subject matter experts: Use experts to provide time, resources and cost estimates.
- Mathematical modelling: Take advantage of mathematical algorithms. These calculate the time or cost of a project based on many quantifiable factors. Blah blah blah for me but if you like numbers, search up the COCOMO model (Constructive Cost Model).
- Comparison: Compare the project to previous similar projects.
- Common sense estimation: How familiar are team members with the industry? What is their length of “service” in the project? What is the level of their skills and knowledge? Complexity & size of the task are also a few factors that come under this bracket. These are then used with common sense to produce estimates.
- Relative estimation: Task A is hard with an index of 1, task B’s index is 2 as it is 2x harder. So, task B will take 2 times longer than task A
Mistake #4: No risk margins for any approximations.
Why do most people not assign estimates a risk margin? It might be common sense for you and me but loads of people don’t factor in the probability of something going wrong.
In every single project, the below tasks should be done and repeated in a logical order:
- A list of tasks made to be estimated
- Estimates for each of the tasks from the compiled list
- Compilation of all these estimates
- Decisions made on risk margins
Identifying and defining what must undergo the estimation process is a crucial step.
Sometimes, estimates are incorrect.
But in most cases, estimates for obvious yet unidentified risks haven’t even been done.
Mistake #5: Estimating without not knowing what to estimate.
Many perspectives are commonly missed out on, due to not having a full view of the project.
This incomplete view of the project comes from issues in requirement analysis.
Do you always have estimations for the below processes?
- Project management
- Technical management
- Obtaining required account credentials
- Hiring contractors if needed
- Getting required licenses e.g. UK Remote Gambling software licences for gambling applications
- Support activities during/after the project delivery
Mistake #6: No decomposition for any tasks
The more details you need to estimate in one go, the later you get to a specific estimate.
Break, break, break down items to be estimated.
They should not be small enough to increase the estimation time. But they also should not be large enough to reduce the estimation accuracy.
Mistake #7: Not making a note of assumptions you’ve made
Write down your assumptions.
By writing down your assumptions, you can get a feel for what is concrete right now and what is not. Regardless of whether they are general or specific assumptions, write them down.
Examples include project requirements staying constant, or browser compatibility.
Mistake #8: Following x number of steps will result in perfect project estimation
Unfortunately, there is no magical pixel dust to be able to sprinkle on a project, so it can tell you what you want to know.
If there was a perfect way, everyone would use it. Projects would be delivered on time and be within budget. Difficult conversations wouldn’t need to happen.
You need to realise that all the methods out there, from simple to complex, to mathematical to practical, to paid and free will only just help you be more confident with your estimations.
Project estimation is not an easy task and it all isn’t always sunshine and rainbows. We’ve outlined here 8 mistakes that we’ve seen happen most often across projects in any sector.
What other project estimation mistakes have you seen?
P.S. we pinched some stuff from the book IT Project Estimation: A Practical Guide to the Costing of Software — shhh.