Fear the Documents

Through my career, it’s easy to say that I’ve worked on hundreds of different projects for many different clients. Some for small companies with small budgets, small teams to get the work done and short timelines. Other projects are for large companies, with large teams and long timelines. The one connection between all of these projects is this: the documents can make them or break them.

Fear the docs. Fear what they can do to your project and your sanity.

What the docs do for you

Documents serve two main purposes. First, they provide a list of instructions to build/test from, and they set expectations of what will be delivered. In other words, you build and test what the documents say, because that is what the client believes they are getting.

Good documents will have a clear list of features with enough detail to build from. Other documents will server other purposes, with other information in them. Regardless of what the document is for, make sure it’s up to par. If there are holes in the doc, it leaves space for errors. Get it cleaned up prior to starting the project, and make sure all your documents get a proper validation before they go into production.

What fear can do for you

The thing about fear is that it will gain all of your attention and essentially enslave you to it. Phobias are an extreme example of this, but it highlights the point. If you suffer from arachnophobia, what do you think is going to be on your mind as you go down the stairs into your dark basement? Are there spiders down here? Will one jump on me? Soon enough all you’re thinking about are spiders.

Fearing the docs

A healthy fear of the documents will force the documents to stay on your mind as you work on your projects. Any decisions that are made will be run through a quick mental filter. You’ll ask yourself “Is this in the docs? Is this what the client is expecting to get? If I add this feature, will QA know what it is and how to test it, or will they think it’s a mistake or bug?”

Having this thought processes before implementing new or changing features to a project will help the flow of the project stay reasonable. There will be no back-and-forth conversations about who gave the direction to add a feature, if it’s valid or if the client even wanted it.

The bottom line

Fear what can ruin you. I’ve seen bad documents and poorly managed changes to documents make projects take twice as long and cost twice as much. I’ve seen projects built from documents not validated or approved by the client. In the end, my teams had a lot of unneeded stress and overtime work to compensate for bad documents. Do yourself a favor: don’t let the docs ruin you. Fear what they can do to you.

If you like this post then why not share it?
  • StumbleUpon
  • description
  • Technorati
  • Digg
  • Slashdot
  • Design Float
  • del.icio.us
  • TwitThis
  • Reddit
  • E-mail this story to a friend!
Add devjargon( ); to your RSS Updates.

Get new posts sent to you by email for free!

1 comment

  1. 1 08.09.08
    11:36 am

    [...] Fear the Documents [...]

Leave a Comment