What does your estimation process look like today? Let me guess, you get a call or an email from a client you’ve been working with or talking to for a while. This is it, after all those calls and emails, they are finally ready to receive a proposal or a quote from you. They may even want to go full steam ahead and receive a statement of work. This is great, your excited, this could be a big client! Now what; what are you going to send this client?

The Current Landscape

In today’s day and age, it’s all about optimization, efficiency, and eliminating meaningless tasks. We live in a world where technology is all around us, yet we sometimes still use technology in ways that create more work. Let’s face it, we love our spreadsheets. For some, it gives them a sense of value by being able to “build something”. Look at the “program” I practically wrote using this 10-tab spreadsheet riddled with complex VLOOKUP operations!

Let me break it to you, people using your spreadsheet hate it. It’s terrible to look at, not intuitive, and way too complex for anyone to want to spend longer than 30 seconds trying to understand it. That said, it still kinda works. You can still put together some rough numbers, and provide you the client with a quote, which I suppose is the important part.

But is it accurate?

Okay fine, the spreadsheet works. Clients are so used to seeing tables in their proposal documents, that it’s become the norm. But what about the content? How did you come up with those numbers? Often times, it’s a SWAG (scientific wild ass guess). You or the person putting together the proposal has just enough information to put together some rough numbers based on very loosely defined features and concepts that your client requested. So how can you possibly provide an accurate estimate? The fact is, it’s likely an inaccurate estimate but everyone tends to expect it.

Decompose, Analyze, Plan

Technical development teams can be very good at estimating when they follow a strict methodology, they ask questions when they are unsure, and they accept the fact that humans are not very good at estimating.

Here’s a brief overview of how they do it:

Decompose

• Start by breaking the scope estimate into workable pieces, chunks, components, whatever the case may be. Create buckets that will allow you to group tasks.

Analyze

• Look at each bucket, analyze the requirements, and come up with a high-level plan of attack or approach.
• Start listing high-level tasks required to complete the functionality requested.
• Write down all the related tasks required to implement the desired functionality.

Plan

• Add a description to every task explaining your approach.
• Describe the final result, and set the expectation.
• Define your definition of done.
• Assumptions can make an ass-of-u-and-me, except if you document them and make them clear to everyone.

Bottom Line

There are plenty of project estimation methodologies; pick one and get comfortable using it. Once you are comfortable with using a methodology, start looking at ways to automate or formalize your approach. If you are looking for a tool to help you automate, you may want to consider Scope-R!