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.

Four Critical Components in Successful Project Implementations

As most project managers know, having solely a project plan does not guarantee project success. We can fill entire buildings with project plans that are associated with failed projects.

I have found in my experience that there are generally Four Critical Components that a project manager must consider when implementing programs or projects to assess the probability of success for his project.

1. Senior Management Support - this is a key ingredient to success. The project must have full senior management support and this does not mean just financially, but that helps of course, but senior management must believe in the output and must advocate for it to the general business community. This is where excellent stakeholder management skills come into play. A project manager must understand what BUSINESS KPIs are important to senior management, how the project supports those and what is the ONE PROJECT KPI that senior management will protect in times of crisis - cost, schedule, quality, scope?

2. A Solid Strategy - Thee project must tie up to an overall business strategy that can span multiple years and it must be an important part of that strategy. The strategy must be concrete (not just a vague vision), comprehensive, sustainable and drives significant incremental value to the company or client. If the project feels more like an off activity then it probably is a rogue project and we all know that at crunch time - nice to have projects are no match to critical to do projects.

3. An Enabled Talent Pool - we all know this - even the best project plans out there will not bring any benefit to the company and the project if the people leading and executing the plans are not properly enabled and/or not the caliber required by the project. Don't be deceived by some people saying that project managers are generalists - the best project managers I have seen are actually specialists. Not to say that they can't run general projects but they excel in their chosen fields. The project team members must also complement one another, know their roles and must be properly resourced to execute their jobs. The most mature team are those that understand that individual superheroes do more damage than good to a team and at the end of the day - it is the entire project team - working as one - that can deliver successful projects.

4. A Consistent and Appropriate Set of Tools and Processes - from process definition, handovers and even documentation requirements - all of these must be consistent and appropriate for the project being undertaken. A good PM will know the different process and tools (like those from the PMBOK) - a great PM will know which processes and tools will be most effective in the project. Discuss early on in the project what processes will the team follow, who will do what at every task (RACI), what documents will be required at what phase and what tools will be used to create and share project assets across team members. Regularly assess as well how the tools and processes are helping the project and be open to changing them if need be.

Finding the Balance between the High Level and the Devil

It is amazing that a lot of projects get derailed because new details are found late in the project and some of these projects even become un-recoverable but sponsors still avoid discussing details during the initial phases of the project.

Understandably, at the early stages of the project, not much is known about the deliverables but sponsors and project managers must consciously allocate time early on to talk about potential risks and not put those discussions on the parking lot with the hope that eventually people lower than the managers will think about it.

Sponsors and Project Managers always say that "the devil is in the details" but let the devil remain uncontrolled. Control the devil - or at least identify the worst case scenarios - early on and the probability of project success increases.

The key is finding balance between defining deliverables and identifying critical risks that might derail the project.

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.

Gray Areas are Wonderful Places

As people rise up the ranks in management, there comes a time that they learn a very important lesson - management exists to live in the gray and to provide direction for the rest of the team to follow.

Managing gray is really a very dangerous activity -> if you lean toward one end more often than is perceived as required will bring you negative reviews. An example of a gray area is "the desire to service your customers" vs "the capacity to realistically deliver everything they ask for" or the gray area on " I believe in this employee and will give him a second chance" vs "I am sacrificing my company's interest by keeping him" or a simpler gray area that matches speed vs thoroughness. Work too fast on a project and you can be called reckless, work too thorough and you can be labeled as slow.

The key to successfully managing the gray is developing the ability to develop the sense to know, case by case, where you would lean into - to truly understand where the benefit will really lie and be wise in deciding and communicating the basis for the decision and what it means tactically to your team. There is no "one size fits all" nor a "silver bullet"

Few people understand the gray areas and fewer still write about it but there is a book that writes about it that I found enlightening in this discussion - >Managing the Gray Areas.

The thing is - we also quickly realize that the higher we go up the ranks, the bigger the gray areas become - eg "should I keep the model of this company being its new CEO and be reviewed as risk-averse" or "I should change the model of this company as its new CEO so I will be reviewed as revolutionary and out-of-the-box" thinker.

Bottom line - if you can't swim in the gray area and if you can't grow it - it will quickly show - not only through your output but also in the belief your team has for you...manage it will and it will be the only place you want to be.