2 Proven Budget-Management Practices for Custom Software Development

Buying custom software development services can be nerve-wracking—especially when you realize costs and scope are difficult to manage in a given budget and timeframe.  This makes it particularly difficult when choosing third-party vendors because you’re faced with a dilemma: Do you push for a “firm fixed” estimate for each feature? Or do you engage with a partner who works with you on a “time and materials” basis to co-develop your vision?

The firm-fixed vendor certainly has pitfalls: First, your vision will only be clear on paper—the translation to working code, however, will uncover many problems, inconsistencies and decisions along the way.  Second, you can likely expect a change order from the vendor every time you “change your mind,” even if you don’t change your mind but merely clarify your vision. With such restrictions, you’re likely to experience an “us versus them” battle with your vendor over what is actually in scope.

Of course, working with a partner who offers time and materials and their best efforts to meet an estimate also has its challenges. The difference is, they will work collaboratively with you to help you clarify and evolve your vision; as budgetary issues arise, you’ll make decisions together on how to proceed while staying within budget.

So, what does the right partner do to ensure your custom software project is delivered within budget? Here are two budget management practices that you should look for in a partner:

Practice 1: Stopping the Process

When budgetary problems arise, any good partner will stop, evaluate the features they’re implementing, and either move on to other features or find an innovative solution to stay within budget. To illustrate this practice, let’s look at a scenario involving one of my friends in the custom gas pipeline installation business:

Frank—the regional vice president of a public pipeline construction company—was asked to bid on replacing hundreds of old gas pipes that run from the street to homes in Baltimore City.  The utility asked for a fixed bid on each pipe, which presented a problem to Frank:  If Frank estimated correctly, he’d profit handsomely, but could not pad his bid or he’d lose the contract; if he was wrong, he’d incur a financial loss. To complicate matters, these pipes were installed in the 1880s and 1890s, and many were made of wood lined with tar (which may have dissolved, with the gas running through the hard clay soil of Baltimore).  Even worse, the actual locations of the pipes were provided by hand-drawn sketches, which are now 120+ years old.

Frank drew on his long experience and generated a set of estimates for his team based on four or five common scenarios they would encounter. He drove the streets to get a feel for a count in each, submitted his bid and won the contract.

His management process was simple: First, the crew and the foreman would arrive at the site and task out work and materials for that location. Then, the foreman would compare the task total to the scenario estimate.  If the tasks were near, at or below the budget, the team executed; if it was above budget, the team would escalate the issue to Frank’s management team, who had very deep experience.  The team would move to the next location, pending a new plan.

Meanwhile, the management team would act as consummate jury-riggers. Their task would be to find a solution that would fit the budget, and once they had a solution, the team would implement it.  They even found some innovative approaches: On one particular job, Frank shipped a large drill to the site and routed pipe through tree trunks to make the budget.

So, the entire approach was simple: If the team could not meet the estimate, they’d move on to the next feature while a new design approach was developed.

So, how would “stopping the process” apply to software projects? Let’s apply Frank’s logic to product backlogs that are tasked out: If the team tasks are at or below the estimate (aka budget), no discussion is needed. If they are above, the team and the architects need to have a discussion: Why are the estimates so far apart? Are there simpler ways to do these tasks?  If needed, the feature can be pushed to a future Sprint while the approach is re-planned.

Once the coding begins, the stop-rule still needs to be in effect. If a developer hits a roadblock or no longer feels the budget is attainable, they need to stop and ask for assistance. The same strategy of finding a way to fit the task into the budget or schedule is applied.

There may be times when these steps will not prevent a budget overrun, but leaks can be stopped in 70-80% of the cases, so the budgets will be reasonably managed.

Practice #2: Manage Feature Scope

Time and material estimates—which are based on feature or User Story headlines—are great budget targets to manage to. But after the team articulates details, adds a description and defines acceptance criteria, each estimate must be re-done.  Like the process above, if the new estimate is near, at or below the proposed bid, it’s good to go.

However, if the expanded understanding results in a higher bid, its decision time. The team must investigate all the items in the feature and ask some questions:

• Do we need all the elements in the Description?
• Do we need to handle all edge cases, or is throwing an error OK?
• Can we schedule some elements to a future release?

There may be cases where the client wants to expand the scope.  In this case, all negotiations should be done upfront with full transparency on how it will affect the overall plan. Otherwise, the team can look for features to trim, or with the client’s approval, expand the time and budget plan.

It’s a Constant Process of Managing to Budget

Finding a partner who understands how to implement these practices can help guide a project to successful delivery, both inside budget and on schedule.  By having a constant eye on budgets, and adjusting along the way, the vision can become a reality.

Want to learn more best practices for custom software development? Download our white paper, “How to Build World-Class Software: Expectations and Considerations,” to learn six guidelines to ensure your next custom software project is primed for success.