My former boss coined the RDI method. RDI means Reflect – Document – Inform (in Swedish: Reflektera – Dokumentera – Informera). The more I think about it, the more I like it; and I’m starting to understand the different steps in RDI as I ponder the development process at my new job.
Whenever something happens, we gain knowledge. What happened is not so important; just as long as we gather lessons from it. If a customer goes irate and we manage to fix the situation, there are some steps we can take to make sure the situation does not happen again:
Reflect
What went wrong? Why did the customer go irate? If we stop and think about it, I’m sure there are details we can see, patterns that emerge; and from these can take lesson. Or maybe we came up with a smart idea; let’s reflect on it for a moment and figure out what was so smart about it and how it can save additional time in the future.
Document
Whenever we reflect upon matters and draw lessons from them, they will invariably be lost in the wind if we don’t write them down. Maybe we will remember them ourselves – hopefully. But if we write the lessons down, there is a much greater chance that we can remember, and others may read and learn, too. Perhaps we can even formulate guidelines, write best practices; we can organize, create execution plans for the future. So when it happens the next time, all you need to do is to pull up a document and start at the top of the list.
Inform
But then, what good is a document if no one reads it? And why would someone read it? Most organizations fulfill step one and two – they reflect and document. But the last step usually isn’t taken: We never inform, or we inform inefficiently. At my present job we have tons of documents, and yet they’re not searchable. I asked my colleague the other day about a specific document that outlines the responsibilities for different parts of the organization, and his reply was “oh, I didn’t know there was such a document”.
The most crucial lesson I can draw from this last experience, and indeed from every job I ever worked at, is that documents don’t work. The knowledge and instructions that we glean from our experiences are faithfully written down into Word documents, and then they disappear from our collective conscience. Our hard-earned wisdom disappears into little containers of knowledge, stored in an archive and subsequently forgotten.
Informing others about reflections and documents can be done through emails, through live presentations, and probably many other ways. But one way that I’ve started thinking about lately is through a Wiki. This is because I believe Wikis mirror the fundamental organization of the human mind: A Wiki is more like a mind-map than a traditional archive. Everyone can, and should, contribute. It’s easily edited; as soon as anyone spots an error, correct it! The hurdle for editing an article in a Wiki is far less than finding and opening up a document, editing it and saving it, and acquiring the appropriate permissions to do so. And most importantly, Wikis are fully searchable.
I’ve seen companies try to take the Sharepoint approach, adding their documents into a website portal instead. For this type of thing I believe Wikis are far, far better. Sharepoint is nothing but a glorified archive anyway. The information is still contained in documents, it’s just that now they’re searchable (reasonably). There are still large hurdles to opening documents, securing permission to edit them, checking them out, editing them, and saving. For the rapid type of idea-based reflect – document – inform process, Sharepoint will ultimately be a large failure.
It is usually said that the closer documentation is to the source code, the more likely it is that the developers will update it. I believe so. I believe it is dead necessary to store software technical documentation in pretty much the same VCS folder as the source code itself. And the same goes for this type of information: The easier it is to collaborate, the more people will collaborate. Therefore, it is absolutely necessary to remove – fanatically – as many hurdles as possible for collaboration, no matter how minute they may seem (and no matter how much they are justified by argumentation). Hurdles have got to go. If it takes me even one more minute to perform the Document/Inform process, there’s a chance I may never do it. And then the reflections are lost.