This is the first article in a series about using ITIL 4 concepts in developing documentation strategy. These articles are for technical writers, documentation strategists, and product managers who want to improve documentation.
A quick overview of ITIL 4
If you haven’t come across ITIL 4 before, here’s a brief summary:
- ITIL stands for Information Technology Infrastructure Library.
- It’s a set of concepts and practices that companies can use to align IT services with their business objectives.
- There have been four iterations of ITIL to date.
- ITIL 4 has a number of differences to ITIL 3. Most obvious is the focus on practices rather than services. If you’re familiar with ITIL 3, you’ll typically need to retrain in ITIL 4.
- ITIL 4 supports fast-turnaround methodologies like Agile, Lean, and DevOps.
Why Continual Improvement?
ITIL 4 has 34 practices in its framework. Why did I pick this one to start the series? Firstly, because it’s a guiding principle of Agile methodology. If you’re working in the software industry, there’s a good chance you’ll need to use Agile at some point in your career. Secondly, it’s an important over-arching concept in both ITIL 4 and documentation.
What is Continual Improvement in ITIL 4?
In essence, Continual Improvement is fairly self-explanatory. It’s the practice of constantly making our services better. As a practice, though, Continual Improvement consists of seven steps to cycle through. These seven steps help us to mindfully work through a structured process to choose and develop the best possible improvements.
We can apply continual improvement to our docs. Firstly, we need to think about our docs as a service: documentation is a communication conduit. Secondly, we can apply the seven steps below to continually make our docs more valuable for users. I’ll explain each step in the context of technical writing.
The Seven Steps of Continual Improvement
What is the vision?
This is big picture stuff. I know I said we’d talk about these steps in a tech writing context, but we actually need to step outside of tech writing for this one. What’s the vision of the entire company? This vision is something typically shared from upper management and CEO/CTOs. It’s basically envisaging the company’s overall situation in five or ten years’ time. If you’re not sure, see if you can hunt out your company’s vision statement.
Think about how documentation might align to your company’s vision.
Where are we now?
Look at the current documentation in light of the company vision.
Some areas to consider:
- User engagement
- Customer satisfaction
- Customer support topics (is the customer support team frequently answering user questions on specific topics?)
- Turn-around times
- Update frequency.
Based on the company’s vision, decide on at least 2 objective metrics for the current documentation. You want concrete numbers that you can use to measure your progress.
If your company aims to be extremely approachable and gain a market share through word of mouth, you might want to focus on user engagement and satisfaction. Your metrics could focus on the number of unique users visiting your help site, the amount of time they spend on the site, and the level of customer satisfaction regarding the help site.
Once you’ve picked your metrics, measure the current situation. This gives you your baseline to improve upon.
Where do we want to be?
Unlike the vision step, here we’re focusing on a short-term goal in a specific area: documentation. The goal that you choose must help the company progress towards its vision. If you can’t link your goal directly to the company’s vision, then it’s a distraction, not an improvement.
Your company vision is that by 2030, it will have offices and market share in 20 countries in the Asia Pacific area. The metrics you choose might focus on the percentage of translation-friendly documentation, as you can see a future need for docs to be translated into multiple languages. Your short-term goal might be to make the 10 most-visited documentation pages translation-friendly.
Pick a short-term goal that’s focused on documentation, improves the documentation, and moves the company (however incrementally) towards its vision.
How do we get there?
We don’t often get the opportunity to improve documentation in isolation. Typically, there’ll be other – important! – demands on your time. In this step, look at how you can work towards your short-term goal without dropping the ball on other work.
Your short-term goal is to write documentation that answers the top three questions that users ask your customer support team. But you also need to keep the existing documentation up to date through six Agile sprints, with code changes happening every sprint. You talk with your team and product owner and decide to devote 10% of your time to creating the new doco.
Put together a plan for reaching your documentation goal in a short-term time frame.
Put your plan into action. This step takes the longest – the time frame you decided on earlier.
Did we get there?
At the end of the specified time frame, look back over your goal and your progress towards it.
- Did you reach your goal?
- What did you learn?
- Did you identify any other improvements needed?
You need to use the same metrics that you used in the Where are we now? step. That way, you can compare your situation when you started and your current situation.
Failure to meet your goal isn’t disaster. One of the key concepts in Agile methodology is ‘fail faster’ – short iterations might fail, but provide learning opportunities. If you learned how not to go after your short-term goal, then you’ve gained a positive outcome. And if you learned how to do it better next time, awesome – that’s actually continual improvement in action, even if it’s in the realm of personal development.
How do we keep the momentum going?
This key step is often neglected. It’s really important, though. If you hit your short-term goal, how can you ensure that the improvement you’ve made so far keeps happening? If you didn’t, how can you modify your progress through the steps for this next round?
Depending on the goal you used, this step might involve:
- Creating a similar new short-term goal that continues along the same path. For example, a new goal of 20 translation-friendly documentation pages.
- Reworking the steps around your original short-term goal. For example, changing your plan to accommodate what you learnt last time.
- Putting processes in place to keep your improvements current. For example, ensuring that new documentation will be updated for future functionality changes.
- Creating a new short-term goal to automate processes developed during this round. For example, your new goal might be to automate delivery of a weekly customer service report that outlines the top 3 customer support queries.
Your aim in this step is to keep entropy from dissolving your improvements.
This is a cyclical process, so your next step is to return to looking at your company’s vision.
Want to know more about continual improvement?
There are lots of courses available for ITIL 4. They’ll teach you not only about continual improvement, but about the concepts and strategies around it. Search for ‘ITIL 4 foundations course’ on Google.
Or, you can use my favoured option and sign up for access to LinkedIn Learning. Dion Training has a good ITIL 4 Foundations course available there.
A quick note about the featured image for this post: Kaizen and ITIL 4 are two different frameworks. I like the imagery, though, and they do have a lot in common – even if the practices used are different.