Project Management

Giving IT consulting clients realistic estimations

To estimate when you'll complete a consulting project, leave the best case out of the standard PERT calculation. Find out how to come up with the worse case and most likely case numbers.

 The first rule of estimating time requirements for an IT consulting job is: Don't do it.

Okay, that's not exactly right. In fact, you should always estimate the time required for a project -- if you bill by the job, that's how you'll determine your price. Even if you bill by the hour, you'll want to get a handle on exactly what you're committing yourself to in terms of scheduling. Just don't share that estimate with your client, if you can help it. No matter how many qualifications you put on it, no matter how many times you remind them that it's only an estimate, just by putting a number or a date out there, you've created an expectation.

But sometimes clients insist on getting a "rough timeframe" -- or, if you bill by the hour, a rough cost estimate. Back in my early days of consulting, I'd just pull a number out of my, um, hat -- a number that was usually based on the best case scenario. You know, the one where nothing goes wrong. For some reason, I was rarely correct.

A while back, Tom Mochal posted about using the PERT technique, in which you average the worst case, best case, and most likely case (heavily weighting the most likely case) to come up with a decent estimate. Personally, I'd forget about the optimistic case and divide by 5 instead. The probability of the best scenario is equal to the probability that Murphy's Law will be suspended -- and we should all know from experience that Murphy's Law is more reliable than gravity.

But even so, how do you come up with the numbers to plug in as worst case and most likely case? For the worst case, you have to stop somewhere. I mean, just think of how many things could go wrong. In the most critical stage of the project, you could be taking your morning stroll and be hit by a falling piece of frozen airliner sewage and not wake up from the coma for six months. Do you build that into your worst case? Of course not! Because the coma could last for seven months. Seriously, though, you can only include the most likely delays in your worst case scenario. How's that for a paradox?

When computing the most likely timeframe, I follow a formula something like this for each activity:

T = (G * U) / R

where:

  • T is the resulting time estimate for the activity.
  • G is my best guess for how long it "feels" like it will take.
  • U is the uncertainty factor.
  • R is my reliability quotient.

G is the least scientific quantity here. Unless your work is highly repetitive (in which case, you should write a program to do it), it's difficult to say with any precision exactly how long any activity will take. That's why I call it G, for Guess. That's also why this equation has the U and the R, which I'll explain below.

U, for Uncertainty, is a multiplier for unknowns. How much of this activity involves new research? How much has already been solved? Here's a guide:

  • (U = 1) I've performed this activity myself before, and I know what I'm doing.
  • (U = 2) Many others have done this before, so I'll be able to Google my way through.
  • (U = 4) I read somewhere that somebody did this before.
  • (U = 8) Nobody has done this before, but all the pieces should be in place.
  • (U = 16) We'll have to invent how to get from point A to point B.

If the solution involves learning a new programming language or other major technology, multiply U by a factor commensurate with your ability to learn new languages, etc.

I often find that when my estimates are off wildly, it's because I failed to get U right. I'll mistakenly assume that some part of the problem must have already been solved before, but then I'll come to find that we're actually breaking new ground. The more research that has to go into a project, the less reliable your initial estimate will be -- exponentially. But sometimes you can reasonably lower the value of U by doing a little prototyping up front.

R, for Reliability, takes your past performance at estimation into account. At the end of each project, compute the ratio of each activity's G value divided by the actual number of hours spent on it. Average these in with the same ratios from all your other past projects, and you have R. R may seem to represent the probability that your best guess will be right, but it isn't -- it's actually far more useful than that, because it's a predictor of how far off your best guess is likely to be. Thus, if you have a history of taking twice as long as your best guess, then R will be 0.5 -- which multiplies your final estimate by 2. It's the old adage "take your best guess and multiply by n", except that n is determined by just how bad your guesses have been in the past.

Now you have an estimate that you're likely to be able to live up to. But we never like to disappoint a client, so when they ask, double it. After all, we're still subject to Hofstadter's Law: "It always takes longer than you expect, even when you take Hofstadter's Law into account."

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

47 comments
reisen55
reisen55

