How to enforce documentation / file structure at an organization

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.

How does one enforce usage and standardization of documentation and following a certain file organizational structure?

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

• Get buy-in from the people that sign the paychecks (or get your direct superiors to do this)
• Have work instructions changed to make your mode of doing things "official"
• Enforce non-compliance via whatever your company uses for punitive measures, probably some kind of write up and lowered bonus or something

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:

• Learning your file structure is not part of their job. Make it part of their job.

When I came into my current job, there was no documentation and I work in web development. It was (and still is) a shit show. A former coworker, who also knew the importance of documentation, set up a doc site for us, and currently it's really only me and another coworker who actually use it. Poor adoption is really because we have bad leadership. I personally document every new system I create because I value it and remember what my start was like. When I inevitably leave, I don't want whoever takes my place to have as hard of a time as I did. In addition to being technically inclined, I'm also a writer, so it's easy for me.

If I was in charge of something like this, I would probably get someone with greater authority over the company to let everyone know that it's part of their job description now. The company would also have to agree that it's important and make sure employees are given the time to write documentation, which can take a lot of time because not everybody can write. And since not everybody can write, there would probably need to be an employee dedicated to managing this, with no other job responsibilities, who is also an editor and expert communicator. Because there is going to be a lot of editing. The file management of the documentation should be managed and organized by this person. All of it is going to be hard. If you don't have upper management on board, it will fail.

You can't expect most employees to both document their job and organize the documentation. So they should have one responsibility: document. Someone else should handle the rest, working with those employees to fix any vagueness or errors. Then there should be an internal site where employees can go to read the documentation. Documentation is hard for most people. You need to remove as many of the difficult roadblocks as possible. If you don't, it's just going to stress you out and feel impossible. Do not make people document and manage files. You're gonna have a bad time.

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.

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.

1. A - Awareness: do people even realize that the status quo is a problem (and why)?
2. D - Desire: now they know there's a problem, but are they personally motivated to do anything to fix it? Lots of different factors can erode desire, like being too busy with competing priorities, cynicism/lack of trust that the changes will stick, and so on. Note that you can build desire through both carrots and sticks.
3. K - Knowledge: now they know there's a problem and they're motivated to do something about it, but do they know where and how to start? Good accessible documentation is usually your friend here.
4. A - Ability: now they know what they're supposed to do and are motivated to do it, but is it easier said than done? You can read a million books on horseback riding and then still fall off the first time you try to actually ride a horse. Sometimes things will turn out trickier in practice; having "live coaches" or similar available to help people through tricky edge cases and such can often help.
5. R - Reinforcement: they made the change once, but will it stick? If people bother going through (what feels to them to be) a lot of effort, only to have things work exactly the same way as before, they're likely going to go back to the thing they're familiar with. Seeing and feeling the firsthand benefits of the change is best, but even a simple thank you/recognition here and there can go a long way.

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!