A budget is one of those pivotal tools that is used across many departments within a company. For the developers, it dictates how much time to spend on specific areas of the application. For the project manager, it’s a baseline used to determine whether the project is on track. For sales or the client, it correlates directly to the success of the effort. It’s no surprise that one of the biggest issues in creating a budget is interpretation.
Regardless of circumstance, a number of basic philosophies can help your budgeting immensely by protecting it from subjective review. By understanding concepts, and making sure that everyone involved understands them, you’ll be on the right track to an accurate projection:
- Project costs and project budgets are two different things.
- Always start by identifying project costs.
- Project costs are not defined solely in monetary amounts. Include actual amounts, with shipping and taxes, for software or hardware purchases that must be made. If you’re pro-rating the costs of using pre-existing hardware and software tools, include it in number of hours. Likewise, developer effort costs are recorded in hours, not dollars.
- Once you’ve laid out your costs, identify your risks and assign a percentage reflecting how much each risk factor may affect the project as a whole, or a portion of the project. Each development team should have a risk value assigned to it, to cover reasonable costs such as hiring the occasional contractor to get a timeline under control, unforeseen overtime, and so on.
- Your budget, then, is the total of the costs, as transcribed into a monetary figure, plus the total risk percentage of that cost. Define conversion values that you use to represent equipment pro-rating and development times.
- Your budget is not an invoice. Once you’ve determined the hard figures involved, leave it up to your company’s business representatives to make adjustments for profits. Make sure they understand your figures reflect actual costs.
- A budget should always be labeled as an estimate, until it is finalised and approved. This helps to manage expectations and prevent miscommunications from being written in stone.
- A single person does not create a budget. At the very least, all of the following should be consulted: lead developer, project manager, and a business-side driver.
Identifying project costs
When you’re identifying the costs of development, be as close to reality as possible. Look at performance of the team members on past projects to get a feel for how long it will take to program a set amount of code. Consult with your lead developer. Watch out for boastful estimates, but save hour-padding for your risk assessment stage.
Don’t forget to include costs of integration and deployment. Meetings, security certificates, license fees, quality assurance hours, debugging, documentation hours and material costs, and planning time are all areas that are frequently overlooked. Whether your company will be billing the client for these items or not, they are all valid and substantial expenses of a project. Including them will help you accurately measure the profitability of the solution down the road.
Next, itemise estimates for features that weren’t included in the specification, but that you suspect will be asked for later, or that would be beneficial to the final product. List these separately as options. Another good thing to up-sell is developer support time for about 60 days after launch. Often when a project is rolled out, support groups aren’t in place or may defer a lot of questions to the developers.
Once you’ve got your costs outlined, it’s time to look at the probability of exactly hitting those costs.
Risk assessment
Risk assessment and assignment is very important to a successful budget. Without it, the crises that happen regularly and are an inherent part of any project will affect your bottom line. Values in your estimate should have this padding built in, and it should not be considered a part of sales mark-up. Risk represents actual costs incurred over the course of development.
Risk line items should include things like development team experience, obscurity (supportability) of the technology used, planning time shortages, number of development teams, location of development teams, number of modular components, proximity and availability of the project driver, product dependencies such as databases or third-party software, and any unknowns.
Once you’ve determined your risk items, assign a scope and percentage to each item. For example, if one part of your application is to be built in Java and another in C, and your team consists mostly of C programmers, the Java component may have a higher risk assignment under the -developer experience” line item. The percent assigned should be applied only to the relevant portion of the project.
All projects have a certain amount of risk involved that can be attributed to human existence. People get sick and take vacation. No one is an expert in everything. I always assign a percentage to this area, beyond other considerations. An average 10-developer, 6-month project justifies a risk assessment of 5 percent of the total project costs. For longer projects and smaller teams, it will be higher; for shorter projects and larger teams, it will be lower.
It is normal for your overall risk assessment to be between 20 and 30 percent of the total project cost. Does this seem high? Low? Your actual total risk percentage will depend on your experience in evaluating the team and the pending effort. If, after calculating an estimate, your numbers are coming out too high, look at other projects by your company. Did they actually fall within their budget? If not, your numbers may be justified. If so, you may be giving your team too little credit. Rectify project-to-project discrepancies before presenting your estimate to the project driver.
Conclusion
Regardless of how close you come to reality, a client will be much happier if your project comes in below budget than over it; however, too high a risk value can create sticker shock, revealing inexperience and creating misgivings about your management abilities. By following the guidelines we’ve suggested and applying some common sense, you can be assured that your team, project drivers, and client will enjoy the benefits of a well-estimated project.
Recent Comments