How to Make IAM Projects Successful

How to make IAM Projects Successful

In a recent blog, Why IAM Projects Fail several reasons were given as to why projects fail, so given the title of this piece any self-respecting AI would simply rewrite this as a reverse of those reasons given for not succeeding.

However, in the carbon-based world avoiding those pitfalls still do not guarantee success. There is a technique though, that is tried and test, been around since the last millennium and doesn’t require any technical expertise plus has the bonus of being able to be used for other projects.

Sounds to be good to be true, if so, why aren’t more people doing it. That is a difficult question to answer, but the best explanation is that it became a forgotten technique when every nearly all software development and IT projects became agile in their delivery.

The technique is to identify actors or user personas in your organisation. What are actors (apart from people appearing on our screens) or user personas? Before delving into that, it is worth spending some time at how they came about.

Unified Modelling Language

Unless you are an old developer it is likely that you have not heard of Unified Modelling Language (UML). UML was developed in the early 1990s as a modeling language that is intended to provide a standard way to visualise the design of a system. In the 1990s most companies had to develop their own software as there was very little off-the-shelf programs.

There was a great need to have a good process and techniques to be able to design a system. Many methodologies were about at the time, but the visual nature of UML made it stickier with developers than some of the others.

To say that most people have not heard of UML is true, but what is true is that most people have heard of Use Cases. Use Cases has become part of modern vernacular even to people not in IT. Use Cases were developed as part of UML.

Most delivery people will claim they do Use Cases and to a certain extent they do. However, their starting point and the focus is wrong, which leads to potential problems down the line.

Take a look at this image (this is actual UML), in most projects the focus will be on the box and the ovals inside the box. Technical terms for these are System Boundary and Use Case.

The box and oval represent the functionality of the system, in this case the IAM product.

The LS Lowry inspired icons, i.e the stick men, represent Actors.

Actors

An actor is “a type of role played by an entity that interacts with the subject, but which is external to the subject.” Sounds complicated, but essentially, It’s a type of user or a non-human identity. In other words, a user persona.

Aren’t IAM Use Cases Well Known?

As IAM has been around for some time, the functionality and use cases are well known and to a point are fairly standard across the industry. Most organisations will go out a purchase an IGA, MFA tool and just evaluate based on cost and a few desirable features. In a number of cases the vendor will dictate what those features are.

What then happens, during installation its discovered that the product does not cater for all of the users and use cases. The assumption was made that a tool or a solution would, again because everything is reasonably standard and well known in IAM.

IGA and MFA have been deliberately called out, because often with these projects there are fringe use cases which can cause significant problems. For example, with IGA it can be assumed everyone is added to an HR system or everyone’s account should be deleted when they leave, or every user will be placed in your favourite identity store. For MFA it is assumed that everyone will have access to a mobile phone to use SMS OTP or an authenticator app.

How do User Personas work?

Any project should start by looking at the type of user personas in their organisation. These are different types of users whether human or not that have to be considered for any project.

(A follow up blog will describe the process of identifying the user personas). As an indication it is likely an average organisation will have around thirty to fifty different personas. Some industries such as education, health care and even retail may have double that.

For each user persona their journey needs to be considered. Each different journey will be a different requirement. This does not mean to say that every persona will have a different requirement. Consider the two examples given for IGA and MFA.
For IGA, It is likely an HR system and a database will be source for the users. There may only be two requirements to cover the users who are in either in HR or a database. For MFA only some users, e.g those working in a laboratory, will not have access to a mobile phone, but the rest will.

The important thing is that by having the user personas as your starting point this will help determine the requirements of the final solution, not the product dictating the requirements. From this the correct product or products can be chosen that will meet all of the use cases. At the very worst, deliberated decisions can be made not to handle certain users.

Unexpected Bonuses

There are a couple of bonuses to knowing the user personas for an organisation. Firstly it is that the personas can be used for any project, not just Identity. UML, Use Cases and Actors were used as part of a process for any project and that still stands. Knowing all the different types in an organisation will mean that any project can make use of it to define their requirements.

Secondly and one for the project managers. Anyone who uses a RACI Matrix (Responsible, Accountable, Consulted, and Informed) will be obtained from the list of personas. For example, consider the group Software Developers in India using a Linux Machine. It will be known who the Software Development Manager is, who is the Linux Administrator and who manages the Indian office. They will all be added to the RACI matrix.

How does this make a project more successful.

In the blog Why IAM Projects Fail several reasons were given.

  • Exec Sponsorship.
    Whilst no guarantee that an exec will not pull the plug because of a whim, identifying all the people that should go into a RACI matrix will help keep everyone informed and up to date. The more people who are vested into a project the better.
  • Program Goals
    Knowing all users and how they differ will help set the overall requirements for a project and will be of better quality. Having well defined goals at the start should make the whole project easier.
  • Delivery Timescales
    As a consequence of having well defined requirements and program goals it will be easier to manage a project as there will be less risk. Reduction of risk leads to a better controlled project and timescales can be more accurately set.
  • Technology
    A break from the norm of working around the functionality provided by a vendor, the technology can be chosen to meet the needs of an organisation.
  • Costs
    Knowing what is required, choosing the right technology to meet those requirements and then having good control of the project delivery will all lead to reduce costs.
  • User Experience
    Having a user focused project right will lead to a better user experience as all users are considered from the beginning. Even if there is a small minority that cannot be met, for whatever reason, these will be known in advance and mechanisms can be put in place to handle these fringe users.

Summary

Identity projects and products are very mature and therefore it is very easy to be lulled into the assumption that a product will meet all the requirements for an organisation. Only during installation and configuration it is realised that a product or solution will not solve all the issues. At this stage it is complicated and expensive to correct the issues.

An old technique of defining the Actors as part of Use Case Analysis for UML has long been forgotten, but it can be an essential piece of a successful project. Actors are “a type of role played by an entity that interacts with the subject, but which is external to the subject”. Essentially a user or non-human identity. Having a list of the different type of users or user personas will help define the use cases and the requirements for the end solution.

Any project will be more successful if use cases and requirements are known in advance before beginning technology selection, installation and configuration.

Besides helping with requirements for an Identity project some unexpected benefits come from defining the personas. The list of personas can be used in any project and also will help with project management by being able to help with completing the RACI matrix.

Disclaimer

The data set used for this blog was real world experiences rather than electronic.

About Chris

Chris Martin is the head of advisory services at dotnext Europe LTD. Whilst he shares a name with a famous singer, he doesn’t share the talent. He’s rather good with identity though.

Other Posts