By Michael Branson

Quick answer. A complete IT infrastructure strategy engagement covers four stages: a current-state assessment against your actual environment (not a generic checklist), a gap analysis tied to your specific compliance and operational constraints, a sequenced modernization roadmap with named dependencies, and a governance handoff so the roadmap survives the consultants leaving. Evaluate the firm on whether they can name all four stages and what they hand you at the end of each one, not on their sales deck.

Your board or your CEO has told you to commission an infrastructure strategy engagement, and four firms are now in front of you with proposals. You cannot tell which of them is properly scoped, which has padded the work with stages you do not need, and which is thin in a place that will cost you a year and a half from now. The pitch decks do not help, because each one describes a different shape of work under the same words, and none of them shows you the yardstick. If you pick wrong on scope, you buy a document that does not survive the next budget cycle. If you pick wrong on the firm, you buy a plan nobody in your organization can execute. Both outcomes land on you, because you own the vendor relationship and you own the spend.

What follows is the yardstick: what an infrastructure strategy engagement should include stage by stage, current-state assessment through sequenced modernization roadmap and governance handoff, and the four criteria that separate a firm who can deliver that roadmap from one who can only sell it.

What “end-to-end” actually means in scope terms

If a proposal in front of you uses the phrase “end to end” without naming what lands in your hands at each step, you have no way to price it against the others. End to end is not a level of effort. It is four stages, and each one produces an artifact you can hold, review and reuse after the firm has gone.

Stage What the firm does What you receive at the end of it
Current-state assessment Reads your actual environment: the systems in use, the integrations between them, the identity model, where data physically sits, and the license position that pays for it A written environment inventory, sourced from your own admin center exports and directory reports, that names each system and its owner
Gap analysis Tests that inventory against your operational constraints and against the obligations your compliance officer has already identified A gap register in which each entry names the gap, the constraint it sits against, and the operational consequence of leaving it open
Sequenced modernization roadmap Orders the gap register into work that can actually be done in sequence, given what depends on what A dependency map and a sequenced plan in which each step carries its own exit criteria
Governance handoff Transfers the decisions, the reasoning and the ownership to your team before the engagement closes A decision record naming every choice made and why, plus a named internal owner for each roadmap step

Current-state assessment. The failure mode you are guarding against is a firm that assesses your environment from a questionnaire your team filled in. An assessment worth buying reads the environment itself: tenant and directory reports, admin center exports, the integration and connection inventory, the license assignment report. Ask which exports the firm will pull and who on your side has to grant access to pull them. A firm that cannot answer that in the proposal will be answering it in month two, on your clock.

Gap analysis. A gap list that is really a product wish list is the second failure mode, and it is harder to spot because it reads as thorough. A gap is only a gap against something: an operational constraint you have stated, a service commitment you have made internally, or an obligation your own compliance officer has identified for your organization. Each entry in the gap register should name that something. Where an entry names no constraint, it is a preference, and preferences belong lower in the sequence than obligations.

Sequenced modernization roadmap. Sequence is cheap to assert and expensive to demonstrate, because asserting it costs a sentence in a proposal and demonstrating it costs a dependency map. A roadmap that lists workstreams without saying which must finish before which is a list, and a list will not survive its first contested budget review. What makes it a roadmap is the dependency map underneath it and the exit criteria on each step, so that any person can look at a step in flight and say whether it is done. Ask to see the exit criteria for the first two steps before you sign.

Governance handoff. Where a proposal drops a stage without the omission being visible to you, the governance handoff is the stage it drops, because its absence changes nothing in the table of contents of what you receive. That is the mechanism that produces a plan nobody in your organization can execute. A handoff is a working session plus two artifacts: the decision record, which explains why each choice was made so that a successor can revisit it honestly, and a named owner against every step, so the roadmap has somewhere to live after the invoice is paid. If the proposal ends at the roadmap, the engagement ends before the value does.

When two of these stages disagree, the earlier one governs. If the roadmap assumes a system the current-state assessment did not find, the assessment wins and the roadmap is corrected, because a plan built on an inventory nobody verified is a schedule of work against systems that may not be there.

Why a proposal with no scope framework cannot be evaluated

