In part 1 and part 2 of the series on roadmap development, we covered scenarios where you should not develop an IAM Roadmap and some of the prep work towards developing one.  In this entry, we'll cover the actual steps of working out a roadmap.  Hat tip to Luca, who left a comment on part 1 of this series which helped provide some direction for this blog post.  Luca asked:
How can a long-term road map help to achieve a good outcome (architecture, software, finance) in highly dynamic environments? In your opinion, is it possible to put down a road map that can be useful even after plenty of mergers and reorganizations? I am wondering if is possible to define a road map that could be, in the same time, enough flexible, to be respected also after some important changes, but well defined, in order to be useful and drive choices in the right direction.
My short answer to the question is, yes, I do believe that it is possible to develop a flexible roadmap that can weather the storm of environmental changes. The core is to approach the development of your roadmap using a proven and agile methodology (we at Identropy have developed our roadmap development methodology). But before we get there, a little background information is in order.

An IAM roadmap should consist of multiple phases or iterations, where discrete use cases are implemented in each phase.  Each phase should have an average duration of 3-4 months --, slightly shorter or longer is acceptable, but we try to never exceed 6 months at a time; and identifying 'Lessons Learned' and a 'Roadmap Review and Adjustments' exercises between phases is critical. You cannot assume that the roadmap is static, it needs to be adjusted and recalibrated.  The total duration of the roadmap should range between 12-36 months. Beyond that timeline, your roadmap starts to lose touch with reality and its value diminishes.

The following is our 5-step process for IAM Roadmap development:

1. Assemble the Building Blocks (Use Cases)

 The building blocks of any roadmap are the identity initiative use cases that you have already identified as important for your organization.  Furthermore, each use case should be related to a set of requirements.  All of which must have been developed prior to roadmap development, as described in part 2 of this blog series.

2. Discover Roadmap Placement Criteria

Roadmap Placement Criteria are meant to serve as a guide towards placing a use case in a specific phase within the overall IAM program.  Our fixed criteria are 3, and are seen in almost every identity management program:
  • Value: How valuable is this use case to the organization?  Many times, this is directly related to who the use case is important to within the organization. For example, if the CEO has a directive that the use case addresses, then its value to the organization will be greater than that of a use case that addresses a departmental need, not directly aligned with the critical path of the organization.      
  • Complexity:  How complex is it to orchestrate the completion of this use case? Complexity should not be viewed from a purely technical perspective, but as a whole – is there a capital investment required? is the organization ready to undertake the initiative? does it have the right resources and change management approach? is there executive sponsorship and organizational alignment to make it happen?. For example, most Identity Provisioning projects today are not terribly complex from a technical perspective, although they can quickly become complex due to political reasons.
  • Dependencies:  Does the use case require that another use case be completed prior to addressing it? Is there a logical progression for tackling the use case that makes sense to sequence?  This could be an architectural dependency (which it often is), although it could take a broader meaning. For instance, you may address a smaller-value, but related use first to build momentum, credibility and build experience and confidence, which will help you undertake the higher-value use case – in a way “walk before you run”. Other factors may be taken into consideration based on the organization's priorities, such as  timeline dependencies (for instance based on compliance-driven deadlines) or specific “quick win” use cases.

 

3. Create a Roadmap Analysis Diagram

Once you have identified the use cases as well as the criteria, you will need to create a roadmap analysis diagram that displays the information in a consumable format.  By placing all relevant information in a single diagram can be instrumental in forging meaningful dialog towards developing a roadmap.

identity management roadmap analysis

 

In the diagram above, we've kept it simple by representing the 3 main criteria: complexity, value to the organization and dependencies. Complexity is represented on the x-axis, value on the y-axis, and dependencies as arrows between use cases, which are represented by the green boxes. You could extend this chart as needed to accommodate additional criterion as appropriate (for example, by adding a z-axis, but we tend to get lost after the third dimension).
Placement of use cases (green squares) in the correct place on the chart can be a tricky endeavor, and should generate fruitful debate among stakeholders. The particularly challenging part of this exercise is to have a fair degree of consensus of the relative value and complexity that the organization assigns to each use case. Clearly, this will vary greatly for each organization, and hence why there is no “cookie cutter” approach to an IAM roadmap.