One horror to avoid and we all have had them from time to time are the hell projects, ones that begin small and dovetail into monsterous time eaters. I have avoided these for ages but the memory of a Gateway system that, in old Windows, went from a cdrom problem to a motherboard reinstall in a bad Gateway box that ate up hours of time, which I could not realistically invoice the client for, are subjects I care to forget. I have not seen those of late, because our industry has greatly matured. But the best estimates can always run bad when these demonic "Invasion of Russia" projects surface. So, learn from Napoleon and Hitler and DON'T DO IT.

jmgarvin
jmgarvin

Once UAT goes bad, at least another 4 hours ;-)

bond.masuda
bond.masuda

i've been a consultant for quite some time, perhaps longer than I would want to admit. i was first given the "give me an estimate" problem when i was working for a consulting firm not of my own. and back then, i made mistakes when under pressure from my sales rep to "give me a number". i think as I made mistakes in my estimates and learned from them, I intuitively got better at making more accurate estimates. I think that is what your "R" factor is about... a bit of an "iterative correction" process. i have to disagree with your remark about "avoid giving an estimate unless you have to" and treating the estimation(guestimation) process as a "necessary evil." Or at least, that's how I read it. I find that being able to give estimates, whether as time or cost, is a great opportunity to demonstrate your dedication and reliability to the customer. I feel that these qualities are even more important than one's technical ability and so this type of opportunity is very important seize. when you can tell a customer, I will do XYZ in this many hours, for exactly this much and you completely nail it on the head, it is indeed a very impressive feat! also a great closing slide if you're doing "end of engagement" presentations to managers and show "here was our estimate, and here is what we accomplished." even if you don't end your projects with a powerpoint slide, people will know that they can rely on you. You have to keep in mind, that your PoC at the client depends on your word. When you give an estimate, they commit themselves to their boss and budget as well. If I totally screw it up, I'm screwing over the guy that i'm working with at that company or the person that referred me to that client. On the other hand, if I do it right, it makes my contact look good to his bosses, which strengthens my relationship with that person and he/she is more likely to want to use my services again. sure, there will always be mistakes, and some pretty horrible ones. but sometimes those mistakes are what make us better consultants. so, I don't see giving "estimates" as the necessary evil, but rather, the process of giving bad estimates (and learning from it) as the necessary evil. by the way, i also try to insist on fixed price bids, though some clients insist that I bill by the hour (to fit within their framework and pre-established processes). if i screw up the estimate, i eat the cost.

PMPsicle
PMPsicle

