by - Jon Inge. 
Jon is a featured writer of 
Hospitality Upgrade Magazine. 

• View more articles covering technology for the hospitality industry at the Hospitality Upgrade web site
• To request a free publication please call (770) 953-2300 or email.

These words can strike both joy and terror into our hearts.  As many a tool-oriented person will tell you, the best part of getting any new tool is in the buying.   The anticipation, the thoughts of new capabilities, the looking through the catalogs and thinking of the nirvana to come when it arrives�  But soon as you get it home and put it to work, the real challenges begin.  And somehow, the reality of the new tool never quite lives up to your hopes and expectations, or the project you bought it for never seems to work out quite as you�d hoped.

Hotel systems are just the same.  We start out with the best of intentions, but Murphy�s Law is irrevocable.  Sometimes things go wrong in the outside world; vendors are occasionally a bit optimistic about the capabilities of their systems, and support can often be a trial.  But sometimes we just trip ourselves up all on our own and fall headlong down the road to hell.  This article explores some of the more common traps we set for ourselves.

The Purchase and Advance Planning

These belong together, since you have to plan for all the implications of what you�re buying - the impact on other systems, the hotel infrastructure, the length of preparation and training time, etc. - before you can come up with a total budget. 

According to my Murphy�s Law desk calendar, Blair�s Observation somewhat cynically says that, �The best laid plans of mice and men are usually about equal.�  The difference is that men (and women) can track progress against the plan, and make corrections if things go off course.  But you have to have a plan to start with, one that covers what you want to achieve but that also allows for the possibility that some things might go wrong. 

Let�s look at some of the more common problem areas.

Lack of Executive Support
Support from the top is the most fundamental thing you must have.  Without executive commitment to the new system and its budget, along with buy-in from all departments affected by the change, no plan has much chance of succeeding.  Any department proposing a new or upgraded system must be able to make the business case for it, with an open evaluation of the impact on other areas, all of which must agree to support the change.

Remember Murphy�s Seventh Corollary: �Every solution breeds new problems.�  What are the wider implications of improving things in one area?  Is this just transferring a problem somewhere else, or is it truly part of a property-wide strategic plan with known and agreed implementation phases? 

Being Enticed by the Wrong System
There are so many different systems, in so many different forms, that it�s easy to be attracted to one that isn�t really a good match for your property.  You can assume that they all cover the basics - all PMSs take reservations, check guests in and out and manage folios, back office systems all cover general ledger, A/P and A/R functions, POS systems all handle menus and guest checks, etc. - so you need to focus on defining the specific needs of your property.  Do you have a heavy percentage of group business, needing rapid handling of check-ins?  Are you a resort with all kinds of bookings for guest activities?  Outside the USA, what are your needs for international date formats, paper sizes, tax structures?  There are so many systems to choose from that these basic guidelines are essential to narrowing down your choices.  Make sure your preferred solution covers these basics before you even get close to buying it.

Sound obvious?  Sadly, it�s not. Quite often properties are drawn to systems for other reasons, such as a powerful report generator or an attractive user interface.  These things are definitely important, but only to differentiate systems that already address your core requirements. 

Apart from the application�s inherent functionality, it must also fit in well with your existing systems.  Data exchange continues to increase in importantance, and the lack of essential interfaces can truly hamper productivity.  The vendor may offer an interface to your central reservations system, for example, but is it truly a two-way link, and are the data fields being transferred the ones you need and expect?

Every property has its own technology comfort zone, too.  If you want a Windows - based system, are you prepared to commit to the more powerful hardware it needs, or the extra maintenance and support required to keep it running smoothly?  If the system you�re favoring is missing a few features that the vendor agrees to develop for you, are you comfortable being a beta site, knowing that the additions may not be ready on the date promised, and that nothing ever goes in the first time without problems?  There�s often an operational advantage by going with the latest technology, but it takes real commitment and awareness of the risks to follow that road successfully.

Bad Timing
Aiming for a really fast-track installation to meet a short-term window of opportunity can be a disaster.  You might want to rush to install before your high-occupancy period starts, or the vendor might offer a near-future installation date to take advantage of an unexpected gap in its implementation schedule.  But these systems are complex and cover many areas; doing things in a rush means that short cuts will be taken and critical steps will be overlooked. 

While it�s tempting to get the new software in as soon as possible to take advantage of its features, it pays to be patient.  Allow enough time for a proper evaluation of systems and vendors, for a thorough review and negotiation of the contract, and for agreeing on realistic implementation and support plans.

