Blog Viewer

With a little over 35 years on the vendor side of the software environment, I have read quite a few customer requests for software enhancements. Indeed, one of my current roles involves reviewing enhancement suggestions for software projects.

Nothing in the list that follows is intended to keep you from suggesting changes to software. Enhancement requests represent an important conversation between you and your software vendor. The way those requests are phrased, however, can play an important role in how they are received and used by the vendor.

As a result, I have some suggestions that may help users be more successful in getting their enhancements considered.

• Describe the problem your team is encountering rather than suggesting an implementation. The best solution to your problem may be entirely different than the “tweak” you are tempted to suggest to the current software; and may result in a far better user experience.
• Determine whether your enhancement could be created with currently available configurations of your software. Many of the software systems we use today are highly configurable, which means two things:
  1. A problem you are having may be the result of configuration decisions that are already made and need to be reconsidered.
  2. A feature you would like to see may be available through additional configuration options you have not yet deployed.
• Avoid using departmental jargon when describing either a desired feature or a current problem. Departmental jargon can leave those trying to evaluate and support the request puzzled regarding what you are talking about.
• Marked up screen shots or report outputs are always helpful and provide further insight into the request being made.
• Avoid overplaying the patient safety card. If the problem you are trying to address is truly a patient safety issue, it is important to say so. But if the only reason a problem is described as a patient safety issue is that the person supplying the enhancement request thinks that doing so will improve the likelihood the idea will be implemented, that tends to become immediately obvious and may have the opposite effect.
• If the software you are using is new, or an upgrade that changes the user interface or the workflow, give your team time to become accustomed to it before requesting that it be changed to what it used to be.
  1. We tend to equate habit with competence; we therefore rarely greet change with joy, even when that change helps us be more productive. Changing habits is hard but can be worth it.
  2. In many cases, a current workflow is a workaround to a previous issue in the software that has become enshrined as a necessary feature. Therefore, it is worthwhile to take the time to learn the new way of working; you may find that it is better than the old workaround.
  3. A new presentation or workflow may solve problems when used as intended that you were unaware existed.
  4. Consider the entire workflow in your evaluation. Sometimes adding a task at one point in the workflow can save considerable time later in that same workflow, making that additional step worthwhile.
  5. If, after getting some break-in time, it seems like a software change is making work harder, or posing a safety problem, carefully document the impact of that change as part of your enhancement request.

So, by all means, use whatever resources your software vendor provides to describe problems or propose enhancements. These are the lifeblood of your vendor’s software staying current. Clear phrasing using common terminology and well-documented issues can be key to getting those enhancements scheduled and produced.

As always, the opinions expressed in this blog are my own, and not necessarily those of ASHP or of my employer.

Dennis A. Tribble, PharmD, FASHP

 Ormond Beach, FL

datdoc@aol.com