How to enforce documentation / file structure at an organization
Hey Tildes,
I work at an international company which, over the course of COVID, probably had a turnover rate of 80% over two-three years. This was less due to the company, and more due to the incredibly restrictive COVID policies that the country we are located in tried to enforce. I was brought on in 2020, and due to the hemorrhaging of long term employees, a large gap in institutional knowledge was created.
We aren't a tech company, and use Google Workspace/Drive for a lot of our storage and documentation. Within my department I recently put in a lot of effort to create a file organization structure and proper documentation so that we would no longer lose resources and knowledge when people left - and a main purpose was to make it as easy for people to use, cut down on work, find information faster, and provide an easy way to leave with a bunch of resources if they wanted to move to a different company (we aren't in a field where we really compete with others or would lose an intellectual property). It was received with a ton of positive feedback from my peers and direct superiors.
This effort was recently noticed by management and I have been tasked with providing a rollout plan to get the entire organization on a similar structure with documentation processes for every department. My issue is, how does one enforce usage and standardization of documentation and following a certain file organizational structure? While I can think of a ton of ways to structure my process, communicate, and demonstrate the benefits to people, I know that there will be resistance (and in some cases, non-compliance) from staff. I am more than willing to work with them, provide training, and do a lot of the leg work myself, but I am wondering if anyone here has gone through something similar and has good strategies on what I can only describe as leading without authority.
My initial plan was to use the results from my department to get the more enthusiastic departments on board first, and then hopefully good word will spread to help reduce friction with other departments that may be more resistance and not as technologically inclined. However, I know that no matter what I do, I will hit resistance at some point.
The only two times I have had a similar task at a previous employer I had absolute full reign over everything, and it was a completely solo endeavour, or was working with such a small tight-knit group that I didn't have to worry about non-compliance. This is my first time working on such a project in a larger organization and could really use tips from others experience.
I'm trying to not dox myself here - but hope I provided enough information to get some overall tips and comments.
enforcement is so tied to how easy the solution is to use. I've worked at several manufacturing companies that have had various success levels in file management. the key is making it easier to abide by the rules than go against the grain.
some tips I've seen work well.
build a template folder for the structure you want. try not to make things buried in the tree. you really should only go down 4 folders max. try to keep individual files out of the main hubs (never lvl 1, very rare lvl 2)
automate repeating folder templates creation. We have a folder for every work order number we produce. I made a tool that would add a new numbered folder in the sequence with blank files as placeholders for files that needed to be in there. then you could save as over the blank file. PO 123456 is a blank PDF. when a user prints a file to .PDF from the software, they navigate to the WO folder and overwrite the file. this was making it easier to abide than fight.
set permissions for where people can create folders or save files. this helps with non repetitive folders.
set them by job role or department. accounting staff can create folders in the accounting folder but only them. senior staff can access and maybe save a file but no one else can. mapping these permissions out in a chart really helps the people approving these changes understand.
give people their own stash folder for junk but encourage them to put shared documents in the correct location. rather there than on their local hard drive for when they spill coffee on their laptop.
structure enforcement is very tricky. you don't want to come off as a file Nazi on day one. these guidelines or rules need to be clearly explained and documented. be friendly when someone goofs and explain to them why a file structure needs to be tidy. and document when they goof so when it keeps happening you have ammo to back you for discipline actions.
sorry for long and rambling. I love file structure setup. I've been lucky enough to own the project at several companies now. it's a frustrating puzzle with no clear rules or picture of the finished product.
Also. set realistic time frames. successful file structures take years to develop fully. it's really more of a work culture, no different than the culture in the break room or lunch fridge.
implementation and full adoption are two separate milestones spaced far apart. make that clear to your boss if they don't understand it. I've fought hard over this before. people want sudden results and that can be jarring for employees. turning their world upside is hard enough. demanding them to walk on their hands on day one is unrealistic.
The people doing work in your company are presumably busy. Asking them to take time out of their work to learn a new system is a no-go because they are spending time doing things that are required for them to earn their paychecks.
What you need to do is
This kind of sounds excessive. However, even the best plan fails in any medium sized company when there are no teeth behind it.
Or, in shorter form:
This is the answer. You have solved the technical issue, which is providing an easy-to-use centralized place to store knowledge. Now management and HR need to solve the people issue, which is making sure people use it, and use it properly. Document what “using it properly” looks like. Let them devise how they will do the enforcement. It can be as simple as them saying, “wow, this new widget system looks great - where can I find the documentation to read about it?” and then actually following through on setting that expectation that an idea/process/product is not complete and ready until it has documentation also.
You cannot solve people issues through technology, but you can endlessly frustrate yourself and erode internal trust by trying.
A few of the comments (yours, @Tilbilly, @simplify, and @Jennandtonic) all touch on the fact that there will need to be enforcement. Thank you for this. It was something that crossed my brain after the discussion on where should the enforcement authority come from and many of the things you three said have given me ideas on how to discuss that with management (which is literally the head of the company and their direct subordinate).
It seems we are similar. I started the documentation process because I didn't want people to have such a piss poor time as I did and genuinely wanted to make peoples lives easier and more efficient so they can focus on other tasks.
The goal with this project I have been set on is to make me the employee with that experience who takes care of editing, management, and well maintenance. I have the technical knowledge of the position, but seemingly the organizational and documentation knowledge is what everyone else lacks (including all the way to the top - but they at least identified it as a problem and are trying to fix it through me).
Thank you for this.
As a Technical Writer, I can tell you that if you build it, they will not (usually) come, even if you make it easy to use.
Making it easy will certainly help, and I commend you for doing it! Sounds like a very usable solution for your company's needs.
As others in this thread have stated, the best way to ensure widespread adoption is to get backing from those who have the power to enforce it. Not only backing, but active participation and support.
From a product manager perspective, one thing you can do is treat the departments as "customers" and interview them to understand their processes and get their feedback on the system you are putting in place. That doesn't mean that you act on every note you get, but it's worth some serious reflection about whether the system you have designed meets everyone's needs or just your needs (or maybe just the needs you understand).
Part of this reflection is to document the problems your system is meant to solve, incorporating the feedback you have gathered. It sounds like you are pretty far down the road to solution, but it may be worth asking yourself if having one structure for every department is the right thing. Or maybe that is what is needed for some problems, but there are some problems that should be solved another way.
In the end, communicating the goals (problems to solve) and how your system solves them will help you pitch it to management and even to the rank and file. If they understand how it is meant to help them, it may be easier to get them to adopt it.
All that said, there will be some people who balk at new things for no good reason. Others comments on getting management buy-in so that they can impose the system where there is resistance will also be useful in overcoming those hurdles.
In my plan I have been creating there was meant to be a feedback loop on reflection and refinement of implementation. However, I missed the fact that I need to talk to the other departments first before I implement the structure - what works for my department may not be the best fit for all the others. Thanks for the reminder there. I have some departments that I know their buy in was going to be easy, but this will probably extend timelines for others as they may even need some consultation and training beforehand.
Hahahaha I'm not Japanese, I just really like these noodles when I get hangovers.
Rather than answer this question specifically, since others have already given plenty of good advice there, I'm going to give you a short writeup about one of my favourite change management models more broadly as a lens to look at the problem through: The ADKAR Model.
Essentially, there are 5 stages that anyone needs to go through in order to make lasting behavioral changes. These stages need to be done sequentially: try to skip over or rush past any, and your efforts will fizzle.
Reiterating again: you need to move up these stages one by one in order, if you want the change to stick. If you, for example, try to build Knowledge before first building Awareness and Desire, people will just tune you out, feeling that the information is irrelevant to them.
So, if you take your first crack at rolling out this change and end up getting stuck somewhere, try an ADKAR analysis: which stage are you most likely getting stuck on? That will help you tailor your response efforts, since building Desire will look a lot different than building Ability, and so on and so forth.
Another nice thing about this framework, I find, is just how agnostic and broadly applicable it is. Now that I know to look for it, I find myself pulling it out in the oddest places sometimes - like when building powerpoint presentations to structure my slides, for example, or even outside of work in various tricky situations in my personal life. Hopefully you'll find it similarly useful!
Interesting, I've never heard of this model before. I will try to apply it more directly to my plans as it seems like solid advice.