On Functional Specs and Project Pitfalls
I found a good post about functional specs when I was reading Ian landsman's blog this morning. Ian notes the different opinions on whether or not writing functional spec is a good idea - one camp claiming that spec is purely a political appeasement move, and the other claiming that spec is vital to a well-written app - and ends up coming down on the side of those of us who write functional specs. Good show, Ian! He also wisely notes that functional spec is best done in small bits. I agree - the bigger a single iteration of spec is, the more likely it is you missed something.
There is a reason that I included inadequate/unclear requirements amongst The 5 Pitfalls of Estimating a Software project - this problem is HUGE in the industry and it cannot be solved by saying "specs don't work - don't write specs". It's true that ultimately you need people to agree on the functional spec, just as it is true that they eventually need to agree on a user story or an interface mock-up. This doesn't not make the functional spec an appeasement document, though. If anything, the process of developing a functional spec should get people talking about - even fighting about - what task experience the app needs to provide. The biggest fear a developer has is to deliver an app only to be told "that's what I asked for, but it's not what I want", and the process of developing a functional spec - done correctly - will avoid this.
Why did I qualify my previous statement with "done correctly"? Simple - too many developers have an "order taker" mentality when it comes to developing a functional spec. A client will rattle off a list of wishes - "Yeah, this program needs to cure cancer, gnarfle the garthok, walk my dog, do my taxes, and make me a sandwich. It's pretty simple, you should be able to do it in about 2 hours." Now, at this point the developer can go one of two ways:
- Say "yes, sir" and shuffle off to make a half-hearted attempt at doing what he knows is impossible, only to be driven to drink and beat his children when hopelessness finally sets in, or
- Push back on the client and challenge his demands
I'll give you three guesses what a good developer will do. ;)
When developing spec, it is your obligation to act in a consultative fashion and challenge your clients assumptions and requests. This is not McDevelopers - you don't simply serve up whatever the client in the drive-thru orders through the speakerbox. It is your job to protect the client from himself. If you find that even after developing a functional spec, the delivered app is met with "that's what I asked for, but it's not what I wanted", then odds are you have failed your client in some way. Note that I did not say the spec has failed - you have failed. Perhaps you didn't probe deep enough. Perhaps you let some assumptions slide. Perhaps you didn't lay out the different scenarios your client's requests could lead to clearly enough. I've been there, and it is painful to not only let your client down but fall flat on your face with your release.
Controlling scope creep is also part of doing functional specs correctly. One can claim that functional specs inherently lead to scope creep because it is easy to add something to a Word document, but I disagree. I think weak developers lead to scope creep. Again I say - a good developer will not allow this to happen. A good developer will push back. "This change conflicts with xyz" or "This change will double the cost of abc" or "This change is not technically feasible", etc. When it is obvious that the scope of the project is in jeopardy of changing, a good developer will speak up and offer suggestions. In some cases, the developer must be willing to stand firm and say NO.
Functional specs don't fail. Developers do.
To be fair, the "don't write functional spec" guys are designers, not developers, so they are probably dealing with a different set of concerns than a developer is. In fact, I get the impression that their mental image of a functional spec does not include any interface examples, which is not how I do my specs. Photoshop or Visio representations of a UI are always liberally sprinkled throughout my functional specs to illustrate what the text is describing. However, I don't go building a real, functioning UI until it has been decided what that UI should do, and how it should do it.
I will stick with the approach that has made my projects successful - committing the application experience from a user POV down on paper - and vetting it with the users - before writing a line of code or building a working interface.
