★ The Customer Is Not Always Right

I came across this post by David Maynor, and something really stuck out to me:

Security is the first business I have seen where the customer is not always right.

I will admit I have changed testing strategies to appease customers. The wide eyed “you are gonna do what?!?!” response to a testing planned has made me worried about losing a client so although I will ruffle my feathers and puff out my chest on the importance of the testing but in most cases I will acquiesce to please the clients. This is my fault and I should not do it.

I’m sure this has happened to many of you, it has certainly happened to me.

  1. You visit a customer.
  2. They refer to you as an expert (because you are).
  3. You analyze their needs.
  4. You give your suggestions.
  5. The customer ignores you.

In the end, they say “That sounds great, but we do things this way…  We need to be able to emulate that with our new processes.”

Rather than stick to your guns, you go along with them because after all, they are the ones signing the checks, and you want them to be happy with your services/product/etc.  I often end up saying something like “Well, that is my advice, but it is ultimately your decision.”

The problem is, they end up being unhappy.  Customers often don’t fully understand the scope and impact of an Identity initiative, especially if this is their first.  The project often gets out of control.  Once they start seeing the results of implementation, they realize that maybe they should have done some things differently. Maybe they should listened to your advice.  By this time you are in testing, and its too late unless you want to start taking steps backward and pushing out your timeline.

Here are some of the situations I have run into:

  1. The customer does not want to invest in separate development and test environments.  This creates many issues.  It makes it difficult to develop one work stream while another is being tested, as they are often intertwined in some way.  It ends up being a situation where all work needs to be completed before any of it can be meaningfully tested.  You then end up with a list of changes and defects that is difficult to manage and prioritize, and you must be fixing them at the same time the customer continues their testing.
  2. Not allowing the engineers to have administrative rights on development servers.  It’s a development server!  I understand you have policies where outside contractors/vendors can’t be administrators, but let me reiterate:  It’s a development server!  This can tremendously slow down an implementation.  Often the engineer must wait for the customer for things like replacing a file, installing a component, restarting services, etc.  You are trusting us with building the system that will control the entirety of your identity infrastructure, but you won’t trust us to have full access to a single box where we perform our development.
  3. Moving forward with development before design has been fully signed off.  This happened very recently, and it has been a major headache.  We received approval for architecture, and design was 80% complete, and we moved forward with development.  Now guess what?  Requirements weren’t properly incorporated.  Screens weren’t built out as expected.  We end up doing more discovery while we are deep into the build phase.  I’ll admit this is one where we didn’t push back because we wanted to move forward, but in hindsight I wish we would have.

I’m not saying that we’re always right, or that we immediately understand all customers’ cultures immediately, but maybe we should do a better job of pushing the customer towards best practices and recommendations based on our prior experiences.  Maybe we should stand our ground a little more firmly.

The problem is:  How do you do it?

Here are a few of my suggestions:

  1. Have a prepared document of implementation best practices with supporting information.  Provide this to the customer prior to the initial engagement.
  2. Require sign-off any time a best practice isn’t being followed.  Nothing too formal, it could even an email.  Just make sure the customer is consciously aware of the decision they are making.
  3. If you deem the issue large enough, escalate it to your own project sponsor and let him or her handle further communications with the customer’s project sponsor.

How do you push the customer appropriately?  They are the ones who own the project, and they are the ones who can pull in another vendor. How do you become a “Trusted Advisor” and better guide them  through their implementation?

4 thoughts on “★ The Customer Is Not Always Right

  1. This conundrum sounds like it requires a bit of salesmanship.

    I’d recommend something like the following:

    1) Say you’ll do what they want, but don’t recommend it.

    2) Use the power of analogy and concrete examples:

    2a) Apply an analogy. “Ever get started on a home improvement project with an idea of how you want to do it? Then you get underway and discover that your plan needs to change, sometimes in a big way? A few months ago, I [some project], but after I [passed the point of no return], I realized [new approach needed]. I got in touch with [plumber, carpenter, etc.] and he told me what I needed to do. Why? He’d done hundreds of ’em. The guy was a wizard. I’m not sayin’ I’m a wizard, but I’ve tackled these sort of things quite a few times before.”

    2b) Talk about previous deployments that are remarkably similar. Use client company names and even internal employee first names. Make it real, not abstract. Note cost overruns due to increased billed hours.

    3) Softly reiterate your willingness to do it (don’t want to leave an adversarial taste in their mouths), but re-state your objection.


  2. DJK,

    That is typically the route I follow. I tell them my objection. I tell them my real world example/analogy describing why my advice should be followed. Then, I reiterate my objection.

    The customer basically says “That sounds great, but we are different and unique, and that won’t work in our organization. We need to replicate the way things currently work just with automation.”

    At that point, my hands are pretty much washed of the problem, until it surfaces later during implementation (or worse yet, after implementation).

    Basically, how do we convince the customer that we are the expert they hired us to be? That is very difficult to do in a short amount of time.


  3. Agreed. Great recommendations as well. Documentation is key and so often just presenting the same recommendation in writing has a much bigger impact. We are experts not only because of what we can do, but what we know and how well we can communicate it. Thanks for the reminder!


  4. Taking an Apple Approach to IAM Implementations | mike.trachta

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s