Across the IT industry, we rely on experienced technicians so much to just “jump in and do”. We put ourselves at risk when it comes to being able to adequately and confidently support IT systems by not documenting critical (or even mundane) processes and not having a documentation strategy that includes defined templates, creation, review, and archival.
When it comes to major incidents, minutes matter. If you’ve worked production or application support for any length of time, you’ve likely run into this scenario. System X goes down, prompting a major incident. Support teams are paged to a call to mitigate the issue. Support team Y representative joins the call. They are provided with a synopsis of the issue at hand only to respond with, “I haven’t done that before. We need to get my teammate on the call to address this.” A second page is issued for said teammate, and the teams on the call now wait for that resource to join. Again, minutes matter.
In the scenario above, if it occurs during business hours, and all necessary team members are working, this may not elongate the period of impact, or at least not by much. Figure in incidents that occur after hours, on weekends and during PTO and you’re potentially looking at a very different story. Minutes can become agonizing hours. Colleagues trying to enjoy some work-life balance feel the scales tilt,, and another soccer game or the party for Nana’s 98th birthday gets missed. Now you have colleagues that are downright angry for the interruption.
If your organization doesn’t have processes in place around support documentation management, or they are a bit haphazard in areas of consistency, there are some initial steps that should be taken to get you off the ground smoothly:
Create your plan
Decide Who Should be Involved
Decide the standards that should be defined, including:
- Location/Tool - Ideally the repository should be easy to use, searchable, and have the ability to store multiple documents/images with details around creator, creation date, and date last modified and/or reviewed.
- Templates – Naming and format consistency is important for usability.
- Content – Screenshots, error messages, and escalation points should all be included. You want to make it easy for the reader to ensure that they are looking at the right document for the right system or task.
- Publishing/Review – Standardizing a review process for initial publishing ensures that the details in the document are clear to the reader. As technology changes, documentation reviews should be completed periodically to identify necessary changes that may be needed, or when archiving is appropriate. At minimum, this should be done annually.
Consolidate, review, and archive existing information
If there is legacy documentation from previous efforts, identify all existing support documentation and move it to the new centralized location.
Determine what goes (archive), what stays, and what needs updated.
If you think documents are no longer used, move them to an archival location for a specific period. Once that time has passed, if they remain untouched, clean them out.
Find the gaps
Start simple, ensure day to day work is covered, including:
- Daily tasks/processes
- Reporting/Dashboards – include where the data comes from
- Recurring meetings – logistics, purpose, and expectations
- Acronyms defined
- Escalation/Emergency procedures (aka critical contacts)
Expand your scope
- Identify tasks that are always done by the same person
- Identify “routine” maintenance procedures (patching, DR, etc)
- Diagnostic, recovery, and validation procedures
- Review incident and problem data to find opportunities
- Poll your team, particularly newer members
- Listen for additional opportunities
Time. Support. Upkeep.
Committing the time to a solid knowledge transfer and documentation process is an investment in the successes of the team. The claim that we don’t have enough time should be proof in and of itself that we need to make the time. In tiered organizational support, there’s opportunity to hand off work supported by well documented procedures to other teams with bandwidth and resources. A well-documented troubleshooting document can be the difference between identifying incidents before they happen and fighting the “fire” after the fact.
Identifying and supporting a documentation strategy lays a great foundation for growth. Documentation can be used as training aids when onboarding new colleagues. It can also help identify inefficiencies; what manual processes have an opportunity for automation? What is the MTRS for issues supported by good documentation versus those without?
No, documentation isn’t “sexy” like writing code, architecting a new solution, or solving issues, but it’s necessary. Committing to the upkeep of documentation ensures that the benefits continue. Having that foundation allows you to focus on primary functions (aka the “sexy” stuff) when you’re not trying to recall or solve from scratch every time. Not to mention that regulatory teams like Risk and Audit love to see a good doc repository.
Angie Handley has a broad background in information technology and is an experienced IT leader in application production support, technical training as well as incident and problem Management. She is ITIL and HDI certified and has a degree in Information Technology. Her career passions include is building effective, happy teams, creating lasting partnerships in both IT and business as well as leveraging business and IT process improvement techniques to make processes more efficient, cost-effective, and reliable for both IT staff and their customers, both internal and external. Currently, Angie is the Manager and Process Owner of Problem Management in the Financial Services Industry. Outside of work, Angie enjoys working with local animal rescues, volunteering time with Lions International and playing Pickleball.