- An IT Phase 0 discovers the environment itself rather than business processes, so the method is inventory, audit, and access review rather than facilitated workshops.
- The common gap is that no single person inside the company can answer what systems exist, who administers them, and whether they're backed up.
- A written questionnaire is a starting point, not a substitute; one engagement found a peak-load figure understated by roughly 70 times, which changed the whole sizing model.
- Deliverables center on a prioritized findings report, an identity and security baseline, and a sequenced remediation roadmap that leadership can prioritize against.
- If you engage us for the follow-on work within three months of the assessment completing, 100% of the fee is credited toward it.
Last month, the IT manager at a multi-site retail and food operator described what his handover had looked like when he took the job. There wasn't one. He'd inherited the administrator credentials for everything and no documentation of any kind, and he'd been in the seat about seven months.
He said as much about the limits of anything he could tell us. "I maybe don't know everything that's going on everywhere else in the company," he said, "so a lot of this probably needs to be a broader discussion with the people who are running these things. This is just what I'm seeing from my side."
That sentence is the reason an IT Phase 0 exists, and it's why the engagement looks nothing like the design phase we run ahead of a Dynamics 365 build.
Discovering the environment, not the process
Ahead of an ERP or CRM implementation, discovery is about how work moves through the business. We sit in facilitated workshops with finance, sales, and operations and document the process.
An IT assessment asks a blunter question, which is what the company owns, who administers it, and what condition it's in. The method is inventory and audit rather than workshops, and the unknowns are different in kind:
| Dynamics design phase | IT assessment and roadmap | |
|---|---|---|
| What's being discovered | How the business operates | What the business owns and runs |
| Method | Facilitated workshops by workstream | Tenant audit, inventory, access and license review |
| Core artifacts | Process flows, data dictionary, security role matrix | Findings report, identity and security baseline, remediation roadmap |
| Who's involved | Business leads, controller, IT lead | Internal IT, finance, existing specialist partners |
| Central unknown | How work really gets done | Where the systems are and who administers them |
| Posture | Design work, decisions made | Read-only, findings documented |
That last row matters more than it looks. An assessment doesn't change anything. Beyond a handful of low-risk configuration fixes made with your approval as we find them, it's a read-only exercise, which is what makes it safe to run while the business keeps operating normally.
The questions nobody inside can answer
The retail operator runs about 150 employees against 65 Microsoft 365 licenses, because most store staff don't need a mailbox. He had a reasonable working knowledge of the tenant and a specific list of things he couldn't answer:
- Whether SharePoint content was being backed up at all. His words: "I know it lives in the cloud, but…"
- Whether the file structure his operations lead had built was laid out sensibly, or whether most shared documents had simply ended up in individual OneDrive accounts.
- Which users were sharing what externally, and whether the right people could see the right documents.
- Why the company was paying for 10 or 12 seats of a desktop conferencing product nobody used, when the same capability was already in the Microsoft licensing. Nobody knew the renewal date either, which meant nobody could time the drawdown.
- How much of the network hardware had passed end of support, and which consumer-grade equipment was still quietly passing traffic.
None of that is unusual, and none of it reflects badly on him. Those answers live in a tenant, in a license portal, and in a switch configuration, not in anyone's head.
A different engagement showed the same shape at the other end of the technical spectrum. A nonprofit running a large online training platform had operated its own infrastructure since the 1990s: three production servers in a single data center, a custom application, and a network administrator retiring at the end of the quarter. The technical lead had 26 years of institutional knowledge and was completely clear about the limits of it.
"I've only done on-prem, so I think of the infrastructure. I don't know if platform as a service may work for us. I don't even know. And I don't know what the cost would be. I don't even know how to estimate it."
Why a questionnaire doesn't close the gap
We send a technical questionnaire before an engagement like this. It's useful, and it isn't sufficient.
On that same nonprofit engagement, the questionnaire came back listing peak concurrent users at 1,200. We drafted a sizing model and a cloud spend forecast against that number. On the review call, the technical lead read it and corrected us on the spot: peak is closer to 86,000, on a handful of mandated training days a year. As he put it, 1,200 "wouldn't even be one county."
That single correction changed the compute design from fixed servers to an auto-scaling model, moved the monthly cloud forecast into a different bracket entirely, and would have changed the migration quote by a wide margin. It surfaced because a senior architect walked a decision maker through a draft, line by line, and asked follow-up questions. A form doesn't do that.
The same engagement's questionnaire also came back with two sections blank: the inventory of intranet applications, and the record of existing cloud subscriptions and licensing agreements. Both went onto the assessment scope as named items to close. Discovery has kept turning up more since: a second web server nobody had mentioned, a storage array with 36 TB allocated and 2 TB in use, a test environment larger than production, a database failover process that is a manual address swap, a 30-minute recovery point objective with no recovery time objective defined at all, and an undocumented site-to-site link to a partner network that has been in place for decades.
We also struck an assumption from our own draft. An early version stated that no regulatory frameworks applied. Nobody had established that, so it came out and became a discovery item instead: identify the applicable state security policy series, the sponsoring agency's requirements, and the correct data classification for training records. An assessment that assumes a compliance posture isn't an assessment.
What comes out of it, and why it's phased
The deliverable is a prioritized findings report, an identity and security baseline, documentation and administrative access recorded in a form that isn't proprietary to us, and a remediation roadmap with the work sequenced. The roadmap is the point. An inventory that doesn't tell you what to do first is a filing exercise.
Two principles shape it. The first is that we work through what your existing Microsoft licensing already covers before adding anything on top, because most organizations are paying for capability they haven't turned on. The second is portability: the tooling and documentation should lift out cleanly and be adoptable by any IT partner, because the goal is an internal capability that belongs to you.
Sequencing is deliberate, and things get held back on purpose. On the retail engagement we pushed backup deployment, file governance, the conferencing consolidation, and the network refresh out of the assessment and into the roadmap, each for a stated reason: the backup design should follow the findings rather than assume them, the voice migration should line up with a renewal date, and the hardware refresh should be something leadership can put out for competing bids. That also matches how the money works. Phased, digestible spend is easier to approve than one large commitment, and leadership gets to prioritize the findings rather than inherit our ordering.
If you engage us for the follow-on work within three months of the assessment completing, we credit 100% of the assessment fee toward it. Much of that work would be part of onboarding anyway, so it shouldn't be paid for twice.
When it's the wrong step
If you have a current asset and license inventory, a clean identity model, one directory, documented backups, and a list of the applications in use with named owners, you don't need someone to produce those things for you. Bring us the specific project instead.
An assessment earns its place when the environment has grown faster than the documentation, when responsibility for systems is spread across people who have moved on or are about to, or when you're being asked to approve a roadmap that was written before anyone looked. In the first of these engagements, the client proposed the sequence himself before we did: audit where everything is today, find the gaps, then decide. Nothing was on fire. That's usually the best time to do it.
If that's roughly where you are, we're glad to walk through what an assessment would cover for your environment and, as importantly, what it wouldn't.