Jumping Too Quickly

The Manager, the Director and I sat around a small table staring at feedback for our (not so) little LMS project.  We are in the process of walking this project through our relatively new project intake process and have asked for feedback from some of the executives - including the SWAT team leader and the Data Whisperer.

'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.

I've been kicking around the idea of separating the reporting piece from the LMS project altogether.

• 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.

So this is what we decided to do (at least as I currently understand it)

• 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.

The plan is coming together.  Next step - see if the senior execs think this is a decent idea.