A successful implementation begins and ends with a successful partnership.

This may sound obvious, but you’d be surprised how many people don’t understand this concept.  I’ve seen customers who are more concerned about extracting everything they possibly can from a vendor that they lose sight of their goal.  They point to the vendor any time a deadline is missed or a mistake is made.

I’ve also seen software vendors and integrators who seem to care more about landing a deal and maximizing revenue that they fail to serve their customers in the best way possible.  They look for excuses when things go awry, and resort to making up answers to issues.  This does not build trust with a customer.

I recently completed a project with a healthcare organization that understood this very well.  The project wasn’t the biggest technical challenge, but it was going to noticeably affect everyone in their organization, most notably their help desk who was going to have to handle calls for the new system.  However, we didn’t see the same resistance we see when implementing visible change at other organizations.  We were even able to get buy-in from the doctors, which is often a challenge in itself in healthcare.

The customer sponsor, the implementation team, the help desk and Identropy had all formed mutual trust with one another.  Because of this, we were able to effectively communicate the benefits of the project and work together towards a successful implementation.  One member of the customer’s implementation team even told me they liked Identropy from the start because we were willing to say ”I’m not sure about that, let me get back to you” to questions before even landing the deal.

We ended up going live with barely a blip on the radar.  There were a few things that had to be tweaked after feedback from end users, but nothing major.

And one other thing, the project was also completed WAY under budget.  Part of it was due to changes in the initial scope.  Most of it was due to two things:

1. We rarely had the communication issues that can arise from looking out for #1, and
2. With guidance, the customer was willing to take on some of the work even though they weren’t formally trained on the product.

Rather than focusing on CYA and individual interests, we focused on the project.  I attribute this to the fact that the customer saw the value of our partnership, and viewed myself and Identropy as “Trusted Advisors” rather than just another vendor.  On the flip side Identropy understood the value of the project, and rather than just billing just because we had the hours, we truly worked in the customer’s best interests.

After wrapping up that project I joined an ongoing implementation with a large telecom.  Its an aggressive project.  Within the next 24 months we are to design, build, test, and implement a best of breed collection of logical access controls, physical access controls, privileged access management, as well as automated and request-based provisioning for an organization that cannot tolerate any real measurable downtime.  Oh, and the customer is new to pretty much all of these concepts and products and is relying heavily on Identropy’s expertise.

In most situations I would call this a daunting task.  In this instance I not only think its doable, but I have every confidence we will exceed expectations and deliver on-time.  How can I be so confident?  This customer recognizes the value of partnership.  They value a work-life balance, even for their vendors.  As a services vendor, I must say this is refreshing.

I just returned from my first on-site visit.  The purpose of the visit was to get to know the team and build rapport.  Of course I had deliverables to work on, but they could have just as easily been completed at the home office.  The better we know and understand one another, the better we will communicate and work together.

Don’t get me wrong, this customer can’t afford to simply waste dollars just to have their vendors visit the office.  Nor do they think they need to watch over us. They have assured us that they fully trust our abilities to work off-site without watchful eyes.  They just understand the value of getting to know one another.

It seems like all too often we focus on short term goals rather than building lasting relationships.  It’s good to work with customers (and for a company) that understands the value of these relationships not only for the team members, but for the organizations themselves.

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 never thought I would have a post on an Identity Management and Security inspired by a cartoon, but here we are.

In my earlier post about using CAPTCHA for authentication, I referenced a blog post by Thomas Baekdal.  A large part of his post was devoted to the idea that one should use a password comprised of a few relatively uncommon English words, rather than 8 – 10 characters of mixed case, punctuation, and numbers.

Randall Munroe was able to sum it all up in today’s xkcd cartoon:

Password Strength by XKCD

It may sound counterintuitive to some, but we can break it down:

• According to Webster’s, there are about 475,000 words in the English language.
• To brute force a 3 word password would take on the average ((475,000) ^ 3 / 2) = 5.35e16 attempts
• At 1000 attempts per second, that amounts to about 1.7 million years, on average, to brute strength crack the password.

Even if you limit it to the 50,000 most common English words, you are still talking about it taking 1,980 years to crack, and that doesn’t even take into account that you could still capitalize a letter here and there.

Using short pass phrases of 3 of the top 50,000 English words is not only more secure than your typical password, it is also more memorable.  That means it is less likely someone will write it down or need to call the help desk to have it reset.

Why aren’t more organizations pushing for pass phrases over passwords?

Email Overload

I’m sure that by now many of you have read or heard about the idea of an Email Charter by Chris Anderson.  It ended up spawning the site http://www.emailcharter.org/ which lists the 10 Rules to Reverse the Email Spiral.

