Remember when Dorothy, the Tin Man, the Lion and the Scarecrow approached the Wizard of Oz? In each case they already knew what they needed. They had done their own rough needs analysis. To think about migration to freely sourced software, you need to start from a needs analysis perspective as well. This migration framework parallels a planning model used to locate a factory or centre of production. When situating such a business, planners need to weigh access to raw materials/product markets, costs of transportation for raw materials/products, as well as any special requirements such as particular energy sources, or research and development centres. Depending on the identified needs, some industries are materials-oriented (situated closer to raw material sites), some market-oriented (situated closer to markets), some transport-oriented (situated closer to the means of transportation) and others energy or research oriented (situated closer to sites like hydroelectric dams or university research centres) (Dunlop, 1987). Your job is to discover if open source or free software provides a viable alternative to relocate your needs.
When a potential adopter looks at changing software, a form of triangulation has to occur, factoring in the following:
- Availability and comparability to current proprietary commercial software—This first consideration has to do with knowing what types of software are currently available. As this information changes almost daily, you need to stay current with developments in freely sourced software. The closer the freely sourced and proprietary software programs are in terms of look, user friendliness, features and functions, the smoother the transition and the quicker the adoption. In addition, if the new open source option can approximate or better the old product while delivering desired, voiced needs for upgrades, the more assured the transition.
- Software viability—Here you review what version was being considered, how long the program has been around, and how robust a user community and/or commercial community has been built around the product. Certainly, products like Moodle, ATutor, and Sakai are safer bets. Experience has shown that the longer-lived and more robust the communities are, the more successful the freely sourced software will be.
- Implementation and support costs—Remember that while the source code is free, you have to have the expertise to deal with it. This includes not only necessary hardware purchases, but the skill to implement and support the software in your group or institution, or the cost of any necessary outsourcing.
- Level of customization desired—Unlike proprietary software, freely sourced software is highly customizable. You must know what you want from the software application. If customization is desired, key questions include: is there existing, budgeted expertise in our organization to accomplish customization through modifying programs? or would this work need to be outsourced, and at what cost?
- Software succession history—Generally, when organizations undergo a rapid succession of software transitions that involve significant changes/challenges, resistance to adoption of any new software will increase. Your transitions must be managed for the relative comfort of your users.
- Risk assessment—This involves an examination of how much risk is acceptable in a transition to freely sourced options. This may be measured by reliance on reputation, availability of warranties, or assumption of liability for the software. If low risk is desirable, then a group or institution can experiment with more established applications, or those with warranties and/or vendor support. If a program plays a critical role, then high software viability, usually at a higher cost, must be sought. The level of risk assumption you are willing to make will affect whether your group or institution will be comfortable with newer, less tried-and-true programs, or a blue-chip program like Moodle or ATutor.
Needs Analysis
First you need a team or individual in your group or institution best positioned to do a software review. This is probably the person(s) responsible for buying, maintaining, and monitoring your technology. You want to look at the applications you are currently running in your organization. Determine which ones are the most expensive, have the most associated costs for upgrades, maintenance, etc. Which ones do your people complain about, or wish were better? For which ones do people request alternatives? When you’ve established a base list, examine these programs for the functions and features your users need, the ones they don’t use, and the ones they wish the programs had. Use this to create your wish-list of functions and features for a freely sourced alternative. This list will form the foundation for a software analysis grid when you review your software options.
- Outputs: Needs analysis report—formal or informal; wish lists of software functions and features.
- Resources: Technology employee time for analysis.
- Costs: Employee wages for needs analysis time.
Research and Analysis
Now it’s time to find out if there is anything in the freely sourced world that could meet most of the features and functions on your wish list. Build a research team: invite a technology expert(s) with programming experience from your group or institution to work with your needs analysis group (they could be one and the same) as well as one or more potential end users who are demonstrated early adopters of technology. End users might be clerical staff, instructors, teachers, accountants, etc. Always keep in mind exactly who will end up using the software. Ultimately, they will have to be satisfied with the new software. Sometimes your team may only consist of two or three people, and that’s fine to start, but you will need to increase your participants in subsequent stages. Feedback from the end users is vital. If the interface—the front end of the application—is too challenging to use or user un-friendly, or clearly outweighs other benefits, look for something else, have it developed or wait until it is developed. Keep in mind, many user communities will take requests that build up over time to drive the direction of software development.
Have the team research possible alternatives for use in your organization in light of the needs analysis conducted and your wish list(s). Part of this process should assess viability of freely sourced alternatives including existing hardware and potential costs of new hardware or outsourcing. It should also generate estimates of technology support time required for migration to the new software for initial testing. Another important aspect of assessment is the development/support community for the specific program. Solid freely sourced applications have vibrant communities that support their use. You might also look at potential partner organizations with similar needs and aims who might contribute resources or otherwise support your migration activities. Using your wish list from the needs analysis stage, build a software comparison grid including any additional considerations you might have so that you can evaluate your options side by side. Depending on the item in the grid, you might have an X or check mark (to indicate an item is present) and/or a 1 to 5 scoring framework (e.g., for easy of use where 1 is most difficult and 5 is easiest).
If your team determines that there are viable freely sourced options, the next step in the assessment process is to create and submit a project outline with a draft budget to determine if your group or institution is prepared to commit more resources. Be sure to include meeting time for the project team to discuss the project, review reports, generate communications, etc. When drafting your budget, you should also prepare a rationale for a migration. Be sure to compare existing and projected costs of current proprietary commercial software/applications in use with implementation of the freely sourced options. Look at projected licensing costs for versioning, etc. Review the product versioning cycles of existing software to determine how often you are required to upgrade, and the associated costs. This is often a big selling point for conversion to freely sourced programs.
- Outputs: Comparison grid; research and formal or informal analysis report with organizationally specific recommendations; draft budget/cost including estimates from technology expert for migration of limited organizational data to freely sourced applications/programs.
- Resources: Employee project time for research and drafting proposal.
- Costs: Employee wages for research and analysis.
Trial Implementation
If you reach this stage, you have already determined that there are viable alternatives, and possible potential partners for converting to freely sourced software. You have drafted a proposal with a potential budget for conversion that has been accepted. Resources have now been committed to determine if freely sourced options will work for your organization. If you haven’t already done so, designate a project manager or lead who will help draft schedules, track tasks, monitor budgets, etc. This is a critical position and will help keep the project on track. In a perfect world, this individual would have project management training or experience. During the first wave of implementation, you will probably test a set of select applications with your early adopters in limited deployments.
Initial testing might look at three to five applications for a week or month then narrow the field to just one or two options for a longer trial. The early adopters run the programs, comment on the benefits, pitfalls, etc., while working with the technology experts. Those periodic team meetings you budgeted for should guide the program pruning process. Be sure to get feedback from everyone: the people installing, maintaining and tweaking the source code, as well as the end users. Should the applications work well, these early adopters can become your professional development mentors who will then train other people to use the new software.
One of the results of this work may be a decision to abandon the trial software, but if you’ve found something that works well, you will need to communicate that news through your organization. Show people what you’ve done, how well it works, chat up the benefits of a wider conversion. Plant the seeds of interest in the new software and draft a project plan for wider organizational adoption. The project plan for the second phase of implementation should include a rationale, a budget, a change management plan, professional training/development, etc. For the fuller roll-out, you should definitely involve a project manager with experience who is skilled with managing organizational change. However, if the freely sourced options do not work for you at this time, provide a project close-down report indicating the issues with the software, but remember, freely sourced software will continue to develop, and new options will present themselves. Be open to further alternatives and research in the future.
- Outputs: Installation of programs/applications; limited conversion of organizational data to new programs/applications; training of select organizational personnel on new software/applications; meetings and periodic reports on challenges and successes with the new programs/applications; assessments of whether the project should continue/expand; project plan for wider organizational adoption, or report on the close-down of the project.
- Resources: Employee wages, including meeting time for project team; additional resources as designated in draft budget.
- Costs: Dependent on budget.
