We should not mistake that the reasons and benefits of having a proactive naming convention are purely technical; let’s consider the following:
Saving time and money by avoiding duplication
If users have an expectation that information finding will be a lucky dip every time they try; sometimes finding something quickly, other times having to laboriously dig for what they need; then expect to find inefficiency and discord creep in. Additionally, employees may be tempted to venture ‘off-piste’ with their data storage and hold their own local copies in abstract locations. This quickly leads to ‘Employee A’ seeking a document, asking ‘Employee B’ where it is and finding a response of ‘I have that, let me send it to you’. A simple, well intended workaround now leading to lack of document control, and old versions being used and shared to customers accidentally.
Worse still, as soon as this starts our off-piste snowball will continue to grow, leading to multiple versions of important documents to proliferate and therefore remove the entire value of the collaboration tool for which it was intended. With remote working now proliferating, expect this shadow document sharing behaviour to increase and burrow further underground away from the reach of IT.
Some advice here; if and when you discover this behaviour, even if through a singular incident, do not ignore or penalise it. This is a valuable warning sign that your user setup may be less than optimal and self-serving. Ask the ‘why’s’; why did it happen, why could the user not find what they wanted; why did they chose to go this route; then use these answers to find resolution and build a foundation that mitigates it happening again. If you make it easy for users to find the right Teams, documents and data, end users are less likely to create duplicates through accident or frustration, and therefore this practice cultivates a positive cycle. If you make it easy for staff to habitually name data and documents properly, and to share them effectively, you will build a confidence factor that the frustration model is the exception – not the rule. When of course it does happen, instead of users working around it they contribute to staying on-piste and finding an appropriate resolution that does not break the model.