Advice: A good piece of advice that our clients have found useful is to start with extremities (the most and least valuable, mostand least complex), and place all other use cases on the chart relative to those. We typically iterate a few times through this chart before we discuss it with a broader audience. Additionally, we suggest that you start with two dimensions first, say value and complexity, before you factor the third dimension, say dependencies.

 

4. Translate the Roadmap Analysis Diagram into an Implementation Plan

 By taking the information gathered during Roadmap Analysis, use cases can be intelligently placed in different "buckets" that represent a phase. Which once defined and sequenced, will become your Implementation Plan.  Phase 1 should consist of foundational components that can be quickly identified from the Roadmap Analysis Diagram by singling out use cases with multiple arrows pointed towards it, without any arrows emerging fromit – this is a good way to identify your “quick wins”.  Phase 1 should be relatively rich in “quick wins”, or use cases that have no dependencies and fall in the top left quadrant of the Roadmap Analysis Diagram: lowest complexity, highest value.Analyzing dependencies should also provide insight into parallel vs. serial execution/implementation of use cases.

 

Advice: Each phase should last an average of 3-5 months.  Since the success of your IAM program is so heavily dependent on incremental wins in order to build momentum, as well as feedback and lessons learned, anything longer than that should be broken down into sub phases.  Two 3-month phases are almost always better than 1 6-month phase. Also, at present times, we believe that any Implementation Plan that extends further beyond 24 months becomes unrealistic, and there is no use in forecasting activities that far out, since the pace of changes will undoubtedly invalidate most of your assumptions, not to mention the pace of technology evolution may provide different options to achieving the objectives.

 

5. Vet Results with Executive Stakeholders, and Get Their Support

Once completed, vetting the roadmap with executive stakeholders is critical. An executive stakeholder can provide valuable insight that will better align the roadmap to the organization's drivers.  During this exercise, demonstrating your thought process is as important as the actual roadmap that you've arrived at.  Expect it to be altered. In fact, be disappointed if it isn’t.  But, if you fail to provide a framework for executives to think within, alterations can break the overall approach you've spent so long thinking through.  Here are a few questions you'll want to have answers to for before this session:
  • Can we complete this roadmap in less time? Perhaps by adding more resources?

  • Can I implement a specific use cases earlier if necessary?

  • Can implementation costs be reduced by executing 2 of the phases in parallel?

  • What risks do I face for stopping after a specific phase and taking a break until the following year?

Spending up-front time constructing the right framework for your organization during the roadmap development exercise will prove invaluable to your efforts in the long run.  It will allow your organization to be flexible and make informed decisions (instead of reactionary responses) to the cross paths that lie ahead. At the same time, by having the executives engage in discussions and revisions of the roadmap, your chances of securing their support (and thereby securing funding) drastically increase. In another blog series, we will talk about the most common pitfalls in an IAM initiative, and not having executive sponsorship is perhaps the “kiss of death” for any IAM initiative. Hopefully, this series has provide you with enough tools and confidence to navigate your path, but we do recognize that every organization is different and there are externalities (such as a recessed global economy) that will greatly impact an IAM initiative, regardless of how well your IAM roadmap had been developed, but to quote the great Wayne Gretzky: “you miss 100% of the shots you don't take.” This concludes our 3-part series on Developing an Identity Management Roadmap. We hope you've enjoyed it, and look forward to your comments.

 

IAM Program Data Sheet
Ash Motiwala

Ash Motiwala

I’ve been in the identity space for most of my career, and I’m still passionate about it. Anyhow, a CTO is supposed to be the person who sets technical vision for the company, but honestly – Identropy has way too much brainpower for a single person to do that. Instead, I get my hands dirty with the customer development process, lend a helping hand wherever its needed, and I have the privilege to talk identity with some of the brightest minds in this space every day.