Project documentation: balancing between blind spots and bureaucracy

All complex organizations need some sort of administration to understand what has been done, what is going on and what is expected. The recording of past, present and future events and their synthesis is essential to develop complex thinking.

I’ve read somewhere that bookkeeping is probably at the origin of all writing systems, used to represent stocks and exchanges at first, evolving towards spirituality and literature and finally covering all aspects of life.

So, it’s only normal that some kind of administration in the form of writing/documentation is needed in projects. By documentation, I mean not only intake documents, business requirements, functional analysis, timelines, fit gap, test cases but also any kind of presentation, notes, mails, whatever support containing essential data to build the project and communicate on it.

From experience, there’s nothing more dangerous for a project than people working without documenting, in some way, what they are doing. They can be brilliant collaborators, but if their work is not documented, it will be fatal either during the project or at some point in production.

On the other hand, too much administration will slow down the project till it finally drops dead. Because bureaucracy creates dead minds.

So, how to find a balance between no documentation and too much documentation ?

First of all, when talking about balance, we have to know there are no rules, except constant adaptation. You are walking on a tightrope and whenever you try to correct your balance, you’ll have to counterbalance it the moment after.

Secondly, we need to identify the weaknesses and advantages of both sides. When you don’t document your work, you are faster; when you document it, you are more structured and can be challenged. Both are needed in project mode.

Thirdly, documentation is knowledge transfer of past considerations, for future actions. You set boundaries on which future developments can be constructed. Without those boundaries, you’ll keep reinventing the wheel.

And finally, documentation is about communicating towards other stakeholders in present or future periods. Again, as it is said: too much information kills the information. There’s nothing worse than spoiling you precious time in reading mails and reports on topics that don’t even come close to your own scope. So when sharing information, don’t consider only the “need to know” principle, but also the “useful to know” AND at what level the information is relevant (detailed/high level). No one will remember your vital communication if it is drowned in a mass of information or if it’s too complex for the understanding of the stakeholder.

As I said, there are no rules to keep the balance between both. If you set up rules, you’ll invariably fall into some sort of bureaucracy. That’s what we see on lots of Agile projects. Nice intentions, till they evolve into ceremonies and finally end up in a dogmatic religion without any agility...

Regularly, ask yourself the questions:

• do I need speed or am I consolidating a structure;
• is it a quick workaround or a building block for the company;
• am I losing track of all the requests exchanged by mail, Team, chat, phone, during meetings…;
• will all stakeholders understand my documents;
• are there any “politicians” between the stakeholders that could harm the project or myself if I forget to communicate to them.

The list is as long as your own experience. My personal advice: never forget we’re there to SOLVE issues, so focus on the action first. But take time to document the pillars of your work. And create templates that you can reuse, even when you change company. This will avoid losing time in thinking about the structure of your documents.