The Importance of Documentation

October 11, 2016

Written by: Steve Glaser

Documentation is defined as the language that accompanies a product, often outlining its development, design, and technical language in clear, definitive terms. Whether you are working on building a business or home-based projects, documentation is critically important. When documentation isn’t handled properly, or even worse – doesn’t exist, problems will arise, especially if you are a new system administrator or new end user.

I work with many clients who have been through a full Applicant Tracking Systems (ATS) implementation and they need to reevaluate current processes to stay current with the software or new business process changes.  Many times the original project Stakeholders are no longer involved, or there was change over with the original project team.  There may have been changes, but never documented.  This creates support issues with their processes, such as bottlenecks, failed integrations, and/or lack of knowledge transfer.

There are several types of documentation essential to have when it comes to Human Capital Management (HCM) implementations.

Types of Documentation:

  1. Step-by-Step Walk-throughs – General Guides or Training Materials, often with accompanying visual elements like screenshots or video clips.
  2. Knowledge-base, Frequently Asked Questions (FAQ), and Forums – Resources for the end user are helpful in promoting self-service and minimizing inquiries directed to the system administrator.
  3. Product features– This lists all the features and settings, without really any real world examples. Often the help buttons inside the software points to sections of this document.
  4. Troubleshooting Documentation – What to do when a failure occurs. Where are the logs and how to read them? How to turn on or increase logging and debugging.
  5. Internal Development Documentation – This includes items such as code and development documentation, internal only features used by developers and/or testers, and architecture documentation (Note: For open source projects, this information is usually public).

There are a few things to consider when creating your HCM documentation:

  • Documentation is only as good as the ability or willingness of a person to follow it.
  • Project documentation should be accessible and well organized in a Shared Folder.
  • Project documentation should be reviewed before the project starts, during the project, and after the project is completed, in order to confirm the completed status of the project at hand. Having a poor plan is sometimes worse than having no plan at all. Reviewing documentation often reduces the time spent analyzing current processes.
  • When a project is completed, changes and updates made should also be reflected in the documentation. Most of us are not going to remember details months or years later.  A little extra time can go a long way in ensuring your system, and the team using the system, are maximizing the system.
  • End user training is ongoing. It is also important to maintain and update training materials on a regular basis or after changes have been made in the system. Also, post those materials in an Intranet page or a Share Point site so that as new end users join your organization, they are able to get up to speed.
  • Considerable time, frustration, and expense can be incurred by not properly documenting (downstream effects). Time is money.  If you have to spend more time troubleshooting your HCM system because of lack of documentation, this results in increased support and redevelopment costs.  This is especially critical for you if the issue involves recovering a system that is down, or if it involves some other time sensitive issue.

HRchitect is a leading implementation resource for many HCM vendors. As part of our process and best practices, we highly recommend our Change Management services which include an element of training, communication, and documentation.

Steve Glaser

About Steve Glaser

Steve Glaser is a Senior Consultant at HRchitect who specializes in assisting clients with their Oracle Taleo systems. He is a professional Business Analyst with seven years of experience in configuring, documenting, testing and building end-user training manuals for Recruitment and Talent technology systems.  Steve is dedicated to assisting business stakeholders and partners by finding the best solution and resolving their issues through creative problem-solving methods while providing excellent customer service.  Additionally, he has  six years of experience in providing technical support by analyzing, troubleshooting and resolving client issues.  Steve is widely recognized for his strong analytical and problem-solving skills and thinking outside of the box.