Common Project Issues: Budget Overrun
Posted by Brad EgelandI’ve talked about Budget Management in other articles, but it’s such a huge issue it’s worth another look or two. Depending on how your organization is setup and how your PMO mandates projects to be tracked, the concept of budget management may not be getting as much visibility as it should…but it’s still critical and extremely important to your customer.
The Status Quo
All good Project Managers know all about managing their projects well with formal weekly status reports, formal weekly project status meetings, delivering a revised project schedule on at least a weekly basis and conducting at least weekly status calls with your internal delivery team members. But when you’re acting in the role of a PM, the target is firmly planted on your forehead. That means that anything….ANYTHING….that goes wrong on your project will be perceived to be at least partially your fault. Because if it’s something you didn’t know about, then everyone will want to know WHY you didn’t know about it.
That brings me to the concept of budget overruns. The key expense that is churning through your project budget is delivery team man-hours. As the PM, if you’re not tracking your project team members time charged to your project on a weekly basis, then you better start – better late than never.
The Overrun
The common problem is the Project Manager who is very intent on managing the project with the status report, project schedule and regular status meetings, but who forgets to track the hours and expenses on the project. If things are going smoothly, how can the budget be out of whack? Easily….each professional on your team wants to charge as many productive hours as possible and if they are charging to multiple projects and you’re the PM who isn’t tracking hours, then you’re the one who is going to get any ‘grey’ hours charged to your project. And it could be that they are legitimate hours anyway, but most IT pros go through the week concentrating on their detailed work and don’t give much thought to actually tracking where their hours were spent until they have to…on Friday or the following Monday.
It’s easy for extra hours to get logged to projects and you’re a sitting duck if you’re not running through the budget and forecast with your team on a weekly basis so they know how many hours they can charge and what you’re expecting to see each week.
In this scenario of over-trusting your talented staff to charge as few hours as possible, it’s very easy to get ¾ of the way through the project only to find that you’re now forecasting the project to be 30% over budget. This is not good news to either your customer (who may have to pay more for the project) or your organization (who the customer will complain to and who may have to eat the $$ if your customer decides they shouldn’t have to pay for the budget overrun). And who looks bad in the scenario? The PM – and justifiably so.
Summary
The moral to this story is that it’s critical to maintain a tight control of your project budget. It’s just as critical as the project schedule, project status report and project status meetings. Keep the team aware on a weekly basis of what you’re forecasting in the way of effort for them on the project. And keep the customer informed of the budget status on a weekly – or at least monthly basis. That way, the team will feel more accountable and the customer will be more aware and likely more confident and satisfied…which ultimately is a very good thing for the Project Manager.
Related posts:
Pradeep Bhanot says:
Brad, you bring up a very common problem and you are spot on with identifying the reason for this grey time allocation. Software development projects that I have worked on have had developers having to allocate their time to the project they are supposed to be working on as well as having to firefight other issues (allocated to a separate project) at the same time. When allocating their time to a multitude of projects they usually round up the time they actually spend on the job. One solution you might mention is to put a system in place that shows actual resource allocations across all projects. This would highlight resource over allocations that the PMO or resource manager could bring to the attention of the project managers involved.
If an have an interest in how the PMO is most commonly viewed, checkout the latest research on my blog: http://clarity-in-emea.blogspot.com
The following is an excerpt from the report that talks to the budget management role of a PMO:
The research highlights a certain degree of consistency concerning how the value of the PMO is expressed in the organisation. Three quarters of respondents (75%) cited the same four themes: ‘delivering projects on time’ (21%), ‘delivering projects on budget’ (21%), ‘alignment with business objectives’ (20%), and ‘generate higher customer satisfaction’ (13%).
Niels Malotaux says:
If “All good Project Managers know all about managing their projects well …” and these Project Managers do not also guard, and stay within their budget, how can you talk about “good Project Managers”?
If people in projects write their time spent on other things on your project, they are effectively stealing from the project budget. Is that normal and acceptable?
I developed my way of “Getting and Keeping a Project under Control”, without burdening the people in the project with excessive metrics. Actually I teach them to control themselves, spending their time wisely, resulting in better results more quickly, more satisfied project-people as well as more satisfied customers. See http://www.malotaux.nl/Booklets : Booklet#2 describes the basic way to organize the work better, so that people in the project spend their time on the right things, while you (the PM) better understand where they spent it. Paper#7 (How to achieve the most important requirement: Time) describes how to see quickly and quite reliably when what will be done. Once we have early visibility on the project’s outcome, we usually see that it will take more time and budget than we have available. We don’t just accept that as fate, but once we know that, we think what we can do about it. One of the problems here is that most of the measures taken to do something about it work counter-productive. These I call the “deceptive measures” (hoping it’ll get better, going for it, working overtime, moving the deadline). Then there is the dangerous measure (in case there is not enough time): adding people, which usually also works counter-productive and makes the budget easily explode. It even shows that taking some people from the project may yield a faster result in even less budget spent. Absolutely counter-intuitive.
Finally there is the low hanging fruit, although apparently not obvious, otherwise it would be applied more often: saving time. Paper#7 describes the various ways we can save time in projects and how you can, early in the project, make predictions about the outcome, in order to act upon it. After all, every day you spot a problem earlier, you have a day more to do something about it. Techniques described are estimation and calibration to reality.
I don’t want to say that you should use the same approach. All I can say that it works very well in the projects I coach.
As you mention: Time is usually considered the most important requirement. Still, most projects are late. Isn’t it weird that apparently all other requirements in the project are considered more important that the most important requirement?
Niels Malotaux, Project Coach