Way before the LinkedIn humble-brag, way before the partner awards named after precious metals on the periodic table, way before consultancies discovered that independence rules do not inhibit them from accepting such awards from vendors — Identity Governance (short for Identity and Access Governance or IGA) projects were a beast to deliver.
Unleashed by the Sarbanes Oxley Act (2002) and christened by an eponymous vendor that went on to lead this particular category well into the noughties, the simple idea of having a central place for users to manage access to applications has been a fraught one to deliver.
At the heart of the Identity Governance conundrum is the overriding reality that Enterprises are not static entities – applications change, integration and hosting models change, security perceptions change, acquisitions and divestments happen. “Success” is as elusive as a feline chasing its own tail, very visible but fleeting and inconsequential.
There are no manuals out there that you can follow to get a Identity Governance programme delivered. Lived memory can help with some obvious gotchas, but for everything else, you have to learn at the coalface to get wiser.
There are a few patterns though, that will indicate to the discerning IGA manager where their programme is headed. I have tried to compile such learnings in a three part series, the first one starting with a doomscroll with its obvious patterns and anti-patterns.
#Reel 1
The business case for investment. Your chance to define success.
Favourable pattern: Think risk reduction and not audit points. Think efficiencies in hard numbers, not imaginary opportunity costs. Target 4 weeks max.
Anti-pattern: Bringing in the consultants to build the business case for you! If you don’t know what the business case is, likely they won’t either.
#Reel 2
The RFP. Alright, all those incisive “so-what” questions have been answered and you need a solution overhaul.
Favourable pattern: Stay with the business case. Stress-test achievement possibilities through conversations with industry peers. Thrash out an RFP approach.
Anti-pattern: Bedazzle yourselves with vendor spiel from conferences. Select your down-select from the Gartner Magic quadrant or Forrester Wave. Copy the requirements template used by the consultant umpteen number of times. Send out RFP to an imperfect down-select hoping to get to a perfect select.
#Reel 3
The RFP Decision. How much have you shepherded the process? How much of your personal brand is invested in the decision?
Favourable pattern: Build a structure/framework for decision making that does not need your veto. Kick the tyres on whether business case outlined can be achieved. Put forward your vote and escalate only if the decision that the panel has come up with impedes the delivery of the business case (on time/on quality/on budget).
Anti-pattern: Going on an ego-trip by shepherding the decision, badgering stakeholders, reacting aggressively to honest feedback, putting your personal brand at risk even before the project has commenced. Talk about starting off weak from the blocks.
#Reel 4
The Solution Implementation. Go big or go-small? There are three categories really — things you want to accelerate/expedite because you can and they deliver rapid benefits, things you want to proof to open new possibilities and things (big rocks!) you want to avoid while charting the ship out of the harbour.
Favourable pattern: While the vendor selection is in progress, pull together a team to structure the building blocks of your target solution. This is led by you and augmented by key stakeholders internally (and a few consultants too!). This basically sets the stall out, to define your sequence of execution, the trade-offs, their rationale and the corresponding benefits delivered by timeline.
Anti-pattern: Spending all your resource efforts on the product RFP to follow up with another expensive roadshow to select an implementation partner. Getting the Consultants to define your roadmap, because your stakeholders will agree if “so and so” said so. Hiring an implementation partner for their purported track record for implementation but ending up doing a heavily tied down fixed price statement of work that fritters away any advantage that you may have started off with.
# Reel 5
The Auditors. Internal or External, this reel could unspool real quick.
Favourable pattern: Engage early. Communicate frequently. Do not offer quick and easy solutions. Do not over commit. Demonstrate healthy pessimism. Operate an open book.
Anti-pattern: Well, the opposite of all the favourable patterns. Add to that “being smug about it”.
# Reel 6
Supporting the soon to be delivered platform. Internal or external. IGA Operations team or managed services. Or something in between?
Favourable pattern: Configuring the team to support the platform starts off as an integral part of the roadmap. Work commences on Day one. Support teams take an active part in the build. Transition checklists begin getting drafted at the same time that deployment commences.
Anti-pattern: After ignoring the internal BAU team (or worse still, picking feuds with them) for months, deeming them as unfit to support the new platform. Extending implementer scope to a Rolls Royce version of managed services where even basic BAU activities like application onboarding and major incident fixes requires a change control.
#Reel 7
Application Onboarding. What is the objective? Onboarding just enough to address the business case or onboard to replace legacy. Go back to Reel 1.
Favourable pattern: Laser focus on the business case and attendant focus on self-perpetuation of application onboarding as BAU (refer to Reel 6). Building key patterns and establishing pathways, proofing, building SLA based pipelines for demand management.
Anti-pattern: Begging application owners to get their applications onboarded to the new solution because it is bigger and better, or worse still, is “the mandate from leadership”. The self-defeating tone will be very discernible at this stage. Continuous slippages in onboarding timelines because application owners are not committed.
#Reel 8
Communications and stakeholder engagement. The bouquets and the brickbats. The easy wins and the curve balls.
Favourable pattern: Communicate success, recognise failures and present feasible action plans. Build trust by delivering on action plans. Demonstrate vulnerability in personal interactions with key stakeholders. Enlist support through positive engagement and clear asks.
Anti-pattern: Defensive to feedback. Solutioning without acknowledgement. “Your fault, not mine” approach. Passive aggressive approach to genuine or loaded feedback. Single minded, brash and loud about accomplishments.
#Reel 9
End user feedback. You say that the programme is delivering a better way to do things. How much do the end users agree? You have delivered a transformation in your mind, but for the end users, is that a regression in UX?
Favourable pattern: Exposing the solution early to end user feedback. Encouraging self-serve with bite sized tutorials. Being upfront and clear about what is configurable and what is not (and why!). Recognise views from recurring detractors and enlist them to be a part of the solution. Formalise solution acceptance to reduce noise. Enlist ambassadors that say, “Initially we did not like the solution either, but once we started using it…..”
Anti-pattern: “It is so much better than the legacy solution. I am not sure what is the problem” or “Your problem is with change, not the solution”. Beyond a point and down a few million quid it is credibility sapping if you set the legacy solution as the baseline for improvement.
#Reel 10
The afterlife. A bad memory or a feeling of accomplishment? The “glad to be over with feeling” vs “what an awesome team effort this was”.
Favourable pattern: Albeit tentative and seemingly fragile, in the defined period, key capabilities as per the business case have been delivered. It is an imperfect board, but one that can be built upon.
Anti-pattern: Frustration with results. Product/Project Managers are fired and everyone agrees that the fault was with the product after all. Redux Reel 1 again.
This is a three part series on IGA. In the next one, we will talk about the IGA business case.
The views expressed here are based on the author’s own experience and knowledge and does not represent artefacts, output or perspectives from or of any organisation. The text has been wholly human generated.