The Identropy Blog

Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

The Customer Is Not Always Right

  
  
  

This blog post was originally published here.

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.”The Customer is not always right

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 at Identropy, we have captured, high-level lessons learned on what to avoid, which we follow and apply on anything we do. But more specific to this discussion, 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?

    Comments

    Currently, there are no comments. Be the first to post one!
    Post Comment
    Name
     *
    Email
     *
    Website (optional)
    Comment
     *

    Allowed tags: <a> link, <b> bold, <i> italics