How to Deliver a Successful Project – Part 3 – Accurate Estimates, Quoting and Proposals

Posted in: Blog, Methodologies, Project Delivery | Jan 12, 2013 at 12:03 PM

No comments

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

ESTIMATION AND QUOTATION

First of all, as part of this article: DOWNLOAD Proposal an Quote Document Template FOR FREE!

Now that we have documented the business requirements, the next step is to produce an estimate or quote or as I would like to call it: a proposal. In the proposal is where you document the effort required to deliver the deliverables documented in the business requirements.

This part of the project is probably the most difficult one to produce because there are so many variables that we need to think of. First of all we need to determine how many people will be required to do the project and that is not including the “personal” variables ie. what if the person is suddenly sick or having personal issues, etc.

Therefore, in this article I would like to mention few tricks and suggestions to produce an accurate estimate. This trick has worked pretty well for me.

The steps that I normally take to produce an estimate:

1. Determine who will be doing the project

Now that you have identified the deliverables and the tasks within the project, you can then choose the appropriate resource (ie. the personnel). For example: in the web development scenario normally we have someone does the HTML design and the developer doing the actual coding.

2. Sit down with the resource to discuss the effort required

Do NOT determine the hours yourself from your past experience if you are not the one doing the work! This is very important! I have dealt with many project managers that just decide the hours himself while I am the one doing the work. Just because he has managed a similar project in the past does not mean that he can quote the same amount of effort for the current one. Every project is different and we need to sit down with the actual person doing it to properly determine the effort required.

Identify the effort in hours. From hours you can then translate into days, months, etc. My base currency for effort is always in hours. This way it doesn’t matter who do the work and how many resources are required in the project, what matters is the total hours quoted. As long as at the end you don’t go over, you’re good!

Get your resources to quote the effort to do the work only excluding testing and documentation (ie. the variables). If you are doing a non-IT projects get them to quote on doing the actual work without any other variables. We will properly calculate the other variables later.

3. Identify variables in percentage

Now we are identifying the variables. In IT the variables are things like documentation and testing. In other fields I’m sure you have other different type of variables. Add these variables in percentage based on your experience.

With software development I always add 20% testing and 10% documentation. What this translates to is this:

If a project takes a total of 200 hours to complete (effort only – see point 2), testing will be 40 hours and documentation will be 20 hours on top of the 200 hours. Therefore, total estimate is: 260 hours. This has always worked very well for me.

If you are leading a non-IT projects, identify the variables in percentage then add the hours into your estimate.

4. Add project management time in percentage

Project management time is stuff like entering weekly timesheets, writing weekly project status reports and attending meetings.

I normally add 10% of the total effort hours.

5. Always add contingency – again in percentage

We always have to count for “the unexpected” and the “what if-s”. In IT this is a common case: security issue. Server on the DMZ can’t talk to the internal server. A domain trust has to be put in place. You are on site and you face this roadblock. What are you going to do? Without contingency you will eat up your project time.

I’m sure with other type of projects – from time to time – you will face the unexpected. This is where contingency time comes handy.

For me I always add 10% contingency into the estimate. So for a 200-hour project, the contingency is 20 hours.

6. Add other well-known costs such as software licenses, materials cost, etc

Then add the rest of the costs that are “well-known”. What I mean by well known is, it is easy to identify. Things like software license or material cost is easy to identify.

Put a terms and conditions that materials cost is subject to economy inflation.

CONCLUSION

So that’s my method to do a proper estimate. It has always worked 99% of the time. It’s not 100% because we don’t live in a perfect world.

Just to re-iterate, for a general IT project I will do the following:
– Effort required (in hours);
– Add 20% testing (internal testing and NOT UAT. UAT is normally a process that is done by the client hence outside your project hours);
– Add 10% project management;
– Add 10% documentation (may not be required, depending on the client. As a best practice you have to always offer documentation);
– Add 10% contingency.

For example:
A 200-hour project will be put as 300 hours in my estimate.

Then from that total hours you can then create a project plan which you break down the project into tasks and assigning resource to each task so everyone knows who is doing what and when each task is due.

No Comments Yet.