Login

Needs Analysis: The Next Step in System Selection

Needs analysis involves breaking down your requirements for a new system, defining and documenting them.

This series of columns on the basics of system selection provides a baseline understanding of the principles and strategies involved in making an informed purchase decision. Although couched in terms of IT purchases, especially the selection of an IT system for a hotel company or a hotel, these practices apply to purchasing anything for your hotel enterprise, especially high-value, high-impact purchases.

Today’s segment will focus on the needs analysis aspect of system selection.
In needs analysis, you define and document what your requirements are for the new system. Some of the requirements you need to capture are high-level, macro concepts. Others are low-level, specific functional requirements that you need the system to do for you. Others are quantitative, addressing questions like “How many and how much?” You’ll also need to define the services required to implement and support your new system. Let’s examine each of these major categories.

High-level conceptual requirements
This is where you capture things like “As a company, we have determined to move to true cloud solutions over hosted, and hosted solutions over on-premises.” An example of an aspirational conceptual requirement might be, “We require open application program interfaces from the new system to any potential interfaced system, such that the API exposes most features of the system to the interfaced systems.”

The point is, these are high-level statements describing where you want the new system to take the company. These should generally be suggested, if not required, by a formal corporate IT strategy statement that informs the needs analysis for the current initiative and others that arise. Many companies don’t have a documented IT strategy, in which case someone must work with leadership to elicit the key concepts that the enterprise chooses to operate under going forward.

Functional requirements
This category of needs addresses what you need the system to actually do. For example, an extended-stay hotel will need the ability to present daily, weekly and monthly rates. A global brand will need the ability to present a user interface to employees in multiple languages and guest-facing content in multiple languages.

Determining these functional requirements is typically a holistic exercise, drawing on “must-have” capabilities of your current system, wish-list items for the new system, and features suggested by the specifics of that hotel company’s unique characteristics. Perhaps the richest source of functional requirements come from interviews of operating managers and employees and observation in the workplace by individuals with a broad perspective on hotel operations and the technology itself.

Quantitative requirements
Although in many ways the easiest set of requirements to assemble, gathering the detail for this class of requirements is often tedious and error-prone. This is where you capture things like:

  • How many properties, rooms, countries and segments need to be serviced?
  • How many devices, concurrent user seats, rooms or other variables need to be licensed?
  • What interfaces to what other systems are required, down to model and version number?

Existing system inventories, if accurate, are a big help here. However, they often do not exist or are outdated, so at a minimum need to be validated or constructed from scratch.
Service requirements
These are perhaps the most difficult and crucial set of needs to document. Generally, one looks at services in two phases: Implementation and ongoing support. Implementation services begin with project management. Amazingly, many vendors fail to build in a project-management component to their proposals, so they don’t invest in the service and it lacks in performance. Also, the client needs to be able to specify what project-management services they require. Other major categories of implementation services include training and interface installation. Under training, address questions such as:

  • How many people in each department need to be trained?
  • Will it be instructor-driven classroom training led by vendor personnel, ad hoc training by hotel personnel after receiving instruction from the vendor or online training, live or recorded? Or some combination?
  • When relative to go-live or opening will training be conducted?

Ongoing support requirements should detail hours of support required, escalation paths, service level agreements and more.
Once you have documented these requirements, what do you do with them? We’ll share those answers in the next part of this series.

Mark Haley and Mark Hoare are Partners at Prism Hospitality Consulting, a boutique firm serving the global hospitality industry in technology and marketing. Managing system selection efforts is a core practice area. For more information, visit https://prismhospitalityconsulting.com.

The opinions expressed in this column do not necessarily reflect the opinions of Hotel News Now or its parent company, STR and its affiliated companies. Columnists published on this site are given the freedom to express views that might be controversial, but our goal is to provoke thought and constructive discussion within our reader community. Please feel free to comment or contact an editor with any questions or concerns.