Techies are cursed by the reluctance to create documentation. This is so bad when a member of the techie sect actually starts becoming diligent and creates some documentation he or she is ridiculed. My opinion is that technologists have evolved into a mindset where the expectation is to be spoon fed and mollycoddled. In the good old days, it was common practice to tell people to
RTFM. This was the "old school" way I learnt Computer Science. Nowadays this is deemed rude. "
RTFM or Google it are two inappropriate responses to a question. If you don't know the answer or don't wish to help, please say nothing instead of brushing off someones
question. Politely showing someone how you searched or obtained the answer to a question is acceptable, even encouraged. If you wish to remind a user to use search tools or other resources when they have asked a question you feel is basic or common, please be very polite. Any replies for help that contain language disrespectful towards the user asking the question are unacceptable and will not be tolerated." (from the Forum Policies and Expectations - Ubuntu Forums). If these wimps are not expected to do some of their own reading and research there is no chance in hell that they will create any documentation. It is time to be a
traffic cop.
Being involved in problem management I have gathered some stats about the major incidents that have crossed my desk. The service that causes the most major incidents is data networks. This is no surprise as in this neck of the Kalahari the former telecommunications monopoly that dominates the market is not renowned for service excellence. This is followed closely by messaging and then voice. Again no surprises as the email and voice systems are by far the most used IT systems.
The statistic that is of more interest in this blog is the second one. The cause of most major incidents is around mis-configurations. This is often because techies do not configure a system or solution correctly. Further analysis usually indicates that the techies never bothered to
document it in the first place and the reason for the incorrect configuration was that they were flying blind. Next is component failure. Again this is traced back to not knowing what systems are where and what the warranty and maintenance schedules happened to be! Yes, you guessed right! Again insufficient documentation. The next category are the vendors (carriers and service providers). I will deal with vendor management in another blog post.
The documents that should exist and are never created are Standard Operating Procedures, also known as SOPs. The term is used to describe a best practice approach to executing tasks related to hardware and software maintenance, as well as incident and change management. SOPs are created to provide specific documentation for various processes, usually highly-technical processes. Businesses are finding that they lack this kind of documentation; either there has been inadequate process definitions altogether, or they have no documentation in place. When reviewing the existing documentation, it is important to know where a particular SOP may be needed, or that the SOP available is detailed enough or not current.
The reasons for a SOP are:
- To provide techies with all the environmental and operational information necessary to perform a job properly.
- To ensure that IT operations are performed consistently to maintain quality control of people, processes, partners and products.
- To ensure that processes continue uninterrupted and are completed on a prescribed schedule.
- To ensure that no failures occur in the live environment that could result in major incidents.
- To ensure that approved procedures are followed in compliance with corporate due diligence and compliance to regulations.
- To serve as a training document for teaching newbies about IT processes.
- To serve as a checklist for the techie's superior when job performance is being evaluated.
- To serve as a checklist for auditors and they become an important part of compliance due diligence.
- To serve as an historical record of the how, why and when of steps in an existing process so there is no hearsay when reviewing a process when a process has changed. As people move from job to job within and between companies, unwritten knowledge and skills disappear from the workplace. Properly maintained written SOPs can chronicle the best knowledge that can serve new workers when older ones move on.
- To serve as an explanation of steps in a process so they can be reviewed in major incident analysis.
The SOP should take the following format:
- Title and description (include reference numbers)
- Definitions
- Scope
- What Vital business functions are being serviced?
- Lessons learned
- Equipment, hardware and software lists
- Daily availability checklists
- Diagrams
- Full system configuration
- Testing plans
- Schedule of administrative and maintenance tasks
- Costs and charge back models
- Risk mitigation actions
- Continuity plans including disaster recovery and methods for restoring data
- Escalations
The following are guidelines that apply. Use pictures, diagrams, tables, and bulleted lists for quick reference. Often screen shots are great. Keep the steps involved to a maximum of ten. If the steps are more than this amount, break it up into logical sub procedures. Review the effectiveness of SOPs after a few weeks and make necessary changes if in-the-field practice suggests that descriptions should be improved. A SOP template is available
here.
Some of the important Infrastructure SOPs required are:
- SOP for major incidents and problem management
- SOP for handling security incidents
- SOP for messaging
- SOP for directory services
- SOP for WAN quality of service
- SOP for video conferencing
- SOP for corporate voice, least cost routing and branch to branch links
- SOP for call centre
- SOP for voice recording
- SOP for SAN and storage
- SOP for backup and restore
- SOP for virtual servers
- SOP for patch management
- SOP for server images
- SOP for hosting
- SOP for access management
- SOP for hardware management
- SOP for anti-virus
- SOP for network management
- SOP for cabling
- SOP for licensing and asset management
and my final opinion on the subject is, "READ THE
~!@#$%^&*()_ SOP."
NB: The SOP template has been updated!!! Read about it
here.
I wrote about the "techie curse" some time ago. Techies don't create documentation and most environments are a SOP (Standard Operating Procedures) desert. In every job in which I have started, no-one has ever given me a SOP of the services being provided. I would have to "sink or swim." Most techie managers who were treated in this manner, reinforce the behaviour by treating their subordinates in a similar manner. In reality they even go further to ridicule those who create documentation as bureaucratic. By this they imply that it is a waste of time but often the underlying reason is to be able to be a hero, as when the sh1t hits the fan, they are the only ones able to resolve it, as all the knowledge is in their heads and not on paper for anyone else to attempt to resolve. I have even been told that it stops their ability to be "business flexible." What a load of codswallop! Imagine if a new hire was given a SOP of the service they are responsible for delivering on day one of their tenure. Alas, most techies spend the first three weeks of their job being unproductive.
