Best Practices | 6 min read | Audience: Systems Integrators & Enterprise IGA Program Managers
Most IGA programs begin the same way: a successful pilot. A small set of applications — usually the highest priority, best-documented, and most cooperative application owners in the portfolio — gets onboarded in a controlled environment with dedicated team attention. The pilot succeeds. Leadership is satisfied. The program expands.
And then the problems start.
The applications that made it through the pilot were selected precisely because they were tractable. The rest of the portfolio is not. Application owners are less available and less cooperative. Entitlement documentation is incomplete. Connector types vary. The team that ran the pilot is now stretched across twenty applications simultaneously rather than five. The process that worked at pilot scale — intensive, expert-driven, individually managed — doesn’t scale to the full portfolio.
This is the pilot-to-program transition problem, and it’s where more IGA programs stall than at any other point.
Why Pilot Success Doesn’t Predict Program Success
The gap between pilot and program isn’t a technology problem. SailPoint IdentityIQ performs at program scale the same way it performs at pilot scale. The gap is a process problem.
Pilot programs are typically run with a level of individual attention — per-application intake meetings, dedicated developer involvement, close coordination with application owners — that is inherently non-scalable. When the same process is applied to a portfolio of 200 applications, the math doesn’t work. There aren’t enough identity architects to run intake meetings for 200 application owners simultaneously. There aren’t enough developers to hand-craft configurations for 200 applications in parallel. The timeline slips. Costs exceed projections. The program loses momentum.
The organizations that successfully scale from pilot to program don’t do it by adding headcount. They do it by systematizing the process so that per-application overhead decreases as portfolio volume increases.
The defining question for program scale isn’t “can we onboard this application?” It’s “can we onboard the next hundred applications without proportionally increasing the team?”
The Four Process Failures That Kill Scale
Expert-dependent intake
When intake requires an identity architect in every meeting, capacity is limited by identity architect availability. At pilot scale, that’s manageable. At program scale, it creates a bottleneck no amount of additional effort can fully clear. Scalable intake is self-service — application owners complete the process accurately without expert guidance at every step, guided by embedded context, plain-language explanations, and AI-assisted answers in organizational terms.
Manual configuration
Developer time is the most constrained resource on most IGA programs. When configuration requires manual development for every application — intake translation, connector setup, role definition, lifecycle rule authoring — developer availability becomes the rate-limiting factor on program velocity. The fix is not more developers. It’s generating configuration from validated intake data rather than hand-crafting it from notes. Developer involvement shifts from construction to review.
Inconsistent governance
Pilot programs often establish governance defaults informally — the team knows what birthright roles look like, how approval chains should be structured, what eligibility checks are required. That knowledge lives in people’s heads and gets applied case-by-case. At program scale, case-by-case governance creates inconsistency: applications onboarded by different team members end up with different governance profiles. Audit findings result. Rework follows. Scalable governance means codified defaults applied consistently to every application, regardless of who ran the intake.
No pipeline visibility
On a five-application pilot, every team member knows every application’s status. On a two-hundred-application program, nobody does — unless there’s a systematic way to track it. Without pipeline visibility, status updates are collected in meetings, tracked in spreadsheets, and communicated in reports. That process consumes hours every week that could be spent on delivery. Bottlenecks aren’t identified until they’ve already caused delays. Scalable programs have real-time pipeline visibility: every application’s status visible at a glance without requiring anyone to ask.
Building for Scale Before You Need It
The organizations that navigate the pilot-to-program transition most successfully make one critical decision: they build scalable process infrastructure before the portfolio expands, not after.
Retrofitting process improvements onto a program that’s already in delivery is significantly harder than establishing them at the outset. Application owners who have already experienced one intake process — even an inefficient one — resist changing it. Developers who have been building configurations manually for months resist changing their workflow. Program managers who have been tracking status in spreadsheets resist moving to a new system.
The best time to implement a systematized onboarding process is when the program is defined. The second-best time is at a natural inflection point — before the next phase of application onboarding begins.
What Scale Actually Looks Like
Programs that systematize application onboarding typically see three measurable changes:
|
3–8 wks Per-application time The difference between a program measured in years and one measured in months. |
0 Additional headcount needed Developer capacity freed for higher-value work without adding to the team. |
↓ Audit findings & rework Governance defaults applied systematically produce more consistent, auditable outcomes. |
These improvements don’t require a different team or a different technology platform. They require a different process — one that’s designed to scale from the beginning.
The DoD Migration Scale Problem
For SI teams pursuing DoD migration work under the DoD CIO ICAM mandate, scale is not a future concern — it is the present reality. Programs that require hundreds of application onboardings within a 24-month window have no margin for manual, expert-dependent processes.
The delivery teams that win and successfully execute this work will be the ones that enter with a systematized onboarding methodology. Not because it sounds better in a proposal — though it does — but because the programs that don’t have it will not finish on time.
Built for Programs That Need to Scale
Structured intake, automated configuration, codified governance defaults, and real-time pipeline visibility — designed for exactly the pilot-to-program transition.