First ... that's an excellent calculation for estimating time. People tend to forget the estimator's error. I congratulate you. The only part (formally) missing is that of when you are estimating and the efficiency factors. Studies have shown that engineering types (IT included) have a tendency to underestimate the length of time needed to complete a task. In addition, standard engineering practice, has identified a rolling error of (-50/+100%, -25%/+50%, and +-10%). Studies on IS have confirmed that this applies to IS (and presumably IT) as well -- at least when identifying the workload (i.e. not time). HOWEVER, those studies have also shown that the person doing the work has an influence of +500% when compared to the best person. Since we tend to have our best people do the estimate, the estimate tends to reflect their speed. In short, our chance of getting a reasonable estimate when doing a team development is zilch. With independent consultants fortunately, we're typically not estimating other peoples' time. If we are then we need to include some form of adjusment for the team efficiency. All of which comes down the fact that you need to include the following errors (variances) in any estimate: 1)knowledge of situation/timing of estimate (in theory built into PERT but often not) 2)project risk factors (built into PERT and also in your U factor) 3)"low-balling" tendency (+20% and no-low varation of PERT). 4) estimator reliability (your R factor) 5) efficiency factor (which isn't covered). 6) decision efficiency (i.e. how will scope change management overheads affect the estimate) Since you covered 4 out of the 6 influencers, you've done a great job with your calculation. HOWEVER, I do need to comment that this is a cost estimate. In the case of a fixed price quotation, you need to estimate this to decide if you want to bid or not. Remember also, that your client is intending to transfer the risk to you (that's why they want the fixed price). You need to consider this as an extra part of the cost. You need to be compensated (think of it as buying insurance). But your price should be based on what the client is willing to pay (which tends to be based on their savings/benefits if you can guestimate that). If the price is greater than the cost - bid on it. If not - forget it. As independents, we too often confuse cost and price. They're not the same. (BTW, I HATE fixed price contracts (including per-diems). I always tell my clients that they are going to pay more if they fixed price something vs T&M because under fixed-price one of us has to lose -- and it can't be me.) I also always price fixed-price contracts based on retail price (i.e. twice what I get as an independent). After all, if I was a large company and doing it all the time, I'd need to hire others and they'd be demanding to get paid regardless. So I deserve the same. Glen Ford http://www.TrainingNOW.ca

GTGeek88
GTGeek88

Ok, some mods are in order: (U = 16) We???ll have to invent how to get from point A to point B (and the specs suck) Well, actually, the specs probably suck for all of those, so just add it to every "U" line. Overall, though, I like it.

reisen55
reisen55

I recently quoted for a server upgrade on a small business account. I knew the time variables well enough to be accurate and they indeed WERE on my first go-around until I hit a total brick wall with access to critical office apps on workstations. Nothing worked as well as it should and for no good reason I could immediately see. I backed out the replacement hard drive, replaced the original back and gave it a 24 hour thought. I found a solution, using GHOST of all things, that worked great and took 2 hours to complete. I was then able to use the spare hard drive, now removed, to use as a GHOST-test bed for an image of the primary operating system drive. This test I did on my own and it worked great. Restoration of server if BSOD or failure cut from hours to 10 minutes. I gave a bill for the 2 extra hours and the client COMPLAINED ABOUT IT. I had to make it very clear that workstations I can negotiate on and generally do, but server work is critical and the unexpected occurred. HOWEVER look at the DR benefit they obtained. I have that spare hard drive on a table next to this very computer. If that server goes down, I can have it back with all current data inside of 10 minutes. And the client complained. Sheesh.

Tig2
Tig2

When I told my father (aerospace design engineer (has his "E") ) that I was doing project management, he was appalled to discover that he had raised a PM. He told me that the best thing I could do as a PM was trust my technical staff. I have supported, programmed, and developed security strategy. I have worn many IT hats. What I learned was to develop a team and stay close to it. My guys tell me what they think. At a high level estimate, I add 20%. My father was a part of the L-1011 team at Lockheed (anyone recall them? They merged with Martin). He told his PM what the design issues and needs were. And the PM cut around 30% out of Dad's estimate. And then wondered why they couldn't meet the time line. The L-1011 was probably the reason that Lockheed merged with Martin Marietta. Bottom line- trust your crew and add 20%. At a high level estimate, you won't go wrong.

apotheon
apotheon

"[i]by the way, i also try to insist on fixed price bids, though some clients insist that I bill by the hour (to fit within their framework and pre-established processes). if i screw up the estimate, i eat the cost.[/i]" I actually prefer kind of a modular approach to project pricing. I kind of hinted at that in something I was publishing elsewhere at about the same time Sterling's article about project estimation was being published here (they both appeared on Saturday, the 15th this month). The whitepaper in question is titled [url=http://apotheon.com/wp/deadline_math.html][b]Deadline Math[/b][/url], and I talked a little about it and its relationship with the points Sterling covered out of band, in an entry at my personal Weblog called [url=http://sob.apotheon.org/?p=647][b]First AL Whitepaper -- Deadline Math[/b][/url]. Basically, that "modular" approach boils down to this: 1. Get specs. 2. Develop an estimate according to those specs. 3. Break it up into phases. BobR's comments earlier up the thread draw surprisingly near to this approach. The first phase, if possible, should be a research and preparation phase, the second a working prototype phase, and the third a minimal working solution. Later phases are expected to include adding the features (or whatever) that makes it "complete" rather than "minimal", if you're optimistic, and a lot of redirection of the project if you're more of a cynic. 4. Estimate each phase separately, with each successive estimate being more imaginary and full of hand-waving than the last because each depends on the results of the previous. You really should not commit to any serious estimates to anything past the minimal solution at all, nor in fact anything past the prototype if you can help it, before you get to the phase in question. There should also be a caveat to the prototype phase to the effect that the research and evaluation phase exists to a significant degree to determine what changes need to be made to all later estimates. 5. Charge per phase, based on an understanding of the hours spent. An hourly rate is actually basically just a case of breaking a project down to a very, very small phase length, with little or no guarantees of time and money budgets. The reason I like my approach more is that the phases are linked to actual productivity milestones -- and in my opinion the best way to make sure everyone's happy is to set some expectations with regard to achievements in the course of a project, to fullfill those expectations, and to provide plenty of opportunity to meet the changing needs of circumstances and even to cancel the halfway through if needed without setting up a situation where anyone on either side will feel screwed over. Even if someone does end up screwed over, that person will only be screwed to a relatively minimal degree, because of the way the project is divided up into parts. The consultant should be getting paid at the end of every phase, so if the client entity fails to live up to its commitments the consultant is at worst cheated out of the time and resources put into the current phase, and if the consultant entity fials to live up to its commitments the client is at worst cheated out of the time given to the consultant on the current phase, since everything that has been paid so far is for something that was completed and is at least valuable for purposes of shopping around for a different consultant to complete the project. Obviously, no plan for something like this is perfect, but I think that approach comes closer than most. Relatively little in the way of whatever resources are important to a given party needs to be irrevocably committed to a risky relationship. Of course, as I said, this is my preference -- but that doesn't mean that's how things work out. Quite often, clients demand either hourly or (more often, in my experience) monolithic project commitments. They might be talked into the idea of turning a large project commitment into a series of smaller project commitments, but they might not. The larger the client organization, the less likely the client is to go along with this approach, I think. You might notice this iterative/modular approach is pretty similar to "Agile Development Methodology". That's not entirely accidental.

Sterling chip Camden
Sterling chip Camden

Thanks for rounding out the factors of a good estimate. Yes, I agree that fixed-price carries risks that should be compensated. That's why you always want to quote breathtakingly high on those, so you don't ever end up taking a loss. I, too, hate the fixed priced contract -- because even if I make out OK, then I feel bad for my client. It's a lot better for everyone to go hourly, IMO.

Sterling chip Camden
Sterling chip Camden

You thought everything was certain, but it wasn't. That's the hardest factor to get right.

Sterling chip Camden
Sterling chip Camden

... that the crew builds their own Uncertainty and Reliability factors into the number they give you, so it all works out. As an independent, my estimates are almost always only for my own work. But back when I was a manager, my experience was similar to yours -- estimates from staff were pretty reliable.

reisen55
reisen55

I am a big supporter of AMERICAN INFORMATION TECHNOLOGY support. I call my own activities OUTSOURCING, AMERICAN STYLE - i.e. no helpdesk in Bangalore. I subscribe to Silicon India, an IT board from the land of cheaper, faster, better. This is a real question and following are real answers. so if you clients complain - there is always the land of FAR WORSE. ***** ?I have install McAfee Anti virus in my system.After Installing McAfee, no one application is opening. And always showing run.dll file is missing. After that I removed the McAfee. But still the applications are not opening. And the same problem is showing(run.dll is missing. why its happening? Any idea!? That is her question, cut and paste. Wonderful language. Here are some of the tech answers that came back. Read these and weep. American IT is being replaced by this level of incompetence. **** Quotes ***** Run System restore with the date tentitively before this problem started and then install A/v. It is best to format the system after taking backup of data and install your a/v. U HAVE TOUGH TIMES I ALSO FACE SUCH PROBLEMS AND GENERALY CALLS OME COMPUTER GUY hi.......... to solve ur problem u must repair your window with window cd Ur dll files were infected with virus and have been corrpoted/deleted. Replace the missing/corrupted dll files or repair OS by using f8 feature Hi. ur run.dll file has been curuupted ! just repaire ur pc with ur os !! u may copy this same file to windows directory !! it will be resolved !! Hi.Some files will not copy from another pc. better u can repair with oprationg system (like XP)cd. Go to Console mode during boot with F8 option. Get a copy of the run.dll from another working PC (with same OS), typically located at C:\Windows\System and copy it to your PC in the console mode. you should have to see computer master think ur computer having virus & the run.dll file is deleted.So plz. repair ur window or New installation.

BobR
BobR

(echo) by the hour is the way to go (echo) I generally do not work for a fixed price, especially if there are unknowns. Even for non-binding estimates, I like to work on a phase basis: I ask the client to approve X number of hours for analysis & design, specifically to address the unknowns. The only guaranteed deliverable for this initial work is the results of my research. I may need to ask for additional hours to make sure I 'have my arms around' the entire project. Sometimes during this phase I determine that the project is not viable. When I have worked through the unknowns, or if there are no major unknowns, experience guides me to a fairly accurate estimate, and at this point I am willing to do fixed price. My formula is to take what I optimistically think it will take, then multiply by 2.2. (Double it and add ten percent.) I have used this formula for over 25 years and it has guided me well. Past reliability gets factored in subconsciously in coming up with the original optimistic number. Additional note: When working on the project, I shoot for my original optimistic guess. Projects always take longer than we expect, and if I shoot for the number I gave the client, I will probably go over it. By shooting for my original optimistic number, I always go over, but generally come in at or just under the estimate I gave the client. Bob

Bizzo
Bizzo

But using G, R, U doesn't work. I keep getting a "divide by zero" error. Am I that unreliable? :D

ssharkins
ssharkins

Chip, well... I never knew about G, R, and U, and that would explain a lot! First, I did my best to be accurate -- big mistake. Then, a colleague told me to take my best guess and triple it -- still didn't work. You know, if you get something done too quickly, they don't like that either. My final solution, that seems to work, is to say something like, "...normally, it should take about 3 weeks, so let's plan on a year..." They laugh, I laugh... I work by the hour now. I haven't take a "by the project" payment in years. I simply can't afford to -- you end up spending too much time explaining why "that'll be extra..." I charge by the hour, supply regular updates, and if I'm not moving fast enough or they don't like what they're seeing, they're free to hire someone else -- it's in my contract -- nobody's obligated... seems harsh, but it works for me.

apotheon
apotheon

Buzzwords shouldn't be presented in passive voice. They'll never catch on. Try "Invade Russia" instead of "Invasion of Russia". That might actually play in Peoria.

jmgarvin
jmgarvin

A few times, even with good communication, do I hit the users and then get socked with various processes I knew nothing about until that moment. It seems the managers weren't actually communicating with the users...you know...finding out what they actually need. So the managers scape goat the consultant and it's starting all over.

Sterling chip Camden
Sterling chip Camden

... that fixed-price contracting only works well for very low values of U. My consulting work is often research-based for a large portion of the project, so my U factor is very high. It would be completely unrealistic to base my compensation on my initial estimate -- chances are, either I or my client will get screwed. On the other hand, if your work has a relatively low U value, then your estimates will be more accurate and a fixed price may provide more security for both sides. But I'm suspicious of any work that is completely predictable. There should be software to do that.

reisen55
reisen55

The unknown, whatever it is, is always a tough one. When it comes to workstations, I will play games there when I have to. But on SERVER SUPPORT, I am firm and solid. First off I have not had to really work with any modifications of it in over 2 years. Monthly shutdowns, patches, etc. Nice. So when I had to charge 2 hours for that, I was firm - SERVER WORK IS DIFFERENT. AND the Disaster Recovery benefit was of immense value. That I did not charge for because a disaster recovery colleague of mine, Harvey Betan - google his name - asked me if I could GHOST a Windows server? I had the right tools and opportunity to test that idea and it worked great. As far as I can see, my client received one substantial value on this one.

Gate keeper
Gate keeper

.. as a matter of fact neither does IT .. so I don't get what you mean by 'American IT'.

Sterling chip Camden
Sterling chip Camden

"corrpoted" -- a self-referential verb! "oprationg system" -- is that the system that Oprah recommends?

Sterling chip Camden
Sterling chip Camden

1. Get the client to sign off on a research phase. That can definitely bring your U value down. 2. Shoot for your best estimate, instead of the one you give the client. You are so right that if you take the latter as your schedule, you'll overshoot it.

Sterling chip Camden
Sterling chip Camden

So, your projects required an infinite number of hours, or your G value was zero?

Sterling chip Camden
Sterling chip Camden

But on reconsideration, I think geology is more to the point. The deeper you're buried, the more pressure you're under.

road-dog
road-dog

Time + material is the way to go. If the customer wants a day/hour/minute/second estimate of time on most projects, they really don't have their mind around the environment and all of the variables in play. A time estimate does nothing for the consultant but can work against him big time. T+M also makes them pay for scope creep and when they come dependent on for something aside from your chartered activities. It's easy to say to the customer that standard rates apply. Short negotiation, yes/no.

Sterling chip Camden
Sterling chip Camden

Well, Susan -- you probably haven't heard of G, R, and U before because I invented them -- and this is the first time I've shared these ideas on a public site. Hourly is the way to go, because scope creep just means more money. I have agreed to the occasional fixed-price project, but only when the scope is so well- defined that any add-ons are obviously not part of the original agreement. I always word those agreements such that it's understood that any add-ons will be billed at an hourly rate or through a separate agreement. And I still avoid them like the plague, because my estimating still sucks.

Sterling chip Camden
Sterling chip Camden

It stands for "Pointy-Haired Boss", like the one in the Dilbert comic strip. The meaning has been generalized to include anyone in management who has no clue.

PMPsicle
PMPsicle

What is a PHB? Anything like a BDU?

Sterling chip Camden
Sterling chip Camden

... can't be all bad. Unless he thinks that Operation Barbarossa was actually a good idea but failed because they didn't follow "best practices" in the implementation.

apotheon
apotheon

What if the PHB is the only one that gets it?

Jaqui
Jaqui

but I bet you are right and most will miss the reference.

reisen55
reisen55

The analogy about invading Russia holds very true. You start out with a single task and after four months realize you have put far more resources into the work than you will EVER get out of it or, worse, can EVER invoice the client for. My daughter had a Toyota Tercel with something that went to hell in the transmission. Took it to Toyota and they quoted $450 to fix it. Nope, did not do that and since we agreed on a quote, that was the number. Their service manager turned into an alchoholic and the manager of the entire dealership became engaged - FIX THE DAMN CAR NOW. Well, it was a small fault somewhere the cascaded down through the entire transmission. They never told me the hours they had to put into this car. Same story, just different subject.

Sterling chip Camden
Sterling chip Camden

though I couldn't be certain that you were joking. The rest of your story makes me want to cry tears of sympathy. Been there.

Sterling chip Camden
Sterling chip Camden

Something like producing an RSS feed is very well defined. The hardest part of the problem is where to get the content -- the format is standardized. My projects tend to be more along the lines of "step 1: achieve something that's not supported by any vendor and as far as we know has never been done before." By the time I'm done researching and prototyping it, I'm virtually finished -- but there was no way for me to accurately estimate how long that phase would take.

apotheon
apotheon

If you pay close attention, you might notice that my description of my ideal pay schedule basically involves cutting it into small enough chunks that you can accurately set a price for the next chunk [b]without[/b] having to cut the size of the chunk down to the point where you can't promise anything discrete is getting done. Sure, if you are working on a complete content management system, you might have a difficult time estimating the total time and effort that goes into it. If you cut it into small enough parts, though, you should be able to at least accurately estimate the time and effort that goes into the next part you'll complete -- e.g., the RSS feed generator for the CMS (if that's the part you're doing next). You can then say "I'll have the RSS feed generator done in two weeks at the outside. It will probably be done in one week. The total cost for that component is $foo. At that time, we'll assess the next step and determine the time and effort investment for the next part of the project, and we'll be able to figure out how much that'll cost you. Once the RSS feed generator is finished, you'll have one more discrete chunk of functionality, so you won't be left holding the bag for an entire CMS development project that's completely useless to you if I run off to Boca halfway through, and if you refuse to pay me for the RSS feed generator I'll still have the money you gave me for everything else I have already completed."

Tig2
Tig2

This has gone far enough! I can't take this kind of PUNishment on only a couple of cups of coffee!

Sterling chip Camden
Sterling chip Camden

The "et" must have been sheared off. But don't worry, it isn't much of a fault.

ssharkins
ssharkins

I did mean rocket science and I didn't even notice until now that I didn't write rocket -- I don't know how that happened! :)