I recently ran across an article by a company that I really admire. I am referring to 37 Signals. They are the folks behind the great apps Basecamp, Backpack, Highrise, and Campfire. We use Basecamp internally, and would have to implement many other methods to accomplish what we accomplish using their app.

Initially the article “Getting Real, Step 1 : No Functional Spec (Signal vs. Noise)“ really took me back. In this article, they talk about the traditional way of developing (in this case) an online application, and how this is a backward approach. The traditional method being the creation of a Functional Specification document that outlines, well, how the application will function. Here is what 37 Signals had to say about this traditional process:

Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.

Historically Cora has developed online applications for clients. Often times for clients that do not understand the web development process, or understand the difference in time that it would take a developer to swap out the color of a link, vs. reworking the way the signup process operates. This isn’t to say anything bad about these people, as we all have our areas of expertise, and one of our objectives in every project is educate our clients on the process whenever possible.

37 Signals is in somewhat of a different game, hence their approach to the development process is different. If you are sitting around a table with a designer, programmer, and usability geek that have worked together for years, then we can skip over some of the baby steps. For example, when we develop applications for internal use, or for our pet sites, the process never includes a functional specification. It typically starts with a whiteboarding stage, then goes to Photoshop, then gets coded. And this approach works for us, because the programmer knows that when the designer put a comments link under the blog entry in the mockup, that is meant to go to display a comment form using AJAX, blah blah blah.

In our world, the Functional Specification document is key to the success of a larger project. If the document leaves room for ambiguity, then it isn’t serving it’s purpose. The document should outline, in no uncertain terms, how the application will function. True, the outline is meant more for the technical stakeholders of a project, but this is because this document will serve as the outline for the development process. At the same time, a key objective has got to be having the input of the client and non-technical stakeholders. If the specification cannot be read and understood by non-technical stakeholders, the specification has failed. If there isn’t a meeting of the minds before development begins, yes scope creep will quickly ensue.

Case in point : I recently wrapped up and delivered a functional specification document to a prospect. This ideation and spec’ing period was a mini-project, before we started development. In fact, at that time our prospect wasn’t sure who was going to be developing. We were one firm in a handful that he was shopping. Our recommendation was to take a couple of weeks before he jumped into development and let us sit with him, brainstorm ideas, make notes on those ideas, and draft a document that combined his input with our experience that would serve as a road map for the developers. So what happened? For us (as developers) it allowed us to get a firm grasp on the project and properly set a project budget and milestones. What initially appeared to be a 20K project ended up being a 8.5K project. How is that for unmet expectations and ambiguity? Just today I ran across this prospect-turned-client, and he raved about how smart it was to first spec out the project before getting started developing.