Banking

The IT consultant's eternal question: 'Who is the client?'

It's often difficult for an IT consultant to determine who the true client really is. Rick Freedman offers advice and shares his rules of engagement.
 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!

About

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...

14 comments
JohnMcGrew
JohnMcGrew

In the early '80s, I was stuck in the middle of this kind of scenario a couple of times. In one particular case, I had designed a system based upon the needs of a field office of a particular financial company. Formerly, everything was produced by hand, and then sent off to the mothership on a weekly basis where it was then manually input into a mainframe system. My system automated the intake of new clients, produced all necessary reports and kept customer data accessible at fingertips, and reduced workload by 90%. Not long after due to mergers and what-not, the operations of the field office were absorbed by a very financial company, where all IT was centralized. At this point, the field office was still "the client". The executives at the mothership were bedazzled by the efficiency of my client's operation, and wished to see it deployed to all their other offices. This is where things started on their way to hell. Mothership sent their people out to meet me and to see how my system worked. It took me about 5 minutes to see that this was not going to work out well. Who was the client? The people who originally hired me or the mothership? NIH syndrome took over, and they wanted nothing to do with me. I sold the source code and walked away. Since I was still doing other projects for this office, I was able to watch what they did to my system. Modifications were totally driven by the needs of the mothership, (people paying the bills) with no regards for needs of the offices (stakeholders) that would actually be using it. It became slow and unstable, and the offices rebelled and refused to use it anymore. After that, I think they reverted to using spreadsheets. The reality is that the "client" is the one who signs your paychecks, and the "stakeholders" are the ones who have needs to be met or the project fails. If management doesn't recognize this, there's little you can do for them. Best to be ready to move on to the next job.

Sterling chip Camden
Sterling chip Camden

would be "stakeholder", although "client" does communicate membership in the set of people that we, the consultants, need to satisfy.

PMPsicle
PMPsicle

And small companies. And any company where different people authorize payments and do the work. Sometimes it goes one way (boss makes the decisions without understanding what actually happens), sometimes it goes the other way (users make the decisions without regard to costs). Part of a project manager's job is to get the stakeholder/users and the client to work together. Sometimes it's possible. Sometimes it isn't. Glen Ford PMP http://www.trainingnow.ca http://www.learningcreators.com/blog

jck
jck

Whoever decides if you get to do more work in the future for the customer. :^0 As long as they are happy and the checks keep coming in, that's really what matters.

Sterling chip Camden
Sterling chip Camden

I've seen cases when the stakeholders resist change for various motives: (1) they feel threatened by having to adopt anything new, (2) they had a better idea that wasn't entertained, (3) they have a political reason for wanting to take someone down.

JohnMcGrew
JohnMcGrew

Upper management is just concerned about their problems as they see them, and it's everyone else's job see to it that those issues are addressed without help from above.

Sterling chip Camden
Sterling chip Camden

... can be tricky, and recommending a course of action for it trickier still.

Sterling chip Camden
Sterling chip Camden

When I was young manager, I used to have an instinctive aversion to dissent. over the years, my instinct changed -- now I instinctively perk up my ears when I hear a dissenting opinion. That change in instinct came only through practice and hard experience.

PMPsicle
PMPsicle

One of the contradictions of change management is that the most important opinion to listen to is the dissenting opinion. Why? Because that's the voice that contains the weak points of the new. Unless the weak points are addressed the new will ultimately fail. Unfortunately, we usually forget that resistance to change is a survival mechanism for a reason.

JohnMcGrew
JohnMcGrew

...they just don't know what the heck they are doing.

PMPsicle
PMPsicle

And therin lies the sinking of many a project and the wreck of many a project manager's career.

Sterling chip Camden
Sterling chip Camden

if the stakeholders sink the system, the client may think twice about paying for it.

Editor's Picks