When we begin to work on a web development project, whether it’s a site we’re building from scratch or a rebuild of an outdated site, we almost always include some kind of specification document before a developer begins to code. A specification document is a document that a project manager creates. It’s based partially off the design files we receive from our clients or our collaborating design firm and partially off the discovery process we walk through with clients. In it, we break down exactly how all of the functionality on the website is expected to work:
- Is the logo clickable?
- How does the navigation behave?
- How will the user enter content for a particular Drupal block module on the backend?
- What special list views are needed? What about custom filtering for those list views?
The goal of the document is to provide our developers with a clear expectation of how the site will function and, ultimately, reduce the amount of communication needed to clarify site functionality.
How can a specification document help my web development project?
The de facto position at Knectar has, for years, been that a thorough (30+ pages) specifications doc is a requirement for any web development project we undertake. And in the large majority of cases, that’s still true.
But I’m here as a devoted technical writer to say that a full spec may not be the best fit for every project. Now, before gasping in horror, hear me out. Because there are certainly pros and cons to the spec’ing process, and it all boils down to the ever-valid Quality Triangle:
Spec’ing for Good and Cheap
Without fail, if there is a strict budget that a project has to stay within, we insist on a thorough specifications doc. As any contractor in any industry can tell you, it’s the unexpected changes and new features that will immediately destroy a budget.
Part of the spec’ing process is figuring out what can be done within the budget, and this evaluation keeps all parties honest in terms of what will be built. While the initial front-loading of discovery budget can be higher, it insures that the project stays on time and under budget.
Spec’ing for Good and Fast
Here’s a combo where a full 30+ page specifications doc may actually harm the project, as folks get bogged down in the specifications process and making minute decisions for every page on the site. For a project with a short timeline, we may instead scale back to a “bare bones” specifications doc, that lays out what a user needs. This document may be created in the course of a few hours, instead of a week or two, and will result in a “skeleton” that a web developer can begin building.
Then, since content entry usually begins on these short timeline projects before the development is officially complete, as additional requests come up they can be incorporated into the development provided the schedule can still be attained.
The potential downside of this approach, however, is the budget implications. A project without a finalized, signed-off spec means that expenses can not be fully estimated. It also means that the client team needs to have a single point of contact who can quickly approve new features, and the billing associated with those new features.
However, if the budget is large enough to support this more agile workflow, it can be a great solution for teams that are active and engaged in the development process, and result in beautiful sites.
Spec’ing for Fast and Cheap
Much like spec’ing for Good and Cheap, for Fast and Cheap Knectar also insists upon a formalized specifications doc. The difference in this scenario, however, is that we will often present a client with a specifications doc at 90% completion, and the final 10% can be negotiated to fit within the timeline and budget. This is in contrast to the Good and Cheap approach, where the discovery effort between the two teams can sometimes last for a series of weeks, as every last detail gets ironed out.
As a note, we always, always suggest that any “Fast and Cheap” project have a Phase 2 on the schedule for post-launch. This is handy information to have during the spec’ing process, as sometimes features can be sketched out during the initial build, and enabled later.
Summing it up
The TL;DR version of this blog post? A full, finalized specifications doc can be done away with; but only if the budget, timeline, and team coordination can account for that. Otherwise, the finalized spec, as involved as it can be, is truly in place to protect all aspects of the web development project, including client satisfaction with the final deliverable.