Boring and not very �new media� though it may seem, documentation is vitally important. I see it less as the nasty technical details that the nerds need and more as an implacable, unmoving taskmaster forcing you to clearly articulate what it actually is that you want to do. Painful, obstinate and relentless in the way it forces you to answer the questions you do not want to have to confront but absolutely must for the project to succeed. Good documentation achieves the following:

• It reduces complexity of communication.
  Have you ever got so deep into a project that your brain is fizzing just holding all the little bits together? Where you haven�t had time to document and now you �might as well do it yourself because it would take too long to explain�? And you�re working too hard and getting ill with the stress? Perhaps not quite to this extreme, but wouldn�t it be nice to just point everyone in the direction of the font of all knowledge, your most excellent documentation.
• It gives a holistic level of clarity.
  As you think up new ideas and add bits and pieces here and there you risk losing control of what the totality now looks like and how it holds together. Documentation forces you to have a single place where the whole project can be examined.
• It forces consensus between project members.
  Verbal agreements, descriptions and specifications (is a verbal spec possible?) are dangerously open to misinterpretation, or can be conveniently discarded or refuted at a later stage. Documentation enforces the same kind of focus as a written contract. It flushes out any inconsistencies or difference of interpretation.
• It engenders commitment.
  It is so much easier to buy into something if you believe in it and you do not have those nagging questions at the back of your mind. Good documentation is like a good business plan to an investor: all the aspects are covered and there is no reason to believe that this won�t be a winner.
• It saves you time and money and might just save your project.
  Imagine that everyone on your project really knew what they needed to do, when and why, because they had been forced to rigorously think it all through and understand it in advance. Just think how well things could go. Good documentation helps force you do all those things you know you should but somehow don�t quite happen in the real world.

Why it�s worth catching up with your documentation

Despite all your best intentions and such worthy reasons for good documentation as I have given above, it is often the case that web projects are delivered with scant, or inaccurate, documentation. In an ideal world you will have created good documentation when planning your web projects and then updated the documentation as you go to reflect the actual state of the system. This ideal is rarely realised. Documentation is typically started well and then starts to falter as delivery pressures mount. It is then unable to keep up with the pace of change through the development process and what is finally delivered bears little resemblance to what exists of the documentation.

Assuming your documentation has fallen into a state of disuse and disrepair then one of the first priorities when entering the post-launch maintenance phase should be to bring it up to date. Budgets are currently being frozen and new initiatives postponed so now is a good time to catch up with lapses documentation efforts. There are (at least) three very important reasons why you need to bring your documentation up to date to effectively maintain and evolve a web presence:

• 1. You know what you have actually done.
  Whatever your initial project plans showed it is very unlikely that this is what you have actually ended up with. Subsequent changes, iterations, phasings, scope changes, reprioritisations and so on will no doubt have significantly altered the course of your original plans. This is not necessarily a bad thing, it just reflects the iterative and changing nature of Web projects. However, at some point you do need to take another �snapshot� to understand in detail what you do have. Among other things, you need this to then plan future work, perhaps to fill the gaps that you identify. Iteration is good but now and again you need to bring your team back to a single, solid reference point that can be used for reorientation and focusing ongoing efforts. Updating project documentation forces a process of audit and reconciliation that reins in and realigns the chaotic energies of change.
• 2. Without documentation you cannot measure change.
  To have a clear notion of �change�, and what to do about the change, you need to understand what your reference points are. Change is an alteration of one state to a new state. But what are those states and what kind of alteration must occur? Without any benchmarks, yardsticks or agreed understanding of what �is�, it is extremely hard to define what �should be� and how it will be different from what is. This may sound a little philosophical but it becomes painfully real if you have ever spent time arguing over whether a site update was really a change, or an addition, or how much of a change it was, or whether it should always have been there in the first place and so on. Documentation forces consensus on what �is� at a point in time. It is then infinitely easier to define and manage changes to that state thereafter.
• 3. You need to protect yourself going forwards.
  Whilst it is to some degree excusable, or at least understandable, that not every last detail is buttoned down in a document in the run up to a site launch, all the loose ends must be tied up as soon as possible afterwards. In particular any documentation with contractual or other legal implications such as service level agreements or intellectual property rights contracts. If you allow these elements to go undocumented then it is likely no-one will address the issue until one day it becomes a very sudden, and potentially very serious, problem. Just look at the number of companies whose website development efforts are severely thwarted by their internet service provider or perhaps their web agency where relationships have turned sour and the company finds itself stuck in a difficult legal position, unable to free itself and move on. You must ensure that all relevant documentation is up to date to protect your ongoing efforts.

How can you keep documentation up to date

OK, so we all want up to date documentation and recognise its benefits. The hard part is how to do it. Do you:

• 1. Create your documentation up front and then just stick rigidly to the plan so that updating the documentation is a small and easy task?
  This would be nice and should be aimed for in theory, but practice tells me this just isn�t realistic.
• 2. Have someone charged with keeping it up to date?
  You could put a project manager in charge of this, or a dedicated documentation team. However, to keep up with the daily changes makes this an onerous and full-time task (aka �expensive� and �resource-intensive�). And where�s the value if things change so often?
• 3. Create the necessary documentation up front and then just batch update it all once the project launches with what has actually been delivered?
  This doesn�t sound like a very sensible way to do things but it is what I see happen most often. In many cases, particularly on smaller projects or where there is a small-ish core development team with good communications, this works out just fine. If you are using change control procedures during the development process to log changes to the orginial documentation then updating it all in one go is less of a problem too.

I�m not sure I have the answer. The answer will, of course, totally depend on the project and circumstances as well. Has anyone found a particular approach to work well? Anyone pioneered miraculous self-updating documentation? In theory with web-based project management software, a bit of workflow, a touch of standardisation in working practices, a dollop of document/content management, and a liberal does of XML, it is perfectly possible to create self-updating documentation. Doing it as HTML is certainly a good start.

About the author: Ashley Friedlein is CEO and Co-founder of E-consultancy which publishes research on best practice online marketing and also runs events and training. Ashley has written two books, " Web Project Management: Delivering Successful Commercial Web Sites" in 1999 and " Maintaining and Evolving Successful Commercial Web Sites" in 2002.