Different Focuses – Client Vs Consultant
Clients and consultants often have unique and different focuses during business hours. This can lead to issues throughout IT engagements.
The Consultant
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 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.
The Client
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.
With more than a decade of experience, Phil Simon assists organizations in all phases of systems consulting including vendor selection, project management, business needs analysis, gap analysis, system testing and design, end-user training, interface and custom report development, and documentation. The result: providing his clients with superior systems, increased ROI, and a healthier bottom line.
Phil is the author of the book Why New Systems Fail and a seasoned independent systems consultant. He started his company in 2002 after six years of related corporate experience. With his extensive knowledge of both well-known and homegrown applications, he has cultivated over twenty clients from a wide variety of industries, including healthcare, manufacturing, retail, and the public sector.