Why Enterprise Identity Projects Fail Before Anyone Writes Code

Month nine. The program has a name, a logo on a slide, a delivery partner, two architects, four engineers, and a burn rate somewhere north of $300k a month. It has a signed contract with an identity vendor and a provisioned tenant nobody has logged into in six weeks.

It does not have a user schema.

Not "the schema needs review." There is no schema, because there is no agreed answer to the question the schema exists to encode: when the HR system says a person's employment ended on the 14th and the directory says their account was active on the 19th, which of those is the fact? HR says HR is the system of record for employment. IT says the directory is the system of record for access. Both are correct within their own charter, and the schema needs one of them to be correct globally, and no meeting on the calendar has an attendee who can make that true.

The status report says blocked on data governance alignment. It said that in month six too. The engineers, meanwhile, have built the parts that don't require anyone else's permission — the CI pipeline, the Terraform, a very nice local dev environment — which is exactly the work you do when you cannot do the work.

This is the most common way enterprise identity programs fail, and it fails before anyone writes code, which is why nobody writes a postmortem about it. Postmortems are for outages. There is no genre for a program that spent eighteen months being reasonable.

Identity is the only system whose requirements are owned by four departments

Most enterprise systems have a messy but tractable ownership story. A data warehouse is owned by data engineering, with stakeholders. A billing platform is owned by finance systems, with stakeholders. There is a distinction between the group whose requirements are the system and the groups who merely have opinions about it, and that distinction is what lets a project manager run a project.

Identity has no such distinction, and this is structural rather than accidental:

Four departments, four budgets, four fiscal calendars, four definitions of success, and — the part that matters — four legitimate claims on the same requirements. This is not a turf war. Every one of those claims is written into someone's charter, and in regulated industries several are written into law.

Notice what is missing from the table: a column for who owns whether the program ships. That column is usually filled by a program manager who has none of the four budgets and cannot overrule any of the four charters.

The standard diagnosis is "misalignment," and the standard remedy is more alignment: workshops, a steering committee, a stakeholder map, an offsite. Alignment is the wrong variable, because it is not measurable and has no obvious derivative. The measurable thing underneath it is decision latency, and through that lens the program stops being a management problem and becomes an arithmetic one.

The arithmetic

An identity program is, from a delivery standpoint, a pipeline of decisions. Very few are technical. Almost all require agreement between at least two of the four departments above, so each has a cycle time: the interval between a decision being framed and being closed in a way engineers can build against.

Three numbers describe the program:

• N — the number of decisions that require cross-departmental agreement.
• L — the average latency of one such decision, measured from framing to written closure.
• D — the dependency depth: the longest chain of decisions in which each must be closed before the next can even be framed.

For a mid-sized enterprise IAM program — one HR source, one directory, SSO for 60 applications, provisioning for a dozen, an entitlement model, a revocation SLA — N lands between 30 and 60. I will use 40. L, where these decisions go through a biweekly governance forum, is two weeks at best and more often three to four, because the first meeting discovers the right person wasn't invited.

The number everyone reaches for first is the serialized one: 40 × 2 = 80 weeks. That is an upper bound, and wrong, because decisions are not strictly serial. The lower bound is wrong in the other direction: if all 40 were independent and closed in parallel, the decision phase would be two weeks.

The real floor is set by two independent constraints, and the program pays the larger:

Constraint 1 — dependency depth. You cannot frame "what does a terminated contractor's group membership look like at hour 4" before closing "what is the authoritative source for employment status." You cannot frame the entitlement model before you know what a role is, decide the revocation SLA before you know what "terminated" means, or design the audit schema before Legal has said what may be retained. In practice D runs 8 to 12 for a program this size. At L = 2 weeks that is 16 to 24 weeks of pure decision latency, during which no amount of engineering staffing changes the date.

Constraint 2 — forum throughput. The same four people are on every decision. A biweekly forum that genuinely closes three decisions per sitting — which is generous, because most of them close two and re-open one — processes 1.5 decisions per week. Forty decisions is 27 weeks.

So the decision phase is roughly max(D × L, N / throughput) — about 27 weeks here — plus rework. Rework is where the model gets ugly: a reversed decision costs one cycle plus every decision downstream of it in the chain. Reverse a depth-3 decision at week 20 and you have invalidated the six built on top of it, for another 8–12 weeks.

The reversal rate is not small. The largest driver by far is a decision closed in a meeting where the department that will veto it was absent or represented by someone without authority — call it 20–30% of decisions closed without full authority present. That is the real reason programs slip a quarter at a time: not one big failure, one reversal.