You are holding four proposals and they are not comparable, and the reason is structural, not a fault of any one firm. Each proposal has chosen its own boundaries, named them in its own words, and priced against its own boundary. Without a fixed yardstick, you are comparing four different products that share a name.

Read each proposal against the four stages above and mark which stages it actually contains. Three patterns show up quickly. A proposal that is assessment only, with the roadmap named as a later engagement, is a real product and a legitimate one, but it is not what your board asked you to buy. A proposal heavy on current-state assessment and light on sequence is selling you the part that is easiest to staff. A proposal that reaches the roadmap and stops there has left out the stage that determines whether anything gets executed.

Mark the gaps on a single sheet, one row per firm and one column per stage, and take that sheet into the vendor conversations. A firm that agrees a stage is missing and explains why it was scoped out is giving you information you can use. A firm that reframes the question is giving you an answer about the firm.

The four criteria for choosing the firm for this engagement

Once you know what the engagement should contain, the firm question narrows to one thing: can this firm produce a sequenced modernization roadmap your organization will still be executing a year from now? General partner-evaluation criteria are set out in how to evaluate a custom Microsoft software consulting partner, and that framework holds. Four criteria are specific to strategy and roadmap work, and they are the ones that separate firms who look identical on a capability slide.

One: references for strategy work, not build work. Ask for two references where the deliverable was a roadmap, and ask those references one question: what were you executing a year later? A firm with deep build references and no strategy references is a competent firm being hired for the wrong stage. Build references answer a different question than the one you are asking.

Two: named senior people, committed across all four stages. Ask who specifically runs the current-state assessment, who writes the gap register, and who sits in the governance handoff, by name, and ask whether those are the same people. The pattern to watch for is senior presence at the pitch and the kickoff, then a handover to a delivery team that was not in the room when the reasoning happened. Get the names into the proposal.

Three: a handoff artifact you can name before you sign. Ask what the decision record looks like, and ask to see a redacted example from other work. A firm that runs this stage routinely has an example. A firm that has to describe one in the abstract has not run it recently, whatever the capability slide says.

Four: a written statement of what the engagement will not cover. The exclusions section tells you more about scope discipline than the inclusions section does, because inclusions are written to win and exclusions are written to be lived with. A proposal with no exclusions is not a broader engagement; it is an engagement whose boundary will be negotiated later, when you have less leverage than you do now.

When two firms split these four criteria between them, the handoff artifact settles it. A roadmap your team cannot operate once the firm leaves is the failure that costs the most to repair, because the repair is a second engagement.

When a lighter assessment is the right first step, and this engagement is not

There is a situation where the honest answer is that you should not buy this engagement yet, and if you are in it, a full strategy engagement will waste your budget rather than protect it.

If the decision in front of you is already made, and what you need is a plan to execute it, you need delivery planning and not strategy. If your environment has been inventoried inside the last year and the inventory is still accurate, you are paying twice for stage one. If a single application or a single integration is the problem, and the rest of the estate is stable, a scoped assessment of that one thing will answer the question faster and for less.

The test is whether the open question spans more than one system and has more than one defensible answer. Where it does, sequence is the hard part and the engagement earns its cost. Where it does not, buy the smaller piece of work, and keep the strategy engagement for the year when the question is actually open.

If your organization is a government contractor

If your organization holds federal contracts, the engagement has a stage this page does not cover, and the scoping is materially different. Contract-clause obligations shape what the assessment has to look at and what the roadmap has to sequence around, and that work belongs on its own page rather than as a paragraph here. Start instead with IT Strategy Consulting for Government Contractors: What the Engagement Covers and How It Runs, which sets out that engagement, its deliverable and the conditions under which it is the wrong thing to buy.

Where i3solutions fits against this yardstick

If you are running the four stages above across a shortlist, you are entitled to see us measured the same way, so here is the attested version and nothing beyond it: i3solutions sells and delivers an enterprise IT technology assessment of a Microsoft environment as a named engagement, comprising discovery, gap analysis and a future-state roadmap. That is a named engagement covering the first three of the four stages on this page, in a Microsoft environment.

