The Lifeblood of IT

Posted by Jesse | Posted in Uncategorized | Posted on 09-21-2007


DocumentationDocumentationIs documentation.


I know that I just lost 95% of the audience I had, but bear with me I’ll explain myself. Let’s say you have an extremely complex reporting system, or 2 systems that interface and share data. Pretty common, right? Now add in the fact that the data in both cases “starts over” every fall. Obviously I’m talking about Higher ed reporting and our student information systems. Our entry terms change, and the new class starts to roll in. Who knows where you need to change an entry term value in the reporting system? Who will add the translation values in the mapping tables of the interface? If you don’t still have the people at your institution who built the system, 99% of the time you’re going to have someone jump into the documentation at the last minute to figure out all this stuff.

Imagine then, the stress level of above mentioned IT person when they see horrible (if any) documentation. So at the last minute, when VPs and managers are just dying for new and accurate data, you have to try and teach yourself where the variable locations are, what the correct values are, etc. Now you have IT person wound up in an angry stressball that just got behind on everything else he was responsible for. That’s bad.

Fast forward towards your new initiative, better documentation practices. At the last minute your IT person is asked to update to the new year. He responds calmly – “Sure thing, I’ll grab my documentation and have it ready by the end of the day!” You think, “WOW- they deserve a raise!” You give him a raise, he’s happy and productive, you make your goals and the institution immortalizes you on the wall of fame. That is good.

So how do you get from angry stressball to the wall of fame? Well, just like everything else- it takes planning and organization. In dreamland you have wonderful documentation when a product is delivered, with smiling developers waiting to train anyone interested. In my world, we want to hit a deadline and usually follow up after a project is complete with decent documentation. At the very least, we want to outline what you have to do to update the software when a new term starts. Best case scenario is where you explain all the user documentation and back it up with technical documentation on the framework of the software.

There are tons of different documentation standards, documentation methodologies, etc. My advice is to pick a system that fits you. Don’t try to mold a million dollar software project type methodology around your office attendance system is only for 12 people. Include the important things- how to add new people, delete old people, add attendance records, etc. My boss is computer literate. She can build a website, and do just about anything in our SIS system. I try to build documentation so that if I’m gone and something breaks, she can follow some documentation and either fix the problem or know who to call to take a look at it.

Comments posted (1)

Write a comment