Once I’ve taken the time to figure out the opportunity costs of particular scenarios and a decision regarding direction has been made, I start breaking down what needs to happen to get from here to there.
——————
A valuable lesson I learned while working on my Master’s Thesis is how to break down a large effort into manageable chunks.
My Master’s Thesis, by itself was 96 pages and 3 chapters. I started with….well.. nothing.
The deadline I set for myself was May 1994.
I was starting in September 1992.
I had a rough idea of what I was going to do for my thesis.
Because I was going in with a rough idea of what I wanted to accomplish and the time I wanted to accomplish it in, I could project plan.
– Leverage coursework assignments as research. This made every individual assignment an opportunity to complete the research portion of the project – as much as possible. I considered this a mini-phase. Also – the course attendance time was used as what would now be considered as Initiating and Planning phases.
– For the actual Execution phase – I separated the thesis into the 3 main chapters plus the introduction and conclusion. Dr. Stephens and I set deadlines (milestones) for each phase.
– Closing – the phase closures were the reviews of the individual chapters. Final closure of project was the Master’s defense, formatting and submission to the library.
Note to future grad students, when providing a culinary example…mark it clearly. One of the other professors, expecting coffee, got a very unpleasant surprise when he consumed the beverage I had created.
————————-
How does this work in our Learning Architecture?
Let’s take the example of an architectural direction to reduce from 3 LMSs to 1 solution (often this will be an LMS, but not necessarily – especially with some of the technologies that are now available and the increasing maturity of the xAPI spec)
Project 1: Requirements collection / LMS inventory
This is the project where we collect requirements and get an inventory of what is being used and by whom. The final deliverables are a requirements document, an LMS capability matrix of our existing solutions and a baseline architecture – including access and reporting (what are each of those LMSs connected to. You could do this during source selection, but our organization is finding that doing this separately allows people to focus on the conversation and what they need – separate from any solution that is in the environment or the shiny thing they found at a conference.
Project 2: Source selection
Depending on the opportunity costs and budgetary constraints – this is where you decide which LMS you are moving to. This could be either an entirely new LMS (with the advantage of putting everyone on a level playing field) or using an existing LMS (with the advantage of having familiarity with the tool in-house). Or maybe not even an LMS at all.
Project 3: Solution Implementation
If the organization is using an existing LMS, this could be the project where you move the people using the other 2 LMSs into this solution. If the organization is using a NEW LMS or an entirely different solution, this is where you would implement that and begin moving the other LMSs into this one. Depending upon resources and organizational appetite for change, you may want to separate moving LMSs into a separate project or series of projects.
As part of the solution implementation – make sure that in your task list that you are accounting for any integrations that need to occur such as single sign on integration and business intelligence integration. If you don’t have those in your current environment, you might want to consider each of these as separate projects themselves.
Project 4: LMS Decommission
If I were doing this in my current environment – I would have 3 separate decommission projects – 1 for each LMS. I have found that making a specific, separate decommission project ensures that each stakeholder group gets the attention they deserve + helps to reduce the number of lingering legacy zombies we have in the environment. More aggressive organizations would do this during the implementation and not need a separate project for this.
Just one way of thinking about breakdowns.
The goal is manageable chunks with a beginning and a free-standing end.
Big enough that you are actually getting something done.
Small enough so you can keep track and not drop anything.
And you want to do this across all of the domains of your learning architecture.
Because your learning architecture isn’t just the LMS.
Or, at least, it shouldn’t be.
Disclaimer: this example does NOT reflect what our organization plans to do. It is just an example.
Leave a Reply