Three levers fall directly out of this, and they are the only three:

1. Reduce N. Every configurable knob is a decision someone must make — the unglamorous argument for a platform with fewer options rather than more, which is Configuration Beats Customization seen from the program-management side. A platform offering 12 ways to model a group means convening four departments to pick one. Programs that arrived here by accumulation rather than intent, in the pattern of The Identity Tax and Nobody Plans to Build an Identity Platform, tend to have the largest N, because every past deal added a knob nobody has since removed.
2. Reduce L. Most of L is queueing time, not thinking time.
3. Reduce D. Break dependency chains so decisions proceed concurrently — which requires provisional answers, which is what the timer mechanism below is for.

Anything that does not move N, L, or D is not moving your date. Most "alignment" activity moves none of them.

The escalation distance, and why it is usually the CEO

Here is the mechanism that determines L, measurable in ten minutes with an org chart.

When two departments disagree and neither can concede within its charter, the decision escalates to their lowest common manager. Count the levels. HR rolls up to a CHRO, IT to a CIO, Security to a CISO who may or may not report to the CIO, Legal to a General Counsel. If Security reports to the CIO, an IT/Security disagreement escalates two levels and resolves in a week. An HR/Legal disagreement escalates to the CEO.

Escalation distance is a hard multiplier on L for every decision a given pair shares. A decision that needs CEO time does not take two weeks; it takes as long as it takes to become the most important thing on a CEO's desk, which for a schema question is approximately never. So it doesn't escalate. It sits, gets described as "still being worked through," and the program reports green because nobody formally raised a blocker.

Draw the four departments on your org chart and mark the lowest common manager for each of the six pairs. If any pair meets only at the CEO, you have found where your program will stall, months before it stalls. The remedy is not to change the org chart; it is to make sure that pair's decisions never need escalation — which means pre-agreeing their defaults.

The four stalls, concretely

Abstraction is what makes this topic unteachable, so here are the specific questions. Each one blocks a schema or an API contract. None of them has a technical answer. All four appear in nearly every program.

1. Who is authoritative when HR and the directory disagree about a person?

Not "in general" — for each attribute. HR is authoritative for employment status and legal name. The directory is authoritative for the account identifier and usually the email address. Who is authoritative for the manager relationship, when HR has an org-chart manager and the directory has an approval-routing manager and they differ for 8% of the population? Who is authoritative for a contractor whose record exists in the vendor-management system and not in HR at all?

Until this is answered per attribute you cannot write the sync. You can write a sync that assumes an answer — teams do this constantly, and it is how you get a reconciliation job that quietly overwrites HR data every night and a payroll incident nine months later.

2. What does "terminated" mean, and how fast must it propagate?

"Terminated" is at least five states: resignation submitted, last working day, HR record end-dated, payroll final, and rehire-ineligible. Access should probably die at last working day, but HR's system frequently doesn't end-date the record until payroll closes, which can be two weeks later. So the event that Security needs — "this person's access must stop now" — is not an event HR's system emits at the time Security needs it.

The propagation SLA is a second decision hiding behind the first. Security wants minutes. IT wants the process to survive an HR data-entry error, because a false termination locks out a working employee and generates a P1. The answer is usually asymmetric — fast propagation for disable, slow and reviewed for delete — but someone must decide it, both departments must agree, and the decision determines whether your architecture needs an event stream or a nightly batch. That is not a detail you retrofit. The adjacent boundary question — what belongs in HR versus the identity platform at all — is Identity Isn't Your HR System.

3. Who approves an access-policy exception, and on what clock?

Every entitlement model produces exceptions on day one: the auditor who needs production read access for six weeks, the acquisition whose staff aren't in HR yet, the executive assistant who genuinely needs delegated mailbox access the policy forbids.

The question is not whether exceptions are allowed. It is who signs, what the maximum duration is, whether the exception auto-expires or requires a revocation action, and what happens when the approver is on leave. A program that has not answered this ships an entitlement model that begins eroding in week two, invisibly, because nobody instruments exceptions.

4. Retention: Legal says delete, Security says keep.

Legal's obligation under privacy regimes is to delete personal data when the lawful basis expires. Security's obligation is to retain authentication and authorization audit trails long enough to investigate a breach discovered late — and breaches are discovered late by definition. Both cite regulation. Both are right.

