5 Reasons Not to Conduct a Software Bake-Off

A full software bake-off, one that involves an in-depth comparison and review of competing software platforms and and solutions from a variety of vendors, is the gold standard for software selection. This bake-off should commence following the development of a full set of requirements and use-case examples, so that the products can be evaluated and scored against a rubric. Bake-offs usually commence from an industry scan, progress to webinars, elevate to face-to-face demos, and culminate in pilot projects. A full software platform selection process can take many months and involve a complicated governance process.

Bake-offs are good things. Except when they are not.

There are some cases when going through a full product selection process does not make sense. The key is knowing when to short-circuit the process.

5 Reasons Not to Conduct a Software Bake-Off:

1. A Platform Is Already In-Use on Campus: I am always hesitant to bring in a new software solution or platform if a similar one already exists on campus. We often get hung up on finding the perfect product or the perfect company, but they don't exist. We get enamored by features and a gorgeous UI. We want to work with a hot company. But in most cases, leveraging an existing campus solution will be the smarter play. The fact that a system already exists on campus means that many of the learning curves have already been climbed, relationships have developed, and problems solved. The best software projects are those that actually get done (you'd be surprised at how many go over-budget, over-schedule, or simply fail). Accepting a less than perfect system, but one that is already up and running, is often the best way to inoculate your software project against failure.

2. Other Parts of Campus Have Already Commenced a Selection Process: Before you start a full product bake-off, check that one is not already going on somewhere on campus. You'd be surprised at how many different parts of a large academic institution may be engaged in a software discovery process that is similar to what you need. Despite our best intentions, we are not always good at sharing with our communities what we are up to - particularly if a project has not risen above the level of research and discovery.

3. An Existing Trusted Vendor Partner Has a Solution: If you have a vendor partner with which you very much enjoy working, one that has provided a good product with good service, it sometimes makes sense to stay with that vendor in a contiguous or related space. An industry scan and research about the various solutions and vendors is always important, but it may be wiser in some instances to short circuit the process somewhat if a trusted vendor relationship is already in place. A full selection process is a costly and time consuming activity, and sometimes this time and resources is better spent actually getting on with the project.

4. The Requirements Are Evolving: Small scale pilot projects are sometimes necessary to understand what sort of software platform is really needed. We learn much more by actually doing something as opposed to sitting through endless selection meetings, webinars and demos. The software as a service (SaaS) model makes it much easier to try platforms out, to learn by doing. It is okay to hold-off on doing the integration work to existing campus systems (say authentication against the campus directory), if you are in pilot and trial mode.

5. The Project Is Small, Exploratory or Short-Term: Some projects that require software have quick time horizons. You have an immediate problem that needs to be solved. A long term solution is not possible due to budget issues, organizational changes, or planned campus infrastructure projects. These short-term projects are sometimes best served by being willing to jump into a lightweight software solution - one that is hopefully delivered as a service and sold monthly on a subscription or per-seat model. Finding a "good enough" solution that is fast and cheap, something that can be done through research and communication with peers, might be better than going through a detailed selection process.

What software selection projects are you currently involved in?