Three things this section deliberately does not say, and the reason is the same each time. It names no client and no project, because a reference you cannot verify is worth nothing to someone about to defend a vendor decision. It quotes no cost, no duration and no outcome figure, because none is attested for this engagement outside the government contractor case, and a figure nobody will stand behind is a figure you would be asked to defend on our behalf. And it does not list the artifacts we hand over, because the artifact names in the table above are the yardstick for the market, not an attested description of our own deliverables. Ask for all three in the conversation, against your own environment, where the answers can be specific.

Contact a senior integration architect to work through the four stages against the proposals actually in front of you.

Key takeaways

  • An IT infrastructure strategy engagement covers four stages: current-state assessment, gap analysis, sequenced modernization roadmap, and governance handoff. A proposal missing one of the four is a narrower product, which may still be the right purchase if you know which stage you are skipping.
  • Each stage should produce a named artifact: an environment inventory, a gap register, a dependency map with exit criteria, and a decision record with named owners.
  • Where the assessment and the roadmap disagree about what exists, the assessment governs and the roadmap is corrected.
  • Choose the firm on four criteria: strategy references rather than build references, named senior people across all four stages, a handoff artifact you can name before signing, and a written exclusions statement.
  • Where two firms split those criteria, the handoff artifact settles it, because a roadmap your team cannot operate is the most expensive failure to repair.
  • If the decision is already made, or the estate was inventoried recently, or one system is the whole problem, buy the smaller assessment instead.

Frequently asked questions

What does an end-to-end IT infrastructure strategy engagement actually cover, and how do you pick the firm for it?

You are comparing proposals that use the same words for different work, so start from a fixed definition. An end-to-end IT infrastructure strategy engagement covers four stages: a current-state assessment of the real environment, a gap analysis against stated operational and compliance constraints, a sequenced modernization roadmap with a dependency map, and a governance handoff that transfers decisions and ownership to the internal team. Pick the firm on whether it can name all four stages and the artifact each one produces, on references for strategy work rather than build work, on named senior people committed across every stage, and on a written statement of what the engagement excludes. Government contractors should start from the government contractor version of this engagement, which adds contract-clause obligations that change the scoping.

What is the difference between an IT assessment and a full infrastructure strategy engagement?

You may be quoted for both and find the difference is not explained. An IT assessment produces a picture of the current environment and stops there, which is the first of the four stages in a full engagement. A full infrastructure strategy engagement takes that picture forward into a gap analysis against stated constraints, a sequenced modernization roadmap with a dependency map and exit criteria, and a governance handoff with a decision record and named internal owners. An assessment answers what you have; a strategy engagement answers what to do about it, in what order, and who owns each step afterwards.

How do I choose a firm for an IT infrastructure strategy engagement?

Firms look identical on a capability slide, so test them on four criteria specific to roadmap work. First, references where the deliverable was a roadmap, with the follow-up question of what that client was executing a year later. Second, the names of the senior people who will run each of the four stages, with confirmation that they are the same people across all four. Third, a governance handoff artifact the firm can describe concretely and show as a redacted example. Fourth, a written statement of what the engagement will not cover, since an exclusions section reveals more about scope discipline than an inclusions section does.

What should the firm hand us at the end of an infrastructure strategy engagement?

If the proposal in front of you describes activity instead of artifacts, ask for artifacts. A complete engagement produces four: an environment inventory sourced from the organization’s own admin center exports and directory reports; a gap register in which each entry names the gap, the constraint it sits against, and the operational consequence; a dependency map with a sequenced plan carrying exit criteria on each step; and a decision record naming every choice, the reasoning behind it, and the internal owner of each roadmap step. An engagement that ends at the roadmap has left out the handoff.

Do we need a full strategy engagement if we already know what we want to build?

If the decision is already made, a strategy engagement is the wrong purchase and delivery planning is the right one. Three situations point the same way: the choice has been settled and only execution remains; the environment was inventoried within the last year and the inventory is still accurate; or a single application or integration is the problem while the rest of the estate is stable. The test is whether the open question spans more than one system and has more than one defensible answer. Where it does not, buy the scoped assessment of the one thing, with its own exit criteria written into the proposal, and keep the strategy engagement for a year when the question is genuinely open.