Over documentation
-
At what point is it too much? I just had a meeting where we created a document about how to create the document for the project plan of a project so that we can present that document in a different meeting. I will literally spend hours doing meetings and documentation around this project before I ever actually get to start doing any real work. Sometimes I miss my crappy menial labor jobs because there you were just told what to do and you did it however you could. No meetings, no paperwork, no documentation. Request for work was presented, work was done, end of day.
-
The idea of creating the document to help you build out your documentation in theory should be a one time thing... As the management side of things I would say that there is hardly ever a case where too much documentation is an issue. All documentation should be done on the theory of "what if I get hit by a bus today?" can someone else step into my position seamlessly and the client not see any lag?
-
@Awkward-Gamer I know what you mean. Now where I thought you were going with this at first. LOL
Anyways, I agree. Paperwork can be a pain. There is a line between CYA/good notes and just raw stupidity. Too bad most management don't know the difference. @minion-queen is an exception to that.
-
I agree with @minion-queen whole heartedly. You want to be covered so that others can pick up the pieces but also have enough to remember what you did. If you're a MSP, it is important to document what the project requires before you start so you have a clear scope of work and that you are giving your customer only what they paid for in the beginning. That can properly set expectations for the project at the whole and avoid issues on both sites.
For internal IT stuff I can see this to some extent. Defining scope could save trouble later down the road, and documenting all of the config could help pick up the pieces later if there is a phase 2.
It sounds to some extent like you need to get a standard template going for these projects (just a general one that can be changed as needed specific to the project you are doing).
-
At what point is it too much?
Basically, when it prevents other work from getting done. It is not a one-time thing. Rather, needs be continually revised and reviewed. Not to mean at an OCD level, rather a guideline/checklist level and by different people. Fantastic times for documentation reviews are when a person leaves, and when a new person comes on board.
It will take many iterations for I.T. operations to get the right documentation feel for the culture.
"Hit by a bus" stuff is DR/BCP. Typically higher level, and review ought be no less than once a year. Timing can be pre-business peak time, post peak time, post end-of-fiscal-year, or whatever is agreed on .. by senior management (not I.T.) who ultimately ought be the ones checking it out as BCP is their responsibility.
-
First, many people perceive documentation as something they write and shove in a pile. This isn't true, especially in regards to IT. Stuff changes and with it the documentation must be kept up to date. Yes, you have to invest the initial time, but once you do, revising the documentation in the future is a fairly easy process that should be done on a regular basis.
Documentation should always cover absolute worst case scenario. As in should the entire department be unavailable or turned to zombies or whatever and new people have to come in from the ground up.
And if you think there is a such thing as too much documentation, try complying with documentation for ISO... that can be a headache...
But @networknerd stated, the best way is to start with a template. Then outline what all you want to cover. It gets easier the more you do it.
-
@Minion-Queen said in Over documentation:
The idea of creating the document to help you build out your documentation in theory should be a one time thing... As the management side of things I would say that there is hardly ever a case where too much documentation is an issue. All documentation should be done on the theory of "what if I get hit by a bus today?" can someone else step into my position seamlessly and the client not see any lag?
Too much documentation, though, can result in people being unable to find what is needed and the time needed to maintain it can become a point of inefficiency. And the more that there is, the more likely that it will go out of date and become a negative rather than a positive. Only good documentation is useful, and the more documentation you have, the higher chances that some of it will not be maintained.
-
@scottalanmiller said in Over documentation:
@Minion-Queen said in Over documentation:
The idea of creating the document to help you build out your documentation in theory should be a one time thing... As the management side of things I would say that there is hardly ever a case where too much documentation is an issue. All documentation should be done on the theory of "what if I get hit by a bus today?" can someone else step into my position seamlessly and the client not see any lag?
Too much documentation, though, can result in people being unable to find what is needed and the time needed to maintain it can become a point of inefficiency. And the more that there is, the more likely that it will go out of date and become a negative rather than a positive. Only good documentation is useful, and the more documentation you have, the higher chances that some of it will not be maintained.
We had an old guy that would "document" everything. He had tons of binders full of stuff and his home directory was huge with "documentation." His documentation was he would make a tiny note and then run a command and copy the output. That's pretty much all his notes were spanning back to ~2004-2005. He left and we ended up throwing it all away because we couldn't find anything useful at all.
