It seems like such a simple question but often it is not such a simple answer. What I do know is the wrong answer to this question. The simple and always wrong answer is ABC company, the place I am working.  Learning how to discern who your client is may be the single most important consulting skill you will learn. It’s harder than you think.

Example: You work for a large systems integrator. They have a customer they wish to sell a solution to. Say an ERP solution that they have developed or have a partnership with a specific vendor. They send you into their customer at no charge and ask you to do a requirements and architecture analysis to determine the “fit” of the proposed solution. Let’s call the systems integrator SI and the customer ABC co.

Is ABC co your client?

Is SI your client?

Let’s ask two important questions.

1) Who commissioned the work?

2) Who will ultimately  decides whether you succeeded or failed at the engagement and authorize the payment of your fee?

In this example, it is clear that “SI” commissioned the work with a specific task of determining the delta between their product and what the company needs.  “SI” will also decide whether the analysis and architecture work done meets their requirements. So who is your client?

Well, the technical answer is “SI”. So now what happens when you are engaged by “SI” and you determine that the “SI” product is an incorrect fit for this customer. You are fully aware of better, lower cost solutions not provided by “SI” but would be very beneficial to ABC co.  Now what?

Let’s take another example. The CIO of ABC Co. decides that he or she needs an enterprise-wide architecture review completed and hires your firm to complete the activities. You are assigned the task and are told to work with the Director of Architecture for ABC Co.  The director is very specific that they would like you to look only at portal and integration architectures and will provide the required technologists for your to talk to. Who is your client? The Director of Architecture, the CIO or ABC Co.?

Apply the test. The work was commissioned by the CIO and ultimately the CIO will decide whether what you produce on the engagement met his or her expectations and authorize the payment of your fee.

So we need to be extremely careful working within the client system that we don’t inadvertently “adopt” a client instead of really focusing on our real client. The more critical point also is that once we have identified our true client, how do we ensure that we keep this client/consultant relationship? That is the subject of a future blog.

I spent a portion of my career traveling the globe, “fixing” projects that were either underperforming or failing for a major systems integrator. One of the most stark examples of getting the client wrong  was a project in a South American country  for an AFIS (Automated Fingerprint Identification System) project. The operator of the system was this country’s federal government agency responsible for the issuance of the “Cédula de Ciudadanía”, in essence your citizenship card.  The funder of the program however was not this government but an agency of the US federal government, known as the DEA. The objectives of the program were very different depending on who you thought your client was. One had the objective of uniquely identifying their citizens to allow for votes, taxes and social programs. The other was looking to create a knowledge repository of identities for criminal investigation.

When the project was reviewed, the operator of the system was getting the features and functions they were requesting, but the entity paying the bill was about to cut-off funding to the program. What was wrong?  The local team forgot who their client was. The client was the person who commissioned the work and was authorizing the payment of the fee.  The DEA. As a by product of meeting our client’s objectives, if we could solve the requirements of the operator, then that was a bonus. In some cases we could express back to our client, the advantages of enriching the solution with operator-requested features to enhance adoption or speed roll-out and generally they were accepted and paid for.  But it took a “reset” of the project to get focused back on what the real client wanted for the project to “succeed”.

I say “succeed” in quotes because the core purpose of the system was the unique identification (once) of each citizen and the issuance of a Cédula, which was used for everything from opening a bank account, to obtaining a passport , to getting your children enrolled in school.  The subsequent use of this data was for the original client to process. The problem was that all you needed to get a Cédula was a finger that did not exist already in the database and it turned out to be pretty easy for the less squeamish people who did not want to be in the system to either buy one or take one that wasn’t theirs. The program was disbanded.

Who is your client? Apply the fingerprint test.