Avoiding the "TBD" in Web-Design Projects

Avoiding the "TBD" in Web-Design Projects

This article originally appeared in the September 2016 issue of Association News

Whether your group is looking for a complete website overhaul, a migration to a new content management system or just a revamp in design, your budget will often determine the result of the final product. Undoubtedly, you'll want a web-development firm to provide your organization with an accurate estimate up front, but unfortunately, sometimes that’s just not feasible. Instead, you'll probably find yourself faced with that vaguest of acronyms: TBD - to be determined.

Avoid random guesses. Most firms will make an estimate based on their previous project experience and the known requirements for the project at hand, which can be difficult to define early in the process. Web developers certainly shouldn’t provide you a random guess at how much the project will cost; in such a guessing scenario, there is incentive for the development team to guess high, perhaps using its most expensive project as a reference. Or worse, as in the case of a competitive bid situation, a developer might opt to submit the lowest-possible proposal knowing a lower estimate could win the work, but then plan to navigation any TBDs 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. This can also be a task that requires time and foresight, but what well-executed job doesn't?

Address the details early. Want to add 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, and will it need to expire when the content is out of date? Will the format change on every slide, or is the text just part of the image itself? This is just one piece of functionality. [Ed. Note: When I originally wrote this piece, hero-image rotators will still in vogue. They have since fallen out of favor. I wouldn't recommend using one in your design.] This exercise should be effectuated for all major design points, other examples of which may include the following questions: How does your event sign up process work? How does someone become a member online or make a donation? How do articles get published or reviewed? What would a forum interaction look like? The more details you can give, the better a development team can evaluate what your project will entail and provide you with a more accurate cost figure. By adhering to this model, the responsibility of hitting your budget shifts to your own willingness to stick to your list of initial requirements.

Think of it another way, would you approach a home builder and say, “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 you'd like, how many bedrooms and bathrooms, and what kind of materials, finishes or brands you want to use, the builder will be able to come up with a plausible estimate. Better still if you can give him a full set of detailed architectural and engineering plans.

Establish clear goals. But, what if you can’t give that level of detail because you don't know enough about web design? What if you know how much money you have to spend, but not necessarily what you will be able to get for that amount?

In such a scenario, an Agile project management approach can be of value. Establish a list of functionality goals your organization will approach over “sprints” of time, checking functions off the list as you go, tackling as much of the list as your pre-determined budget allows. 

This approach isn't always easy. It requires a level of trust in your team and for that team to be well managed and focused at staying on task. However, it will yield a great deal of control over how, where, and when your money is spent on the project.

So, if you know exactly what you want for your new or updated site – great. That makes your developers’ lives a little easier and will narrow down how much the whole thing will cost. Or, head into a discussion with a pre-approved budget and a list of ideals. Armed with information and a specific financial allowance, your group will be better prepared to work with incidentals that create the dreaded TBD.

Jason Stone is vice president of sales and marketing at Engage Software. He can be reached at jstone(at)engagesoftware.com or 314-884-2448.


James Thompson, UXMC

Senior UX and Product Design Leader

8 年

Jason Stone The things you describe here, all fall under the umbrella of User Experience of UX :). I typically use a variety of techniques to partner with the client and help determine what those requirements are. I have a pet peeve about 'Requirements Documents'. We don't build books, documents are a great way to start a book, not an interface. :)

要查看或添加评论,请登录

Jason Stone的更多文章

社区洞察

其他会员也浏览了