How to Estimate Project Cost High Level

Sooner or later, we will alll need to estimate costs and though there is an entire science on this subject and it can fill many books - sometimes you just need a "high level" number or a "ballpark figure" just to assess whether a project will be cost prohibitive or not to do.

I just want to share with you what my "rule of thumb" process when estimating technology project costs and I hope it helps you now and in the future. I found that the numbers I get from this process are within 10-18% of where the science will take me - enough to drive a decision on whether to proceed with the project or not.

My Definitions:

• Base Estimate - Ideal Estimate assuming all things go right
• Base Budget - the internal budget we use to actually move the project forward
• Planning Budget - the budget we use for planning and budget requests 

Calculations:

1. Base Estimate = summation of all the resource costs you need for the project (eg Labor, Hardware, Software Licenses, Conference and Travel, Support and Sustain costs, Implementation and Training Costs)

2.Base Budget = Base Estimate + Impact of Known Risks (see below how to estimate)

3.Planning Budget = Base Budget * Unknown Risks/Contingency Factor (see below for rule of thumb)

How to estimate the Known Risks

1.Analyze the risks you identified and determine which are related or dependent to each other (if one risk happens - the other will happen too) and classify them into risk groups

2. For each risk group identified - estimate the dollars it would take to recover the proejct or the business if the risk happens * probability of it happening (there is a more accurate way that includes impact - talk to me if interested) . Note - if the probability is > 50% - then it is an issue, not a risk.

Sum the resulting dollars

  

How to estimate the Unknown Risk Factors/Contingency Factor - this is more a gut feeling based on experience or parametric analysis of historical projects

If your gut or experience is telling you that

1.There is a low probability of unknowns - add 5-10%

2.There is a medium probability of unknown - add 10-15%

3. There is a major probability of unknown - add 15-20%

 Sum your numbers.

Projects Must Align with Corporate Priorities

In the everyday hustle and bustle of user communications and the desire to serve by managing the low hanging fruits as fast as possible, project management teams are most likely to miss out on a critical aspect of a project - is it really needed by the corporation?

Most of the projects I have seen are more responses to the short term pains of a few groups of people rather than an answer to an over-arching need of the company. Most of these pains are mere symptoms of the root problem rather than the problem itself and thus there are several project teams that deliver what we call "band-aid" solutions rather than long-term pain relief.

There are some questions that help determine where the project request is truly rooted on and what need does it truly answer and some of them appear below. In several cases, just asking the project sponsor a few of these questions can get people collaborating more across peers or having them re-think their original requests.

1. Priority -> How does this project tie-up to the corporate priorities(sometimes call the CEO agenda, the company mission,etc)?

2. Cost/Benefit - > What will the company gain if we do this project? Don't forget to ask as well what will the company lose if we don't do the project? The more specific the answer - the better. It is, for example, better if the sponsor can tie it to profit growth or profit loss or if the user can tie-it to a specific business process problem that the project will address.

3. Project interactions -> Does this project tie-up with any existing or planned projects that the company is already undertaking?

4. Resources -> To what extent will the company support the resource requirements of the project?

It would be an eye-opener if our executives realize how many projects failed (and costed the company money) because the questions above were not asked(or answered) early on.

The Project Management Circus: Act 1 - The Tightrope Walker

I have heard several people in my career say that project management is easy - just give someone a project, resources and a goal and all he has to do is create a plan and monitor it to completion.

This is similar to what I hear from my co-spectators when I see a circus.

Truly, Project Management can be like a circus - in more ways than one and the performers are the project managers.

Take the tightrope walker as an example. What does he need to do anyway? He only needs to walk from end to end - how difficult could that be? Let see...

A tightrope walker, like a project manager, to succeed in his endeavor, would need to

a)know first where is his starting point - including information about how high he is from the ground, is there a net below him, how strong is the post he will stand on before he begis the walk, what is the length of his balancing pole,  how hot the spotlights can be, etc... - much like project initiation

b) know where his end point is and what is the definition of success (eg making it to the other side alive maybe in 5 minutes), what resources does he has to reach the other point (eg does he have a pole to hold on to and use as a balance), how many steps would he most likely need to take and how much can he trust his resources(eg his rope quality, his pole quality or the net quality if he falls). At the same time, he must know the pace he needs to take and how to take the steps - much like planning, contingency allocation and resourcing

c) know how to traverse the rope and keep his balance ensuring that he checks at each step whether he is on the right track or not. He must also know what to do when something goes wrong along the way(eg an ant is biting his armpit - sometimes called management pressure - or when his rope starts to shake because of a sudden wind gust - sometimes called sponsor wind) - much like project monitoring and control

d) know what to do when he gets to the end - if he gets to the end - including putting the pole down first (let go of resources), ensuring both his feet are really on the other end and raising his arms and waving to his adoring crowd - much like project closure and team celebrations.

Easy you say? Maybe...up until you are truly the one walking the rope.

Estimating Project Costs based on One-liner Scope Statements

A lot of project managers typically encounter situations wherein they are asked to give a high level estimate of cost and schedule for certain projects during the initiation process - much too early to have the detailed requirements that most PMs would need to give an accurate estimate. Some companies go through this exercise to plan for next year's budget.

In my experience, these numbers are typically used for planning purposes or initial feasibility assessments and the following formula has shown great success in this exercise so far for the software development projects that I lead.

1. Base project costs which include labor (direct and indirect), hardware costs(whether purchased or leased), software licenses, separated by capitalizable costs and expensed costs which may differ based on your company policy +

2. Risk Costs (which is the amount required to recover the project and only for those risks with a 25-50% probability of happening that is identified as risks that are still recoverable - anything more than that is not a risk - it is an issue!). This risks reduce/increase as the project develops. The total of 1 and 2 is then multiplied by

3. A factor as contingency (which is dependent on how much you know of the project at the point of estimation although I typically use the following: 30 - 40% for one-liner scope statements and more if less is known and 20-30% for more developed requirements). This contingency reduces as the project develops. The new total is then multiplied by

4. A factor for management contingency and the factor that typically works for me is 10%

Some things to remember:
1. Labor rates may vary but you can use a blend rate for estimation purposes
2. Labor rates may increase/decrease over the time of the project so blend with this in mind
3. Ongoing Support and Maintenance Costs considerations including depreciation for the capitalizable items