If you're specification is this big, you know something must be wrong
Ah, the good ol’ specification. If there’s one thing I’ve struggled with during my years working in the web industry it has to be specs. Are they worthwhile? Does anyone actually read them? Are they a bureaucratic burden or an overlooked necessity? It seems no one can make their mind up.
I started writing specs for web projects about six years ago when the agency I worked for began developing more complex and functional sites. A year out of university and coming from a programming heavy background, it seemed like the logical thing to do – you’re building a product so naturally you should specify all functionality and interactivity in a blueprint document. Simples. Or not. The reality is that it’s not this black and white and I’ve seen projects that have benefited dramatically from specs and others that have crashed and burned as a result of them.
What’s the point?
It doesn’t matter if you’re building a small web site with only a tiny members area or the next Facebook, the theoretical point of a specification is to create a definitive document that outlines the entire functionality of the project, giving developers a schematic to work to and, perhaps even more importantly, making sure both yourself and the client are on the same page. A spec should help designers create more accurate mock-ups, developers code more efficiently, inform clients about what exactly they’re getting and keep the whole project running on time, on budget.
Oddly enough though, it doesn’t always seems to quite work out way. Don’t get me wrong, when the moons align and everyone’s drinking the same Kool-Aid, a detailed specification can make running projects a breeze. Clients know what’s in, what’s out and have a solid understanding of what the final site or app is going to look like, developers have a fantastic blueprint to reference and code to and designers don’t go off on tangents and introduce all sorts of crazy new functionality in their mocks. When specs work, they work well.
Unfortunately though, they also come with a weight of disadvantages that can make them quite unappealing to bother with.
The problems with specs
Perhaps out of all the spec naysayers out there, 37 Signals is the biggest advocate against them, condemning them as fantasies that are only used to appease stakeholders, wasting people’s time and doing nothing other than constraining us all to concepts and functionality that we have no business committing to at such an early stage. There’s a lot to agree with in what they say.
“The business world is littered with dead documents that do nothing but waste people’s time.”
ReWork
There’s no denying that specs create a large burden of maintenance and I’ve worked on projects where we’ve spent weeks with the client debating what should go in the spec and how functionality should work rather than just getting on and doing it, ironically spending more time updating a document with alterations that it would’ve taken to do in code. And don’t even get me started on just how many clients (and developers) never even bother to read them. Ultimately, on some projects, they were more of a needless bureaucratic burden than anything else.
And, just like 37 Signals say, you end up building your product to spec rather than to purpose, robotically following words written on a piece of paper rather than trying to solve the problems at hand with a holistic view of what’s best for the entire product.
Law enforcement
Specifications aren’t all negative though and, aside from the many positive features I pointed out right at the start of the article, they’re also great tools for managing time and budget, enforcing the constraints of a project and preventing scope creep which, in my mind, are perhaps some best weapons any web agency can have on their side. How often have web projects ballooned in scale because the client somehow mysteriously manages to keep sneaking in new features? How many times has that simple contact form become a fully detailed enquiry system? How many times has your simple availability calendar turned into a full blown booking system?
Perhaps these things are avoidable by improving communications with clients and learning to say no more but, ultimately, it’s a lot easier to control the scope of a project when you both have a shared, detailed vision of the product from a very early stage. Specifications are a great way to achieve this because they force you to think about everything up front and go through functionality with the client right before you even begin coding. Not only is it far easier to make large scale, sweeping changes at this stage in a project but it also means that if you’re somehow on completely the wrong page from your client, far less work has been lost.
What to do?
Deciding on whether or not to write a functional specification is a tricky question, one that I wish we knew the answer to. Sometimes they prove to be incredibly valuable, saving time and hassle further down the line, whilst other times they just end up being an albatross hanging around the neck of the project, weighing the whole thing down, constraining you from achieving the best solution.
“Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.”
Getting Real
There are alternatives to specs though that can work well and sometimes just rapidly prototyping work is far a more effective that trying to write down all its ins and outs first. Likewise, implementing a test driven approach and creating test case scenarios first can be very beneficial. Sometimes even just writing down a brief high level overview of the system in question rather than a full blown spec can work wonders. Perhaps though, one of the most worthwhile things you can do is utilise an agile development framework that makes altering things as quick and easy as possible, taking the sting out of a lot of the late-in-the-day changes that specifications are designed to curtail.
At the end of the day though, we don’t have a definitive answer to functional specs and just judge each project we embark on individually, trying to gauge whether or not creating one is the best idea for the job. Sometimes this involves writing detailed functional specs, sometimes just quick outlines of what’s involved and sometimes nothing at all. Until we figure out a better, completely definitive solution, it’s the best we’ve got.
What about you? Do you bother writing specs for web projects?
Image credit: The Telegraph
I personally feel that project proposals are the way to go. They have the major points, milestones, functionality and scoping to keep all members pointed in the right direction. But, I stay clear away from the rigid, hyper-detailed project specs that some treat as biblical. All application projects I’ve worked on are almost always in a state of flux; not in the large sense, but the details are constantly evolving.
But, to go with nothing written down is a disaster waiting to happen, unless you are the only one involved. I’ve been on projects that have nothing in writing, and it almost always causing major problems, some of which are worse than the problems caused by having too much written down.
Anyway, like always, I feel there is a middle ground that suits the majority of all projects. It’s just finding that middle ground that causes the growing pains.
We use proposals for all work and I wouldn’t advise anyone to do otherwise. Aside from outlining the general project, they are are very important for containing information like payment terms etc. Whether we follow them up with a spec though, varies from project to project.
The big issue with proposals is that they are usually pretty vague. Stating that you’re going to develop a members area or an enquiry form can be open to a lot of interpretation and it’s the point where you sit down and define the exact fields and functionality that I struggle with. I suppose ultimately the best scenario is just have a good relationship and rapport with your clients and the flexibility to include alterations and changes as they naturally happen.
I always include some of the most important specs in a proposal. Things that I foresee that could alter the project in a significant way, but these are always the larger technical aspects of the project. I don’t write a separate specs sheet because specs ALWAYS CHANGE. One of the major reasons for this is best said in this thread: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3
There’s another reason why I don’t write spec sheets. It’s because I don’t do fixed pricing. This is one of the largest reasons why spec sheets are necessary. As designers/developers, we have to make sure that we outline every spec if we are doing fixed pricing because that’s how we control costs.
In a proposal, I provide a pretty large range of what will be the end cost, then charge hourly during development. I provide complete transparency of project progress and current costs during development. This provides a constant reminder that anything that changes or modifies the project affects cost because they are paying for my hours, not the end product.
One of the problems with fixed pricing is it gives the illusion to the client that the project’s price is a static entity. For example, a “website” costs $2000 because they are only aware of the end product, the website, and not the hours the produces the end product. The client SHOULD be paying for the man hours and expenses that build the product, not for the product itself.
“I suppose ultimately the best scenario is just have a good relationship and rapport with your clients and the flexibility to include alterations and changes as they naturally happen.”
That’s exactly right. I only do work for clients with which I can build that type of relationship. Too many times have I worked for people that I knew would be trouble, but I was greedy
I learned my lessons.
I’d love to be able to charge by the hour but, unfortunately, I don’t think it will ever happen. OK, I’ll caveat that and say that yes, it may be possible if we have a very good relationship with a client and a capped monthly maintenance agreement but otherwise it’s unlikely. Maybe it’s a location thing and it’s just the way agencies here are expected to operate but fixed pricing is definitely expected, if not demanded, by the clients we encounter. It goes without saying just how hard this makes things like doing estimates for tenders when sometimes all you have is a document and a phone conversation to go on.
I’d love to hear from more people on this subject – maybe I’m wrong and clients would be more open to paying by the hour than I think.
Well, I can tell you that I’ve been charging by the hour for years, but I don’t consider myself an agency, so that may differentiate us. I consider myself a consultant that has a small team that assists me. But, people hire me, personally.
Ever since I’ve been charging hourly, my clientele as improved, my happiness has improved and my quality of work has improved. I’m also more productive because I’m no longer anchored by long, drawn out proposals and estimations, spec sheets and unwanted comprises because of an artificial number that was given prior to any REAL knowledge of a project.
But, I’m very lucky, and I thank the stars for it. But, I would believe it to be partially caused by the perception of an agency. Something that is somewhat sterilized of personhood. The larger the entity, or perceived entity, the less empathy one feels towards that “thing”. Rather, an individual is a single person, so empathy is more likely given because that “thing” is a human.
In other words, you pay a person hourly, but you buy a product/service from a company/agency/firm. When I buy a Mac, I don’t pay them for the hours it took them to build the computer, I buy it at a price that I think is competitive. But, I don’t buy people, I hire them, pay them. Anyway, maybe I’m just rambling here … I hope that made some sense
I think the separation between individual and company is really a perceived one and something that can be broken. I think we’re just to used to stuffy, formal, impersonal businesses whilst in reality they are merely a gathering of individuals and don’t need to be that way. For instance, when I think people meet us they realise we are very normal human beings and I believe that it’s an important factor for having good relationships with our clients.
Whether or not being a company changes the way people think about money though is an interesting subject and something I honestly have no clue on. Maybe we should just try experimenting and see what happens. I know that in other professions, accountancy and lawyers for instance, it’s still considered quite commonplace so maybe it’s just that it’s become convention in the web industry for no real reason.
[...] few months ago we asked if you actually bother to write specifications for your web projects. In that article, the main argument against them was that it’s a dead [...]
We use proposals but we struggle with specifications for all the reasons listed above. Our proposals have grown somewhat in an attempt to mitigate this though, and now includes not only a project brief, but also user stories, milestones, estimate, and billing schedule.
Like Justin, we too charge hourly for our time. But just like Gordon, we find that no client ever wants to sign a blank check. Our solution is to spend a few hours estimating time/cost based on the agreed stories, add some contingency, and then provide a cost range.
Our clients seem OK with this approach. But we are also very transparent with how we are doing against said estimate. We track burndown, basically, and we make sure that the client understands that the cost estimate is just that, an estimate.
Larger projects do still require additional specifications. But these are, for the most part, internal documents that the client never sees. The user stories (which our clients do see) are fairly high-level but serve to set a general direction.
Good post. Good discussion.
Cheers,
/Andreas