Editor's note: This TechRepublic article was originally published May 22, 2000, although the advice holds just as true today.
No two IT consultants look alike. Some are e-commerce specialists, others are networking experts, and still others are business strategists. But one area where they find common ground is, when a job calls for sorting through a varied group of individuals, the need to determine who the true client is. It's not an easy feat, but it's one that every good IT consultant should master.
A lesson in client relations
Early in my career, when the PC revolution was in its infancy, I worked in the real estate division for a large New York bank. The real estate loan origination process, at that time handled on the bank's mainframe computer, was slow, cumbersome, and frustrating to both customers and bank officers. Complex financial analysis needed to be done before a loan could be approved. Data needed to be input multiple times, as the lending process slowly worked its way through the bank. Customers were frustrated, bank sales teams saw deals disappear, and bank staff members hated the tedious, repetitive work of inputting and updating loan portfolios.
To fix these problems, the bank's senior executives, IT managers, and their trusted consultants gathered together to design a replacement system that could run on the real estate division's new PC network. After days of debate, working sessions, and whiteboard prototyping, a specification for a new system, to be called "Task Mangler," began to take shape. The assembled team agreed that this new system would revolutionize the lending process, allowing sales teams to evaluate and issue loans in days instead of weeks. The consultants and IT teams then worked hard for months to deliver the system they had designed.
Three months later, a pilot group of users was selected to try out the prototype. Drawn from the data-entry pool, their task, as it was described to them, was to "try out the system and see if it made it easier to enter loan data."
"Yes!" they eagerly responded. The PC's color monitor, highlighted in contrasting colors, was a delightful change from their green-screen CRTs, and its uncluttered keyboard made data entry much simpler. The pilot test was a rousing success. The consultants and bank executives were eager to unveil their revolutionary creation on the real estate teams.
Avoiding a "Task Mangler" scenario
That's when all hell broke loose. The loan profitability team performed a pilot test, ran into a few of the inevitable glitches, and dubbed the new system "Task Mangler," a name that stuck with the project forever. The sales teams refused to participate in training exercises. Rather than resulting in improved efficiency and speed for the bank, widespread resistance to the system created a backlog of loans that hurt the bank's bottom line that year. The executive team was eventually forced to compel the use of "Task Mangler" by removing access to the mainframe. As a novice IT manager, this episode was one of the formative experiences of my career. Why did this nightmare occur, and who was to blame?
Looking back over 20 years of consulting, it now seems pretty obvious what went wrong. The bank executives — and especially their consultants — never asked the most fundamental question about the system they were designing — "Who is the client for this system?" I say "especially the consultants" because I believe it is our essential duty to help our clients focus on this question. In hierarchical organizations, like banks, it's not uncommon to find IT managers and line-of-business executives designing system specifications in isolation from the eventual users of the system. Even in more participative organizations, I've seen managers and IT teams perform detailed comparisons of different accounting or manufacturing software packages, make implementation decisions, and never involve the teams that would use those systems every day. Failure to answer this central question leads to all kinds of engagement errors, such as inadequate communications, weak consensus building, and deficient training efforts.
Engaging the client
I've also seen many consultants unwittingly participate in the forced implementation of systems. To the novice or unwary consultant, it can seem obvious: the IT manager or department head who engaged me is my client. Only by painful experiences of the "Task Mangler" variety do many consultants learn the critical importance and the complexity of identifying the real client(s) in every engagement. So how do consultants, dedicated to helping our clients get the most benefit from the systems we implement, figure out who the constituents are in each engagement, and make sure that the needs of every client community are addressed in the systems we design?
First, it's critical to understand that most engagements have many clients. The IT manager or department head who engages you is your primary client. You will need to satisfy him or her with the business results he or she expects from the systems you design. You must understand the project status reporting needed, the budget controls expected, and the change-management and issue-management disciplines he or she will require you to apply. This individual will typically be your guide to the cultural, political, and organizational rules of the enterprise as well as the final authority as you develop your specifications and your technical deliverables.
Other constituencies or clients for your engagement can include the senior management team, the staff, the data-entry or word-processing team, the analysts who review the output that the system produces, external customers (for instance, visitors to the client's Web site that you're designing), and even regulatory agencies such as the Securities Exchange Commission (SEC) or the Internal Revenue Service (IRS). With all these possible communities, how do we ensure that we're acting in the best interests of all our clients, not just the manager to whom we're reporting?
The rules of engagement
Here are some rules I follow in each engagement.Uncover additional clients from the beginning. In my initial meetings with clients, I begin to investigate the complete client base of the proposed system. I ask questions such as:
- Which teams in your organization will be inputting data into this system?
- What reports or output will this system produce?
- Who is the audience for that output?
- Will your managers want to be involved in the progress of this engagement?
- Are you in a regulated industry? Will any external organizations, such as the SEC, the IRS, or the Federal Trade Commission, be reviewing the output of this system?
- Will any customers or other outside parties have access to the system? This is especially meaningful in the age of intranets, extranets, and business-to-business exchanges.
- How do these users, managers, and regulators get the information they need today?
Susan Madden, managing director of the Boston office of Razorfish — an IT consulting firm —summarizes the key lessons of full stakeholder inclusion this way: "Most important is to help the client really understand the benefits of communication. In many politically charged environments, they can feel it's a risk, because knowledge is power. We try to help them understand there can be more of a risk in not sharing."
If we can learn to take the broad view of our client communities, we can deliver systems that are embraced by the enterprise, instead of needing to be enforced (like the "Task Mangler"). We can elevate our games by gaining broader understanding of the business issues. Ultimately, we raise our value as consultants, becoming business advisors, rather than technicians-for-hire, to the clients we serve.Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.