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?

Understand the data and workflow of the system. Whether you’re a C programmer developing a check-writing module that fits into a larger system or an Internet consultant designing a complete e-commerce strategy, it’s critical that you investigate and understand the flow of data into and out of your system. By mapping the data flowing in and the reports, transactions, or even products that flow out the back end, you can get a clearer picture of all the clients who need to be satisfied by your activities. It’s also important to understand workflows: many clients may never touch a keyboard, but may be integral parts of a business process that your system will influence.
Negotiate for broad access. In both the initial project-scoping process and the design process, it’s critical to set up formal communications processes with every client community. You will often need to negotiate access to client groups, as there are still many managers who believe that they know best what their teams need. Some projects may be on a tight schedule, and some clients resist wide access for fear of affecting the deadline. Many consulting clients will also resist widespread interviewing simply because of the cost, fearing it will drive your billable hours through the roof. When you encounter clients who resist widespread access, you can use the “soft stuff” — building consensus, generating excitement and demand for the applications, determining training requirements, and so on — to help the primary client understand the importance of broad access. If your access to critical client communities is being unreasonably restricted, that’s a sure project distress signal. I’ve walked away from engagements in which I couldn’t negotiate the appropriate access.
Remember that internal IT is also a client. The existing IT staff will take responsibility for running and maintaining your system once you’re gone, so make sure that their needs for training, documentation, and integration with existing systems are taken into account. If the new system requires IT to learn new skills, you can add real value by participating in knowledge transfer as you implement your systems.
Set broad success criteria. Once you understand the broader client base and have involved all clients in the design of your system, make sure that your success criteria are based on the needs of all. Meeting schedule and budget are important, but so are usability, robustness, and supportability. If your system is “customer-facing” (for example, an e-commerce site), measuring the customer experience is another crucial metric of success.
Allow all client communities to participate in the post-project evaluation. If we have successfully involved all client communities in our design and implementation efforts, we should be prepared to let them all vote on our success. While this can seem threatening and complex, it offers tremendous benefits as well. It gives us wide visibility within the organization, opening new opportunities for project work. I find that it often creates add-on billable work, such as additional training, documentation, or system enhancements. It also allows us to continue growing as consultants, helping us take off our technical blinders and learn about the holistic business benefits of our systems.

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!