Jun 06 2007
Defining Content Remediation
Recently I was asked about the issue of content remediation.
Surprisingly there is limited information on this subject.
Therefore, I suggested and developed the following approach…
There are a number of reasons why an organisation would wish to perform content remediation, especially in the context of learning content. Firstly, to update courses, for example, due to compliance issues or because a learning management system’s (LMS) core functionality has changed. Or, to rationalise, harmonise or refine skills. The latter, could be due to a change in course structure or awareness of synergies between different courses, i.e: gaining greater value by bringing them together. This is natural as over time it can surface that new improvements can be achieved post experience. Sometimes companies change and that may mean new core-competency frameworks have to be put in place.
A typical approach for content remediation project would be to:
* Define players
* Define project scope
* Understand internal expectations
* Review the possibility to structure the project into phases
* Create a contact list
* Assemble project dashboard items (inc: capturing success criteria)
Organisational
* Structure plans
* Create timelines showing milestone markers
* Categorise issues
* Run a risk analysis workshop
* Establish Risk and issue log
Technical
* Perform a technical analysis (inc: risk assessment)
* Categorise as many content areas as possible, both initially and and on-route
* Develop a content matrix with the following initial headings:
- New
- Conversion (low, medium, high or re-develop)
- Reusable
- Update needed
- Screens version code
- Assessment data parsing capability
- Replace audio?
- Use web 2.0 features to enhance - Opportunities
- Re-record audio / video and then check the Learning Management system to understand if it can include podcast versions of these media types.
- Check for Packaging compliance - especially important for SCORM integration.
- Build a cross-reference document to document exactly what changes have been performed on the content.
- Accessibility Reviewed Y/N?
- Estimated cost of conversion
- Components to be changed (state content type and time per item)
* For example, building a Priority Course list for cleansing or conversion. The latter matrix could be used in conjunction with a 3rd party vendor to assess their capability of actually delivering each course for conversion.
* Build a test lab (need to spec this first!)
* Immediate skills assessment of 3rd party provider(s)
* Agree SLA with the latter
* Pilot a series of course’s to identify the most common migration issues.
Team Assembly
* Identify roles
* Lobby strategy for Project board (Strategic Advisory Team)
* Suggest stakeholders for Project Assurance Team (Business, Technical & User assurers)
* Define reporting structure / schedule
Project specific
* Agree a project brief
* Agree a project approach (Specs, documentation and remediation approach)
* Commence Project initiation with agreed stage charts
* Agree PRINCE 2 products
* Agree signoff criteria
* Agree plan & update process
* Assemble a project support office (sized as required)
Finally, as per most project it is important to phase expectations to achievements!
To help the latter, a wiki could be set-up as a bridge between content cleansers, developers and user acceptance test personnel. Wiki’s are great for informing progress.
Popularity: 60% [?]
