Web development projects have many moving parts: taxonomy, navigation, page types, plugins, and so on. The challenge comes in keeping track of all these pieces and parts. Over the years, we've used a traditional scoping process. This creates a fairly rigid set of documentation. Our process has evolved.
The concept of a build spec was presented at a DrupalCon our team attended, but applies to most traditional web development. The build spec becomes a tool for flexible discovery rather than rigid documentation. It helps focus on the items that need to be examined on current sites, and becomes beneficial when we're helping clients find out exactly what they want to do. The build spec provides a big picture of the technical pieces that are to be delivered to a client.
Build Spec Findings
Through the creation of a build spec, we discover:
- Plugins or modules needed early on
- Custom code that should be identified and scoped
- A high level view of the project as a whole
- How to communicate information to the team to reduce knowledge dependency on a single team member
- Help text to utilize in the project as the user experience and use case is discussed
Our build spec template is a spreadsheet tool we use to identify these pieces and parts, apply existing solutions to new projects, and document how we'll do it.
Creating a web development project build spec identifies the technical needs of the project but is flexible enough to be modified to fit most any web development project we're involved in. Our more complex projects involving content management systems (CMS) like Drupal, Wordpress, or MediaWiki greatly benefit from following our build spec path.