Bob Lambert

Jazz on the harmonica

How to be a good client


I recently listened to Brian O’Neill’s excellent interview with Tom Davenport, headlined “Why on a scale of 1-10, the field of analytics has only gone from a one to about a two in ten years time.”

The conversation covered a lot of ground as Mr O’Neill and Mr Davenport explored the reasons why. Highlights included general lack of technical literacy and lack of an organizational data driven culture. But to their credit, they took responsibility on behalf of analytics professionals, emphasizing how we in the field could change in order to make more analytics efforts successful. Rather than focusing on providing technology-centered solutions, they recommended that data and AI professionals seek first to understand and empathize with their clients or internal customers, enabling data and AI pros to develop more effective analytics capabilities in light of that understanding.

I agree that analytics professionals can improve their game. However, as a former consultant who’s switched over to the client side, I think there’s room for improvement all around. To me, clients who work proactively to prepare for an analytics project position themselves for better outcomes. (For convenience I’ll write in terms of a consultant working with a client, but this equally applies to IT/business and analytics/non-analytics relationships within organizations.)

I recommend that clients prepare for consulting assignments in four steps:

  1. Know your own business
  2. Research potential solutions
  3. Be humble and welcome change
  4. Spend wisely

Know your business

In a very real sense, when you bring in consultants it’s like inviting aliens to visit. You expect them to know the field well, and to have solved similar problems in other cases. However, they likely don’t know your situation: your organization’s unique vocabulary, quirks and workarounds due to your unique practices and culture, and perhaps specifics of your business and regulatory environment.

The project will go better if you understand and document your current process and data, as well non-functional requirements: the parameters within which current and future systems and processes must operate. Often, organizations will have already done that. For example, regulatory mandates dictate that the organization with which I currently work maintains current workflow definitions.

Consultants must understand the lay of the land in order to define an effective solution. Your documentation won’t give them everything they need: they’ll have to follow up with questions and conversations to fill in missing information and understand unique elements. But preparing documentation yourself before the engagement saves you consulting time and effort and results in deeper, more insightful vendor work products.

Research potential solutions

Organizations engage consultants because of their relative expertise in a particular area. However, that doesn’t let the client organization off the hook for basic subject area knowledge. Most importantly, clients must know the field well enough to contain their own expectations and recognize unreasonable vendor promises.

Here are some data-related promises available with quick web searches:

  • “We help accelerate your data-driven digital transformations so your
    business becomes a next-generation intelligent enterprise.”
  • “Harness the power of your data. Unleash the potential of your people.”
  • “Build, deploy, and scale ML and AI applications through a repeatable industrialized approach and turn data into decisions at any scale, anywhere.”

These are great tag lines that, properly contextualized, are true, so I don’t mean to pick on the companies that made them prominent on their web sites. However, for most organizations achieving promised results requires significant transitions involving infrastructure, talent, development methods, and culture.

Clients should understand the field well enough to see the submerged iceberg of foundation work under the surface as well as the tip of the iceberg that single products and services represents, and set expectations and plans accordingly.

Be humble and welcome change

There’s a paradox in being a client that I believe few who haven’t been consultants understand. Your business is, at the same time, totally unique and just like all others. That is, your organization solves the same problems using similar tools and approaches as any other organization, but it does so within its own unique culture and describes it with its own unique language.

The thing is, the latter doesn’t invalidate solutions based on the former: a good solution provider can customize a “one size fits all” approach and make it work in your unique situation. For example, if your organization is open and willing to evolve, your projects will fit agile methods, your execs will drive decisions based on data rather than instinct, and your report users will embrace new, more efficient and usable, data visualizations. You’ll reap real benefits from these and other improvements if your culture is open to the change required to do so.

Spend wisely

According to this BizTech article, “a whopping 93 percent of organizations have some shelfware, while more than a third waste at least 21 percent of their software spending on neglected software.” In my experience the same applies to — and I’ll use the same term for — spending on consulting and custom software development: I’d estimate that a similar ~20% of consulting and custom software projects result in products that go unused. 

  • Sometimes definition of the problem to be solved was insufficient or incorrect, leading to a work product that, whatever the quality, failed to address the issue at hand. On more than one project, we were asked to build out reports presenting data that, as we learned during requirements analysis, didn’t exist in source systems.
  • In other cases, the project served a group within the client organization that had failed to obtain support among other groups needed in order to make the project succeed. I remember a client saying “Oh no! This is a disaster!” on an unmuted line during a very successful demo of software we delivered. It turned out that this individual had an interest in the project failing. Although the client company paid according to the terms of the contract, the system was never implemented.
  • And finally, sometimes there was money to spend on consulting services, but no desire to implement the recommended improvements. I’ve seen many analytics, data management, and user experience strategic plans languish after delivery after the client decides to carry on as before, forgoing the potential lift of following the plan.

The key to avoiding problems like these is a consensus business case. This previous post lays out key steps: know your goals and objectives, identify a champion, identify and work with stakeholders, document tangible business benefits, and define a quick win first project. If you can’t put together a consensus business case that delivers tangible return, then it probably isn’t worth doing the work at all. Unsuccessful business cases may feel like failure, but avoiding shelfware is in itself a kind of success!

If clients know their business well, have a basic understanding of the subject area, are open to change, and spend wisely, then they will be ready to benefit from experts like Mr. O’Neill and Mr. Davenport, and maybe we can move that needle up from 2 out of 10.




Leave a Reply

Your email address will not be published. Required fields are marked *