Selecting, Integrating, and Extending Learning Management Systems, Part 2

Monitor development

Just as with any development project, once you have passed along all of your detailed information to the developers, you must mon­itor progress. If you have given all of the cor­rect and detailed information, you shouldn’t have to spend a lot of time on this. Periodic checks are important though, to make sure that the project is moving in the right direc­tion, and to answer questions and make deci­sions. Staying in contact with the developers keeps the project fresh in their minds, as well as in your own. There may be unantici­pated problems or questions that arise during development, and periodic contact with the developer will help keep the project on target.

If creating a new database or making changes to an existing database, insist that the designers keep the data dictionary up to date. The data dictionary explains the tables of data within the database. With the data dictionary current, updates or changes made to the database are much less time-consum­ing. If programmers are creating new code, make sure they comment the code with notes that explain the function of each block of code imbedded in the code itself. These com­ments allow new or multiple programmers to walk into the project and understand the function of the code. All of these annotations will help to eliminate future headaches if you must make staff changes, updates, or other changes. Make sure that the time spend on this task is included in your timeline.

If something doesn’t work as anticipated, ask the programmer to suggest options and to lay out the time, cost, and functionality consequences of those suggestions so you can consult with the other parties involved and make the best decision for the project at large. Many times, the quickest and easiest way to finish a programming job is to leave out the automation of an end-user task. You need to weigh the time saved in the program­ming portion of the project against the time required to perform the task by the end users — the trade-off may not make sense for frequently performed functions. Don’t expect programmers to keep track of the big picture or understand how a job works within the organization. That is not their role.

As important as it is for you to keep on top of the project, there will be times when pro­grammers will do better if they can speak directly with the vendor’s technical team or with programmers working on other parts of the project. We believe this direct communi­cation is important for efficient development, but all team members need to keep you in the loop — and know when they need to get approval first — on any issues or decisions that might impact time, costs, or functionality.

Implement and test

We included implementation and testing as a phase in our process for this article because not doing so would be grossly negli­gent. However, in this brief article we don’t pretend to give this very important step the full coverage it deserves. As multimedia developers, most of us have experience in courseware testing and you will find you can effectively use the same rigor and bug-track­ing methods in this context.

When you are first implementing the sys­tem, it is imperative that you do so in con­trolled stages. First, you’ll want to create a backup of all data and systems that are involved (just in case). During this trial run, go through every step, procedure, and process that the system will be doing in a test environment. When you’ve worked through any kinks that pop-up, you’ll want to extend your testing to involve a few end users. Make sure to document any issues, bugs, or changes that come up in the testing process. Make these as detailed as possible so that the developer will be able to jump right in and make the change without having to spend a lot of time figuring out where to look for it.

You will want to review all of the write-ups to verify the problems and recommended fixes before passing the “bug-sheets” to the programmers. You’ll also need to prioritize the fixes and make time and cost estimates on anything significant. This will most likely involve conversations with the developers, and you will probably have to make some compromises. Some changes may have to wait for the second version, or certain compo­nents of the system may have to move into production before all cosmetic changes are completed. While typos, bugs, and human error are inevitable, if you expect them, and plan appropriate time and resources to deal with them, they are not insurmountable. If you’ve done solid design work up front, you shouldn’t be looking at any major surprises.

One thing we have found during this process is that it’s really difficult to be away from a particular screen for some time and then have to reintroduce it to your brain again during testing. Your detailed notes, process data maps and scope documents, along with running project history notes of decisions made and why they were made, are critical not only for your project team, but also to remind others in the organization about any compromises they made along the way.

Conclusion

We wish we could end this article with a sigh of relief and say, “And they all lived happily ever after.” The reality is both more frustrating and more satisfying. The frustration is that with major system implementations it’s never really “over.” If you’ve chosen to do incremental development and deployment, one wave just leads to the next. Even when you’ve checked off all the tasks on the timeline, you find you already have a list of improvements and enhancements you want to do next, and you begin to see new ways to use the system to improve organizational performance. The satisfaction comes when you recognize how much you’ve learned, and how the insights you’ve gained actually came from those nitty gritty details you were trying to avoid.

Comments

Login or subscribe to comment