Too Small A Budget
No-one wants to overpay for a system, but squeezing a vendor too hard during the negotiations is not a good way to start a long-term relationship.  It�s unrealistic to expect prompt, willing support from a vendor whose margins have just been cut to the bone. They have to make enough to stay in business to support your operation, after all.  You may get that last ten percent off the price by holding his feet to the fire, but that makes it painful for him to hobble to your help when you run into problems later.  Not investing enough in the hardware and infrastructure to support your systems is folly.

Picking an Incompatible Vendor
A good match between your operation and the vendor can make all the difference to a successful implementation.  Some vendors have excellent, fully-featured systems, but concentrate on the hotel chain market and may be too focused on the big players to pay proper attention to a small independent�s needs.  Others may have a good system that appears to meet all of your functional requirements, but they may be too small to cover your training and support tasks, or may not have installed their system before in a property as large as yours. 

It�s always a good idea to look for a variety of solutions from a variety of vendors: some large nationals, others more local but perhaps more innovative.  No one vendor has a lock on originality or the one system that suits every property. 

Not Checking References
This is a big one, but it�s amazing how seldom people actually do it.  You may think you�ve found the perfect system; the literature and Website are helpful and encouraging, the demo went exceptionally well, the salesperson understands all of your operational situations and is convinced that the system covers them.
But you need to verify the real-world performance of both the system and the vendor�s other staff.  How much of the demonstrated software is actually in production?  Do all those neat features really work out in practice?  The salesperson may be charming, energetic and familiar with hotel operations; how about the training crew?  And the Help Desk?  Does the vendor deliver on its software development promises? 
The only way to find out is to check with other properties using the same software, or other products from the same vendor.  Don�t call only those references the vendor provides; they�re a good start, but they should also know of others who might provide an alternative viewpoint.  And be wary if a vendor asks you not to call certain properties, even the beta sites, �because they�re being swamped with reference calls.�

One caveat on making reference checks is to remember that every property is different.  Every one will use the product in a slightly different way, and every one will have approached the system with different expectations about what it will do for them.  Don�t take their comments, positive or negative, at face value; think about their context, decide how similar their situation is to yours and weigh them accordingly.  But do make the calls.

Inadequate Budget
The vendor�s quoted price is only part of the cost of the implementation, albeit usually the largest part.  It may or may not include the computer hardware (PCs, servers, printers, etc.), but it certainly won�t include the hundreds of other things that go to prepare the property for the system. 

Some of these are easy to overlook when pulling a budget together; others may seem overspecified by the vendor, and it can be tempting to ignore them or go for a cheaper alternative. 

They include:

• network wiring and hubs
• air conditioned, secure server location
• dedicated power circuits for computer equipment
• uninterruptible power supplies for servers, key workstations and network hubs
• extra phone lines for support or interface modems
• front desk/restaurant millwork
• general office software (e.g. MS Office, e-mail, anti-virus software on all PCs)
• general office printers 
• start-up supplies (toner, paper, back-up tapes, magstripe cards, etc.) 
• surge protection for PCs 

Too Narrow a Focus
Allied with the infrastructure issue is the new system�s relationship with and impact on other systems already in place.  The classic case of this is when you need an interface between the two; you may have allowed for the cost of the interface in the new system budget, but is there also a component you have to buy for the existing system?  It�s an easy one to overlook.

Cutting Back on Training
Another favorite area for reducing the price is to cut back on the amount of training scheduled for the users and system administrators, and it�s equally self-defeating.  However, intuitive a new system might appear, there�ll be a thousand ways of using it, and the vendor�s trainers have the opportunity to teach your staff the most effective ones for their environment and situation.  Training isn�t easier if you�re changing from one system to another, compared with installing a new system into a manual operation; it�s actually harder, because the staff has to overcome the habits and routines they learned on the older software.

There�s a lot going on during a system cutover, especially for a new hotel opening.  The staff has many other things to do apart from learning a new system, and it�s pointless to try to teach them everything in too short a timescale.  They won�t have the time to focus on it all, and retention will be minimal, especially for the less-used functions.  It�s much more effective to schedule enough sessions pre-cutover to ensure a thorough grounding in the principal functions, and follow that up with refresher training a few months later to review the basics and move them on to the more detailed areas. 

And also don�t forget to budget for annual refresher training.  With the normal rates of staff turnover, and the fact that people only pass on half of what they were taught, these annual sessions will make sure that you get the most productive use out of your investment in systems and people. 

