I’ll be the first to admit, this project could’ve gone wrong from jump in so many ways. We had an internal client who, like many clients, was very risk-averse, so the thought of doing a “game” was a risky move and required a lot of handholding. They could have bailed at any time. We had an incredibly tight deadline for a project like this. Normally, a multimedia-heavy project like this one, you’d like a solid six months to develop it out. We gave our vendor three, and by a lucky break for all of us, the delivery was delayed by a month which was needed.

We used a brand new vendor who was brought to us initially by our CLO. I’ll be the first to admit based only on the sample products they provided that I would not have chosen them — mostly because they seemed more like an Agency than a game development house and the look and feel of the products I saw were similar in nature, and I felt their production would be a disconnect with our audience (and our internal client). When the project was emerging from the Instructional Designer on the project, I ballparked the project at a certain cost. I expected the vendor to come in high and then we’d have to haggle and negotiate. I expected that working with the vendor, like many vendors I’ve both worked for and worked with, would be a painful tug-of-war, followed by some finger pointing, followed by relief that the project just “got done.”

I could not have been more wrong about this vendor, and I’m very, very happy to say so. They came in so close to the number I ballparked, I began to think they were taking us seriously. I waited with baited breath to see their first draft of the storyboards indicating the look and feel for the game, and having taken the time to visit and talk with one of our branch stores close to their office, they produced storyboards that I felt so perfectly blended my expectations for how to be at once “cool” and at the same time “mindful” of the people we were looking to instruct, as well as the complexity of the subject matter we were looking to demystify. They made learning the material (and the subject itself) “fun” and still “tasteful.” I was very impressed, and I’m the kind of person (as you know on this blog) that doesn’t run out of opinions. I became hopeful that this really could work.

They created the project in a very complete Alpha state. We tested it in our network and found that the bandwidth required would be a major obstacle for the target audience. We talked with our vendor about reducing the audio and video quality a bit and retesting it in our network before doing any more work on integrating it with the LMS — because if it wouldn’t perform as “content” out of the LMS, there was no point on troubleshooting the LMS communication. They had new files to us in a matter of days. We retested and got a green light on performance.

Then we moved onto LMS integration. I put together the API Wrapper and the rest of the SCORM packaging for our vendor, because they had not built for an LMS deployment before, and it would be just silly to make them go through the learning curve when I could just do that heavy lifting with little effort. They were able to write and read from the LMS at the prototype level (we did a technical test before they even tried to get the real content working to debug the communication issues). Not looking at their ActionScript at all, when we noticed some issues with suspend_data not being sent to the LMS, even though the code was the same as the prototype. It turned out that the content was sending consecutive JavaScript calls, which goes back to the whole synchronous/asynchronous deal about ActionScript and JavaScript (we had to use Flash 7 Player because my organization had not upgraded to Flash 9 Player at the time). Moving the calls so they were separated and event-driven made a huge difference. I was on the phone for a day and a half with the vendor. In ten years, I never worked as, for or with a more willing partner.

For reasons I’m sure you can understand, I can’t show you the game. I probably can’t talk much about what the game is about or what we’re trying to teach. I probably can’t broadcast the vendor we’re working with (though if you ask me offline, depending on whom you work for, I’ll be happy to tell you).

The point of this posting is to get off my chest in as public a means as I can how happy I am to be able to help make the vision of one of our Instructional Designers a reality — even if all I am is the babelfish (Hitchhiker’s Guide reference). We have our foot in the door for serious gaming. I’m betting it’s going to be a smashing success and will usher in a shift in instructional approach, both as far as what we propose and what our internal clients will consider.

And… I’m just happy as hell that after years of producing cool and not-so-cool page turning stuff, I get to finally be part of something different. I worked with a fantastic Instructional Designer and a really incredible Project Manager (I actually am gushing over Project Management and Instructional Design) — both of whom really “get it.” I had a boss who was willing to take a chance and a CLO who was ready to be a sponsor on something different. Best yet: I had an internal client who, despite their concerns, was willing to trust us and get the job done right.

And one more thing: I’m very humbled that there are vendors out there that can really be a partner in making great learning experiences, on-time, on-budget and far-exceeding expectations.

For the first time in as long as I can remember, I have a happy project story and it didn’t kill us.

With learning content so similar in every technical way to web content, the same rules apply, but as with everything in our trade, it’s got a little bit of a twist to it.

Keep reading for an example of real action items from a cursory review of existing content being modified for a new version of the learning content. So no context is really needed here. I’m revising a course I built last year for the same internal client. Here’s the notes I took down of the high-level changes that need to be addressed.

It goes on and on for about 20+ rows, I won’t retype it all… you can view it here if you really want to. Of the changes spelled out, I’ve identified about three of them as “Critical” — these are the ones that will take the most time to produce, require the most “design” to get the message right, have the highest potential to need more rework because the presentation of the information can be so subjective and they have the most ambiguity. To the client and the project manager, these represent maybe 20% of the changes I need to make, but they’ll probably take about 400% of the time it will take me for all the other changes combined.

See, each change is equally weighted to the client, the subject matter expert and/or the project manager. But on the design and production side of things, we know that there are some tasks that take considerably more resources than others. The degree to which project managers “get it right” weighs heavily on their understanding of what things take more or less effort than others.

There’s another side to it, though. That 20% I’m talking about — a lot of it is playing right into my weak spots, which is visual design. I know a lot of graphic designers who dabble in Flash enough to be dangerous, and I know that many more technically brilliant people who can’t make something pretty enough for them to look at themselves (you know who you are). I’m a jack of both trades but a master of none, which is where I’ll bet a lot of you readers are, too.

I guess I’m not sure what this all means, but it occurred to me on the train this morning that as tensions ride high in project management of learning technology projects, one of the core reasons has to be how each team member weighs the level of effort on a given task — and that’s probably a good place to start having conversations about developing and designing E-Learning with your team. In other words, what does it take to build x? Because there’s nothing to technically building a simple click activity for a timeline… but if you want it to look right, consistent with the interface and the content — it may take a level of effort far beyond the basics of slapping the pieces together or using Articulate Engage. You may draft out the interface for about five hours for a 30-second piece of content, and only the last draft you make is useful.

And… it still might not be “right.”

Basecamp is so easy for the end-user, it’s going to be rolled out to Project Managers in the organization, too. Finally, we’ll have everyone working on the same project on the same page — literally.

One thing that BaseCamp is not so good at is reporting. I have a pretty non-techie group and there are a lot of clicks involved (although pretty easy) to read into what everyone’s doing on their projects. Fortunately, BaseCamp has a documented API (one of the reasons I wanted BaseCamp was its extensibility) and there are a number of scripts emerging to make use of it.

Aaron Quint at QuirkyBlog posted a PHP wrapper for pulling information from a BaseCamp project. After having to fumble around with DreamHost’s implementation of PEAR (adjusting some relative paths to hard paths in some of the PEAR scripts as well as Quint’s Basecamp.php class), I was able to pull a list of projects lickety split.