I’m in a position where I can re-organize my company’s entire file structure. If I had my way, I’d want to create ONE company-wide system for all departments to use.
We are a small company with two development contracts, in addition to us commercializing 2 new product lines in the next 3 years.
While the workbook gives examples of how large a system should be, e.g. “build a farm”, not “remodel a kitchen”, there’s no clear guidelines to check myself if what I’m trying to do requires 1 or more systems.
How do I determine if my scope statement is too large for a single system?
"I ran a three-year data centre migration for a large government department using a single system.
and
"You should only use multiple systems if they are absolutely required.
I’ve never managed anything at the scale of you or Johnny, but it seems to me like you should try to commit to a single system and expand to multiple only if necessary. I think the need for multiple systems will present itself to individuals (or organizations) that require it.
Also, some advice I found here that was really helpful was to just start with the IDs. And make sure what you are calling IDs are actually IDs. I struggled with all this early on, trying to design my systems, areas, and categories too early, before I nailed down what my IDs really were. I can expound on any of this if its beneficial.
The more of this I do, the more I tend towards fewer, broader everything.
This was the recent realisation.
And if you scale that idea up to categories, areas, and your whole system, I think it applies.
This is especially the case in a shared environment like work. There, there are even more opportunities for ambiguity because you’ve got 2+ human brains.
So give each of them as big a chance of finding the thing they’re after as you can. Do this by having fewer, broader things.
This will probably result in the over-loading of some IDs. You might end up with more subfolders in some of these IDs than you might like.
I think this is okay. I think getting the user to the place they need to be is the primary goal. That’s the problem you’re solving.
When they get there, if instead of 5 things there are 25, that’s okay. They’ll handle that, because that’s ‘normal’ anyway.
And if you do this exercise and you really can’t get all of your areas in to one system, splitting them out to their own system shouldn’t be difficult. You should be designing your system to have isolated, contained areas anyway.
Also: in this situation, having documented naming standards for the files in those subfolders will be vital.
You have to avoid them going back to chaos. Fortunately, this is easy! Date at the front in yyyy-mm-dd format. An agreed versioning standard. An archive folder that old stuff goes in.
The workbook (in the 60-69 area) has more on this. One of the things I want to create is a JD Operations Handbook for small business, it’d have this sort of detail but in a very process-driven way.
Let me know if you want a hand, it’ll incentivise me to write that thing.