'So are you looking at this as an augmentation to an existing system or as a new system? Requirements collection will be really different depending on the direction you all are headed.'
I have already started the process of culling through all of the comments and complaints over the past few years regarding our LMS. Using the Communications Point Man's example - I am pretty much dumping everything and anything into this initial draft of the requirements. I have found over the years that having at least something as a discussion point makes it easier for folks to provide feedback. Rapid Prototyping FTW!
One lesson I learned is that sometimes you have to go with the flow to get stuff done.
I mentioned in a previous post my thought that Compliance Reporting could potentially be an easy "kill."
Compliance reporting - however - is not terribly sexy. Nor does it address the myriad other issues in our current process and tool set. There is also a possibility we can address it within the LMS project itself.
During our conversation - I was reminded of was the importance of timing. There are a few things occurring in our environment that makes separating and delaying the reporting piece of this project very desirable:
- A data cleanup of our HRIS system (long overdue)
- A major re-org in the Data Whisperer's world.
- Because of said re-org - the Data team's priorities might change. Hopefully in our favor, once the dust settles.
- If we wind up getting a new or different or added LMS - we would be creating duplicate work if we decide to completely discard the old one.
- It might allow us more time and focus for determining what reports the stakeholders really need. It would be cool to find an underlying strategy behind it all as a result of those conversations. Not holding my breath there.
- We would be able to focus on what inputs would need to be collected - because there is no WAY one LMS is going to capture everything in our environment. I am also not convinced that whatever LMS we wind up with should serve as a "training portal". Too tough to access and there are likely better tools for the job. I came to this conclusion through hard experience :(
- We could work on something that would scale to different inputs (such as SharePoint, Drupal pages, the Student LMS, external content systems, new enterprise products).
- We will have a much easier time keeping the sensitive information in-house vs. grappling with our Legal department and the vendor.
- We would be able to connect to our business analytics without having to run a number of updates on a regular basis and run the risk of outdated material or accidentally erasing stuff.
- Approach the LMS project as a "new LMS". This will require more comprehensive requirements gathering - which is needed anyway. It's been awhile since the stakeholders have had a true "training" discussion and the environment has changed significantly since the last time we chatted.
- Separate out reporting as a whole 'nother project for after implementation. That should give time for some of those environmental factors to shake out.
- Attempt to get a decision made in the March-May timeframe so we can either implement the new or reconfigure the old before Sept 1, 2013.