When the economy goes down implementation costs go up

These days it is not unusual to hear about vendors that may seem like established and safe choices closing offices, cancelling their user conference, announcing disappointing earnings, firing people and even discontinuing products. Among other less visible goings-on in the world of vendors, although much less visible, are daily decisions by engineering staff and product management people to cut corners when working on new product releases. These decisions have a tremendous impact on the final product that is shipped to the customers and typically the consequence is longer and more costly implementation projects.

Here’s what happens at vendor X working on that exciting new release that needs to get out the door:

• New features requested by the sales team are prioritised as new revenue becomes increasingly important.
• Fixing bugs, in particular those that normally reside below the uninformed management radar, is postponed to a distant future, so customers are left to fix accessibility, harmless URLs, and the flawed rich text editor themselves.
• To close even more deals, additional modules with specific features are released, perhaps even for free download. Unfortunately, each and every module is conjured up in a rush and all in a slightly different way. Thus, implementing one module is easy, but implementing and maintaining multiple modules is very difficult and costly

To make matters worse for your implementation, documentation staff and usability engineers are often among the first to be fired, since their work tends to have a direct impact on cost, but only a longer-term impact on revenue, at least in the minds of most vendors.

As a customer, I recommend you do the following:

• Have regular conversations with the vendor about your bugs and problems, upcoming releases and any updates to their roadmap. Apply as much pressure as you can to move things in your direction.
• Talk to other customers, either via user groups, a community of practice, conferences, informal meetings or simply by picking up the phone. This will help you identify the best implementation partners and together you can also exercise more influence on the vendor.
• Save your money and postpone the upgrade for as long as you can. In a future version your issues are likely to be resolved; it may just not be the next release.
• Be cautious when considering beta products
• Get trained and build your own skills, making you less dependant on the integrator
• Take a closer look at the available documentation before you get started.

Act! Otherwise, I’m afraid that my prediction about 2009 as a tough year for integrators will not come true.