There is no question that project success is hard to achieve. More than 50% of all projects are usually considered failures by someone to some degree using some yardstick. Surveys generally put project failure rates between 46% and 57%. Not good... not encouraging. 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, on budget delivery 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 more easy to correct a 10% overrun if you have to than it is 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 what I prescribe to as my own 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 sales person 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 the project manager's best jumping off point. No reason to start over from scratch... 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 and draft numbers and historical numbers to use. For example, on a technical project, if you have a Functional Design Document (FDD) to put together and you know that usually takes 60 hours of a Business Analyst and 40 hours of a Technical Lead to put together and produce plus another 20 hours for team member peer review and 4 hours for customer discussion then you know also – in general – the roles and prices to plug into and 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 till 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 now a potential 51% higher price (($1,130,000 - $750,000) / $750,000) to the project client and help them up off the floor.
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. For me they are one in the same and my template is a self-built spreadsheet that I still use and have as a free download on my website... you are welcome to it.
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 of 98% of the working resource pool. I've never done that as a developer or project manager and I've only known maybe two people who completed their time sheets like that. No, most wait till the 11th 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 / call for input
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.
There are usually three key ingredients to project success in most stakeholder's books: on time delivery, on budget delivery 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 more easy to correct a 10% overrun if you have to than it is 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 what I prescribe to as my own 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 sales person 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 the project manager's best jumping off point. No reason to start over from scratch... 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 and draft numbers and historical numbers to use. For example, on a technical project, if you have a Functional Design Document (FDD) to put together and you know that usually takes 60 hours of a Business Analyst and 40 hours of a Technical Lead to put together and produce plus another 20 hours for team member peer review and 4 hours for customer discussion then you know also – in general – the roles and prices to plug into and 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 till 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 now a potential 51% higher price (($1,130,000 - $750,000) / $750,000) to the project client and help them up off the floor.
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. For me they are one in the same and my template is a self-built spreadsheet that I still use and have as a free download on my website... you are welcome to it.
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 of 98% of the working resource pool. I've never done that as a developer or project manager and I've only known maybe two people who completed their time sheets like that. No, most wait till the 11th 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 / call for input
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.
RSS Feed
