The Overwhelmed Help Desk Operator
Every morning, Tommy Sherman opens his laptop, clicks the help desk portal, and faces a growing list of tickets that look almost identical: “New hire needs a system ID,” “Employee transferred - change access rights,” or “Ex‑employee still appears in the directory.” His queue swells as the company expands, and each ticket seems to take longer than the last. Despite his best efforts - batching requests, checking the provisioning database, and calling vendors for support - Tommy finds himself constantly playing catch‑up. The root cause of his frustration isn’t the volume of work; it’s the age of the underlying provisioning system that serves the entire organization. This system was built in-house, using custom scripts and a legacy database that never saw a major overhaul. Over the years, the codebase grew unwieldy, the hardware degraded, and the documentation fell into disrepair. New employees shout for system IDs and have no way to check the status of their requests; existing staff demand updates as they move between units, yet their tickets linger in the system. Ex‑employees remain listed in the directory for months, posing security risks. Tom’s manager, who has never seen the root cause, is preparing to confront him about the apparent unresponsiveness that he perceives in the system. This scenario is not unique to Tommy. Many organizations find themselves in this dark place because their provisioning and user management platforms simply do not meet the evolving needs of their business. When a company fails to plan for upgrades or improvements, the symptoms - slowdowns, security gaps, and frustrated staff - become unavoidable. The first step toward relief is understanding why these upgrades rarely get off the ground. Below, we examine the ten most common roadblocks that keep companies from modernizing their identity and access management infrastructure. Each section delves into a specific obstacle, illustrating how it manifests in real organizations and outlining the underlying causes that make it so hard to overcome. By the time you finish reading, you’ll have a clearer picture of the factors that keep provisioning projects stalled and be better equipped to address them in your own environment.
No Budget
When a company’s IT budget is frozen or tightly controlled, the most obvious casualty is the identity and access management (IAM) infrastructure. In many enterprises, IAM is treated as a background utility rather than a strategic asset. Because of this perception, the board and finance team reserve funds for high‑profile initiatives such as ERP upgrades, cybersecurity hardening, or cloud migration. Even if the IAM system is critical to daily operations, it rarely features on the funding list because its benefits are diffuse and long‑term. For example, a company might invest millions in a new HR system to streamline onboarding, but still neglect the underlying provisioning platform that feeds employee data into that HR system. The result is a chronic maintenance drain: the old hardware demands replacement parts, the custom code needs frequent patches, and the help desk staff spends countless hours troubleshooting failures. This budgetary neglect cascades into a vicious cycle. As the platform ages, more time is spent on firefighting rather than strategic development. Stakeholders see no tangible return on investment (ROI) from the IAM system and therefore continue to deprioritize it. Over time, the platform becomes a liability, increasing the risk of security incidents and operational bottlenecks. The only way to break this cycle is to frame IAM as a business enabler. Demonstrating how a modern provisioning system can reduce onboarding time by 70 percent, cut help desk tickets by 50 percent, and lower the cost per user can help reallocate resources. However, unless the financial leaders see concrete numbers, the project will remain on the backburner. In short, without a dedicated budget, IAM upgrades struggle to move from a wish list to a funded initiative, trapping the organization in a state of reactive maintenance.
Infrastructure Is Not Sexy
Even when a budget exists, the underlying hardware and software that supports IAM often gets overlooked because it doesn’t look exciting. Think of a server that has been running a stable, albeit dated, identity platform for five years. To the IT director, this server represents a single point of failure that is still “up and running.” The investment required to replace the server, re‑architect the database, and migrate data to a cloud‑based IAM service seems like a luxury rather than a necessity. The term “infrastructure” rarely triggers the same emotional response as “new feature” or “innovation.” Because of this, the IAM system becomes a maintenance task rather than an opportunity for improvement. The phrase “cheap is expensive” rings true in this context: the hidden costs of an aging platform - downtime, manual work, and security breaches - eventually outweigh the upfront cost of a modern upgrade. When the infrastructure appears “not sexy,” executives may feel that the risk of disrupting an apparently stable system is too great, especially if the current setup rarely experiences outages. In reality, the stability of legacy systems is often illusory, built on workarounds that mask deeper vulnerabilities. The lack of enthusiasm for infrastructure upgrades is a primary reason many IAM projects stall, as the organization continues to accept the status quo while the hidden costs accumulate.
No Champions
Even the most well‑designed IAM upgrade can flop if no one within the organization can champion it. A champion is more than a technical advocate; it’s someone who can translate the benefits of a new system into business language and push it through decision‑making layers. In many companies, the people who identify the need for an upgrade are also the ones who work daily on the legacy system, and they may feel defensive about its failures. Without an impartial advocate, the project risks being labeled as a “nice to have” rather than a priority. Moreover, champions can suffer from burnout. If the first attempt to secure buy‑in fails, the champion may lose energy and interest, leaving the initiative without a clear voice. Without a dedicated champion to navigate budgetary discussions, stakeholder meetings, and vendor negotiations, the project can become lost in the shuffle of competing priorities. The solution is to identify individuals who are cross‑functional - someone with technical knowledge, business acumen, and strong influence across IT and operations. These champions should be empowered to own the project, set milestones, and communicate progress. When an IAM upgrade is supported by a passionate, persistent advocate, the likelihood of moving past the planning phase and into execution rises dramatically.
Business Case Is Hard to Write
Crafting a convincing business case for an IAM upgrade is often the biggest hurdle. Decision‑makers tend to focus on hard metrics - numbers that can be quantified easily, like the cost of licensing or the price of a new server. Soft metrics, such as the time an employee spends waiting for a new account or the frustration of a help desk ticket that has bounced between systems, are harder to capture but equally important. A strong business case blends both, showing how the upgrade reduces downtime, improves security posture, and frees up IT staff for higher‑value projects. The challenge lies in quantifying these benefits. For instance, a new provisioning platform might reduce onboarding time from three days to one day, translating to a savings of X hours per employee per year. Capturing these savings requires a detailed analysis of current processes, cycle times, and user impact. Organizations often avoid this deep dive because it demands time and effort, which they may feel they lack. As a result, the business case remains vague, and the project is dismissed. The key to success is to gather data from real users, document pain points, and create a realistic ROI model. Even if the numbers don’t look spectacular at first glance, the narrative that ties user experience to productivity gains can be powerful enough to secure funding and executive support.
Can’t Agree on Software or Hardware
Choosing the right technology stack is rarely straightforward. In many IAM projects, different stakeholders bring their own preferences to the table. HR may favor an open‑source directory service, while security insists on a commercial solution with built‑in multi‑factor authentication. Infrastructure teams might champion a cloud‑native approach, whereas operations prefer on‑premise control. These divergent views can stall the project as each party negotiates a compromise that satisfies none. The underlying issue is a lack of clear, objective criteria for selection. Without a documented framework that weighs factors such as cost, scalability, security compliance, and integration complexity, decision makers default to “let's pick something quick” and then face a cascade of integration problems. Even when a vendor is chosen, configuration disputes - like whether to enable certain attributes or integrate with legacy payroll systems - can create roadblocks. The root of these conflicts often lies in a misalignment between business objectives and technical capabilities. To prevent stalemates, an early, cross‑functional evaluation should map out the organization’s true requirements and test candidate solutions against a set of agreed‑upon metrics. This structured approach reduces the chance of post‑selection disputes and ensures that the chosen platform aligns with both business and technical goals.
Undocumented Current Environment
Most legacy IAM systems suffer from a lack of documentation. Over time, as developers and administrators leave, their knowledge of the system’s intricacies gets lost. When the documentation that does exist is out of date, new team members find themselves guessing how the provisioning workflow operates. This uncertainty leads to mistakes, duplicate effort, and a high error rate. For example, an outdated script might still reference a non‑existent database field, causing account creation to fail silently. Because the root cause is unclear, teams spend hours debugging, often without success. The result is a culture of “you’ll have to figure it out yourself” that delays onboarding and increases help desk tickets. Building a detailed map of the current environment - covering data flows, integration points, user roles, and business rules - should be a prerequisite for any upgrade. By making this information readily available, organizations reduce the learning curve for new staff and provide a clear baseline against which to measure improvements. An up‑to‑date documentation suite also facilitates future upgrades because the team no longer needs to reverse engineer the system each time.
No Shared Vision
Without a shared vision, the IAM upgrade becomes an isolated technical project rather than a strategic business transformation. A clear “to‑be” roadmap outlines how the new system will change processes, roles, and technology. When such a roadmap is absent, stakeholders see only their own slice of the system - how it affects their day‑to‑day work - and ignore the broader picture. This siloed view leads to conflicting priorities: HR wants quick user onboarding, security wants robust access controls, and finance wants cost efficiency. Without a common goal, each group pushes its agenda, and the project drifts. A shared vision is created by engaging all stakeholders early, capturing their requirements, and aligning them under a common set of objectives. The vision should also be communicated through tangible milestones and a phased implementation plan that balances speed with stability. When every department understands how the new system will benefit them and how it fits into the organization’s overall strategy, the project gains momentum and the risk of scope creep decreases.
No Project Resources
Even if an upgrade is approved, the project often stalls because the organization cannot spare the necessary talent. The same people who manage daily operations, maintain legacy systems, and support help desk tickets are often the only ones available to work on the upgrade. Hiring new staff or contracting external consultants might be frowned upon due to budget constraints or a belief that the existing team already knows the system. As a result, the upgrade gets postponed or never starts. A well‑planned project reserves dedicated resources from the outset, whether internal or external. This allocation can take the form of a project manager, a business analyst, a technical lead, and a dedicated dev‑ops engineer. Even a small team can drive progress if the work is scoped appropriately. In many cases, partnering with a vendor who offers a managed service or consulting package can fill resource gaps without increasing the company’s long‑term headcount. The key is to treat the upgrade as a strategic initiative that requires focused effort rather than an incremental tweak that can be done in the margins of daily work.
No Agreement on Upgrade Requirements
Without a consensus on what the new system must achieve, the project can devolve into a series of misaligned efforts. Different departments may have varying expectations for features such as self‑service password resets, role‑based access control, or multi‑factor authentication. When these requirements are not formally captured and approved, teams often implement features that satisfy one group but create problems for another. For example, a security team may push for granular access policies that complicate the onboarding process for HR. If the requirements remain ambiguous, the final product may fail to meet the needs of any stakeholder, leading to dissatisfaction and a perception that the upgrade was a waste of time. Establishing a rigorous requirements-gathering process - through workshops, user stories, and approval checkpoints - helps ensure alignment. Once the requirements are documented, they should be locked in before development begins, and any changes must go through a formal change‑control process. This discipline prevents scope creep and ensures that the final product delivers the intended value.
Other Concerns
Beyond the ten core obstacles, a variety of additional factors can derail an IAM upgrade. Security regulations may require specific data protection controls that the legacy system cannot provide without a major redesign. Physical limitations - such as insufficient rack space or power constraints - can prevent the deployment of new hardware. Remote sites may have built their own “underground” provisioning solutions that conflict with corporate standards, creating fragmentation. Organizational changes, like mergers or acquisitions, introduce new systems, users, and policies that the upgrade must accommodate. Vendor dynamics - mergers, product discontinuations, or shifting support contracts - can threaten the stability of the chosen platform. Each of these concerns requires proactive assessment during the planning phase. By identifying and mitigating them early, the project can avoid costly surprises later in the implementation cycle.
For further reading on how to navigate these challenges, see “15 Rules for a Successful User Management and Provisioning Project” by Abridean. The white paper offers a practical framework for designing, implementing, and sustaining a modern IAM system. You can download it from Abridean’s website. Additional insights are available in Barbara Gomolski’s “When Cheap Is Expensive” (Computerworld, 2004) and Jamie Lewis and Dan Blum’s “The Enterprise Directory Value Proposition” (Burton Group, 1999). For a Microsoft perspective on provisioning challenges, visit Microsoft’s provisioning challenge page. These resources provide deeper context for the obstacles outlined above and practical advice on how to overcome them.
No comments yet. Be the first to comment!