The technically-informed resolution is usually to split the record: retain the security-relevant event (subject identifier, action, outcome, timestamp) for the longer period, and delete or pseudonymize identifying attributes at the shorter one. That is a good answer and still not one an architect can make alone, because it requires Legal to accept that a pseudonymous identifier is not personal data in their jurisdiction — a legal opinion with a signature on it.

Note what these four share. Each blocks a data model. Each is cheap to decide and expensive to convene. And each one, unresolved, produces the same symptom: engineers building infrastructure that doesn't depend on the answer.

A RACI with four Accountables is not a RACI

Somewhere around month four, someone produces a RACI matrix. Good instinct; it almost always produces the same artifact: a grid where the interesting rows carry an A under HR, an A under IT, an A under Security, and an A under Legal.

The single rule of RACI is one A per row. It exists because "accountable" means the person who decides when the responsible parties disagree. Four Accountables is not a governance structure; it is the original problem re-typeset. It converts an unowned decision into an unowned decision with a document.

What makes it worse than doing nothing is that it launders the ambiguity: the steering committee sees a completed RACI and marks governance done. This is the failure mode of Who Owns the Incident When Every Layer Worked Correctly? one phase earlier — complete ownership coverage of the parts, zero ownership of the outcome. There the unowned thing was a security property emerging from four correct layers; here it is a decision emerging from four correct charters.

The second-order tell is a role called "identity architect" with an A on every technical row and no budget authority. That person will spend the program writing options papers for a forum that does not decide.

What a working structure looks like

Four mechanisms, ordered cheapest-politically first. The second is the one worth stealing even if you ignore the rest.

1. One accountable owner with a decision budget

Exactly one person is accountable for the outcome, and — the part that gets dropped — holds a decision budget: explicit authority to close a defined class of decisions unilaterally when the forum does not converge.

Bounding the budget is what makes it politically survivable. It looks like: the program owner may close any decision that does not change a regulatory position, does not increase headcount, and is reversible within one quarter. Everything else escalates. Write those three tests down. In a typical program they cover 80–90% of the 40 decisions, dropping the escalation load from forty to five — and five is a number a real executive will actually schedule.

The owner need not come from any particular department. They need to be senior enough that overruling them costs the overruler something.

2. Pre-agreed defaults that take effect on a deadline

The highest-leverage mechanism here, and nearly free.

For each open decision, at the moment it is framed rather than closed, the forum agrees two things: a default answer and a decision deadline. If the deadline passes undecided, the default takes effect and engineering builds against it. No further meeting is required; the absence of a meeting is the mechanism.

The effect on the arithmetic is not subtle. An open question has unbounded latency; a question with a default and a deadline has latency bounded by the deadline whether or not anyone converges. And because the default exists from framing time, the decision stops blocking its dependents — which flattens D. Both constraints move at once.

flowchart LR
    F["Decision framed:<br/>default + deadline<br/>recorded together"] --> W["Review window"]
    W -->|"forum converges"| C["Closed: agreed answer"]
    W -->|"deadline passes"| T["Default takes effect<br/>automatically"]
    C --> B["Engineering builds"]
    T --> B
    B -.->|"reversible until<br/>the freeze date"| F

Three details make or break it.

The default must be the safe answer, not the convenient one. For identity that usually means the more restrictive option: shorter retention, faster revocation, narrower entitlement, HR authoritative for employment facts. A department that dislikes the default then has a strong incentive to show up and argue, which is exactly the behavior you want. A default that favors whoever wrote it destroys the forum's trust in one cycle.

The default must be reversible, and the window stated. "This default holds and can be changed at no cost until the schema freeze on 14 March; after that it costs a migration." That sentence converts an argument about correctness into an argument about a date, and dates are things enterprises are good at.

It must be written where engineers read it — in the repository beside the schema, in a decision log recording the default, the deadline, who could have objected, and what changed if anything did. If it lives in a slide deck it is not a mechanism.

The cultural objection is that this decides by forfeit. It does, deliberately. The alternative is not a better decision; it is the same decision made in month nine at ten times the downstream cost, or never made at all. A timer is what turns an open question into a bounded one.

3. An authority map per data element, not per system

Stop asking "who owns identity." Ask, per data element: who is the authoritative source, who may write it, and who must be consulted before its semantics change.

Perhaps twenty rows for a real program, and the single most useful artifact the governance track can produce, for two reasons. It is per element, so it exposes systems that are authoritative for some of their own fields and merely a cache for others — which is where sync bugs live. And it is directly implementable: it maps to write permissions, to conflict-resolution rules in the sync, and to the reconciliation logic that decides what happens when two sources disagree at 3am.