This thread created quite a spirited discussion at Identropy with some pushing strongly for better email restraint, while others believe one should err on the side of over-communication, letting the receiver decide for him or herself what is important, rather than the sender.  I’d like to outline each of the arguments and share my own opinion:

Pro-Charter:

1. Email can be a major timesink.  The more people are cc’d on emails, the more time is consumed by reading email.
2. Brevity is a virtue.  The ability to be concise with language can more precisely illustrate a point while consuming less of the readers’ time.
3. Appropriate communication is better than over-communication.  Often when over-communication occurs important emails get lost in the shuffle and ignored.

Anti-Charter:

1. We should err on the side of over-communication when working with customers, so that the left hand always knows what the right hand is doing.
2. Everyone on a project should know all the information about the project.
3. “If it wasn’t written, it wasn’t said”.  Always follow up a phone conversation with an email summary.
4. I would rather have too much information than not enough.
5. Today’s effective professional doesn’t operate on a M-F, 8-5 schedule.

After weighing the pros and cons, I have to side with the Email Charter.  Reading email has become a constant interruption and a chore for many.  The key is to be thoughtful and respectful of others’ time.  If you can say it in 2 sentences, then please do it.  If I send you an email about something, don’t respond back with “Got it.”  Its pretty safe to assume you got it.  

If you want to be cc’d on everything in a project then let everyone know and they can cc you, but don’t assume everyone else feels the same the way.  This allows the reader to have better control over their inbox and therefore their time.

Item 2 of the charter, Short or Slow is not Rude, addresses one of my biggest beefs with email: the idea that you should respond to email within minutes of receiving it.  If you need an urgent response, IM or call me.  I may not be sitting in front of my email.

Just this week I had someone ask my boss why I was ignoring them because I hadn’t responded to an email within 40 minutes.  I typically only even check my email every 30 minutes to an hour, and rarely check work email in the evenings or on weekends.  It’s nothing against you, I just don’t want email interrupting a meeting or my train of thought during the work day, and I don’t want work to interfere with my personal life.

Some may argue that you have to be available after hours to be effective.  I would argue that if you can’t get it done during your normal business hours, then you are either overworked or ineffective.

While I like the overall charter, One thing I would add is “Be polite when being concise.”  I’m old fashioned and still include a salutation at the beginning of virtually all of my email correspondence, even if it is a short one sentence response (Many people think I’m crazy for doing this).

I’m not saying that a salutation is necessary for all emails, but I am saying that one should at least be aware of how the recipient could view the tone of your response.  It can sometimes be difficult to discern tone in an email.  I typically give all my emails a quick second read before sending.

I think the email charter is a step in the right direction.  If we can all be thoughtful and concise when sending emails, it can greatly reduce the amount of time spent on checking email, as well as the distractions it causes.

We’ve all tried to log in to a website and been frustrated by the dreaded CAPTCHA.  We stare at it trying to figure out what exactly it says.  According to a study at UC San Diego [pdf link], the median response time to CAPTCHA is 14 seconds, and accuracy is about 90%.  That adds up to a lot of wasted time.

Here is the latest one I received from Google:

naushdest? ndishclest? noushclest?

Can anyone tell what this says?

I’m sure some of you can but I sure couldn’t, and I have 20/20 vision.  The biggest problem I have is that it wasn’t even necessary.  I was logging into my Google account.  It already has authentication.  If you’re worried about bots brute forcing authentication, CAPTCHA is not your answer.  Better authentication is.

It reminded me of a blog post by Thomas Baekdal I read a while back about the usability and hackability of passwords:

All you need to do is to prevent automatic hacking scripts from working effectively. What you need to do is this:

1. Add a time-delay between sign-in attempts. Instead of allowing people to sign-in again and again and again. Add a 5 second delay between each attempt.It is short enough to not be noticeable (it takes longer than 5 seconds to realize that you have tried a wrong password, and to type in a new one). And, it forces the hacker to only be able make sign-in requests 1 every 5 seconds (instead of 100 times per second).
2. Add a penalty period if a person has typed a wrong password more than – say – 10 times – of something like 1 hour. Again, this seriously disrupts the hacking script from working effectively.

If you just add in a 5 second delay between attempts with a 5 minute penalty period after 10 failed attempts, then a 6 character password, letters only, case insensitive would take an average of 171 years to crack via brute strength.  I have a feeling the password would either be irrelevant or reset by that time.

I understand that CAPTCHA has it’s place when you want to make sure a human being is using a page to answer a poll, purchase tickets, register for a site, etc.  For those limited circumstances, it’s appropriate.

It is not appropriate when coupled with authentication.   Can we finally get rid of it and actually make sites that are easy on end-users?

Hat tip to Kerem Kacel for pointing me to the 14 second stat.

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.

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?