I’m trying a new thing with the blog to get myself into the habit of writing articles on a regular basis. I’m going to try to just write about topics while I’m actually doing different projects. I figured that might be a good way to go about things since the topic’s fresh in my mind.
This week I have seven different courses that are in development and being reviewed. So I thought I’d talk about review cycles.
In a traditional/waterfall project model, there are typically three formal review cycles for an elearning course:
1. Prototype (aka. Alpha)
3. Final (aka. Gold, Live, Production)
The prototype is a rough first pass at the module. It tends to be static, unfinished, and riddled with notes about what content will be there instead of containing some of the actual content (e.g., animations, videos, graphics, interactions). It’s only done enough to give the client an idea of what the end product will look like. This way they get an early glimpse at the elearning to validate that it’s heading in the right direction, and it gives the development team a chance to course correct early if it’s not headed in the right direction.
The prototype review should not be a thorough content review because the content isn’t there. It’s all mostly concepts and ideas. Instead, you should be reviewing a prototype for these three things:
1. The core content is there. (i.e., the right topics are being discussed though perhaps need more detail)
2. The flow is correct (i.e., the order of topics. slides flow clearly and logically.)
3. The look, feel, and overall vision appear to be heading in the right direction.
That’s it. Nailing down these pieces will give you the skeleton you need to flesh out your content, and also give you a chance to make any necessary redesigns of the course before too much effort is wasted.
I usually tell clients that the beta is between 70-90% of the way to a final product. The purpose of the beta version is to give the clients a clear first viewing of the final course, minus a few (hopefully minor) elements. This way they have a clear picture of the end product and can provide you with all the necessary feedback you need to create the final product they want. So when you’re developing your beta version, actually try to create the final product. This way you get all the feedback you need, and hopefully minimize the work needed to create the final version.
IMPORTANT: Time and again developers push all the work to the very end of the product, and this is what causes them to miss deadlines and fail to meet client’s expectations. Avoid this by creating a solid beta!
When bringing your beta version to your clients for review, basically tell them to pull out all the stops – don’t hold back any feedback. This should be the most rigorous and nit-picky review of the three. The last thing you want is for people to hold back until the final review, and then you feel broadsided with major changes when you thought you were nearing the end of the project.
The final version, is (of course) intended to be the final version of the course. But this is rarely (read: never) the case. If you’ve done your beta and alpha reviews right, and managed your client’s expectations well, then you should be about 95% done at this point and nearly all the changes should be minor after the final review because you would have gotten all the major changes out of the way in the beta.
When facilitating the final review of the elearning course, present it in a way that doesn’t draw out feedback that wouldn’t have been provided without your prompting. You can *always* change and improve ANY product. It’s not about perfection. It’s about achieving the project goals and client satisfaction. That said, do NOT squelch client feedback. If a client has feedback that would affect either the budget or deadline of the project, simply tell them how long the change would take and how much more it might cost (assuming it pushes the project out of scope) and let them decide what to do.
Many developers and consultants are too quick to call something a “Change Order” or “Scope Creep”. I’ve (sadly) even seen some who deliberately underbid projects with the intent of adding charges in this manner later on once a client’s locked in. Sickening. Instead of yelling “Scope Creep” at every turn, take the opportunity to go beyond your client’s expectations. Clients find this a breath of fresh air and they really appreciate when you put more effort into something than what’s in the contract. And, selfishly, I find this sort of customer service leads to repeat business.
The Ongoing Review Cycle
One last thing regarding reviews. I just presented you with a traditional, waterfall type approach to elearning development and the accompanying reviews. That said, this is not all you should be doing. A waterfall type plan looks great on paper, but I’ve never been involved in any project where things work just as planned in a waterfall type scenario. Projects that work best tend to be those that incorporate small, informal, ongoing development and review. Having mini-reviews with one or two stakeholders throughout the development process, will help the formal reviews go much more smoothly. The more you can involve clients outside the formal reviews, the more likely they will go as planned.
So that’s the elearning development phase in a nut shell. There’s gads more detail I could add of course, but we’ll save that kind of stuff for other posts.