This post can also be found here on the Identropy Blog.

Ah, the religious wars: vi vs Emacs (vi!), Republican vs. Democrat (Neither), Mac vs. PC (Mac!)…

Mac vs. PC. We all know the talking points:

1. Macs are pretty, PCs are not.
2. PCs can be configured a billion ways, to use a Mac you must do it the way Apple thinks you should.
3. Macs are easy, PCs can be difficult
4. Did I mention Macs are pretty?

You may not agree with these assessments, but they’re popular opinions. You might ask why I would be blogging about them in a blog where I typically stick to consulting and Identity Management.

The fact is, we generally take a PC approach to IAM implementations: Here is the product, and these are the 5 million different switches we can flip to customize it for your organization. We have our best practices (default configuration), but ultimately we’re going to customize it the way you want it to be, whether it’s good for you or not. We want to be everything in IAM to everybody who will pay for IAM.

Is this the right approach? I don’t think it is. Why don’t we take a look at how Apple does things?
I recently read an article from Pragmatic Marketing, a journal my wife used to read as a product manager. They go through some of the reasons why Apple is worth billions of dollars and you aren’t.

A few of them stuck out at me:

You need to know your customer and your market.

The point is not to go ask your customers what they want. If you ask that question in the formative stages, then you’re doing it wrong. The point is to go immerse yourself in their environment and ask lots of “why” questions until you have thoroughly explored the ins and outs of their decision making, needs, wants, and problems. At that point, you should be able to break their needs and the opportunities down into a few simple statements of truth.

This is terrific advice. People do not typically know what they want, they only think they do. Invest the time in figuring out what the end goal is, then you can propose the right solution to the problem.

Pony meetings.

These meetings are scheduled every two weeks with the internal clients to educate the decision-makers on the design directions being explored and influence their perception of what the final product should be.

Keep leadership involved, and keep them on your side. Present them with an elegant solution that meets the needs of the organization. As long as they are on board with your solution, you can better drive the project.

Apple focuses on a select group of products.

Apple acts like a small boutique and develops beautiful, artistic products in a manner that makes it very difficult to scale up to broad and extensive product lines.

Dont try to solve every problem. Dont try to work in every vertical. Stick to what you’re good at, and be the best at it. This will actually make future engagements easier as you’ll have some street cred.

Ultimately, if you pay attention to detail and listen for what the customer really wants, not what they think they want, you should be successful. Just don’t be afraid to tell the customer “no” and explain why they need to change course a bit. The end result will be a successful implementation and a happy customer.

I recently worked on a project that reminded me of Jim Collins’ book Good to Great: Why Some Companies Make the Leap… and Others Don’t , particularly the part about getting the the right people “on the bus”:

First Who, Then What: Get the right people on the bus, then figure out where to go. Finding the right people and trying them out in different positions.

Mr. Collins is referring to startups, but I think it also applies in the context of the implementation of an Identity Management solution (or really any large scale technical implementation).

Now, this quote doesn’t exactly align with a project in the fact that first you find the people, then find their positions. For an implementation I would think you would generally know the role that each of the players will play. It may change a bit as you move forward, so you will need to be flexible. This post is more around the pitfalls of either having the wrong people on the bus to start with, or missing some of the key people that should be on-board.

I’ve run into this on several projects, typically from the customer side. This usually leads to the following issues:

1. Miscommunication: The customer does not understand what they are being told. This is partially the fault of the vendor performing the implementation for not making sure whether or not the customer fully understands. In the vendors defense, there should be a certain expectation upon the customer for understanding basic technical concepts within the implementation. This becomes particularly dangerous when you then have the customer project team communicating with their internal technical people.
2. Poor decision making: The customer may not understand the full consequences of decisions they are making. This is caused by either not fully understanding their own processes, not understanding their own systems, or both.
3. Extending Timelines: There is now more onus on the vendor to drive the project and direct the customer in their decision making. This takes more time for both project team meetings and for the customer to group together to make their own internal decisions.

Given these issues, how do you persuade the customer to get the right people onto the project, or how do you manage a customer if they can’t do it? Here are some of my suggestions:

1. Address the situation with the Customer Project Manager: Simply mention that it would help to have the expertise of certain people on the team on a regular basis. It may not always be possible for the PM to accomplish this, so it leads to the second suggestion…
2. Elevate to the Project Sponsor: If anyone has the ability to free up other peoples’ schedules, it is typically the project sponsor. Escalate to your own sponsor and have them have a conversation with their counterpart at the customer.
3. Participate in ALL meetings:  This means (delicately) pushing your way into meetings that would normally be reserved as internal for the customer.  If you can join these calls, then you minimize the risk of something be miscommunicated internally (and maybe you can convince one of the other parties to join the project team!).  This would also require adjusting timelines and/or burn rates, as there will be less time to do work, and more time spent in meetings.
4. Note it as a risk and adjust timelines accordingly: This is clearly not the best solution. It doesn’t solve the issue, it simply recognizes that it exists. This can also be very tricky to pull off. You go from saying “I think it would be very helpful if Sue could join the project team, because she has expertise in this area” to “I don’t think you have the right people on your team, and therefore we don’t think you can do a competent job, so we’re going to adjust our project plan.” This is quite a dance for a vendor to perform.

Lately we have struggled with a couple of our projects, and looking back it is clear that we need to refine our approach a bit.  Here is what we have currently done:

1. On-Site discovery of processes and requirements
2. Functional Design document based off of those requirements
3. Technical Design document based off of the Functional design document

At this point, the customer is generally very happy.  They see that we have accurately captured their requirements and used those captured notes to design a robust system.  They see that we “get it”.

Then we hit the build phase.  We begin implementing the results of the technical design, sometimes in a vacuum.  Then, a few days before UAT we show them what is built (and it meets the documented design), and they say “That isn’t how I want it to work!  I assumed it would be a-b-c, not a-c-b.”  Now we have a problem.

Sure, we could go back and say “Well that’s not how we have it laid out in the Technical Design Document that you signed off on”, but that wouldn’t be fair to the customer.  When the customer sees a technical design doc, it might as well be in Greek.  In the case of Courion, they don’t understand Provisionee Communities, Provisioners, or the difference between User Success and Resource Success.  Nor should they.  They signed off trusting that we captured and reflected their process appropriately.

In our opinion, we did capture it properly, however there was a requirement here and a requirement there that didn’t make it in to the document.  There were some things that we interpreted one way, and they interpreted another.  There were cases where we would explain a functionality, and we didn’t do a good job of it so the customer misunderstood.  The customer didn’t have the knowledge to detect this, so they signed off anyways.  Now here we are.

In the end we end up giving in because we want the customer and the project to be successful.  We take pride in what we do, and if what we are doing is providing a solution that is of none to little value to the customer, what have we really done?

We’ve had discussions in-house about the waterfall vs. agile approach, or maybe a hybrid of the two.  We currently fall very much into the waterfall approach.  Which has worked for you?

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?