Every project manager dreads the day when he or she has to make the long walk to the executive sponsor’s office to ask for more money. Unforeseen delays, scope changes and excessive consulting costs are often cited as reasons for the increase, and shallow excuses that these costs could not be divined when the project’s budget was originally developed abound.

Legitimate or not, these costs are frequently approved. What’s another 5% to preserve the millions already invested? What becomes unjustifiable is when these budget increases become a recurring ritual, and project costs and timelines double or triple over original estimates. Even more shocking is that justifications are often based on “fuzzy math,” with elusive “man day” estimates and the like serving as justification.

Many executives and project managers have some vague idea of a project’s burn rate, which boils down to a calculation of the cost to run the project for a given period of time. What is lacking in this figure is usually a comprehensive analysis that provides burn rate information down to a granular level, providing the cost side of a cost-benefit analysis. It’s easy to take consulting costs for the last month, divide by working days and produce a burn rate, but to use burn rate as a legitimate project management tool requires a more complex model.

At a minimum, burn rate analysis should include the following:

    * Consulting and contractor cost calculations on a per-team or functional area basis. Consulting costs can vary widely based on a particular skill set or area of expertise, so a “universal average” simply does not cut it. This figure should be based on the smallest unit of measure tracked in your project plan, generally a daily or weekly average. Be sure to include any additional costs that may be incurred through overtime work.
    * Cost for salaried employees working on the project. All too often, these resources are considered “freebees” as the project does not write a check each month to an outside vendor. However, pulling fulltime resources onto a project incurs replacement costs to fill their former position which should be included in a burn rate calculation.
    * Travel expenses for both contractors and fulltime employees may generally be calculated based on a project average. More sophisticated analysis can track these costs on a per-team basis, and include additional adjustments for working weekends or schedule changes that might incur additional travel costs.
    * Facilities costs such as additional real-estate, workspace setup and technology requirements should be factored into the burn rate on a per-person basis. I’ve visited projects where spiraling resource requirements have necessitated renting modular office space, or constructing new facilities in old warehouses, etc. All significant costs not properly accounted for in burn rate analysis.

After gathering the required information to cover the basic points above, a model can be built for the entire project, tying costs to headcount on a daily or weekly basis. With this model a new financial urgency can be injected into a project. If a key manager makes a decision that extends the project by one week, no longer is there some vague understanding of what that decision will cost. With a through burn rate analysis, an accurate price tag can be placed on any decision that will affect a project’s timeline. With accurate costs known in advance, executives and project managers can focus on determining what benefit will be derived from a scope or timeline decision with full knowledge of the financial repercussions of that decision.

Patrick Gray is the owner of Prevoyance Group, a consulting company dedicated to helping companies ensure their large IT projects deliver organizational value on time and on budget. For a limited time, sign up for Foresight, the Prevoyance Group monthly newsletter and receive for FREE “7 Deadly Sins of IT Implementations” eBook. Please visit http://www.prevoyancegroup.com/whitepaper to sign up for this offer.

Article Source: http://EzineArticles.com/?expert=Patrick_Gray