just-in-time-documentationOne of the biggest problems many MSPs I talk to have when first figuring out how to address changes to their security stack is, how in the heck they can get anything done!

It doesn’t matter whether you have an entire team of 40 or more technicians devoted to supporting your clients or whether you are a one-man band looking to grow your team out as your opportunities grow. If you aren’t making the way you do documentation more agile based, you’re probably missing out big time.

How do most MSPs currently work documentation?

Does this scenario sound familiar? Someone doesn’t know how to do something. Maybe you want to implement a new tool—say you want to add an offering to your cyber stack. Before you implement the product for clients, you first test it on your own network and document how to implement and support the system.

Your team has the best intentions of getting the documentation done this week (very latest, next). But then some emergency tickets come in and they aren’t able to get to working up anything for that new product.

They probably had already took a test drive and tested it out briefly, but they hadn’t gotten around to writing the book. At first, they went through the typical writer’s block routine. They found anything else to do but create documentation until some real emergencies came up and the project was kicked down the road.

This was exactly how documentation worked within my MSP until we found Just In Time documentation.

My team stalled on so many ideas and projects simply because they couldn’t find time to document anything.

What they really meant is that they didn’t really want the job of documenting it all! They didn’t see themselves as having the role of writing step by step production-ready documentation that the entire team would use forever going forward.

Flip the script?

Instead of never having time to write and plan out critical pieces of documentation, why not create documentation as you go and get others to update it as they work through the problem the documentation is meant to solve?

This is exactly where agile workflows and just in time documentation come in.

Here's how just-in-time documentation works. Someone has an issue, like needing to get a cyber stack component figured out. Maybe you need to add a new backup solution, or maybe some new endpoint protection. Or even how to update your process to make sure a piece of your stack is configured properly or updated.

Whatever the problem is, someone has to create documentation on how something is done.

Instead of dedicating hours perfecting your documentation that may or may not ever be used (we call this just in case documentation), you will write a living document explaining how to do the tasks as you implement a solution.

Instead of simply piling your expert technician (maybe this is you) with loads of work clearly outlining steps greener techs can run with, you are just going to tell your junior technician the steps they need to take and they are going to document the process as they go. This is how to really scale your operations.

Those technicians are going to describe steps much more clearly than you are (you will have too much knowledge to adequately document steps for someone that doesn’t have an acute understanding of how something works). You will assume too much, leaving your

Newer engineers, especially green engineers, always feel like they can solve anything. One of the issues inside of IT operations is that we must get them to kind of let loose of that that mindset and start asking for help so that we can get them used to looking at documentation. Make sure that you're making it easy for people on your team to ask for help, especially to ask those knowledge gurus.

So far, we’ve got that out of the way the ticket hero. He or she does the right thing by realizing that it's going to take them a long time to solve the issue. He reaches out to the knowledge guru for help and the knowledge grew explains how to identify the issue, how to troubleshoot and solve the problem. The ticket hero then documents the steps the guru gave them while resolving the ticket. They document the steps that the knowledge guru gave them right then, this is critical.

If you follow this process, documentation doesn’t become an extra burden. It was done through the process while they're working on the issue. And then when the ticket hero is done, they send the documentation to the knowledge guru.

They key here is that the documentation is not going to be perfect the first go around, but it’s going to be close. The more runs through the document, the clearer it will get.

If you are struggling with delegating to your team, making documentation something that people are owning, or creating a just in time process that pretty much runs on its own, visit www.galacticscan.com/just-in-time for templates on how to get started.

I can guarantee that this will help you be more effective in implementing important new security options for your clients. When you have a just in time documentation process in place, your team will be able to tackle just about any new implementation without having the all debilitating writer’s block.

Even after you document your stack, one critical piece is making sure it is working as expected. That’s where a good cyber stack analysis comes in. Simulate how hackers evade security measures and see if your configurations, processes, and implementations are working.