Governance document and clean up

If I were in this position I would do two things to start off with.

1. Invest in a sandbox if you haven’t already - with the structural changes you’re about to make, you really want to know you’re not going to break the platform. Having somewhere to test these changes thoroughly before deployment to live is essential.
2. Plan, plan, plan. Write a very detailed document on what you’re going to delete, move, create. Include all the details, the settings, and most importantly WHY you’re making each change. This will serve you in the future, and also allow you to think through each change.

In my opinion, after all of the changes is when you should think about writing the governance document, once you have a nice clean environment.

As I say, these are only my opinions and what i would do. Hope that helps.

Helo YFDK,

I think that the first step is to analyse the target groups and their learning content and then create a matrix with codes for the respective target groups. Once you have finished the matrix, you then search for the relevant admins or power users for the content and assign the same codes there. Finally, restrict the rights of the admin to power user rights and only give them the rights that are necessary. When analysing the target groups, you must also search for notifications, groups, pages, menus, catalogues, in the central repository, etc. and give them the same code if it is only for this one target group.  Take one target group at a time and learn from the experience, then almost nothing can happen. 

An FYI - there are GDPs out there on the interwebs 😁 if you do not know where to start and the above notes are good starting points.

(GDP - good documentation practices)

Here is a copy of my highest level hierarchy of our documentation. By far not perfect - but you need to start somewhere:

Beyond these - a reasonable way to start is to give yourself stubs below these - like for us we have configurations under system practices. Then - walk each and every menu (and point at Docebo help documentation to support your documentation stub(s)) to expose the following:

• a configuration exists
• the configuration is using a naming convention
• the configuration has an impact in production
• time and date your documentation/findings with “documentation and revision tracking”
• begin to label your unknown configurations vs known configurations to avoid multiple passes that are not bearing fruit

Configurations are not always going to make sense or represent footprints that will end abruptly in systems. Tested configurations do not always make it to production.

We do not have the luxury of a sandbox - this should seriously be a freebie Docebo - but the other thoughts on walking the sandbox is great because you can turn on and off things without impacting production.

dklinger wrote:

An FYI - there are GDPs out there on the interwebs 😁 if you do not know where to start and the above notes are good starting points.

(GDP - good documentation practices)

Here is a copy of my highest level hierarchy of our documentation. By far not perfect - but you need to start somewhere:

Beyond these - a reasonable way to start is to give yourself stubs below these - like for us we have configurations under system practices. Then - walk each and every menu (and point at Docebo help documentation to support your documentation stub(s)) to expose the following:

• a configuration exists
• the configuration is using a naming convention
• the configuration has an impact in production
• time and date your documentation/findings with “documentation and revision tracking”
• begin to label your unknown configurations vs known configurations to avoid multiple passes that are not bearing fruit

Configurations are not always going to make sense or represent footprints that will end abruptly in systems. Tested configurations do not always make it to production.

We do not have the luxury of a sandbox - this should seriously be a freebie Docebo - but the other thoughts on walking the sandbox is great because you can turn on and off things without impacting production.

Wow, that looks incredable!! What is your hourly rate and availability to do this sort of documentation. ;)

I only wish that I was running around documenting systems like this - it can feel like it takes a forensics scientist to figure out why a system is behaving the way it does at times. That is the one thing I stride to avoid. I also know that it can be (in the end) and last thing that any team wants to be doing. But, the best at what they do? Realize there is value of passing along business intelligence.

This is a fantastic topic and best practices around this should be provided by Docebo upon implementation. 

I’d love to hear how others are handling this as well, and to possibly help in creating a basic guide for new implementations to consider. How can we get Docebo to support/organize such an effort/group?

@ariel.zimmerman - thanks for the nod - the fact of the matter is that I have a feel for what is good for larger implementations after only 13-some-odd years of making mistakes and going to user groups and telling them though forums and with staff to formulate better practices. I do know that having some documentation is better than none. This is especially true for confusing/complex/custom configurations being left for the next team. Because without them they will inevitably trigger an accelerant on the half-life of a solution.

My lens on the subject is that many implementation teams build into their practices some level of initial documentation to migrate and enable configurations and content. Beyond the initial implementation project - the development of a basic business plan, moving into capacity modeling, understanding what the pipeline is and establishing the objectives and KPIs for what this portion of a learning practice will become with the LMS team? and then establishing some governing strategies with steering committees? 

All of these drivers should continue to contribute the need to document your approach. Even if it is just a project-by-project orientation towards that documentation.

If you don’t? (And this may be a stretch) you may be leaving yourself and team vulnerable to the next shiny thing (that learning system with uber AI 🤣) in the room for your leadership….and noone wants to be on the losing side of that.

Especially during slower times - documenting is the way to go.