It also has a property no RACI has: it can be wrong in a way that shows up in production. A row saying HR is authoritative for employment status, contradicted by a nightly job that lets the directory win, is a discrepancy you can detect and alert on. Governance artifacts that code can violate are the only ones that stay true.

4. Phase on a low-stakes application first

This one is about learning rate. Programs are usually phased by technical difficulty — hardest integration first, to de-risk. For identity, phase by decision difficulty: pick a first application whose failure is embarrassing rather than catastrophic. An internal wiki. A room-booking tool. Real users, real terminations, no revenue attached.

The four departments are being asked to make forty decisions with no shared experience of the consequences. Security's revocation SLA is theoretical until IT shows them what a false termination looks like in the helpdesk queue. Legal's retention position is theoretical until they see an actual audit record. A low-stakes first application converts the decision backlog from speculation into evidence, and evidence closes decisions far faster than argument.

The cost is real: you will do integration work twice and reverse some decisions. Budget for it. Reversing a decision on a wiki is a config change; reversing it after payroll has cut over is a program.

The honest counterpoint: sometimes the technology really is the problem

Everything above has a failure mode: a program owner who has internalized "it's always organizational" and stops listening to engineers. That is its own kind of expensive.

Sometimes the platform genuinely cannot do the thing. A provider that cannot express a group hierarchy deeper than one level, so the org structure is unrepresentable. A SCIM implementation without PATCH on group membership, turning every membership change into a full-group PUT that races with itself. An entitlement model assuming each user has exactly one primary organization, in a company where 15% of staff are dual-affiliated. No amount of governance closes those.

Four tests to tell the difference, and they are quick:

• The empty-room test. Put two good engineers in a room with the vendor's docs and no stakeholders. A design in a day means the blocker is organizational; a list of things the platform cannot express means it is technical.
• The prototype test. Build the disputed piece against the real platform with invented policy. A working prototype in a week means the technology is fine and you have been arguing policy in technical clothing. It is the highest-value week most stalled programs never spend.
• The transcript test. Read the last three meetings' notes and count sentences of the form "the system can't do X" against "we haven't agreed X." If the second dominates — it usually does, by a wide margin — you have a decision problem.
• The workaround test. Ask what doing the disputed thing manually for a year would cost. "Two hours a month of helpdesk work" was never a blocker and should be defaulted immediately. "Four full-time people" is a real constraint.

There is also a hybrid case, and it is the most common of all: a genuine technical limitation whose workaround requires a cross-departmental decision. The platform can't model dual affiliation; the workaround is a second account per affected person; now HR, IT, and Security must agree what a second account means for licensing, the manager relationship, and termination. Diagnose it as technical and you replace the vendor; diagnose it as organizational and you argue forever. It is both, and the sequence matters: confirm the constraint technically, then run the workaround through the decision machinery like any other question — with a default and a deadline.

One note on procurement, because this is where the categories get confused. Most vendor evaluations test features. Almost none test how many decisions the platform will force you to make, which is the variable that sets your delivery date. How to Evaluate an Identity Vendor Without Reading Marketing Pages covers the operational questions; add one — show me every configuration choice I must make before go-live — and count the answers. That count is your N. If the demo takes pride in the number, be worried rather than impressed.

What to do on Monday

If you are nine months into a program with no schema, the recovery is not a replan. It is four steps, and the first two can happen this week.

List every open decision. Not epics — decisions, phrased as questions with a named set of possible answers. Most programs discover they have between 30 and 60 and that nobody had ever counted. Counting is diagnostic on its own: the length of that list is the length of your program.

For each, write a default and a deadline, in the repository next to the schema. Circulate the list noting that defaults take effect on their deadlines. You will get objections, and every objection is a decision closing early, which is the point.

Name one accountable owner and write down their decision budget as three tests. Take the residue to an executive as a single batch of five escalations with recommendations attached, rather than five separate requests over five months.

Then pick a low-stakes application and ship it, so the next forty decisions are made by people who have seen one work.

Who runs the thing afterwards — and the incentive traps that appear once it is live — is a different problem with different answers, worked through in Who Owns Identity in Your Org Chart?. And if your program is a replacement rather than a first build, Migrating Off an Identity Provider Without Downtime makes the same observation from the other end: the technical problems have known solutions, and the quarters go somewhere else.

The programs I have seen deliver were not the ones with the best architects or the most cooperative stakeholders. They were the ones where somebody noticed early that they were running a decision pipeline rather than a build, measured its throughput, and did something about the number.

The rest of them spent eighteen months being extremely reasonable.