Implementation Issues

Murphy�s Law of Thermodynamics says that, �Things get worse under pressure,� and there are few more high-pressure situations than cutting over to a new computer system on a deadline.  Once again, advance planning is the key to keeping things under control - relatively speaking, of course.  Somehow things do occasionally manage to go wrong; for instance:

Poor Communication
It�s absolutely essential to keep everyone in the loop on the plan, on progress against it and on snags as they arise, to insure that any impact on other areas, or alternative actions to avoid the problem, can be identified.  A single project coordinator acting as a focus point, assigning clear roles, responsibilities, action items and due dates to all involved (and with the unwavering backing of the executive committee), is critical to the smooth installation of any system.

Inadequate Infrastructure Preparation
Even if you�ve allowed for all necessary upgrades in the budget, they have to be performed and verified before the system goes in.  Do you have signed test sheets from the network installer showing that every single run has been tested at the promised quality level, and that it�s accurately labeled?  Were the air conditioning, dedicated power circuits, UPS, phone lines, etc. all installed or modified as necessary?  Do you actually have space in the server area for all the back-up tapes, manuals, modems, etc. that will be needed there?  Is it a secured area?  Have all the start-up supplies and revised forms been ordered and delivered?

Insufficient Data Preparation
Too often, we assume that we can just fire up a new system and start work or slam in all the data from the old one and get going.  But every system set-up requires thought on how you�re going to use it, and simply transferring data from one system to its replacement will transfer all the duplicate, error-filled and unnecessary records, too.  It�s a good opportunity to clean up the old data and decide what�s really worth keeping - and the data elements probably don�t match one for one anyway, so you�ll have to decide how to handle discrepancies. 

Take the time to review the operation and identify any operational changes that would help you maximize the power and capabilities of the new system.  Especially, identifying and organizing the necessary codes you�ll be using ahead of time pays huge dividends.  There are plenty of them: market segment/origin codes, room types, housekeeping cleaning sequence, transaction codes, POS menus, meeting room descriptions, inventory stock classifications, engineering maintenance intervals and suppliers, security levels for various groups of users, and many, many more.  You will have issues to face on how to move your operation onto the new system; take the time to prepare for it thoroughly.

Unexpected Training Needs
How many times has the cry, �But I assumed you knew that!� haunted a training session?  The vendor has to assume a minimum level of computer and systems familiarity as a starting point, but they don�t always state that.  Ask up front, and then make sure all the necessary staff receive any introductory training first.  It�s still common for staff with years of valuable hotel experience to be completely unfamiliar with keyboards and mouse operations.  Don�t wait until the first training session to find out who they are and what they need.

Uncoordinated Interface Implementation
This is really a special case of Poor Communications, but interface set-up problems are so common they deserve a special mention.  There are two categories: The first was mentioned above, faulty assumptions about which data fields are transferred between the systems.  Just because you�ve purchased an interface doesn�t mean that it will pass all the information you believe is �obviously essential.� Find out during system selection.  The other issue is not coordinating the installation with BOTH vendors involved.  Ideally, representatives from both companies would be on site at the same time to verify the connection and data transfer, but at a minimum they must be available on the phone simultaneously and working together.  Finger-pointing at any stage is annoying and unprofessional; in the middle of a cutover it�s unforgivable.

Unclear Acceptance Procedures
It�s amazing how seldom there�s any clear acceptance procedure.  Training�s finished, the hotel�s operational, the vendor staff leaves, everything�s AOK and the final payment�s due in ten days, right?  Wrong - that�s when the arguments begin, about bugs not fixed, software modules delayed, commitments not met on either side. 
It really helps to set the acceptance procedure as part of the contract, right up front.  Even with some outstanding work to be done, there�s nothing wrong with signing off on system acceptance after cutover.  After all, you�re using it to run the property.   That acceptance should include an agreed list of all outstanding obligations and due dates, on both sides.  You�re going to be working with the vendor�s support team off-and-on for a number of years; it helps a great deal to start off with a clear understanding and a good problem-tracking procedure. 

Oh, and don�t forget to call the vendor�s Help Desk before the installation crew leaves the property; it�s nice to verify that they�ve heard of you before you need them.

On-Going Operational Issues

Once the system�s operational, we can still shoot ourselves in the foot and make running it more difficult and less productive than it has to be.  Basically, it�s not that hard; it just means keeping on top of things in an orderly way.  Some examples of what not to do:

