Whether you’re looking for a complete website overhaul, a migration to a new content management system, or just revamping your design, your budget can be just as important to you as the final product. And, when dollars are the top priority, you’ll undoubtedly want your web development firm to provide you with an accurate estimate up front. Unfortunately, sometimes that’s just not feasible.

Enter the “TBD.”

The challenge is that an estimate is simply that – an educated ballpark by the firm based on their previous project experience and the known requirements for the project at hand. Known requirements can be difficult to define early in the process, and if you can’t provide the requirements, your developers certainly shouldn’t provide you a random guess at costs. In such a guessing scenario, there is incentive for the development team to guess high (perhaps using their most expensive project as an anchor – “Surely it won’t cost more to build than that one…”), or worse. Say in the case of a competitive bid situation, they might opt for their lowest possible cost knowing a lower estimate could win the work, and that any TBDs can just be done via future change orders. Neither is an ideal scenario and certainly not very helpful from a budgeting standpoint.

One approach, albeit a challenging one, is to begin the process with all of the possible elements of your project defined – thereby eliminating TBDs. This leaves nothing to guesswork. Define everything in detail. Adding a big (“hero”) image rotator on the homepage? That’s helpful, but what does the rotator do exactly? How many slides is it limited to? Do they need to expire when the content is out of date? Does the text format change on every slide, or is the text just part of the image itself? And this is just one piece of functionality. Do this exercise for all of them (other examples: How does your event sign up process work? How do you become a member online? How do you make a donation? How do articles get written/reviewed/edited/published live? What does a forum interaction look like?). The more detail given, the better a development team can relate the effort to previous work and give a more reliable number. Then, the responsibility of hitting your budget at the end of the project shifts to your own willingness to stick to your initial requirements list.

The devil is in the details.

Consider this non-web example: It is not enough to say to a home builder, “How much will it cost to build me a house?” With that level of information how can he know? But, if you tell him how many square feet, how many bedrooms and baths, the level of finishes and kinds of brands you expect, then he can give a better number. Better even still if you give him a full set of detailed architectural and engineering plans.

And in the absence of details…

But, what if you can’t give that level of detail? What if there are simply things you cannot yet account for?  In some cases – and this is especially challenging for associations and nonprofits that operate under a strict budget that must be approved by their board in advance – you know what have  available to spend, but not necessarily what you will be able to get for it.

In such a scenario, an Agile project management approach can be of value. Under an Agile philosophy, you can establish a list of functionality that you approach over “sprints” of time, checking functions off the list as you go and going as deep into the list as your pre-determined budget allows.

Agile is not always the easiest approach. It requires a level of trust in your team and for the team to be well managed and talented at staying on task. But, it should also offer you a great deal of control over how and where your money is spent on the project so you can focus on getting the results you need.