How to get started with an IAM project

What is an IAM project and when do you need one?

An Identity and Access Management (IAM) project is a focused initiative to improve how your organization manages digital identities and access. A well-defined IAM project has a clear scope, measurable outcomes, and a realistic timeline, typically as a concrete first step in a broader IAM strategy or modernization roadmap.

In practice, many organizations do not start with a fully defined project. Often, a single application owner or IT team discovers that existing processes and tools cannot cope, and only then does the broader IAM need become visible.

Typical IAM projects focus on things like introducing passwordless authentication, rolling out Single Sign-On (SSO) or multifactor authentication (MFA), automating onboarding and offboarding, or replacing a legacy identity platform. In each case, the goal is the same: make it easier to give the right people the right access at the right time, and prove that control to auditors and the business.

You usually know it is time to start an IAM project when one or more of these are true:

• Onboarding and offboarding are manual, slow, and handled differently in each department.
• Access reviews are painful, spreadsheet-based, or rarely completed on time.
• You are running several identity systems in parallel and no one is sure which one is “the truth.”
• You rely heavily on shared admin accounts or local admins that are hard to track.
• Audits, incidents, or customer demands highlight gaps in how you manage access.

An IAM project gives you a structured way to move from ad hoc fixes to a planned first phase and a clear IAM roadmap for the next 6–12 months.

Step 1: Understand where you are today

Before you choose tools or design an IAM roadmap, you need a clear picture of your current situation. This sounds obvious, but many IAM projects struggle because they skip this step or rush through it.

Map your identities and systems

Start by listing where identities live and which systems they access:

Sources of identity: HR systems, directories like AD or Azure AD, and any external identity providers.
User types: Employees, consultants, service accounts, partners, and customers (if in scope).
Lifecycle processes: What happens when someone is hired, change roles, leaves, or return after a break.   
Applications and systems: Cloud apps, on-premises systems, custom solutions, and critical infrastructure.

You do not need a perfect inventory on day one, but you need enough to see patterns. A basic spreadsheet with system name, owner, user types and login method is usually more useful at this stage than a complex tool.

Identify risks, pain points, and quick wins

Next, look at where things break down or feel risky in day-to-day work:

Manual onboarding and offboarding, especially for contractors.
Delays when people change roles but keep old access.
Shared or poorly tracked admin accounts.
Systems without MFA, even though they hold sensitive data.
Access reviews that are hard to complete.

Identify which issues are visible, low-effort quick wins and which are structural problems that will take longer. This helps you design a realistic first phase and explain to stakeholders why some items are addressed early while others are planned later in the IAM roadmap.

Step 2: Clarify scope, objectives, and stakeholders

By now, you have a realistic picture of how complex things are. Step 2 is about turning that insight into a clear mission: What are we actually trying to achieve with this first IAM project? Many organizations start with a short pre-study to structure the needs, explore solution options, and agree on a high-level IAM roadmap that leadership can sponsor.

Define 2–3 clear IAM project outcomes

Instead of creating a long list of goals, choose a small handful that really matter right now. For example, faster onboarding, better control of admin accounts, or closing specific audit findings. If you can’t explain the top outcomes on a single slide, the scope is probably too broad.

Set a realistic scope for your first IAM phase

Decide what this project will actually include in practice: which users, which systems, and which capabilities you want to focus on first. A well-defined first phase becomes the first solid building block in your IAM roadmap.

Identify IAM stakeholders and owners early

Finally, list who needs to be involved. You do not need a full governance model yet, but you do need real names, clear sponsorship, and a shared understanding that IAM is an organizational initiative, not just an IT side project.

Step 3: Prioritize your first IAM use cases

Once you understand your current situation and defined scope, the next step is to decide which use cases you will implement first. Focus on a small number of initiatives that deliver clear, visible value without overwhelming the project or your organization.

Common starting points

Most organizations start with a small set of high-impact use cases, for example:

• Single Sign-On and MFA for your most critical applications.
• Joiner–Mover–Leaver automation so people get access faster and old access is removed on time.
• Better control of admin accounts, including an overview of who has privileged access and where.

These use cases are concrete, easy to explain to stakeholders, and directly support security and compliance goals.

 How to choose what comes first

Rank potential use cases by three simple questions:

• How much risk does this reduce?
• How much effort will it take?
• How visible is the benefit for users or management?

When you evaluate effort and risk, look at factors like how many users a system has, how sensitive the data is, and how complex it will be to integrate.

Pick two or three use cases that score high on risk reduction and visibility, but are still feasible to deliver in the first 6–12 months. This gives you a focused starting point and a solid foundation for expanding your IAM roadmap.

Communicate early and manage change

An IAM project changes how people log in, request access, and get work done. Even if the end result is simpler and more secure, it will feel like a disruption if you do not explain what is happening and why.

Good communication answers three basic questions for different groups of users:

Why are we doing this?
What will change?
How do I get help if something does not work?

Most often, executives want clarity about risk and compliance, managers need to understand their responsibilities for approving access, and end users want to know how their daily work routine will be affected.

Start communicating well before the first rollout, keep messages short and specific, and make it simple for people to share feedback through pilots, support channels, or quick forms. This helps reduce resistance, uncover issues early, and build trust in the IAM project instead of creating surprise or frustration.

Example of what the first 12 months with IAM can look like

Every organization is different, but it helps to have a rough picture of what the first year of an IAM implementation can look like. The idea is to take small, concrete steps in the first 12 months, while keeping a longer-term view of where you want IAM to be in three to five years.

Months 0–3: Understand and plan
You map identities and systems, clarify scope and objectives, and pick your first 2–3 use cases. You agree on key stakeholders, a basic governance model, and how success will be measured.

Months 3–6: Implement core changes
You tackle your first use cases, for example: SSO and MFA for critical applications, initial Joiner–Mover–Leaver automation for employees, and better control of admin accounts. You run pilots, adjust based on feedback, and document what works.

Months 6–12: Scale and stabilize
You expand SSO, MFA, and JML coverage, improve data quality, and introduce simple, regular access reviews for key systems. You capture lessons learned and outline the next phase of your IAM roadmap.

This phased view of the first 12 months is most effective when it is grounded in a clear long-term vision for your IAM capability, even though you deliver that vision through small, incremental steps.

Common mistakes when starting an IAM project

Even well-planned IAM projects run into the same traps. Being aware of them early makes it easier to avoid them.

Starting with an overly broad scope instead of a focused first phase.

Choosing an IAM tool before mapping needs and processes, and then forcing the organization to fit the technology.

Treating IAM as a one-off project without establishing a model to maintain roles, processes, and automations over time.

Writing overly detailed technical requirements instead of high-level needs.

Ignoring HR, managers, and application owners when defining roles and access.

Underestimating integration work with existing systems and directories.

Rolling out SSO or MFA without enough communication and support for end users

Having no clear IAM owner, so decisions get stuck.

Trying to automate everything at once instead of starting with a few core use cases.

Next steps

Focus on three things: 1) understanding where you are, 2) defining a realistic first phase, and 3) choosing a few high-impact use cases. With that foundation in place, you have the core of a solid start. From there, you can grow your identity and access management step by step, supported by clear communication and feedback, instead of trying to design everything perfectly up front.

If you want help structuring those first steps into a concrete plan, an IAM pre-study can be a good place to begin.