How do you find time to write documentation?

[-]

AspectAdventurous498@reddit

Using pre-built and customized templates in IT Glue, so I don't have to start from scratch each time.

Reply

[-]

In some places any "background" non-frontline work gets under-resourced or skipped because it is not in a "ticket", and the "PKI" is "tickets". I have found that in those places putting in "internal" tickets for things like "document network server X" might work. In some other places managers instead deliberately skip "background" things like documentation, monitoring, testing, upgrades, and even backups, as a way to win bonuses for being more "cost effective".

Reply

[-]

TheLostITGuy@reddit

100 person non-profit: Itune admin, contract with MSP, Network engineer and a database admin . . . Non-profits have all the money.

Reply

[-]

Darkchamber292@reddit (OP)

Lol WTF does this mean? Are you brain dead? Every company needs an IT team. Also our IT team is new. Only about a year old. Company has been around a decade and JUST got an IT department. 4 people.

Reply

[-]

TheLostITGuy@reddit

Go outside and take a walk buddy ... You seem stressed 🙄.

Reply

[-]

Darkchamber292@reddit (OP)

Lol you're taking the piss. You go outside 🤡

Reply

[-]

TheLostITGuy@reddit

Get therapy.

Reply

[-]

MekanicalPirate@reddit

Fridays, working from home

Reply

[-]

AshyTreats@reddit

If I'm doing a new process I take screenshots and paste them into a word document as I go, then once a chunk of the project is done I go back and annotate what I'm doing in each screenshot. Seems to work for me as it's less distracting than stopping to write a paragraph of explanation each time, but the screenshots mean I can remember what I was doing at that stage of the process. What we don't do is update old documentation enough, but we need a better system than a folder full of word docs for that really. I guess we could just sort by date modified if we had the time to burn updating old processes.

Reply

[-]

PopPrestigious8115@reddit

This is so typical and done by so many admins (I myself included..... in the past)..... the "screenshots dump solution". I like to document but only when I have time. I also liked to do that with Word but not anymore. A customer of mine pointed me at docFreak not long ago when he saw my frustration with resizing images in Word and trying to get hyperlinks from there to an Excel spreadsheet and a few Pdfs. He then asked me to document with that tool. I told him with arrogance, "I'm not gonna use that because people want to recieve a Word or Pdf file as documentation". Then he got a bit annoyed, told me to make the documentation with docFreak and add/create Word and Pdf output from there, "for yourself!", he added. .......oooops........ Okay, I was forced to use a fairly unkown desktop (does not have a cloud version) tool but I still use and like it today. Yes indeed, the "the screenshots dump solution" is still there but inside a single container file of docFreak (including other related Word, Excel and office files, all internally hyperlinked, tagged and visualized by a tree inside as well) but in far far less time composed to what I normally do when using Word. Not everybody wants to use this tool but most customers of mine see the advantage when I only add 1 single file (with all other related files in there) to their enterprise workgroup software like SharePoint, webserver, Wiki, Confluence, Jira and documentation file share. It is a pity that it does not have a mobile or cloud version but it is at least so much better then the out of context amateurish "screenshot dump solution" to a folder ;-)

Reply

[-]

AshyTreats@reddit

Is this an ad or something? 😂 I don't struggle resizing images in word so I think I'll be okay

Reply

[-]

PopPrestigious8115@reddit

Well I'm not a fan of Word anymore indeed ;-) I will explain the resizing problem. Resizing is actually not the problem but keeping it sharp enough is, when you have to resize an image with a lot of details and still must fit on A4 or US letter... which is a typical demand of many customers when you have to use their templates....... brrrrrrrrrr .

Reply

[-]

AshyTreats@reddit

Bruh just admit it's your software, even if it was the best thing since sliced bread I'm not going to use something you're trying to to astroturf on reddit 🤣 Get bent, and I'm sorry to hear you're so incompetent that you're struggling with image sizes still, I thought most of us figured that out in high school but each to their own.

Reply

[-]

gamebrigada@reddit

