One of the most difficult challenges in software development is to come up with proper estimations related to a project.
In traditional Engineering, you are aware of the steps required to finish a road, building or a bridge. There the estimations should be more or less correct than what you would find in Software Development.
Software Development is not engineering in its truest sense because it is still a growing field and there is still not an established methodology to come up with Software Engineering Techniques. Also the client requirements keep changing at each cycle (or sprint or whatever you term it as) and makes the task even more difficult!
There are many standard ways in Waterfall, Agile or other models to do estimations that require involvement of a whole team (in most cases). However as a personal practice for getting better at doing rough estimations by looking at initial requirements, I followed certain techniques:
A decent starting point is to break down the tasks and requirements of the projects to the bare minimum which may enable you to calculate project deadlines and milestones more accurately.
But before that you need to come up with a proper initial spec.
After the spec preparation, if you are from a programming background (which I am), run the following steps.
i) First you can run a basic scan of the spec and break down the hours.
ii) Any tasks which appears to be greater than 5 to 8 hours. you have to break down
in sub-tasks.
iii)Then you have to judge the experience and skill of the assigned person, and then again re-evaluate the hours and go to step ii) again.
iv) Estimate risks and anticipate possible new requests which you did not plan for and go to step ii) again.
v) Now you add some buffer to the estimated hours and then recalculate the hours for the final time.
The testing and debugging hours must also fall under the sub-tasks and has to be carefully measured so that their hours are properly estimated.
And last but not least, if you are the project manager, then multiply the estimations provided the developer by a factor of 1.5 (better if your can multiply by 2 or even better 3) - and submit to the client.
Actual factors will depend on what part of the development is using reusable code, proven APIs and some of it depends on innovations you bring to the table. Developer efficiency is a crucial part in this. Also there is a factor of over-commitment which might get you into trouble in the later stages. Sometimes the developer assigned to the project can be too confident of his/her abilities and set unattainable goals or the team he/she leads.
All projects have their own uniqueness which factors into the estimation. It is not just the deliverable but also the client psych, concept, pocket and tolerance. We all want to come up with the best outcome using the optimum resources, time and adequate QA. But the reality is that there are bindings we need to contend with which all of you know by experience (or will found out soon).
There can be many modules which require proof of concepts that that has to be factored in. In such cases you can do SWAG (Scientific WILD ASS GUESSING) technique. But this is beyond the scope of this article.
All said and done, given the growing nature of the Software Industry, estimations of projects can still be considered more of an art work than science. In many cases there is no guarantee you would come with proper estimations and deadlines even after giving your best shot!
A bit of disclaimer here - the views presented by the author is solely based on his experience only and is not applicable for every situation.
Top comments (14)
"...multiply the estimations provided the developer by a factor of 1.5 (better if your can multiply by 2 or even better 3)". To summarize: The higher your estimate multiplication factor is, the better your estimates are.
Please do not add 'buffers' to your estimates, and especially do not multiply the estimates you are given "by a factor of 1.5 (better if your can multiply by 2 or even better 3)". If you are unsure of how long something will take, ask for help.
As a project manager, I don't expect developers to provide 100% accurate estimates, but it is my job, not yours, to evaluate the risk in those estimates. I'll typicaly ask for two numbers: first, a best-case estimate in which everything goes perfectly well (which will be the smaller of the two numbers), and an estimate of the time needed to guarantee that something will be done (the larger of the two). The probable duration is between these, and I'll use something like PERT to calculate the most likely number.
If you are padding your estimates, and I don't know about it, those padded hours are included in my own estimates, to which I'll be adding a 15 to 20% risk buffer (NOT 3x), especially if the tasks I've asked you to estimate are on the critical path for the project.
Let's say that you, the developer, thinks a module might take two weeks to complete, but you add a week as a buffer, for a total of three. Assume that I take that 120-hour estimate and don't reduce it. How long will it take for you to do the task when it comes time to do the actual work? 120 hours. That's what's in the project schedule. Multiply that by the number of developers on the team and the number of high-level task, and very quickly the estimate can grow much larger than it should be.
What's the harm, though? If ten developers pad their estimates by 80 hours each, I'll end up with an extra 800 hours. At an internal cost of $150/hour/dev, that's $120k extra in the budget (plus of course the extra time). If, toward the end of the project, I, as the project manager, realize that we're coming in significantly under budget and under schedule, I might proudly walk in to my VP's office and announce that we're coming in early and I've saved the company $150k. Everyone's happy, right?
Nope. I might get fired if I do that too often. Companies run projects in order to make money. Granted, there are some required things we have to do, but basically each project run is anticipated to contribute to the top line. The more projects I can run, the better my top line looks. Your bad estimating just tied up $150k that I could have used on another project...you've bascially screwed shareholders out of an increase in their investment, and, if things are tight, might have resulted in a down quarter.
It isn't the developer's job to fudge the estimates. Leave that to the project managers, who should at least have the experience to fudge them correctly.
Great reply. Agreed mostly, however when you are working with over-confident developers (specially good ones too early in their careers), sometimes things get out of hand. The developers should try to give proper estimates. I was kind of coming up from a project manager's point of view who already has a software development background. The multiplying by 2 is stretching the fact a little too much, but was more trying to make a point. If you really have a great team of experienced developers then ofcourse you don't add too much of a buffer. But thanks for the observations and comments - this way we all learn more.
Any padding, whether by project managers or developers, is a problem. where are you getting "15-20% but not 3x" from? All padding is arbitrary - and it's an arbitrary number multiplied by an estimate that is itself based mostly on ignorance.
You're multiplying two unknowns and making decisions and promises against the nonsensical result. The entire approach of time and cost estimates is wrong-headed.
I can't argue that the way we estimate software projects is a problem, but it's the way most non-trivial projects are managed. We normally don't call the extra time padding...really it is a buffer to protect what really IS important in most projects, which is the completion date. That date often is set by product or marketing management, and if it is missed, the result can be as bad as losing market share in a quickly moving market, or missing revenue trargets for a quarter or more.
Typically projects are broken down into work units and laid out as a connected acyclic graph that relfects their dependencies. Estimates are applied to each, both for an optomistic and a pessimistic schedule. The graph will usually have many paths that converge to a delivery in the future. One or more of those paths will be very tight schedule-wise...it has the least tolerance for late starts on tasks such that ANY late start will cause the delivery date to slip. This path through the project is called the 'critical path' and is closely managed since it directly affects the end date.
The critical path is determined by analyzing start and end estimates across the entire graph; we assign a value called 'slack' to each task that reflects how late that task can start before it causes the next task to slip. For example, if I have a task that takes five days, but the following task converges into a path that doesn't need to start for another ten days, I have five days of slack, meaning that I can delay the start of the earlier task by that much without delaying anything else. In some cases I can reassign the resources on the shorter task to another task that needs help.
Since the critical path so directly drives the delivery date, and the delivery date i often a hard stop, when planning a project we'll add a risk buffer to the critical path (and thus the entire project). The critical path has little or no slack, and so that extra time tends to be arbitrary. It's like an insurance policy...I'm happy to pay $1,500 to protect against missing a delivery date that might cost me $10,000.
A method that isn't quite so arbitrary is called Critical Chain, in which slack times across each unique path are gathered into mini-buffers at the end of each of these feeder paths, then rolle into a buffer that sits prior to the delivery date. Managing a Critical Chain project is a little easier than a Critical Path project since we can examine the size and burn rate of the buffer at the end to get a sense of how the project is going overall.
Both methods still require estimates for early and late starts. The project team, and especially the project manager, need to provide reasonable estimates and be able to recognize estimates that are outliers.
This description of project management graphs doesn't begin to address the fact that estimates of non-trivial, unique software-creating tasks are a total wild guess when given at the start of a project. The only way to provide anything close to a reasonable estimate is by knowing as much as possible about everything involved (and even then it could be way off) and that state of knowledge is never present at the outset. You never know less than you do on Day 1 - therefore your estimates only ever improve as you go on in a software project.
This is the core principle of Agile and the reason why big up front designs and their resulting estimates are disasters. How many software projects need to suffer the same fate before everyone is finally willing to admit this?
You very succinctly identified (and ignored) the crux of the problem:
How can a date be set by a team that has no knowledge of the process involved in completing the tasks that must be completed by that date? If I give a contractor a completion date of
2 weeksto build my house, I'm the one to blame when the contractor misses the ill-informed deadline.PS this isn't even taking into account user/product owner feedback, which can (and should) entirely re-steer a given project, making all initial estimates less than worthless and indeed harmful.
I'm guessing you haven't worked on any non-agile projects in your career. I like agile methodologies -- I'm a fan of the Rational Unified Process in particular -- and there is certainly a large class of projects where agile makes a lot of sense. A web site? Sure. A back-end equities trading platform? Not so much.
That said, most of my development and consulting career was spent in Fortune 500 companies (primarily financial services, some healthcare) where projects spanned 12 to 24 months, and exactly zero of the projects I was involved in for those clients used agile methodologies.
Day 1 estimates are not wild guesses, as you put it. They are informed by experience (of both the group and the developers), vetted by management, and in my experience are typically quite close to the actual effort. A large project usually starts with a lengthy requirements gathering stage, during which the architecture and functionality of the system are agreed on by both the business and the technology team.
Project planning at this scale is necessary to coordinate resources, equipment, schedules, marketing, QA/testing, purchasing, deployment, and so many other things. Individual contributors (especially devs) are expected to be capable of providing reasonable estimates; if they can't, they won't be working for long. I've pulled developers from projects and sent thm back to the bench for training when they've shown that they haven't learned how to do estimation yet.
And to that point, you can't just plop a new dev into a project and expect them to be able to provide proper estimates; it's a skill, just like coding, and it takes time and experience to get good at it.
To your last point on feedback from product management changing the project, that's not how it happens at this level. Once the project plan and requirements docs are signed off, there are no further ad-hoc changes. If the product team wants to make a change, the request goes through an approval process (I've often seen them denied) that might require new estimates and a new schedule that must also be signed off on by all parties if the change is significant.
I'm absolutely not saying that agile doesn't have its place, and in fact many of the larger projects I've worked on probably could have been done more quickly if parts of them were done that way. I am saying that not all projects are appropriate for agile and require significant planning and management effort. As a developer I think it's a mistake to brush off non-agile methodologies as too hard to estimate, or having too much overhead, or taking too long. Doing so is to shut off a large, lucrative chunk of software development opportunities.
BTW props for moving to the countryside, I'm not that far away and spend quite a bit of time in the summers down in LC and Westport. Beautiful place to live.
Sort of yes, sort of no. I've worked on clusterf*** projects that had no methodology/approach/management, and I've worked on projects that tried to be agile. The latter were always a bit smoother, but still suffered from lots of over-estimation and over-promising. The former were mostly some version of poorly-implemented Waterfall where the final result looked nothing like the initial plans.
True that I only have experience with web sites, web applications, simple command line apps, etc.
I guess if the problems being approached mostly take the shape of other previously-approached problems then this is can be reliable (given an experienced team. I've also not had the joy of working on a very experienced team.) But what about for entirely novel problems, especially ones that are subject to great change once some initial assumptions start being tested in the hands of users?
This is an understandable problem. One that I don't have a solution for (
This is an important point. But I find it suspicious that it can't be learned or studied other than gathering experience and learning from the experience of others. If tasks are so well-defined as to be accurately estimated by developers (and get the same estimate from disparate devs), then why can't the underlying principles guiding those estimates be extracted and taught from first principles - or even used to train managers and take the responsibility of estimating away from the devs?
Again, it brings me back to: if the tasks are so normalized and akin to other tasks in history, then why would estimates be needed in the first place? If you must estimate, it seems like that is because there is an element of
the unknownorthe uniqueinvolved, and those are - by definition - wildcard, variable-by-orders-of-magnitude factors to be adding into your clean math of dates and times.Yep, it's either this very slow, cumbersome, expensive process you're describing - or do away with the estimates and approval teams altogether and embrace change. The time and money spent on this insane funnel would be better spent on some variance in time/cost, don't you think?
The obvious caveat here being that large corporations, governments, etc. won't be ok with that. But does that justify it? Haven't there been many instances of large organizations setting up little agile bubbles within their walls exactly in order to escape the process you're describing?
I'm taking your word for it that you're correct. But I've never seen that side of it and it seems incomprehensible to me. I've also read articles and books from folks who claim that agile methodologies as well as #noEstimates approaches can work in those situations... Since my bias is clearly in that direction those claims seem viable to me...
IT'S HEAVEN! :D I'm happy to hear that a previously-anonymous avatar on the internet appreciates the beauty of this area. cheers!
Most projects, especially in large companies, really aren't all that innovative and are often just an extension of what's already there. In those cases you can use metrics to crunch most of the numbers to provide a fair estimate. Moderately complex database tables are 30 hours, DB triggers are 10 hours each, integrating a new data feed is 80, and so on. Once you have a large enough set of requirements you can just extract the pieces and do the math.
On the business side it gets even more interesting. We do projects to make money (why else do them?) and so companies want to run as many projects as possible to maximize profit. In a given year there might be 100 potential projects, but resources to run only a few...which ones? We use high-level estimates and ROI analysis to prioritize the projects. One company I worked with required a 10x ROI to fund a project.
Those high-level estimates also give an indication of how many resources you need. If it's 10,000 hours of work and I have six months, I'm gonna need ten devs minimum (roughly 2,000 man-hours in a year so 1,000 hours in six months). If I'm billing devs internally at $200/hour, I get a rough budget, too, in this case $2m. I know that the up-front phases (requirements and design) are typically 10% of the project, and QA another 20%, plus 10% contingency, and so I have a rough budget of $2.8m. That's enough to let me compare projects and prioritize them, and if a project gets green-lighted I can refine the estimates during the discovery phase.
The flip side is that if you grossly overestimate, all hell can break loose. If I'm managing that $2.8m project and get it done early and under budget, that is not necessarily good news! Let's say I brought the project in at $1.75m. Great! I just saved the company $1m! Unfortunately C-level management (CTO, CEO, etc) sees that as $1m tied up that couldv'e been used to fund other projects (and recall that more projects means more profit). Hence, a $2.8m project miraculously always comes in at $2.8m (unless there are issues that drive the number up, which is another story).
A truly unique endeavor would probably be funded out of an R&D budget rather than operations or product, treated as high-risk, and would be estimated / managed differently.
BTW that's just for internal projects. If it's being done by some other firm (consultancy, vendor, etc) there are additional costs, and the type of contract (fixed cost vs time-and-material or cost-plus, for example) will drastically change the quoted price. If I'm in a T&M situation there will be a cap on spend and schedule, beyond which requires C-level signoff, and if it's fixed-cost I'm going to add ANOTHER 10% to cover my risk (the risk is that it'll take longer, which means more spend on my part, even though I'm getting a fixed price). I love fixed-cost since there's an opportunity to work hard, finish early, and keep the extra dollars.
Next time you'r grabbing some ice cream at Gray's, keep going down main road about a mile, and on the left you'll see the old Friend's Meeting House. Across the road from it is the John Irish house, which my ancestor Jonathan attempted to burn down in the late 1600s. John Irish is buried on the property...I stopped at the grave once to apologize for Jonathan.
For small shops, startups, and the like there aren't a lot of competing projects (often just one), and so the budget is the internal cost of dev times however long it takes. There isn't a lot of overhead and requirements can be revised as you dev and learn.
Interesting article! This is a topic I really like.
I recently implemented this open source web application that is Jira Project Estimator: github.com/sebaherrera07/jira-proj...
It allows people to get estimates for project finish dates, not before the project started, but once the team is making progress based on their velocity and the remaining tickets story points.
I would like to share it with anyone who might be interested in it and also thank for any feedback!
After more than a decade of experience, I'm still bad at estimating. This post matches my best understanding of how they should be done though. The goal is small chunks, each of which is well-understood enough to give someone instructions on without them having to improvise.
Another thing is to let the stakeholders know as soon as possible if part of the schedule is slipping.
One problem I've had though, is that sometimes the tasks I've broken something down into turn out to not be the right direction to slice things. So I've got tasks A, B, and C, but a week later I've got half of A, 75% of B, and a quarter of C done.
It is nearly impossible to get everything right in the initial stages of a project and the situation that you mention is not unusual. However this is the reason we now have iterative software development process (agile) in place with small sprints. With shorter sprints, with time as you get more aware of the requirements of the project your estimations get better.
I like the idea of agile, but when done in a formalized way it seems to do more harm than good. I've done scrum in a few places, but never enjoyed it or found it to be very helpful. It seems to be designed to keep people from getting a chance to catch their breath or get into their work. I suppose there may be some types of project where it works well, or some people who are good at it.
Basecamp has recently posted some videos about their process with six week iterations, which looks interesting.
While I kinda agree on this method, there is one particular point worth emphasizing on: once your tasks are laid out, you need to ask two questions.
Just sit there and challenge everything again and again. Don't let anything in oversight. And certainly do not focus on the main features since there is an increasing number of pain in the ass coming to get you (GDPR to pick a recent one, but also password reset, email validation, user preferences, email unsubscription, ...).
Regarding the things you have never done, you need to do preliminary PoCs to estimate how long it's going to take. If you can't sell this, then put those tasks ahead in your planning (the riskier the task the first it should be done) and be ready to re-adjust scope or deadline.