Oz Oscroft

I really wouldn't follow the advice suggested in the subtext of this question (you can use the following format: ProjectName_FileName_VersionNumber_Date_AuthorInitials)! A filename should just describe what people will find in the file. The other information, if required, should be held as meta-data. That way, versions of the file build over the top of themselves and any links will always take people to the latest version of the file. Why is this important? - so no-one works on out-of-date information. And how can this be made really easy? Let SharePoint track all that stuff for you automatically! I've blogged all about this at https://www.linkedin.com/pulse/file-naming-best-practises-oz-oscroft/

If you have a Microsoft 365 license then SharePoint is usually the best solution for all your work documents. It does all the hard work for you in relation to version control, so long as you follow some best practise tips (https://www.linkedin.com/pulse/file-naming-best-practises-oz-oscroft/). It also has numerous options for more formal draft (minor) and final (major) versioning, as well as approvals as part of the publishing process.

No project will ever be successful if you don't involve key stakeholders. These may include end users, service specialists, support team, vendor, auditors, and more. Understanding their involvement and requirements will significantly increase the project's likelihood of success. You can use tools such as a RACI matrix to categorise the stakeholders: R: Responsible (the doers) A: Accountable (where the buck stops if things don't go to plan) C: Consulted (those who need to be consulted to get their opinions) I: Informed (those who need to be kept updated with what's happening)

Assessing (and documenting) your requirements and outcomes is critical in the early stages of any project. This should include early stakeholder analysis so that you can engage and consult with all the key stakeholders to understand their hopes and desires. Without these it will be impossible to gauge whether the project has been successful once delivered. My preferences for assessing requirements are either using a MoSCoW (Must, Should, Could, Won't) analysis, and/or a Pugh Scoring Matrix. When considering your requirements, remember to include non-functional as well as functional - things like security, availability, support, accessibility, and so on.

How best to share files with your IT Team will depend on what the files are and why you need to share them. There are many options as outlined above, but if at all possible you want to keep those files within your secure boundary. If you use third-party tools or cloud services you are increasing the risk of potentially sensitive information being maliciously or accidentally shared / accessed by those who shouldn't have access. If you use Microsoft 365, sharing via SharePoint / OneDrive will always be preferable as your IT Team should have confidence in the protection already layered on top of them. They should also be able to advise on how they would like you to share so you're not relying on advice from LinkedIn!

The key is to make it fun. And ANY training can be fun if delivered in the right way. Make sure you leave time in the agenda for hands-on elements, discussion, quizzes, feedback, and a bit of general banter. If you've jumped straight into the training topic in the first couple of minutes, it's probably going to be a miserable experience! And if the training is remote, everyone needs their cameras on! If not, there's no feedback, minimal engagement, and probably a lack of focus. For Microsoft 365 training I always start with a fun poll - "How do you feel about (the topic)" with emojis as possible answers. This gets the discussion going! And I end with the same poll!