A proper ITIL process helps this so much. But essentially you want to build documentation into the project. If you can do it after completion, great but you realistically can't. So either document as you go, or if you should be documenting all the design decisions BEFORE YOU MAKE CHANGES.

Reply

[-]

awit7317@reddit

Speaking of high staff count, ITIL says “Hold my beer”

Reply

[-]

caa_admin@reddit

I follow the 'just start' method. I installed a mediawiki(r/bookstack is nice too) and just start adding information. As time goes by I add to it with details I learn along the way. It makes it easier for whoever replaces me, I hope. :)

Reply

[-]

awit7317@reddit

So much this! And remember, perfect is the enemy of good.

Reply

[-]

Sgt_Dashing@reddit

You have your Jr following you around writing everything down Then when there's issues you yell at them to find their notes while you fix the issue. Symbiosis

Reply

[-]

awit7317@reddit

Scribe old school !

Reply

[-]

ITLawngnome5878@reddit

What I have found myself doing as of late is as you go. You fix something and know there isnt documentation on it? Take the 15 min and get it on paper while fresh in your head. I also like to include code snipits or screenshots of my terminal in the documentation so its easier to follow. By doing the write up immediately after makes it easy to grab and include that.

Reply

[-]

Proof_Potential3734@reddit

Read only Fridays my friend. 8 hours of no touchy, just writey. It's a great way to document things before you forget what you did, and it gives the whole team time to review your changes and edits before you push them to the kb.

Reply

[-]

mendrel@reddit

