Straight Talk on How to Succeed (or Fail) in an IAM Deployment - Part I

By Buck Bell ·

In his book, The Bed of Procrustes: Philosophical and Practical Aphorisms, celebrated author Nassim Nicholas Taleb (he of The Black Swan fame) has a wonderful thought that has become one of my favorite quotes: “The best way to spot a charlatan: someone (like a consultant or a stockbroker) who tells you what to do instead of what not to do.” While a bit snarky perhaps, it is a powerful notion. In 15+ years of practice, my sense is that while “no” may be hard to say and even harder to hear, as consultants we have seen consistent patterns emerge. While not comprehensive (every good story needs to leave you wanting more, yes?), here is a short list of items and actions to avoid in the interest of IAM project success.

  • DON’T assume that IAM can be deployed in a silo. In the interest of compartmentalizing deployment and reducing overhead for other groups, some well-intentioned clients seek to contain an IAM deployment to a single group or department. A security or application group may be responsible for provisioning and account management today, but that will almost certainly change once a solution is in place. Excluding those groups from the process can lead to mismatched expectations and significant changes to scope down the road.
     
  • DON’T withhold information. This is particularly true during the pre-sales process. IAM projects are significant efforts that can drive efficiency, compliance, user satisfaction and can enable growth. They can also be intrusive on day-to-day business during deployments, and everyone must be on the same team. Get an NDA in place and have an open conversation with all parameters, including timelines and budget. You’re smart enough to determine if you’re working with the right organization very quickly once everything is on the table.
     
  • DON’T plan for more product than process. “How long will it take to deploy this” is a fair question, but it’s the wrong question right out of the gate. People, process and data quality will all impact the approach to an IAM deployment to a greater degree than the core technology. Plan for business processes to dominate early discussions.
     
  • DON’T wait too long to start testing bits and bytes. However (see above), integration risks are real, and discovering challenges early is a key success factor. Do not wait until system integration testing to determine that the IAM solution does not support the API for your key business app! Demo/test, remediate, rinse and repeat.
     
  • DON’T write a product RFP. Cue the hate mail in 5, 4, 3, 2… In all seriousness, vanilla RFPs do not provide much information. Most vendors will check the yes box and usually appropriately so. “Can your solution manage Groups in Active Directory?” is not a question that will generate a particularly meaningful response. Leverage trusted advisors to help you match your business requirements, internal skills and vendor affinity to a few key vendor technologies. REMEMBER:  The combination of your business and technology needs + trusted implementation partners + well-scoped efforts + vendor solution = success. None of those can be missing.
     
  • DON’T try to violate constraints of the physical world. Fred Brooks’ The Mythical Man-Month remains an engineering favorite some 40 years after publication. It’s worth a read, but one of the primary points made in the short book is that the addition of additional team members at key project points will likely SLOW the implementation, not speed it up.  Don’t try to do the impossible. You may have legitimate reasons for short timelines; audit needs come to mind. At the same time, there is a minimum amount of time needed to support the analysis, deployment tasks and organization change management to make an IAM project successful. Nothing on earth will change that, but some folks will continue to try. Don’t be them.
     
  • DON’T over-automate. Automation can be great, right? Well, yes, end-to-end automation of lifecycle management CAN be a good thing, particularly to key identity repositories like Active Directory or commercial databases. But go into IAM knowing that process automation is often more important than last-mile technical automation. Even now, a significant number of IAM initiatives are compliance driven. Controls and audits, in these cases, supersede automation in importance. It’s likely that you can automate the lifecycle process for 25 applications more quickly than you can automate electronic provisioning of six of those same applications. Still, there are exceptions to every rule, and a combination of basic account automation and manual entitlements management (with an audit trail driven through the IAM system) can be a middle-ground solution.
     
  • DON’T mistake estimates for immutable proclamations. Expectations management is a key to the success of IAM projects. Bottom line: things go wrong. Things that have gone right 20 times at 20 other engagements in 20 different environments can still go wrong on time 21. IAM is complex stuff, given that it touches applications, application custodians, users, HR systems, Helpdesk, networks (hello, SSO!), security SOP’s, audit groups… the list goes on. Plan for the likelihood of change. Keep focused on the core mission, assess the impact of the change and move forward appropriately.

In Part 2, we’ll take a look at some specific don’ts when it comes to project plans, environments, testing and more!