Manage Learn to apply best practices and optimize your operations.

Moving away from RFPs: Taking control of a software selection process

Traditional procurement strategies aren't always the best bet when time is short and budgets are tight. Learn how one CIO has reworked his software selection processes.

During the past couple of months, Westminster College has gone through two very different software selection processes. For many reasons -- mostly related to budget, time constraints and integration needs -- we decided not to go through the typical request for proposal-based procurement process.

Scott Lowe
Scott Lowe

In order to achieve our goals quickly and efficiently, we reworked our software selection process to guide us through two different scenarios. While our selection processes were somewhat unorthodox -- the analysis was performed against a narrowed product set and at least one of the options in each case was to stick with the incumbent software if the narrowed list proved unworkable -- we succeeded in making some big changes and creating new processes our stakeholders were very comfortable with.

Here are two examples of how we adjusted our processes to accommodate two different situations:

Software selection after an acquisition

Last summer, our learning management system provider -- Angel Learning -- was purchased by the "Borg" of the learning management marketplace -- Blackboard Inc. This acquisition threw into doubt the future of one of our key systems. While we were already considering switching vendors due to continual double-digit annual increases in maintenance costs and a growing dissatisfaction with the product, the acquisition sealed the deal for us.

As is the case in most organizations, the faculty and staff at Westminster work long hours and don't have time to devote to a major software evaluation. On top of that, budgetary constraints made it difficult for us to consider some pricier options, such as Blackboard's flagship software.

In order to streamline the process and keep the time that would be required of our stakeholders and faculty to a minimum, we quickly narrowed our list of options down to two: Moodle, an open source learning management system that a number of staff members expressed an interest in; and a learning management module provided by our primary ERP vendor that would integrate nicely with our existing systems.

We felt that both products had solid feature sets, but this theory needed to be tested. With the narrowed product set, we put together a selection team made up of a representative group of faculty members and campus constituents. Our first order of business? Verify that the group was comfortable with the narrowed product set. To the person, everyone agreed on the list and there was no need to expand the selection.

Next, we went through multiple demonstrations for each product. Based on the demonstrations, the selection group chose Moodle. The team felt it was by far, the stronger tool, boasting a plethora of critical features. At this point, the team was excited about Moodle's prospects and we launched into a semester-long pilot project intended to accomplish the following:

  • Verify the selection of Moodle as our product of choice. If Moodle proved to be a poor product, we'd start from scratch with a broader set of products.
  • Determine which (if any) needs were not going to be met by Moodle, and what challenges we'd face as a result.

While the pilot project tempered some of the enthusiasm around Moodle, it wasn't enough to derail things -- all but one person indicated a desire to move forward with Moodle, and the lone holdout said she could go either way. As a result, we'll be converting from Angel to Moodle during the summer.

Moving on from best-of-breed software

In January, I began working with our fundraising arm to help identify the root cause of some operational issues resulting in lost opportunities. As part of that effort, we also worked to determine whether the existing best-of-breed software might actually be contributing to some of these operational headaches.

The fundraising arm is the only division of the institution that runs its own software; the rest of the campus offices operate on an integrated system. With central IT supporting the integrated system and a lone, overworked individual supporting the fundraising system, maintaining that separate system is a major challenge in a number of ways.

As is the case in most organizations, the faculty and staff at Westminster work long hours and don't have the time to devote to major software evaluations.

For one, the system doesn't integrate well with other campus systems. As a result, a lot of inefficient, manual processes have cropped up over the years. Also, the thinly staffed organization simply can't maintain multiple major systems like this in a way that makes sense.

In this case, our comparison process was even simpler. We compared our existing best-of-breed solution to a similar module offered by a current vendor. While the best-of-breed vendor is recognized as an industry leader, the current situation was unsustainable. We needed to figure out if the integrated solution could meet our primary needs and if we would lose any capabilities if we went for the transition.

After careful analysis, we decided to move the fundraising division to the software package used by the rest of the campus. I should note that I did not make this decision; I oversaw the evaluation process and provided a recommendation to the vice president of that division that we make the move, but the final decision was his.

If the analysis had resulted in a need to stick with our existing best-of-breed solution, then we would have dedicated money to a training program and invested in integration services designed to integrate the best-of-breed solution with the main campus system.

Scott Lowe is CIO of Westminster College in Fulton, Mo. Write to him at [email protected] or [email protected].

Dig Deeper on Small-business infrastructure and operations