Creating and Managing a Workable Project Budget

There is no question that project success is hard to achieve. One of the most significant factors in making or breaking a project is a workable project budget. A global survey of project managers found that only 57% of all projects were completed without additional funding, while 38% of projects were deemed to have failed due to inaccurate cost estimates.

Enough to make a newbie or would-be project manager go run and hide under a rock, right?

There are usually three key ingredients to project success in most stakeholder's books: on-time delivery, meeting the project budget and project customer satisfaction. So what we are discussing here is a major factor in project success. From my experience, most stakeholders find a 10% budget overrun generally acceptable. Plus, it's way easier to correct a 10% overrun than a 50% budget overage.

The key is to always know where the project financials stand and you do that by reviewing, revising and re-forecasting weekly. Let's go through 5 key practices to creating and managing a workable project budget.

Reviewing the project pricing and initial high-level project schedule

When creating the budget from the start of the project, you're going to want to start with whatever the salesperson or account manager left off with. Because that is where the project price came from. Some time and thought and effort has gone into coming up with at least a high-level list of requirements, schedule, resource plan, budget, and price and it's going to be your best jumping off point as the project manager. No reason to start over from scratch, as that would only serve to frustrate a project customer who is anxious to get started.

Revising the schedule with real resources and understanding the resource effort load

You may not have a real or full team assigned yet, but you can go back and assess the draft info from sales and derive your resource plan for the project based on what they put together, any statement of work (SOW) you may have, assumptions that were documented, and the draft project schedule and high-level tasks that were put together.

Converting the resource plan into project dollars

Next it's time to put those thoughts, draft numbers and historical numbers to use.

Let’s look at a working example on a technical project where you have a Functional Design Document (FDD) to put together.

You know that usually takes 60 hours of a Business Analyst and 40 hours of a Technical Lead to put together and produce the FDD, plus another 20 hours for team member peer review and 4 hours for customer discussion. If you don’t know this from experience, look at data from past projects, or ask for estimates from those involved.

Based on that information, you know the roles required and can estimate the prices to plug in. Using the figures above, you'll probably come up with a price of around $20,000+ at the going rates on projects for those positions.

You'll probably have a fairly similar price in place for a Technical Design Document (TDD) that the dev resources will actually build a tech solution from. You continue doing that until you've built a fairly reasonable and complete resource plan and thus, have a fairly reasonable and complete starting project budget.

What if it differs greatly from the price? You hope it doesn't but it might. You may have worked up to $1,130,000 worth of effort and the project that was sold was for a price of $750,000. Now you have a problem.

Ideally, and in most situations on a tech project, the customer is giving an estimate and possibly a “not to exceed” price but sold as a time and materials project. That's best case, but still you have to explain how a potential 51% higher price (($1,130,000 - $750,000) / $750,000) to the project client and help them up off the floor.

I’ve used an example of a technical project here, but this applies to any type of project. If you can be as thorough as possible when mapping things out at this stage, it will be hugely beneficial for you down the line.

Maintaining the budget and forecast on an ongoing basis

Next, the ever important process of maintaining, reviewing and revising the project budget forecast every week. You can put it together and leave it, but that is a definite recipe for disaster.

Make connections in accounting, do whatever you do to have quick and easy access to weekly project charging and financial information and plug those into whatever tool you are using as your project financials and project resource forecasting worksheet.

I often use the self-built spreadsheet template pictured below to keep track of the budget and log the hours and cost per week.

Making sure your team is charging accurately to the project

First, let's go by the assumption that we are working in a matrix environment where project resources are requested and borrowed on a project by project basis, and that these resources don't officially work for the project managers but rather for department managers (like application development managers for the technical development resources).

Every resource wants to appear to be 100% - 120% productive for work and performance review purposes. Every department manager who manages these resources wants the same thing. What does that mean? That means that you – as the project manager – know that each resource is planning to put 40-50 hours on their timesheet each and every week. Those hours have to go somewhere.

We'd like to think that all resources revise their time sheets every day, but we know that isn't true. I've never done that as a developer or project manager and I've only known maybe two people who completed their timesheets like that. No, most wait till the 11^th hour – often the following Monday when accounting is screaming for last week's time sheets – to document their project charges. They know they worked 50 hours, but can only remember details of about 40 of those hours. Where do the 10 “grey” hours go? To your project if they think you're the project manager who might not notice. Don't let that be you.

How do you keep resources from charging those grey hours to your project? Make a budget review part of your weekly project team meeting so that your team understands how closely you are watching the budget and how important financial accuracy is to you and your project. Do that and I guarantee that your project will not be the project receiving the grey hours to get their time sheets to the 50 hours that they know they worked. It will help keep your project financials in a manageable status and keep the project budget from going way over budget and surprising you some "grey" Monday morning.

Summary

The budget is critical to successful management of the project. Let your tool or spreadsheet help you, let accounting help you, and let your team help you (make them help you!). Your job is hard enough as it is and managing any project budget - no matter how big or small - can be extremely difficult.

Project managers out there - what are your experiences with this? What tricks - and steps - have you employed to make sure you are creating and managing a workable and accurate budget. I've always said a 10% budget overage is usually acceptable and definitely easier to correct than a 50% overage that is usually too difficult and too late to overcome. Stop the bleed before it happens! Tell us how you do that.

Want to improve your project management skills? Learn how to maintain a good project budget and more with the Project Management for Business Professionals course, or prep for your certification with the PMP Certification Training Course.

Prepare to get certified in project management

Start learning today with GoSkills courses

Start free trial