Creating Upfront Estimates and Making Them Management-Proof
Note, September 2014:
This material is not about Agile estimating; however, it does present the “more agile” approach to making up-front estimates that are more meaningful. While I do prefer to measure the velocity of a concrete team and prioritize the backlog, I’m still often confronted with more traditional clients who want to know exactly how much money they’re going to spend on a project, or at least have a rough idea. It can still be done, and in this text, I’ll explain how.
Software developers are notorious for providing bad estimates, and no one looks forward to creating an estimate in the first place.
Inexperienced developers are often too optimistic, and as a result they either omit parts of the job from their estimate or think the estimate is complete when there’s still plenty of work to be done. With such an estimate, you’re in for a world of hurt. We all know of projects that were either canceled or still in the development stage long after the planned release date.
On the other hand, more experienced developers tend to pad the estimate just to be on the safe side, sometimes even doubling it in the process. But overpriced estimates could mean that you end up spending too much money or that you simply don’t get the job. Either way, senior management is none too pleased.
If such unreliable estimates were the rule, however, most software companies would have gone out of business a long time ago. So, what’s their secret?
If unreliable estimates were the rule, most software companies would have gone out of business a long time ago.
In the following pages, you’ll learn how to make reliable estimates with only a skeleton crew for support, how to complete the estimate within a short timeframe, and how to defend the final estimate before an audience of project managers and salespeople. In other words, you’ll learn what it takes to create successful estimates in real-life situations.
First part explains several important principles behind estimating software development projects. For many people, simply being aware of these principles will go a long way toward better estimates.
The second part presents the steps of making a complete estimate, regardless of using one of traditional approaches or working in completely Agile environment. It resembles developing an initial project plan, to some extent. However, many project planning techniques used are intentionally simplified, to give you an approximation that is quick yet “good-enough” for estimating purposes.
PART II: RELIABLY ESTIMATING SOFTWARE PROJECTS
– Risk-Free Estimates Are Usually Not Feasible
– What the Project is About
– How the Work Will Be Done
– Who Will Be Doing the Work
– Organize the Project Around Major Contributors
– Estimating the Bulk of the Effort
– Estimating the Remaining Work
– Putting It All Together
– Softening Project Risks
– Compiling the Final Estimate
– The Time and Cost of Estimate Itself
– Presenting Your Estimate
Described process heavily relies on common sense, instead of filling out templates and correlating numerous checklists and matrices. Thus, it have been successfully used for projects of almost any size. You can use this same process for tiny projects of 20 man-days, or for a big 10.000 man-days project. I’ve done both, and in my experience it’s quick and fun to do for small projects, while for big ones it is a life-saver.
PART I: IMPORTANT PRINCIPLES OF ESTIMATING
The What and the How
It doesn’t matter whether it’s a new feature of your product or whether it is the entire new project you are bidding for. To come up with an estimate, you need to know:
- What is to be done, and
- How it’s going to be done.
For a development task, it could be relatively simple. For example, ask a developer to send you a to-do list of how the task will be accomplished. From this one list alone, you can often see whether a developer has thought it through. You or your lead developer then look for inconsistencies and for things that are omitted. Any questions you might have, need to be answered first.
Note that the same effort would need to be done anyway, so there is no extra work here. You are just pointing out issues now instead of risking leaving them for later. Otherwise, it’s “garbage in, garbage out”. Don’t go there.
Ok, and what about estimating a whole project?
The principle is the same. You can’t estimate something if you don’t know what it is, and what you will do about it.
Imagine painting the walls in your dining room. How big is the area that needs to be painted? Does it need one or two coats of paint, and which kind? Would it be better to spray-paint it or to use a brush? All these questions need to be answered before any reasonable estimate is made. If something changes or more information become available, then you adjust accordingly, but you need that initial estimate.
You can’t estimate something if you don’t know what it is and how you will do it.
And it’s exactly the same with software projects, no reason to be any different. You need that initial plan and estimate, regardless whether you work in “traditional” environment or it’s completely Agile. Remember that the most successful improvisers in human history were at the same time extremely thorough planners. Rigid plans might not be worth much, but the planning itself is indispensable.
Fear of Estimating
Software projects are far more complex than painting the walls, so it takes both competence and a genuine effort to come up with a reasonable estimate. Both are often underrated by management, so many people simply avoid the risk to be held accountable, while performing the thankless job anyway.
Remember the time you simply couldn’t make a person “give you a number”? You might have reasoned, threatened, and begged, but it was like you were pulling teeth.
One way to get unstuck is to use three-point estimates. They are primarily a communication device. The idea is to ask for an exaggerated pessimistic scenario first, because a person will be the least afraid to give you such unreasonable estimate. Then you build up from there.
For example, you could ask “If everything goes wrong, and a meteor strikes, so we have to do this on a ZX Spectrum powered by a car battery. Would it be done by the next summer? Yes? Great, and what about this Summer?”
Usually you will get a smile and a number, with a short explanation. Now you can go for the numbers more meaningful for your purposes. Now ask “And if everything goes just right, with no setbacks and no distractions, and it’s really a walk in the park. Would it be done by lunch tomorrow?”
Note that you are the one giving qualifiers all the time, so a developer doesn’t need to. Also by offering ridiculous estimates, you are getting developers to debunk them and get their brains into “engineering mode”.
When you get the first two estimates, this therefore puts the most probable outcome somewhere in between, so now you can just ask for it. By the way, the most-probable estimate usually won’t be in the middle, but much closer to the optimistic scenario. It’s probably because meteors don’t strike that often.
You Don’t Do Estimates By Yourself
For any task, there is always a “specialist” perspective and the “operational” side of it. When estimating, you are better off with a specialist exploring the work that needs to be done, while you or another senior team member points out organizational and logistical issues.
For a software project, a specialist you most certainly need on board is a senior developer. The other most valuable person to enlist is an analyst, to help establishing what in fact needs to be done.
Including yourself, this group of three makes your core team for developing an estimate. For all the other expertise, you’ll consult other specialists as needed: testers, networking staff, systems people, etc.
The Importance of Sanity Check
Once you get any estimate, how do you know it’s any good? Even experienced professionals sometimes overlook a detail or two, which could explode in your face later.
Thus, your job is to test every single estimate somehow.
The easiest way to do this is to compare the estimate with similar work done in the past. By the way, it would be awesome if you routinely kept records of such things, wouldn’t it?
The easiest way to test an estimate is to compare it with similar work done in the past.
If you can’t get your hands on such data, you’ll have to come up with a way to evaluate the estimate anyway.
For a project task, you can clear the estimate with a different developer. You give him both the numbers and the reasoning behind them. Whatever questions he comes up with, need to be resolved.
And for a whole project, you will need to do several things:
- Break your project into parts, and estimate them instead of the whole project.
- Make a real effort to find out any relevant data to compare it with.
- It’s your field and you know people, right? Go out and find similar projects. Find out how they were done, and what it took to complete them.
Sometimes, you’ll want to have two independent teams develop the estimate. Usually it pays off to do that when the project is either big or important or both.
All this is far from trivial and requires some expertise, but it can be done relatively fast. However, making the reasonable estimate is only half of the job. The other part is being able to defend it.
Making the Estimates Management-Proof
Have you ever developed an estimate you were proud of, just to have it halved by your own management? Such experience can be pretty discouraging, watching the whole teams sent off to battle just to be shred to pieces.
The way to actually do something about it, is to start making your estimates management-proof. That resilience shouldn’t be applied on the finished work, as a coat of magical paint. Instead you need to build it into your estimate right from the start.
Management’s job is, among other things, to get that sale and to maximize profit. Arguably, both are accomplished by making sure the project costs are as low as reasonably possible.
That’s why the managers’ role is to “attack” your estimates, while yours is to provide the balance. They do their job, and they count on you to do yours. You don’t actually think that your managers want angry customers and a negative profit, do you?
Management-proof estimates require some work, but the main trick is to be aware of this as your goal even before you start.
Here is what you need to accomplish:
- No one-big-lump number. You need to break-up your estimate, and each item has to be well presented and backed by sound arguments.
- Nothing must be allowed to be perceived as guesswork. If you provide historical data to draw from, only a fool would attack it.
- If no such data is available, you need to actually do the measuring yourself. If you have 300 reports to develop, you better get busy and actually develop one.
- Where you can’t do that, you can have different specialists give a thorough estimate of what will it take.
You get the picture. Come up with some hard facts, in any possible way you can think of, or be ready to get smashed to bits. The actual know-how in fact lies in how to accomplish this with limited time and resources.
If you provide historical data or actual measurements to draw from, only a fool would attack them.
When presenting your estimate, you don’t want to leave room for interpretations. Prepare fairly short handouts, that present your facts as matter-of-factly as you can. Because there is no guesswork here. These are actual facts, and a results of your hard work. You want to communicate them as such.
Also, you need to demonstrate that you have covered the whole job, from day one to last hour billed on the project. This includes meetings, documentation, user training, acceptance, the support during roll-out, etc. If anyone uncovers a slip in only minutes they actually had to do it during your presentation, it doesn’t put a very good light on the whole estimate, and you might lose credibility completely.
Also be prepared for the two most important questions. The first is: “Can it be done cheaper?” and the other is “Can you deliver it earlier?” When this happens, it doesn’t mean your estimate is being disputed. Most often, there is a genuine problem that your management needs your expertise to solve. Maybe the customer doesn’t have that kind of budget, or maybe there is a soft deadline you were not aware of.
PART II: RELIABLY ESTIMATING SOFTWARE PROJECTS
Risk-Free Estimates Are Usually Not Feasible
Risk-free estimates are the holy grail for software projects, but can a real-life estimate really contain no uncertainty?
With opportunities always comes some risk. You minimize it and that’s all you can do. Thus, the estimates don’t pretend to be 100% accurate, but they come with their precision range. The narrower the range, the more effort you need to make an estimate. Three types of estimates are used often: Order-of-magnitude, Rough, and Definite estimates.
Order-of-magnitude estimates (usually described as -50% to +100%) are both quick and cheap. You need them to decide whether to investigate a particular opportunity further or not.
Rough estimate however, indicates (arguably) pretty much the best you can do, before you are actually half-done with implementing the actual project. Common range used for the rough estimate is -20% to +30%. This estimate is usually the most useful, because it still can be done relatively quickly, while providing some numbers to hold on to. It does require real work and expertise, however.
An estimate in a 30% range can still be done relatively quickly and will provide some numbers to hold on to.
This estimate produces rough solution design (the What) and all the ingredients for a basic project plan (the How). You need a rough estimate to enter detailed negotiations with the customer, although quite a few companies start the implementation with no better estimates than these.
And last, definite estimates fall within -5% and +10% range. Usually, you get to this point when you are half way through with the actual implementation on a project. It’s not so common to see a software project (there are special-case categories though) which has a meaningful definite estimate developed in advance.
Nowadays however, various sources (Project Management Institute included) tend to narrow the rough estimate further. To accomplish this, no additional expertise is required, you just get into details one level deeper. It’s several times the effort though, so I’ll stick to the basic procedure for making reliable estimates in 30% range. If you are prepared to invest the additional effort required, you can decide to refine the same estimate further.
Let’s say you have project documentation, and need to make an estimate.
You start with assembling your core team, with at least these three specialties covered:
- Project planning and estimating; which is probably you, since you are reading this.
- Business and system analysis; it’s your analyst.
- Software architecture and development; covered by your lead developer.
The actual size of the team depends, of course. If the project is small, then the three of you won’t work full-time on this estimate. On the other hand when the project is big, you definitely need a full-time professional for project manager. And both the analyst and the lead developer will need their own teams of 2-3 people.
It is not only project size that matters, but how well it is already defined. For the same size project, user specification can vary from 20 pages to a 500-page document, and the quality of the specification can differ greatly. For example, if you need to investigate what the customer really needs, your will have to do more analysis, thus requiring more analysts.
Basically, common sense applies here. More work equals more hands, in any particular field.
Just remember that big bucks can be made or lost here, so it’s crucial that you have all three main specialties covered with experienced professionals on these positions.
What the Project is About
You got the core team, now before everything else you need to determine what the project is about. Read the spec, all three of you. Compare notes. Pay special attention to the summary. Both your analyst and your developer should have questions they need to investigate further.
Before you let them dig deeper, try to structure a project into main deliverables. This is your main focus now, and it serves two purposes. For one, it is a quick test of your understanding. Until your chart on the whiteboard makes sense to everyone, you are not ready to go further. And second, this reveals major issues so the priorities of the moment become crystal clear.
Your time and resources are limited, so don’t let people go into exhaustive investigations for other than major problems. Once you solve major issues, go update the whiteboard. You will have uncovered new issues in the process, so repeat until you can see no major problems remaining.
Sometimes, there will be multiple ways to solve an issue. At this point, chasing a perfect solution is not an option, because you simply don’t know the whole picture yet. Instead, make a reasonable decision and stick to it, unless and until it proves inferior.
By the way, document any assumptions you make at this point, you will need those later.
Once a meaningful project is looking at you from the whiteboard, it’s time to go both wider and deeper. Start looking for all the prerequisites for items on the board. You will find more work and more internal deliverables. Also look for all the work in the side-tracks. Put it all on the board.
Then try to break each item into pieces. What does it consist of? What do you need to pull it off? Don’t focus on activities, identify the deliverables. Everything goes on the board again. Again, new issues will emerge and you resolve them until the whiteboard makes sense again.
Also, you should start recognizing patterns on the board. You’ll notice better ways to break down your project, it’s time to start deciding how the actual work will be organized. For example: will it be by phases, or you will have several parallel tracks? Restructure the project to fit what you decide is best.
Unless you have a really big whiteboard, you should be hitting its limits by now, so it’s time to start switching to MS Word or your favorite word-processor. Begin with a summary of your project: make it clear what the project is about, and what are its main deliverables. This part needs to be short, no longer than several paragraphs, and described from the customer’s point of view.
Now you have a pretty good idea what are you expected to deliver. It’s time to think about how that would be accomplished.
How the Work Will Be Done
For these workshops, set some time aside. Go through all the items on the board, one by one. How each item will be done? How many people you need to do it? In which roles? Together visualize the team doing it, and tweak the picture until it compares with your past experiences.
Write it all down in your document. Items from the board are your titles and subtitles. Anything that comes up, write as bullets. You don’t want any further structure at the moment, what you need instead is speed.
Keep your document as light as you can, you need to be able to quickly reshuffle everything when necessary. You want the level of detail to expand only with increased understanding that each iteration brings, but not before.
Keep your document as light as you can; you need to be able to quickly reshuffle everything when necessary.
Also, don’t let this step take forever. You are not developing a full project plan, but only an approximation. Thus you can cut corners here. You just have to make sure that everything makes sense, and no real issues are left unresolved.
As you go, identify large amounts of work by comparing with similar tasks on previous projects. Start categorizing these large chunks for later, in a separate chapter of your document.
Also, maintain the list of the main assumptions you have made so far. If an assumption is downright crucial, for example “We won’t develop our own database, but use the existing one maintained by Sales department.” then be sure to add it into the summary itself. It changes much of the project, after all. For the rest, these assumptions will either be important for creating individual estimates, or they’ll be your design constraints once you get the project, or both.
If you get any ideas about how the project might be done cheaper, write them too. In the mentioned example of having hundreds of reports, you might investigate the possibility of using an of-the-shelf reporting system, instead of programming each report yourself.
Another example is when you see a lot of highly specialized work is required. Would you be better off hiring a niche contractor to do it? If so, you need to isolate that work from everything else, and get the contractor’s proposal, or at least an estimate.
These kind of decisions also change your project, so if you haven’t sketched your solution architecture so far, do it now. The goal is to identify all the options that still have to be decided upon.
Your project is shifting shape all the time, but that’s good: the What and the How are rapidly taking shape.
Who Will Be Doing the Work
What you should have so far is that the complete work has been laid out, the architecture has been established, and you might have already decided on distinct tracks or phases. This should be enough to see clearly what expertise you need.
So which separate teams will you need and of what size? Will the teams be specialized or multidisciplinary? For example, you might decide the proper team for one track should have an analyst and a tester attached to otherwise pure-programmers team.
There are many parameters here, so you won’t be able to optimize them all at once. For example:
- Whether you are better off with a single development team or with several smaller teams. Also, who will lead each of those.
- Does a team have enough work that can be done by an intern? Cheap labor is always good, especially when it doubles as a training.
- For each external system, who will be doing the integration.
- How do contractors fit in.
Trying to answer all of such questions “correctly” right from the start is both frustrating and won’t work, because any decision you make influences one or more of the others. Instead, pick the approach that seems most reasonable, and test your plan as a whole later. Soon it will be clear which assumptions are good and which need to be refined.
Pick the approach that seems most reasonable, and test your plan as a whole later.
Organize the Project Around Major Contributors
Two types of work are the main focus of your estimating effort:
- Large number of deliveries accomplished by repeating basically the same task.
- Complex deliveries achieved by repeating the same procedure.
The first type could be, for example, pre-installing 80-100 desktop computers. Or delivering between 150 and 300 reports. An example for the second kind would be 30-50 scenarios your programmers need to develop.
When you put it this way, it’s quite obvious that these will eat most of project’s man-days. It’s the Pareto principle in its fullest: 20% of tasks taking up 80% of the effort, so these are the “major contributors” for man-days of your estimate.
Thus, you want to focus on major contributors, by organizing the project around them. Make these tasks separate, to be able to estimate each group of major contributors independently.
Focus on Major contributors, that is, the 20% of tasks that take up 80% of the effort.
For each category, determine which sub-types need separate estimates. For example, you could further categorize scenarios into those of Low, Middle or High complexity. Or for reports, you could make a distinction between analytic vs synthetic reports.
For each sub-type, determine the exact number you are proposing to implement. For some tasks you establish their number by digging deeper, but for others you won’t be able to do this accurately. Since you are not allowed to guess, you should specify the exact number you are proposing to implement. “We will install the system in 15 different venues, including setting up the hardware and network infrastructure on 4 of them.” And make sure this number has an important place in both your estimate and later in your company’s proposal.
Estimating the Bulk of the Effort
For your major contributors, find where similar work was done before within your company. Dig through old project documentation, and talk to senior staff from those projects. If no such projects exist, talk to your colleagues from other companies (you are not in this business since last Monday, right?) Ask other project managers to share their past experiences. You really don’t have to make the same mistakes if somebody already did them.
In other words: beg or borrow if you have to, but make sure you get some hard data.
If you can’t get the factual numbers, my sincere advice for you is to try harder. To motivate yourself, just visualize the all-nighters and all the misery a wrong estimate might put you in. If you cherish peaceful weekends with your family, or those adventurous trekking trips with your friends, be aware that you won’t have either for months unless you get more creative.
Beg or borrow if you have to, but make sure you get some hard data.
Much of the data you get will be either incomplete or not an exact match. This is normal, and such data is still usable. Think of it as a puzzle, and make necessary amends. For example, the actual man-days may depend on the size of the system, or on the actual tool used. Or on the team expertise with particular software framework.
After you have paid for quite a few lunches, hopefully you will have a large part of the information you need. Now run that information by your team and encourage them to challenge the “tweaks” you applied to the original data. Then agree on the correct approach for each task.
For the data you still lack, you know the mantra by now: guesswork is not allowed. Thus, you’ll have to produce the data yourself, with help of specialists who would normally be implementing that work.
You have several options here. Listed in the order of effort required, these are:
- Actually implementing a task.
- Performing the detailed design for a task.
- Making a multiple-specialist estimate.
If time permits and it’s a reasonable thing to do, go for the actual implementation. You have to judge the importance of doing this against the costs, though.
For the data you definitely can’t get, you’ll have to produce it yourself.
Let’s look at the before mentioned example: you have 300 reports to deliver, and each should take somewhere between a man-day or two. So if you simply take the middle-ground i.e. 450 as your estimate, you might be off by 150 man-days! But if you have the prerequisites to actually develop one report of the same type, you will need at most 2 days to know for sure.
This is a no-brainer, isn’t it?
Just take care that measuring a first-time-anything doesn’t make for good baseline. Either do it twice and measure the second pass, or analyze the first implementation and carefully sort out “first-time troubles” from the actual “run-of-the-mill” work.
For more complex tasks, you won’t realistically be able to do this. Maybe the infrastructure you need is not in place, or it simply requires too much effort to justify. What you can still do is to perform the detailed design. Your specialists should prepare everything for the task, exactly like if they were actually implementing it. Only then they come forward with an estimate, as detailed and thorough as they can. If you can, run such estimate by a different specialist from the same field, and let him come up with questions for the author to justify.
Measuring a first-time-anything doesn’t make for good baseline.
When even the detailed design is not feasible, you can have two specialists make independent estimates, and then sit together and compare their results. Often one has identified issues that the other hasn’t recognized, or came up with a more efficient way to solve a particular problem. When they come to an agreement, you have both the estimate and the reasoning behind it.
All this requires some work, of course. However, your only focus now is on major contributors. Typically you have less than a dozen of these altogether, many of them already untangled by your prior investigative efforts, so there will be only several tasks requiring you to actually implement them.
As a result, you will have the accurate estimates for the great bulk of the project work. Now, let’s see what should be done with the rest.
Estimating the Remaining Work
Obviously you can do the same for all the work remaining, but applying “heavy” methods to every single task is usually not feasible. With the remaining tasks, you should be as quick and cost effective as possible.
For some tasks, you will have the hard data available anyway, so use it, by all means. From the rest, identify the biggest and/or most risky ones and use the method you decide is prudent. Often it’s enough to have one specialist make the estimate and run it by her peers.
Applying “heavy” methods to every single task is usually not feasible.
One way to be even more cost effective is to assign a single expert to estimate all tasks for his or her speciality. This way you can again afford the peer review, because it’s “cheaper” (i.e. the cost is a single meeting) to do it for a whole group of tasks. It’s always a good tactics to have the main assumptions questioned by another pair of eyes.
Sometimes it happens that main assumptions of an important task can’t be reasonably verified. One approach to consider is developing an estimate for each scenario, and document the assumptions that caused this branching. Getting those into proposal itself should be your top priority, so you can clarify with the customer what alternative is most appropriate and negotiate from there.
Other times, the task is something your company hasn’t done before, and you can’t obtain any data by other means. What you can do then is to have a pool of relevant experts do the estimating. To avoid prestige issues among experts themselves, this is best done anonymously, for example by e-mail. Each expert sends the estimate to you, together with main assumptions and their reasoning. After first round, you distribute back to all the experts others’ estimates without naming the author, and start another iteration. In a few rounds the estimates should converge, otherwise hold the joint workshop and refine the estimate further.
At this point, you can finally put your entire project to the test.
Putting It All Together
Draw a rough schedule (a mini gantt-chart) on the board. To do this, you need to roll up smaller tasks into bigger activities. Otherwise, you’ll have a huge number of items, and you need to be able to rework this rough schedule several times over. So, whatever the size of your project, go for 20-30 items.
If you are one of those alarmed by anything resembling a project management software, here is how you do it quickly on a napkin:
The level of detail you will get depends on the size of your project. For a six-month project, you’ll get activities that are accomplished in 2-4 weeks, while for a 2 month project the activities will take 0.5-1 week. Note that we are not developing a full-project plan (which demands more details and thus much more effort) — we need just a solid approximation to test our approach.
First, make sure all the activities are of similar duration. Once, I was on a software development project of 18 months with 728 activities in the plan. Only four (4!) activities reflected actual software development work and took several months each, while there were zillion half-day meetings and workshops taking the spotlight. Needless to say, visibility on that project was zero, and the only idea people had of their own responsibilities was what they could derive from the list of deliveries and their due dates. Thus, by all means, break up activities that are larger than you need, or group together smaller ones, listing what they comprise of in their description.
To avoid slip-ups, you need some buffer. The most common mistake is to add a small padding to all your tasks, because activities tend to take as much time as you have allotted for them. Add some buffer after each sequence of critical activities instead.
Check your approximate plan against reality; rework it accordingly; then check it again.
Then start checking your plan against reality, and rework it accordingly:
- What is done in parallel? If you don’t have enough resources, either add more staff or reshuffle activities to be sequential.
- Look at each specialty: analysts, developers, testers, etc. You might find your plan requires 10 developers one week, then only 2 developers next week, then 15 developers which you won’t actually have. Make sure this doesn’t happen.
- What are possible external interruptions? Such as national holidays, other critical projects in your company, and similar. You might need to tweak your velocity in some time periods.
Speaking of velocity, one thing that’s often overlooked is people taking sick leaves and vacations. A person normally takes up to 5 days of sick leave per year and up to 20 days of vacations. Thus, for half year project for 10 people you are “slower” for 125 man-days!
Also, experts and senior staff usually have many professional obligations, so even when they are assigned to your project full-time, in reality it’s rarely more than 80% of their hours.
Now visualize how will you communicate with:
- Your customer.
- Your contractors.
- Other involved parties.
You might need regular meetings, or even to hold a series of joint workshops. All of these need to be included in your estimate, including preparation time. Often it’s efficient to put one single “fake activity” for all this grouped together, to manage it without getting bogged down with details.
Think of all the accompanying activities on a project, for example have you accounted for:
- Training the project staff where needed.
- Putting all the development infrastructure in place.
- Complying with legal or company policy regulations.
You get the point, be sure to make all the sanity checks you can think of. Make a comparison with your last few projects and see whether anything looks suspicious.
Be sure to make all the sanity checks you can think of.
After you have your plan, two simple tests will tell you whether it’s acceptable:
- Is your plan well within the deadline.
- Are the costs close to the target (or to initial “ballpark” estimate).
If not, remove from your plan everything that would be nice-to-have, both in your final product and in your process. Then proceed with real work:
- To shorten the duration, try both putting more tasks in parallel and adding more staff. Usually you can overlap sequential activities to some extent, but it greatly increases the risks you are taking.
- To cut the costs, check whether there is any “gold-plating” left and mercilessly remove it. Then think whether a part of the project can be done cheaper by somebody else — you might be better off with a highly specialized contractor, after all.
Also you might be able to further simplify the process for non-critical tasks. For example, you might not really need every single document that is recommended by your methodology. Or instead of a formal peer review for every individual design module, you could have a single peer review for all non-critical modules.
One of the possible trade-offs between time and cost is to do the same job with substantially smaller team. If ten developers deliver twice as fast as three developers would, then the opposite should also be true. Thus, when time is of no real concern, this might be a legitimate way to cut down the costs.
When you are off the mark, your only option is to go way back and radically change some of your assumptions.
If you are still off the mark, tough luck. You need to go way back and radically change some of your assumptions. Possibly so much that you will get a much different project. Fortunately, you have been avoiding thick and premature documentation so far, so you just need to reshuffle all the existing pieces and estimate the few new ones.
Softening Project Risks
Now, think of what might go wrong with your plan. Most risks can be made less dangerous, or sometimes even completely avoided. Thus, your job is to make your plan as watertight as reasonable.
Project risks are, in fact, anything that might go wrong with your plan.
Together with your core team, identify the risks you are taking by accepting the project. It’s effective to do this in the following order:
- Start by emptying your heads, because what your team worries about are usually the most important risks anyway.
- Then go over the project plan and discuss what can go wrong with any part of it. Make sure to include not only technical problems that might occur, but organizational and people risks as well.
- You might even use one of the numerous risk checklists you can find on the internet. Just don’t do it before you have exhausted both your own worries and your plan as sources of possible risks.
Then, together with your team, determine these two for each risk:
- The probability of a problem occurring.
- Its impact on the project.
Don’t overanalyze, these serve simply to decide what risks you will be focusing upon. Instead of discussing this for days, there is an effective “trick” to perform this step in 15 minutes flat. Decide whether the probability is either Low or High, and if you are not sure then it’s Medium, period. Repeat exactly the same for the consequences.
The primary method of dealing with project risks is to change your planning accordingly.
Some companies have a simple policy: no high-probability/high-impact risks allowed. If you have one of these, change your project plan to lessen either probability or impact or both.
Now shortlist your risks, and analyze each item on your newly created top-ten list properly:
- Can you avoid it somehow, or at least lessen the chances that the problem will occur.
- How your plan can be hardened to “soften the blow”, if it comes.
- What will you actually do as your reaction to the risk becoming true.
Whatever you agree on, it requires tweaking your plan and probably some additional man-days. Here is the quick reminder of the whole process:
Compiling the Final Estimate
Once you are confident that your project can be done and your estimates are sound, it’s time to sum them up.
You can calculate the final estimate as a project cost in dollars. That is, if you know all the pay grades for different roles on your project. Otherwise, you give your estimate in man-days, plus direct costs. The structure of your man-days is still important, because a NASA expert xeno-biologist most certainly costs much more than a lowly fix-the-paper-jam intern.
At project level, you have to account for each project being different. Some are technically demanding, others have very tight deadlines, or are done by people who can’t speak the same language. And the occasional project has everything going for it, and should be a breeze.
Studies have shown that factors you need to adjust for fall into two categories. Broadly speaking, these two categories are technical complexity (technology, know-how, code reuse, and similar) and environmental complexity (customer, team, workplace, level of formality, and so on). Each category influences the final outcome by up to 20%, statistically speaking.
You need to adjust each estimate for: 1) technical complexity and 2) environmental factors.
Thus, compare this project to other projects done by your company, and decide whether it is more (or less) complicated in both categories. Your baseline for comparison must be your average project, don’t use neither the ideal one, nor the last catastrophe you witnessed. Multiply your totals by a factor you got for each category, and you have your final estimate.
Now you only need to decide on how much reserve to add. You know the saying: “No plan survives contact with the enemy.” Your reserve is what enables you to react when something does happen. But how much, and how do you justify it? Some companies make it simple by having a predefined percentage for the reserve, be it 5% or 10%. Otherwise, you have to decide on the appropriate number yourself, based on your top-ten risk list. Add it to your estimate, and you have your proposed budget.
The Time and Cost of Estimate Itself
This approach definitely takes a lot of expertise. However, the actual cost is surprisingly low, for what you get. A small team can estimate a 500 man-day project in 2-3 weeks, with none of team members working on it full-time.
What you get for this effort is:
- Eliminating guesswork, so there is no real risk in taking the project.
- Better chances to get the project in the first place, because it will be obvious your proposal is well thought-out and professional.
- No one will try to dispute your estimate, when presented properly.
- A project plan you can easily refine, once you get the job.
And the best thing is: all this would have to be done later anyway. So the estimate is free, if you get the job. It doesn’t hurt, of course, that this approach is robust, popular and goes down well with people — especially with senior management.
Estimating effort comes for “free”, in the sense that all of this will have to be done eventually anyway.
This approach also scales well. If you don’t have the time or the resources, you can go into less details and favor cheaper techniques — the estimate will be less accurate, but it still may be good enough. Or the other way around: when you need as accurate estimate as you can possibly get — then simply go into greater level of details, with strong bias toward more thorough of explained techniques.
Just know what you need, be aware of the costs, and adjust accordingly.
Presenting Your Estimate
After all the hard work, you don’t want to stumble at the very finishing line. You need to present your estimate properly. Fortunately, defending an estimate created in the above manner is easy.
Start with a good summary, stating what you are proposing to do, the numbers, and your critical assumptions. These three are of utmost importance, so your summary should state only those, in as little words as possible. You should never go with a single figure for numbers, otherwise it will be the only thing anybody remembers two months from now. If you aimed for -20/+30% accuracy and got 200 man-days, state that the estimate falls in range between 160-260 man-days.
After all the hard work, you need to present your estimate properly.
Next, describe your solution. You need to explain in no more than 2-3 paragraphs what are you proposing to do and how. With this, you achieve the following:
- You are getting everybody on the same page.
- You are demonstrating that you are the person with the best understanding of the situation.
Your estimate probably assumes quite a lot, so make sure to emphasize the critical assumptions you have made. For example, if you propose to use an of-the-shelf reporting system, say so here loud and clear. If assumptions change, this will neither be the same project nor the same estimate.
Before you go about explaining your estimate, stop and wait for questions. This is a great opportunity to demonstrate that you are on the ball. Your answers should be to the point, but postpone any real discussion though. Instead, refer to the appropriate place in the rest of your estimate.
Go on an provide more of the context. You can start with the chart of solution architecture with remaining assumptions, followed by your rough project schedule.
Then lead your audience through the break-down of the work. Focus on the major contributors, numbers for their estimates, and how that estimates were done. Emphasize here all the data that came from hard facts and real measurements. For all project work not heavily influencing your estimate, simply group the effort in broad categories and explain it summarily.
To start wrapping it up, discuss the major risks you identified, and what can be done about them. And for the end, make sure to discuss the opportunities to lower the costs, this will bring you back on the same page with the management. Maybe you discarded an approach because it’s plainly out of your control, the example would be the availability of critical staff. Give your boss all the info, but let her decide her own priorities.
That’s it, your (main) document should be no more than several pages long:
- Summary, short and to the point.
- What are you proposing to do and how.
- Actual break-down of project work, and how you did the estimates.
- Major risks and opportunities.
After your presentation, there will be hard questions. You should be more than prepared however, by the very process of creating the estimate. On the other hand, when you believe management will want to cut something out just for the sake of it, you can prepare by including some nice-to-have things, but which could be thrown away without hurting the project.
By presenting your estimate in the above manner, you are actually communicating several points:
- By making every word count, you demonstrate that you are a role model for efficiency.
- You are an experienced professional who is presenting facts, based on of hard work.
- You have a pile of hard numbers ready, just waiting to demolish any potential pressure of the wrong kind.
Both the above estimating approach and this method of presenting the estimate have been proven to work. In fact, I can’t remember a single time when any such estimate of mine was disputed. If you base it on facts, it will be taken as such.
When you base an estimate on facts, it will be taken as such.
Estimate can still be judged too high, but only to end up in brainstorming with management, about whether the scope could be changed or similar, for instance.
No manager really wants a failed project, and no sane person fights the hard facts.
- Leave a comment, I’ll be glad to know what you think.
- You can share this article with others. To do that, just use the social buttons below.