No Follow Up
Once you�ve agreed on the open action items, of course, you need to follow up on them, and make sure that everyone involved, on both sides, follows through.  But it can be hard to do when you�re focused on getting things moving, and get into the habit of working around known problems.  It�s also worth keeping a close eye on system performance and functionality from the start; it helps to establish a baseline in case problems arise later, and to check that the less common functions are performing as expected once your staff gets around to using them. 

Letting Training Slide
Another reminder about refresher training.  You should have budgeted for it, so make sure you commit to doing it.  Periodic (at least annual) refresher training will pay great dividends in insuring that your staff is getting the best out of the system.

Inadequate On-Site Support
All systems require a good deal of general day-to-day support.  Things will go far more smoothly if this is acknowledged up front and the tasks assigned to specific people, instead of falling to anyone who takes an occasional interest in it!  The accepted standard in the business world is that a network takes one full-time support person for every 50 PCs on it, to handle software hang-ups, printing problems, connection issues, bug tracking and fixing, and so on.  How many properties do you know that have that staffing level?  And yet we run one of the most intensive environments there is, a non-stop, 24/7 operation. 

There are also monthly anti-virus updates to load, daily back-ups to run, general network admin (adding new users, deleting those who�ve left, administering e-mail, monitoring firewalls) and occasional software updates to load, and much more.  Yes, you can outsource many of these functions, but you�ll still need designated people in each major department to be aware of and coordinate all system issues.  Overall, those properties that keep a basic level of technical competence in house will have fewer problems, and recover from them more quickly, than those who rely on the outside world.

In General

Over-Optimistic Expectations:  This is really a catch-all for most of the above situations, and covers expectations about both systems functionality and the smoothness of the implementation process.  It�s human nature to wish for things to go perfectly, for the system to do all that you�d really like it to in just the way you�ve imagined, and for the implementation to go 100 percent smoothly.  We want it to be the right answer, so that we can move forward with all the operational changes we�ve planned.  But in reality we tend to interpret system descriptions, demonstrations and vendor responses to our questions all in the context of our own wish-fulfillment, and to fill in any gaps in the best possible light for our situation.  And it never quite works out that way. 

We may have great plans for all the statistical analysis we can do with the new system, and then find out that it doesn�t capture all the data elements we�d expected.  We may look for perfect integration with existing systems, and discover that there are some incompatibilities between the databases.  Menu analysis may indeed be possible with our new POS/inventory system, but only with more manual data entry and management than we really have time for.  We may think that the implementation process is well planned, and then discover that one or more of the parties hadn�t really understood their roles or responsibilities.

The truth is that no system is ever finished. There are always capabilities that could be improved or added, because human ingenuity will always want to do more, or do it better.  You might think it�s obvious that a system that can do X and Y and should also be able to do Z, but that doesn�t mean it�ll be in the system. The vendor may not have added it just yet, or may not even not have thought of it.  And there will always be misunderstandings between people on who�s supposed to do what, when and in conjunction with whom.  The best we can do is plan for what we want as thoroughly as we can, expect there to be changes and a need to compromise, and communicate with each other constantly to stay aware of reality.

Final Thoughts

Trying to stretch out your systems investment by postponing hardware replacement unreasonably is another false economy.  Three years is a typical life expectancy for PCs, and even then they�ll probably require a memory upgrade along the way.  Beyond that point they break down more often (usually without warning) and are harder to fix, leading to increasingly frustrating - and expensive - interruptions to work.  They�ll encounter more frequent incompatibilities with new office software, which is often bought for specific needs (or arrives pre-loaded on PCs acquired for new hires) and always seems to need faster PCs or more memory.  Keeping current is an investment in productivity and efficient operations, not a waste of money.

And finally - Politics.  Many implementation programs bog down or lose their way for reasons that have nothing to do with technology.  Turf wars between departments can spell doom for any project, denying staff the tools they need to do their work properly, but somehow it�s always the system or the vendor that gets the blame.  Make sure everyone involved has truly bought off on the need for and benefits of the new system, and that your staff is not its own worst enemy.

There�s undeniably a great deal to think about and watch out for if you want to avoid the traps and pitfalls.  If all this planning, effort and constant focus seems like a lot of hard work - it is.  But keep in mind Murphy�s Paradox: �Doing it the hard way is always easier.�

Jon Inge is an independent consultant specializing in property-level technology. He can be reached at [email protected] or at (206) 546-0966.