It feels like there's two parts to this question: 1.) How can you take the time? 2.) Are there recommendations/best practices/how-to on the writing and organization of the documentation.  Part One: Time Are you ready for the BS answers? 1.) Leave yourself a voicemail. 2.) Record yourself talking through the steps. 3.) Loom How does this work? A lot of VM systems now do transcription. By leaving yourself a voicemail you can (likely) get a transcript of you talking through the steps that can be copied to another document. But the length may be limited. If your system doesn't support that and you use O365, you can 'upload' a .WAV to a Word document (Home->Dictate->Transcribe : [Link](https://support.microsoft.com/en-us/office/transcribe-your-recordings-7fc2efec-245e-45f0-b053-2a97531ecf57)) and get a similar effect. There are limits to this as well, but it can be effective. Finally, Loom can record you and your screen as you talk through the steps. It can be an effective way to share not only the steps, but any extra explanation as needed. All of these can be done with fairly minimal cost/time investment and could be part of your workflow as you go through issues.  Part Two: How? Do you have a budget for the solution? The answer is 'Yes' because you're already spending time doing this. Whether it is paid time depends on how your organization works. Hopefully it all works in your favor. Organization and communication is a challenge. If a system was organized enough, text documents would be fine right? But we all know that it doesn't quite work. SharePoint (again, if O365) can be a help with organizing if managed and done right. As a step up, it might be worth looking into something like Hudu to capture the documentation in a manner shareable across the team. But, like all SAAS applications, it requires licenses and yet still...your time. As many others have said, documentation needs to be part of the ticket/project/task but most organizations don't allow for the bandwidth for this to happen. MTOBEIYF

Reply

[-]

Det_23324@reddit

I've started doing videos, if I don't feel like documenting the whole process. I think its more effect actually than documentation...because you won't miss a step.

Reply

[-]

kennyj2011@reddit

Im terrible at the voice over

Reply

[-]

LessRemoved@reddit

Plan time for it. Block your agenda and just write it. Do it in small chunks and plan what you'll do when.

Reply

[-]

bitslammer@reddit

The first step is to make sure documentation is part of every single project and every single change. A project should not be considered "closed" and a change should not be approved until all documentation is finalized, reviewed and approved.

Reply

[-]

NotSoSimpleGeek@reddit

This. Build it into the project. Also document as you go if you can, which can also help you retrace your steps if you need to.

Reply

[-]

Lemonwater925@reddit

Absolutely. Need playbooks on all sorts of tasks. Works to your benefit. The initial start up is going to be onerous. But, once there someone needs info check the playbook. Network diagram. Same. Escalation tree.

Reply

[-]

Techplained@reddit

Have a long conversation with chatgpt and then ask it to create documentation

Reply

[-]

StaffOfDoom@reddit

I make notes in the tickets I work, then take those notes when things slow down to then make documentation out of. The key is to be as detailed as possible in the notes so that copy/paste is the majority of the work…

Reply

[-]

doweactuallycare@reddit

This is how I do it. 90% of my documentation is just copy-paste notes from things, put together and worded out a bit better. I make the documentation in as much of a single run as possible but most of the work is naturally done over time, by note taking.

Reply

[-]

thortgot@reddit

Documentation can have various purposes. I'm going to outline documentation for projects rather than tickets. Documenting the what (config, inventory etc.) is dead easy but largely irrelevant. If anyone wanted to know "the what" they could trivially get that information. It's convienant to document for simplicity. Documenting the how (process, deployment, troubleshooting etc.) is more important but can also be tedious since it should in theory be the same method as the vendor would provide. Cloning vendor docs is a good way to jump start this question. Documenting the why (Product selection justification, business goals, scope limits etc.) is the big question almost everyone misses. This is information that is nearly unreproducible after the fact. I can't tell you how many man years have been wasted because someone didn't document why they chose X over Y.

Reply

[-]

amazinghl@reddit

Document as you go.

Reply

[-]

pilken@reddit

All of those Friday afternoons (all of them) that I refuse to make changes in production - are now set aside for documentation. It's in the calendar as "busy" and DND is on for those 4+ hours.

Reply

[-]

Axiomcj@reddit

Before the project kicks off documentation and diagrams and traffic flows are required. Make sure that's the standard. I use notion.io for everything and then share that with my team members who support whatever application we are implementing/testing/using. How to, installs, issues, faqs, videos, training on it all in one place within notion.

Reply

[-]

ProfessionalWorkAcct@reddit

I wish I had a network tech, a database tech, and an MSP assisting me.

Reply

[-]

freakinuk@reddit

My thoughts too.

Reply

[-]

freakinuk@reddit

Not being funny but there's three of you and an msp for a 100 person company? How do you not have the time? Sounds like there's some fundamentals to get resolved to buy you the time.

Reply

[-]

_haha_oh_wow_@reddit

I do it as the issues come up, no time like the present!

Reply

[-]

Empty-Zucchini@reddit

You can document everything as best as you can and still forget to doc enough so that the next person has a puzzle. I have never once walked into an environment where it was perfectly documented.

Reply

[-]

thee_network_newb@reddit

Most of the time it's as I go. Generally if I wait it takes twice as long. Sometimes we have a lull in action generally on Friday I carve out like 2hrs. We use Asana where I work and I make tasks on what needs documentation.

Reply

[-]

Darkchamber292@reddit (OP)

We just started using Asana and I deployed it to our whole Org. This is a great idea!

Reply

[-]

thee_network_newb@reddit

I believe you can even make private notes as reminders that only show up in your task so nobody else can see them.

Reply

[-]

Darkchamber292@reddit (OP)

Is there a way to share just a task without sharing the whole project? I had a user ask this today. I don't think there is but figured I ask

Reply

[-]

thee_network_newb@reddit

Try and see if you can add a collaborator that might allow you to see it.

Reply

[-]

MDL1983@reddit

Do your documentation as you go. It doesn't necessarily have to be perfect the first time you do it, just key points / bullet list to ensure you can refer to it next time. When you use it a second time, refine it further, and so on. I use OneNote, but you could also use Obsidian or anything else you want. Here's a screenshot of my layout >  https://preview.redd.it/z16ju8tqp4oc1.png?width=1493&format=png&auto=webp&s=7405c88f06fbdfa5869eae0d4bf56051f03325b4

Reply

[-]

Skoho-Thot-Entot@reddit

There’s two types of cooks. The clean as you go cook and the create a huge mountain of dishes you need to clean up at the end, cook. Documentation is the same. Do it throughout the project so you don’t have a mountain to deal with at the end.

Reply

[-]

OneJudgmentalFucker@reddit

I've learned to take at least a page of notes for every hour of work. It helps dramatically

Reply

[-]

WeekendTacos@reddit

Always remember, you may have to go back and make little edits here and there, it's not the end of the world, but make sure if something changes you document that change as well.

Reply

[-]

Opening_Career_9869@reddit

lol aint nobody got time for dat!

Reply

[-]

Unable-Entrance3110@reddit

I am the one implementing so I just make writing the docs part of the project. It's the last step before I mark the project as complete. Documenting is an art and I have found that I enjoy a well crafted document almost as much as I like getting neck deep in the details of a project.

Reply

[-]

schizrade@reddit

Notes as you go, scaps as you find needed, then make it all come together in whatever platform to file system you use. You just have to make it a habit and part of your workflow.

Reply

[-]

heapsp@reddit

"I'm often working late into the night resolving various issues in Intune because I'm the only person who can on my Team" You are never going to document your way out of that, you need to convince whoever is leading the department that knowledge transfer needs to happen, then you need to show the others how to do what you are doing, then the next time it comes up, have them drive, then the third time it comes up, have them handle it solo.

Reply

[-]

matt95110@reddit

I don’t really bother with extensive documentation anymore. Every company that I have ever worked at has sucked at documentation. They either fail to maintain it or put it in a central location to make it useful. If someone wants to look at the random stuff I have in OneNote they can go nuts.

Reply

[-]

WinWix117@reddit

I use OneNote for all my daily tasks, things I find interesting, etc. Kind of like a journal. It's not pretty, nor is it meant for anyone else to look at. For things that require documentations - I take what I've written in my personal OneNote, and daily, or set schedule, re-write the key aspects into the documentation.

Reply

[-]

Warod0@reddit

Documentation is part of every project-ticket-case. Budget time for it like any other steps.

Reply

[-]

GullibleDetective@reddit

Bake it into your ticket

Reply

[-]

-quakeguy-@reddit

A ticket or a change cannot be ”resolved” unless all requirements have been fulfilled and one of the requirements is documentation and whoever just ticks the box without actually doing it too may times eventually gets in trouble.

Reply

[-]

TotallyNotIT@reddit

Scribe. Scribe is fucking awesome. Hit record, do the thing, hit stop, documentation is created with screenshots and a synopsis.

Reply

[-]

andrew_joy@reddit

The implimentation is the documentation. We call this peak efficency.

Reply

[-]

jeezarchristron@reddit

I write as I go using OneNote then export as a PDF when done.

Reply

[-]

thee_network_newb@reddit

That's pretty clever never thought about that.

Reply

[-]

Hotshot55@reddit

Part of my job is writing procedures. If a new task comes in that nobody has done before, it's expected that you will document it. I also add in extra time to my estimations to give myself the time to actually write things down.

Reply

[-]

JMDTMH@reddit

I recommend looking into Scribe.  It's AI driven, but it will create documentation for you, based on the task you are completing.  We have been converting our documents over.

Reply

[-]

North-Revolution-169@reddit

It's a mindset change. You need to start seeing it as a mandatory part of the task and not as optional. You're the only person who can resolve these things because of your own conscious decision not to document.

Reply

[-]

EricSec@reddit

1. Just start documenting stuff, and put all of your documentation in the same place. This will get the ball rolling 2. Search for currently existing documentation, and document the various locations, so you can find it all later 3. Keep a list of all of the topics that you know are missing documentation 4. Come up with a documentation plan, and propose it to your manager. For example, 1. Where will you eventually store all data 2. How will you categorize it? Per system/application, user documentation vs. admin, etc. 3. What format will it be stored? PDF, Word, Wiki, etc. 5. Organize, merge, and format documentation according to your plan. This will be a long tedious task, and you will likely want to dedicate 15 to 30 minutes per day on it.

Reply

Reply to Post

66 Comments