Reading Brian Sommer’s recent post on client incompetence made me think of a critical point on software implementations: clients and consultants often have unique and different focuses during business hours.
As a consultant, my focus at a client site is singular when I am engaged to implement a new system, write reports, train a course, etc. When on site to implement a new system, I usually don’t have a “day job” that would divert my attention in the event of a problem with a client’s current applications. Even if I did, many times I wouldn’t know where to start. Issues such as these are often well beyond my scope or ability to handle:
- I don’t know how to resolve an accounting issue in a client’s legacy system because I have never worked with it before.
- I can’t extract data from a mainframe because the extraction tools are antiquated and I have no experience with them.
Let’s assume that I do have the knowledge of a client’s legacy systems and can pitch in. Let’s also assume that the organization is comfortable the “all hands on deck” approach. From an insurance and liability perspective, however, I may not be able to do this for two reasons:
- The statement of work typically does not cover my working on applications with which I am not familiar.
- From a Sarbanes-Oxley perspective, I may not legally be able to get involved.
In the end, for the consultant willing and able are often not the same.
Clients, on the other hand, are constantly balancing (or trying to balance) present and future priorities. The former almost always defeat the latter, causing
- Project delays
- Cost overruns
- Critical oversights
- Minimized knowledge transfer
This problem is particularly acute at understaffed organizations. Heaven forbid that one of the following scenarios occurs:
- An organization loses a key contributor unexpectedly.
- That end-user’s responsibilities are not (sufficiently) documented, much less understood.
- The organization is confronted with an emergency requiring the immediate and undivided attention of current end-users.
- The project has a “hard stop” for budgetary and/or date reasons.
The end result is that the organization is more susceptible to major problems, oversights, and project failures.