If you're new here, you may want to subscribe to our RSS feed. Thanks for visiting!

Defining a budget for software development projects is something of an art form. Most cost projection tasks are the result of Client requirements, guesswork, gut feel and estimations that have little bearing on reality. Our Clients demand fair prices and solid proposals that they can go to their boss with for signature knowing that a reliable partner is standing by, waiting for the green light. These proposals need to be based on realistic estimations of our costs and our risks for delivering the level of quality that our Clients desire at a rate they can afford and in a time period that they want. Not many people are willing to discuss the topic but, the fact is, it has become a real challenge to deliver both a competitive quote and high quality result for Clients this past decade. The primary reason seems to be a lack of serious, responsible, dedicated and reliable individuals that are skilled in providing services on time, on budget and at the highest level of quality. One of our good fortunes is to have a strong team of A players already on board but a key component to delivering results that make our Clients happy is to deliver within 5% of our estimate.

Since hourly rates for coding, additional costs for rapid development and pricing of tools and other resources can fluctuate based on circumstances beyond our immediate control, we offer the following guidelines to help you create a consistent and justifiable budget that is also realistic.

The Basics
A budget is one of those pivotal tools that is used to make decisions in many areas of a company. When creating budgets please keep the GIGO rule in mind and input quality data as often as possible. For developers, budgets dictate the amount of time they can spend on specific areas of an application. For the project manager, it’s a baseline used to determine if the project is on track. For our Client, the budget correlates directly to the success of the effort. Regardless of circumstance, a number of basic philosophies can help your budgeting immensely by protecting it from subjective review. By understanding the basic concepts, and making sure that everyone involved understands them as well, you’ll be on the right track toward an accurate projection:

Identifying project costs 

When you’re identifying the costs of development, stay 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 them to program a given amount of code. Consult with your lead developer. Watch out for braggadocios estimates & consider multiplying your developer’s estimate by 3 to pad for your risk assessment stage. Remember to include costs for integration, meetings, security certificates, license fees, quality assurance, debugging, documentation, material costs, testing, deployment and planning time are all areas that need to be included in your estimate. Whether we will be billing our 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.

Be sure to itemize estimates for features that were not included in the specification. These are items that you suspect will be requested later on or those that would be beneficial to the final product. List these as options in your proposal and budget for them. 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 yet and thus many questions get deferred to the developers – plan for this eventuality.

Once you’ve got your costs outlined, it’s time to look at the probability of staying within those boundaries.

Risk
Risk assessment and assignment is very important to a successful budget. Without it, the crises that occur regularly and are an inherent part of any project, will affect your bottom line. Values in your estimate need to have this padding built in – 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 (or lack thereof), 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, server side technology, hosting configurations (cloud etc) and any unknowns.

Once you’ve determined your risk items, assign a scope and percentage to each. For example, if one part of your application is to be built in C and another in PHP, and your team consists mostly of C programmers, the PHP 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 nature. People get sick, take vacation, disappear without notice etc. No one is an expert in everything. I always assign a percentage risk to this area – in addition to other considerations. Here is a sample of how we assess risk: An average 10-developer, 6-month project justifies a risk assessment of 7 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. If your overall risk assessment is between 20 and 30 percent of the total project cost, you are within our operating norms.

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 delivered 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.

Regardless of how close you come to reality, a Client will be much happier if your project comes in below budget rather 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 are more likely to deliver your upcoming projects on time, on budget and meeting your Client’s quality expectations. Remember that Time, Quality and Cost are interrelated. If you modify one of them, it will more than likely impact the others.