I have seen the same story repeat across many organizations. A company decides they need Microsoft Intune. They allocate budget, they assign a team, sometimes they bring in an outside consultant. Everything starts with energy and excitement, assessments are planned, planning workshops are booked, documents are started, pilots launch, groups get created, some apps are packaged, a few policies are applied. It looks like progress, it feels like progress, it is listed as progress on slides and dashboards.
And then it stops.
They get stuck. The project does not move forward. Momentum fades. The pilot exists but it is not expanding. Documentation exists but it is not followed. Some apps are deployed, others not. Security baselines are half implemented. The Service Desk is unsure how to handle tickets. Users are confused, some are annoyed, some are ignoring the whole thing. Leadership starts to ask the same question in every status call, where are we with Intune, why is it not finished, why does it feel like we are going in circles.
I have seen companies remain in this half state for months. I have seen companies remain in this half state for years. Intune technically exists, yet nobody can honestly say it is implemented. Devices are half managed, policies are inconsistent, adoption is low. The system is present, but it is not delivering value to the business and it is not giving peace of mind to security teams. It is a system that is there for itself, not for people.
I want to share what I have observed and what I have learned. This is about the administrative and operational side of Intune. Not the technical steps, those are everywhere and they are easy to follow. Microsoft has a guide for almost every button and every checkbox. Partners have quickstart templates and baselines. That is not where projects fail. Projects fail because of how they are organized, how they are governed, and how they are driven from phase to phase. Projects fail because of the administrative approach.
This article is about those administrative approaches. It is about the patterns I see in the field, the approaches that move work forward, and the approaches that freeze work in place. It is about how to pick a model, how to keep a project moving, and how to avoid getting stuck in that never ending pilot that nobody wants to talk about anymore.
⚠️ 20-minute read. Grab your coffee before start.
Why the technical part is not enough
The technical part is the easy part. You can configure Intune for device management quickly, you can prepare microsoft entra id, create device groups, you can apply compliance policies, you can push configuration profiles, you can package apps, you can enable conditional access, and technically it will all run. The documentation is clear, Microsoft Learn is full of examples, blogs repeat the same steps, there are a million tutorials that all say the same thing. You can follow them and you will end up with policies in place and devices talking to the service.
And yet, companies fail again and again. The reason is simple. Success is not measured by a green checkmark in the admin center. Success is not measured by the number of policies or number of profiles. Success is when the system serves the business, when users are enrolled, when policies are consistent, when devices are secure, and when adoption is complete. Success is when the Service Desk knows exactly what to do, when change is communicated before it happens, and when leadership understands the plan, the milestones, and the outcome.
The most common failure looks like this. Intune turns into a system that works for itself. It becomes a pile of policies, a pile of profiles, a pile of scripts, a console that nobody trusts. Users avoid it, IT stops pushing it, leadership loses confidence. That is not a technical issue. That is an administrative issue. That is a planning issue. That is an approach issue.
What moves a project forward is the administrative and operational approach. That is what takes you from a nice pilot and a few green checkmarks to an organization that is actually managed. That is what keeps you from getting stuck in place.
The seven administrative approaches
After watching many projects up close, after being pulled into projects that stalled and needed to be restarted, I see seven main administrative approaches that companies use. Some of these approaches are safe, some are risky, some look safe but freeze in place. These are not technical methods, these are project strategies. They define how you move from a blank tenant to a working system.
1. Crawl, Walk, Run
This is the most common approach. Start with a small pilot. Expand to a larger pilot. Scale to the entire company. Crawl, then walk, then run. It sounds logical, it sounds safe, it sounds like the right thing to do in every PowerPoint deck.
It feels safe because risk is minimized. You take small steps. You learn as you go. Complexity grows slowly and the team can absorb changes. Managers like it because it is easy to explain and nobody gets scared by the word pilot.
Here is the danger. Many companies never get past crawl. Some never get past walk. They stay in pilot mode permanently. They keep adjusting and testing, they expand a little and then pull back, they rewrite documentation, they fix a policy here, they rework a group there, and they never declare success. They never say this is done, we are in production, we are operating. They extend the pilot because extending the pilot is always the easiest decision in the room.
I have seen companies remain in this state for years. It becomes the default behavior. Do another small test. Add another exception. Wait for the next quarter. Bring in another tool. With every small extension the project loses clarity and loses urgency. Eventually the company is stuck so deep that they need outside help, not to configure Intune, but to break the cycle and move to operation.
Crawl, Walk, Run is easy to start and hard to finish. It creates an illusion of constant motion while hiding the fact that adoption is stalled. If you choose this approach, you need strong milestones, strong go or no go checkpoints, and a sponsor who will not let the pilot extend forever.
2. Executive Pilot
The executive pilot is a different way to create momentum. After the technical pilot, the next wave is not a random cross section of employees. The next wave is the executive team, the C level. Onboard them deliberately, configure their devices, deliver the apps they actually use, test with them, collect their feedback, and make them ambassadors.
Why is this powerful, and why does it work so reliably. Because user resistance is real. Security systems bring restrictions. Nobody cheers when their laptop is locked down. Most users will complain or at best remain neutral. That is normal human behavior.
Once executives are using Intune successfully, the argument disappears. The conversation becomes simple. Our CEO is on this, our CFO is on this, they use it every day, and they are fine. If they can use it, so can you. That stops most resistance, not with force, but with authority and example.
This approach works especially well in organizations up to about one thousand people. It works in flatter structures. It works in lifestyle oriented organizations. In these environments, executive endorsement spreads fast. People do what their leaders do. Adoption follows. I have seen companies where this single step changed the entire trajectory. Instead of two years of negotiations with every department, the adoption curve flipped within weeks.
It is not only about politics. It is about focus. An executive pilot forces your team to deliver real value, not a lab. It forces you to fix the real annoyances. It forces you to tighten documentation and support. When the top of the company is using something, the rest of the company learns to use it too.
3. Phased Rollout
Phased rollout divides the company into waves. Waves can be by departments, by regions, by countries, by business units, even by office locations. Each wave goes through the full cycle, enrollment, pilot, production, handover. You do not onboard everyone at once. You complete a wave, you show the results, and you move to the next wave.
The benefits are clear. You can show quick wins. You can point to a department and say, they are done, three hundred users onboarded, here are the metrics. Stakeholders see constant progress on a timeline. It calms the room. And people who still wait for their wave see that their turn is coming, not in theory but on a schedule.
The second benefit is learning. Every group is different. One department might have a critical legacy app that needs special packaging. Another department may have strict compliance because they handle sensitive data. A third department may need admin permissions to run scripts. By working wave by wave, you adapt to these differences with less risk. When you reach the third wave, you already know your blockers and your fixes. You know what documentation you need. You know what the Service Desk must be trained on. The learning curve is real and the project gets smarter as it moves.
There is a cost. Maturity is uneven. Some parts of the company are managed, others are not. You live in a hybrid state for a while. That is acceptable if the program is visible and scheduled. In large enterprises this approach is often the only practical way to handle complexity. It is safe, it is explainable, and it delivers steady progress.
4. Big Bang Controlled
This approach is my personal favorite for organizations that have failed for years. I am called into environments where Intune is half implemented and the landscape is a mess. There are policies, but they are inconsistent. There are apps, but half of them fail. Groups are not documented. Old pilots are still assigned. Service Desk has three different playbooks and none of them are correct. People are tired and nobody knows where to start.
Big Bang Controlled is the reset. You stop trying to polish the broken system. You mark it as legacy. You design a new model like a greenfield tenant, even if you keep the same tenant. You rebuild the structure from scratch. You prepare everything properly. You test it well. You run a clean pilot. Then you go live on the new model.
From that moment, every new device and every refreshed device is managed by the new system. Old devices remain on legacy rules until they are naturally replaced or until they are migrated through a controlled path. Over time, the legacy disappears and the new system becomes the only system. You hand it to operations, you close the project, and you stop carrying the weight of old mistakes.
The risk is obvious, mistakes can impact many users at once. That is why rollback planning is not optional. You must be able to undo a change quickly. You must have clear communication before and during rollout. You must have support capacity ready for the wave you plan to cut over. You must understand the critical apps and the critical workflows.
When done correctly, Big Bang Controlled gives you something most companies never get, a clean, consistent, fully functional Intune implementation that everyone can understand. It breaks years of stagnation and replaces it with clarity.
5. Compliance Driven
Compliance driven implementation happens when IT is not the driver. Security, risk, or audit is the driver. The company must pass ISO, SOC2, NIST, GDPR, HIPAA, or a client audit. The date is fixed. The goal is certification, not adoption. The tone of the project is different from day one.
The method is simple. Implement the minimum required. Enrollment, baseline security, conditional access in audit mode where possible, long grace periods, as little disruption as you can get away with. You try not to block the business. You try to pass the audit.
On paper, the project ends when the certification is achieved. In reality, the system is fragile. Users see no value, because the system was not designed to give them value. It was designed to produce reports. The organization gets a certificate, but it does not get a living platform. Adoption is weak, trust is weak, and the first real change often causes problems.
Compliance driven projects can make sense when the company is under external pressure. They can be a necessary first step. The important thing is to keep going after the audit, move from paper compliance to real adoption, and rebuild the project as an operational model.
6. App Value First
App Value First starts with user value, not with restrictions. You configure Intune to deliver the things people actually want. Office apps, VPN profiles, Wi Fi profiles, the Company Portal with real software that users need. Then you communicate clearly. If you want these apps or these services, enroll through Company Portal. No tricks, no threats, real value in exchange for enrollment.
Users enroll because they want the benefit. Adoption becomes voluntary. Motivation is positive. People choose to join because joining unlocks something useful. That is a very different energy than forcing enrollment with no upside.
As adoption grows, you increase protection with Conditional Access. At first you protect only high value resources. Later you expand protection in steps. By the time you block access to something that matters to everyone, most users are already enrolled. The long tail follows naturally.
This approach works well in creative companies, in organizations with open cultures, and in environments where a friendly path is required. The risk is delay in security. You get adoption first and strong protection later. You manage that by planning your protection steps on a timeline and by communicating those steps early.
7. Baseline First
Baseline First is extremely common. Everyone enrolls immediately, but only a minimal baseline is applied. A few apps, light configuration, basic security, nothing disruptive to the business. It feels safe because it avoids sudden change. It gives IT instant visibility and control without creating noise.
The benefit is real. All devices are known. Policies exist. Apps can be delivered. Reports are available. You get a sense that the organization is in the system.
The problems show up later. Every new policy you add is now production wide. Piloting is hard because the base is already broad. Mistakes affect everyone. Users experience constant small changes. Something works one week, something breaks the next week, and nobody knows why. Some users have one policy, others have three, and the Service Desk is stuck explaining differences that should not exist.
The environment ends up half secure and half adopted. Many Baseline First projects freeze here. The system exists, but it never matures. It becomes a permanent state of almost managed.
If you choose this approach, you need a strict plan for layering. You need a timeline for adding security, for adding compliance, for closing old paths with Conditional Access. Without that timeline and without discipline, Baseline First turns into Baseline Forever.
Hybrid approaches
These seven models are not exclusive. Real projects mix them. Executive Pilot can lead into Phased Rollout. Baseline First can evolve into App Value First. Compliance Driven can shift into Big Bang Controlled after the audit pressure is gone. You can move from one model to another during the life of a program.
The important thing is awareness. Know which model you are following. Say it out loud. Executive Pilot for momentum, then Phased Rollout for scale. Baseline First to get devices under observation, then App Value First to drive adoption, then Conditional Access to close the loop. Big Bang Controlled to escape the mess, then Phased Rollout to finish cleanly. When everyone understands the model, the team can anticipate risks and prepare the right mitigations.
From what I have seen, two models produce the most exciting results. Executive Pilot for small and mid sized organizations, because leadership endorsement destroys resistance and compresses timelines. Big Bang Controlled for large or stalled enterprises, because a clean restart removes years of accumulated mistakes and confusion. Both require discipline. Both require a clear sponsor. Both deliver clarity that most programs never achieve.
Project planning is essential
No matter which model you pick, planning decides the outcome. I am not a certified project manager. I do not hold PMI or PRINCE2. But I always use PIM principles for Intune setup. Without planning, Intune projects fail. With planning, even a difficult environment can move forward.
You do not need a hundred page plan. You do need a rollout plan that people read. Sometimes two or three pages are enough. What matters is clarity. Who is responsible, what are the milestones, what are the go or no go criteria, what is the schedule for the next wave, what is the rollback path if something breaks. Write it down and make it part of the weekly conversation.
Create a simple project charter. Name the sponsor. Name the decision makers. Name the constraints. Name the success criteria. Build a work breakdown structure that turns the plan into tasks that are visible and owned. Define milestones that are real and measurable. Do not hide behind vague goals. Put dates on the table and keep them visible.
Design the future state before you touch the console. Decide what groups you will use and why. Decide who owns which policies. Decide who packages which apps and how quality is measured. Define onboarding and offboarding as processes, not as a hope. Decide which enrollment types are allowed and which are forbidden and write the reasons. When this is done on paper first, the work in the console becomes execution, not invention.
Prepare the Service Desk. Give them the scripts, the articles, the expected issues, the escalation paths. If you skip this, your rollout will create pain and that pain will slow adoption. Communicate to users before change happens. Write clear emails. Record a short video if that fits your culture. Show people what to expect and where to click. A little communication prevents a lot of issues.
Measure adoption in numbers that matter. Percentage of devices enrolled. Percentage of devices compliant. Number of critical apps packaged and deployed. Average time to resolve a ticket related to enrollment. Use these numbers in your steering meetings. Numbers make reality visible.
Set go or no go checkpoints. After each wave, after each step, confirm that you reached the criteria. If you did, move. If you did not, fix and then move. Do not slide forward on hope. Move forward on evidence.
Have a rollback plan that is practical. If a policy breaks a critical workflow, how do you back out. If a package causes instability, how do you remove it. If conditional access blocks the wrong group, how do you unroll the change. Write these paths before you deploy. It is faster to follow a written path than to invent one under stress.
Common anti patterns that freeze projects
There are a few patterns I see again and again. They look reasonable on the surface and they kill momentum.
Analysis without decision. Endless discussions about the perfect structure, about the perfect policy, about the perfect grouping model. The team waits for the ideal answer. The ideal answer rarely exists. Decide, document why, move, adjust if needed.
Pilot that never ends. The pilot becomes a permanent place to hide risk. Extend the pilot, add a few more users, delay the call. At some point the pilot must be declared complete. Create a formal gate for that call when you start the pilot.
Switching models every month. Starting as Phased Rollout, then flipping to Big Bang without the preparation, then drifting into Baseline First without a plan. Every change resets trust. Pick a model and commit.
Delegating ownership to nobody. Policies appear, profiles appear, apps appear, but there is no owner for the policy set, no owner for the app packaging process, no owner for conditional access decisions. Things exist in the console but nobody is accountable. Assign named owners and publish the names.
Expecting users to adopt silently. People need communication. People need a reason. People need a path. If your plan relies on silent adoption, you are planning for confusion.
Ignoring the Service Desk. If the first line does not know what you are doing, they will not support you. Every ticket that ends in a dead end slows your rollout. Treat the Service Desk as a partner from day one.
How to unstick a stuck Intune project
If you recognize your environment in the description above, here is a straightforward way to restart.
Pick a model and say it out loud. If you are small or mid sized, choose Executive Pilot, then Phased Rollout. If you are large and messy, choose Big Bang Controlled, then a series of waves. If you already enrolled everyone with a minimal baseline, explicitly plan the layers and timelines to move from baseline to secure.
Write a two-page (at list) plan. Name the sponsor, name the leads, list three milestones with dates, list go or no go criteria for the next two waves, list the rollback steps. Make this plan the center of your weekly call. Update it as you learn.
Design the future state on a single page. Draw the group model. Describe who owns what. Write the rules for enrollment and for exceptions. This page is your alignment tool with leadership and with the Service Desk.
Reset documentation. Throw away the conflicting versions. Keep a single source. Publish it where people actually look. A short and correct doc is better than a long and ignored doc.
Do a small but real win in two weeks. Package a critical app that was missing. Fix a policy that was noisy. Deliver one concrete improvement that users feel. Momentum is built on wins, not on promises.
Communicate like you want people to care. Tell them why, tell them what, tell them when, tell them where to ask for help. If your culture prefers video, record a two minute clip. If your culture prefers written guides, make the guide simple and visual.
Hold the line at the gate. If a wave did not meet criteria, do not push it to production. Fix and then push. Once people see that you actually use the gates, trust goes up. When trust goes up, resistance goes down.
Conclusion
Microsoft Intune does not fail because of buttons. It fails because of approach. The technology is mature and the guides are abundant. What matters is the administrative path you choose, the clarity of your plan, and the discipline of your execution. If you pick a model that fits your culture, if you state it clearly, if you plan with real gates and real owners, and if you communicate like you mean it, Intune becomes a living platform. If you drift, if you extend pilots forever, if you avoid decisions, Intune becomes another console with a pile of policies and no trust. Choose the path that moves you, write it down, and walk it to the end.