Software projects can be difficult to estimate. That's a pain point for everybody involved when you can't predict the future at work given that proper budgeting is so critical to judging a project's success or failure.

I've been working in software for 25 years and making project bids and estimates for 20 years. I believe that estimates are just as likely to be incorrect on our small $3000 projects as the multi-million dollar enterprises I've been leading. Strangely enough in "computer science", my experience has been that there is a lot of art, feel or instinct involved with making an accurate estimate. It's actually the area where I think my years of experience pay off most.

I'm writing this article with the assumption that the prime objective of estimates and proposals for all parties is accuracy. It helps the client and the contracted party meet budgets and if the accepted estimate turns out to be correct then truly, everybody wins. I'm not dealing with or dignifying here the concept that a proposal is an opportunity to fool people or take folks for a ride at the negotiating table. It's not a good way to live and on a practical matter that approach won't keep you in business for very long.

Here I'll attempt to cover what I consider to be the main aspects of software project estimating, with specific thoughts for people on the client side of how each tenet applies to the.


Who Should Do The Estimating

Sometimes estimates are put together by one person, sometime a team of coordinating companies, contractors and project managers (as is happening with us on a large software bid here this week).

But one thing is for certain: The head of the team that would be doing the work should be estimating the time of completion. Project managers are terrific and will hugely shape a correct proposal. But nobody else comes close to knowing what tasks will take as much as the project lead.

Note To Client: If you're not hearing any specific questions back on your RFP from somebody on the technical side, I can tell you this is a bad sign.


Details

This is a little similar to the previous item. As is also the case with the language in any contract, the more detailed and specific about potential scenarios a proposal document is, the more successful the project will be.

Our little company has beaten out Autodesk for jobs simply because we asked questions to get things right in the proposal stage. As the saying goes, "A goal without a plan is just a wish".

Note To Client: It's understandable that you don't necessarily know everything you should be listing in your RFP. But if a bidder's response is basically a price and an attitude of "sure, no problem" - I urge you to think twice, even if (or especially if) they are the lowest bidder.


Avoid Wishful Thinking

Wishful thinking in estimates are a recipe for cost and schedule overruns. That's not good for anybody. It can happen on the request side and also the bidding side.

Prompts like "we're really like this to come in under $80,000" are a terrible idea. That tempts the bidder to make the price $78,000 even if it's a $200k job. Then you probably know what happens eventually: cost overruns, it ended up failing and/or costing the $200k anyway. The execs at the hiring company are unhappy, as are their customers. Everybody loses.

And when responding to an RFP, software companies can surely strategize on how to cut come costs or justify a little less money to land the job. But you're doing everybody a disservice if your estimate is based on the scenario of what happens if everything goes great with no surprises. Don't.

Note To Client: You think you're a here to your bosses by getting a low bid and pouncing on it. I can tell you from experience, 9 times out of 10, it doesn't work out that way.


Actual Hours, Price And Schedule For Estimate

Stage 1 is to figure out what you think it should take if everything goes as smoothly as possible. That's your baseline. I can tell you it's never gonna happen that way. There are so many innocuous and non-incompetent reasons for why things can go slightly off the rails: Key personnel get sick or get pulled to other projects, approvals and testing can't get done in a timely manner, the client very understandably doesn't know what they're asking for, once deeper in the project new ideas will result in major change requests, poorly defined scope or requirements, etc.

But if you use historical estimates of past work on similar jobs, that's a great start. Failing that, just take your best guess and live with the consequences.

Another important reminder here is to consider all of the aspects of the project, not just the coding. Figure the time to gather requirements, admin/project time, documentation, training, travel.

Note To Client: This isn't the full price, we'll get to that. Just keep in mind that if you're asking for something uncommon or brand new, the bidder is not necessarily going to know if a feature takes 8 hours or 48 hours. Hopefully they are experienced and can narrow that range down, but computer science is not always a science.


Algorithm For The Real Estimate

Here's where the rubber meets the road. Let's say I think a project "should" take 100 hours. Add 20-30% on top of that immediately. Again, this isn't to become a profiteer or to rip off the client. It's just that so many different things can happen that cause delays (listed in previous section) you've got to allow for them. Make that 100 hours into 125 hours in your time and budget estimates.

Then, there's another consideration. What if part of the project involves things you and your team have little or no experience with? What if you're adapting an existing codestream that's in Python and moving to PHP and you have limited Python experience? It's time to make that 20-30% bump up guess to more like 40-50%. Trust me, I'm sadly correct about those numbers. Also, new areas of code mean that you do not have a library of functions that you can recycle or repurpose for this project.

One last complicating factor. Is there confusion on the client side? Let's say in your initial questions to clarify the RFP you're hearing back from six different people giving you three different answers. Your spidey senses should be telling you that it's going to be difficult to get clear, agreed-upon answers over the life of the project. Bump it up by another 10-15%.

Note To Client: This is not a negative reflection of you the client, but to paraphrase Donald Rumsfeld, there are a lot of "unknown unknowns" in a project. Any good estimate is going to build in wiggle room for them.


Don’t Break Up Your Costs By Section

For your project let's say you've identified five major sections of work. You'll use each section to build your guesses of hours and come up with your totals - lets say five different sections of 10 hours, 15 hours, 15 hours, 30 hours and 40 hours. DO NOT put separate price tags of $2000, $3000, $3000, $6000 and $8000 in the proposal.

These numbers just get in the client's head. The person responsible for the RFP feels like they're doing due diligence by picking this apart.

Yes, one or two of these sections might not take that much time, but it's a good thing because they're make up for the other sections that are running long.

Note To Client: Read that previous paragraph again. Don't question one aspect too hard. On-the-nose estimating is difficult (or impossible). But on a sensibly-priced bid, the various ups and downs will all come out in the wash and equal out on most projects. I've seen it all the time.


Don’t Give Away The Farm In The RFP

I think everybody who has bid on a lot of jobs and projects has had this happen at least once and it changes your whole attitude of how much detail you put in a bid.

The more detailed the project and RFPs are, the more it seems like the details or explanations about the planned project architecture or methods should be in there. This kind of thing can and should be in the contractor's internal planning and documents, but don't let them anywhere near the actual proposal. To do so maybe be giving away a critical idea that saves 100 or even 1000 man hours of work to the potential client, who can take those ideas from you and help them use the other cheaper bidder to finish the work.

Honestly, this has happened to us at Plannedscape with a power company. It's a tough one to get over.

Note To Client: Try to keep this in mind when reading a proposal, think of it from the contractor's perspective. RFPs are free and on the contractor's dime. If you haven't paid them anything and have no contract for you to pay them anything, understand that you don't own this work yet.