As practice shows, many software developers can't estimate software development projects adequately, which usually results in blown-up buffers, overheads related to missed deadlines and other issues that may have a detrimental effect on the overall project success and client's budget.
If you ask any average PM or software engineer about what client's question is most annoying to them, the vast majority will definitely answer with "When will the project be completed?" So, what's the matter with realistic project estimation? Why does project estimation process top the list of developers' most hated challenges? The answer is really simple: it's unclarity and uncertainty that surround the process!
On the one hand, there's a formula saying that project duration = scope/efficiency. On the other hand, we don't know either a numerator, or a denominator in this formula. Why? There're several reasons:
Anyway, when evaluating project scope and resources, we need to make a lot of predictions and bear responsibility for our forecasts. We need prediction as a way to get detached from unclarity and better manage reality.
All known math models that aim to answer the question "When?" (i.e. Gaussian curve, Poisson Distribution and Murphy's Law) are based on simplistic methods that are almost impossible to use in real-life practice. What we need to do is to build an adequate and realistic model of handling unclarity and uncertainly. This model will allow us to create an assessment algorithm, know its limitations and constraints and learn how to use this model for proper project estimation.
If your development team possesses the following features, you'll most likely be able to predict to the project scope and timing with minimal deviations:
How likely are you to have such a team? Well, the chance is slim unless you have a legacy software and a team of developers who're about to retire and, thus, don't want to pursue better projects and IT career opportunities. The reality is such that development teams are becoming younger and more dynamic, and it's getting more and more difficult to retain them on the project if they don't find it cool and challenging enough. Most of today's teams are interrupt and change driven and, thus, don't match the above team profile. Therefore, we need to build a realistic and adequate project estimation model to convince the client they've chosen the right software development provider / project team.
A realistic estimation model is one that provides estimation precision acceptable for practical implementation. While math concepts don't seem to work well in this domain, we still have to learn how to provide estimates that are at least 80% to 90% realistic and how to handle and minimize all possible risks so that the client doesn't pay through the nose at the end of the day.
First off, each client purchasing custom software development from 3rd party provider must understand that project estimation is impossible without time buffers, i.e. safety margins in the project schedule, and safety margins do not equal cheating the client. That's the reality! If your client is too opinionated and doesn't want to see any buffers in the spec, just remove the lower limit! Yet, making buffers requires their thorough management and control. If 1/3 of your buffer time is wasted while the project is still far from its completion phase, it's high time for expediting and pushing! To visualize time-spending, web developers normally use burn-down charts. If your processes are in place, expediting and pushing will account for only 5% of the work scope or less. If they account for more than 5%, you're in big bad trouble!
In complex software projects the key focus should be on finding bottlenecks and controlling buffers that "feed" them.
The principles of realistic project estimations
There're only two ways of a realistic project estimation:
In practice, only typical and repetitive operations can be estimated based on past experience and historical data. While still existent, these operations will soon be automated and managed by robots.
Using past experience and historical data can have some shortcomings that affect precision of estimate:
It's critical for any good PM to not only discuss project schedules with the customer, but also discuss methods and ways of reaching project goals, otherwise there'll be surprises down the road. Everything that's rational to automate and standardize should be automated and standardized indeed! Tasks that imply experimentation with new technologies or development methodologies should be scoped separately as experimental tasks (with separate time and budget buffers).
As we can see, experience alone may not suffice for effective and realistic project estimation, but expert assessment and intuition can come in handy.
The more we imagine how the project will run, the more precise our predictions will be. Key here is not try to deceive yourself! If you can foresee any technological clashes or discrepancies down the imaginary project road, you'll definitely bump into them down the real project road.
Any project task estimation process should be split into four stages:
Further task changes are only possible as a force majeur case and all milestones should be coordinated with the client.
Relative estimating is less problematic than absolute estimating. How large is Jupiter? We can't describe it manually, nor can we easily remember its dimensions we learned at school. But if we're asked "How large is Jupiter compared to Earth?", we can always find good analogies: Earth is just like a pea, while Jupiter is like a watermelon; Earth wears size S and Jupiter - XXL.
Our brain perceives relative values much better than the absolute ones, so use this principle in your project estimate. Divide each big task into a dozen of smaller ones and estimate each separately. Do compare sub-tasks: which one wears S and which one - XXL? Use your imagination to better understand the approximate scope of all project tasks and exercise often to boost this skill.
Although each customer in IT is definitely looking to get a ballpark figure along with the project estimate, it's still possible to estimate some tasks in relative terms. For instance, new tasks can be estimated in relation to one simple and well-known solution, which also allows to compensate for natural deviations in estimates and definition of problems.
If none of the above works for you, start playing Planning Poker, a gamified consensus-based technique for estimating efforts or size of project goals in software development. Team members make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. In this case numbers equal hours: 1/2, 1, 2, 3, 10, etc. The cards are revealed, and the estimates are then discussed. If numbers played are the same or close, determine its simple average and put it in your project plan. If the difference is significant, ask respective team members why they've provided such an estimate. As you get more details and insights into your developers' mindshare, you'll learn how to estimate more realistically.
If you still can't estimate adequately using Planning Poker (because of lack of experience), add a research stage where developers execute a particular function element, estimate work complexity and scope, and improve understanding of how many hours will be needed to get the job done.
Decomposition is a method of splitting a huge abstract task into several small yet clear sub-tasks that are easier to estimate. Break your project scope down into separate components to make your developers better understand the requirement. Software developers should be skilled in splitting a holistic project or technical specification into phases and estimating them separately. The more they exercise this method, the more realistic and adequate estimates with fewer safety margins they'll deliver to the client.
To nurture this skill in developers, we recommend that PMs / team leads do the following:
If you train your Agile team in adequate project estimation on a daily basis, you can nurture this skill within just 2 or 3 weeks. And what's your take on this?
Intersog, a leading technology partner, gains recognition on Clutch's prestigious list for game-changing software developers…
In the shift towards widespread remote work, the adoption of advanced digital tools marks a…
In the quest for innovation, the fusion of AI and Machine Learning with global remote…
In an era marked by rapid technological progress, the fusion of cloud computing and artificial…
Explore Intersog's unique approach to tech recruitment, offering a transparent, direct path to genuine career…
Explore the critical role and innovative strategies of efficient software maintenance for ensuring software stability,…
This website uses cookies.