Senior US-Based Microsoft Delivery Assurance: What to Inspect, What Proves It, What to Put in the Contract

Quick answer. Senior US-based Microsoft delivery assurance is verified in three places: what you inspect before signing, the artifacts that prove seniority, and the contract terms that make the commitment enforceable. Anything that lives in none of the three is a description of a team rather than a commitment about one.

What a buyer inspects, and in what order

Assurance is checked before it is bought, and the checking is cheaper than most buyers expect. Each request below is for something that already exists or does not, which is why the answer arrives quickly and is hard to dress up.

Ask for the names, then ask what else those names are doing. A staffing plan lists roles. Ask instead for the individuals proposed for the architecture and lead positions, and for each one, the other commitments they hold across your dates and how much of their working week your programme has. A name with no allocation figure beside it is a role, not a person.

Read one decision record before you read any proposal. Ask for an architecture decision record from a comparable programme, redacted as far as the provider needs. What you are looking for is whether the rejected options are written down with the reason they were rejected. A record listing only what was chosen is a summary. A record showing what was weighed is evidence that somebody was doing the weighing.

Ask who reviews the most senior person’s work, and to see one such review. Every team can name a reviewer. Fewer can produce an instance of their most senior contributor’s own work being reviewed and changed as a result.

Ask when the proposed people last worked inside a live environment rather than a demonstration. Working in an estate and supervising somebody who does are different arrangements, and both are legitimate. What you are establishing is which one you are buying, and the answer is a date and an environment, not an adjective.

Ask what happens on rotation. Not whether people rotate, because everyone rotates. What notice you receive, whose agreement is required before a named person is replaced, how long the two overlap, and what is handed over in writing.

Ask for the escalation that went badly. Any provider with real programmes behind it has one. What you learn from it is not the incident. It is whether the escalation reached a decision, who made that decision, and how long it took to get there.

Those six requests are the inspection, and each is aimed at one of four properties that a statement about employment geography does not establish. Those four are next.

The four things location does not tell you

These are the four, in the order they bite. Each one is a property of the arrangement rather than a question to ask a firm, and each one is either specified somewhere or it is not.

What location does not tell you What it actually determines What to require instead
Who is assigned Whether the people doing the work have the depth to make design decisions, or only to implement decisions somebody else made The seniority definition the arrangement uses, written as observable behaviour, not as a job title
Whether they stay Whether continuity survives the first competing demand on those people, and whether knowledge leaves with them A knowledge capture practice that runs during the work, not at the end of it
Who owns the architecture Whether the design holds together across workstreams, or fragments into locally sensible decisions that do not compose One named owner for the design across the whole scope, and a written record of the decisions that owner made
Who is accountable Whether an escalation terminates in a decision, or circulates until the program absorbs the problem An escalation path with a named end point and a stated time bound

None of the four is answered by a location. Each of them can be specified, and a commitment that specifies all four is a different object from a commitment that asserts a geography.

The artifacts that prove seniority

A title is an assertion and a resume is a summary. What survives contact with a programme is a document that exists already, because somebody worked in a particular way and the working left a trace. For each behaviour the word senior is supposed to guarantee, there is an artifact that shows it, or shows its absence.

Design authority: a decision record with an author’s name on it. The artifact is a written decision naming who made it, which options were rejected, and what would cause it to be revisited. People with design authority produce these because the role requires it. A person without design authority can describe a design accurately and cannot show you one they moved.

The standing to say no: a recorded refusal, and what happened to it. The artifact is a declined request written down, a shortcut that would not have survived an audit or a scope addition that broke a dependency, together with who had the authority to overturn the refusal and whether anybody did. A refusal nobody recorded is indistinguishable from a refusal nobody made.

Review depth in both directions: two review records pointing opposite ways. One showing this person reviewing somebody else’s work, and one showing this person’s own work reviewed and changed. A team whose most senior member appears only in the first record has a single point of failure that nobody has written down.

Direct contact with the estate: an access record and a change history. The artifact is an entry in an environment’s own logs: an account, a date, a change. One line settles whether the person is working in the environment or supervising somebody who is.

Ask for one of each, redacted as far as the provider needs. What you are testing is not the content of any individual document. It is whether the documents exist at all, because the working habits that produce them are the habits the word senior is supposed to name.

What a delivery assurance commitment should specify

Delivery assurance is not a synonym for staffing. It is the set of functions that keep a program coherent while people, requirements and environments change around it. A commitment that names them is checkable. A commitment that asserts quality is not.

Architecture ownership across the whole scope. One person owns the design across every workstream, and the decisions that owner makes are written down where you can read them later, including the options that were rejected and why. Programs do not usually fail on a bad decision. They fail on a good decision nobody recorded, made in one workstream, invalidated by a later decision in another.

A review standard that says what is reviewed, by whom, and against what. Not that review happens. What is in scope for review, who performs it, what standard it is measured against, and what happens to work that does not pass. A review practice with no standard behind it is a second opinion.

Environment and change control. Who can deploy into which environment, what a change passes through before it gets there, and how a change is reversed. This is the function that decides whether a Friday afternoon is uneventful.

Knowledge capture that runs during the work. Documentation produced at the end of an engagement is a summary of what somebody remembered. Capture that runs during the work, as decisions are made, is the thing that lets a new person pick up a workstream without a discovery exercise. It is also the mechanism that decides whether continuity survives a person leaving, which is the second of the four things location does not tell you.

An escalation path with a named end point and a time bound. Every arrangement has escalation. Fewer have an end point: a named role where the escalation stops and a decision is made, and a stated period after which it gets there whether or not anyone has agreed. An escalation path without an end point is a queue.

Regulated-environment competence held by the people assigned, not by the firm. Competence that lives in a firm and not in the individuals working in your estate is competence you have not bought. If your environment sits under a specific regime, the commitment should say which of the assigned people have delivered under it.

Each of those is a function that either exists in the arrangement or does not. None of them requires a comparison with anyone.

Whose team is it: the scope of a US-based claim

This is the question the phrase itself does not answer, and it is the one that decides what the phrase is worth.

A claim about where people are employed can be scoped three ways, and all three are stated in the same words:

  • To the whole firm. Everyone who works there, on every project, on every technology.
  • To this program. The people assigned to you, while the rest of the firm is arranged differently.
  • To one practice. One capability area, with other capability areas arranged differently, which matters the moment your program crosses into a second area.

The three are not equivalent and the difference only appears when the program grows. Work that begins inside one capability area and stays there is unaffected. Work that crosses into a second one is where a practice-scoped claim stops covering the program, usually without anyone noticing that it has.

So establish the scope rather than the fact. Ask which of the three the claim is, and whether any part of the work is performed by a party other than the firm you are contracting with. Both answers are short, and both are either specific or they are not.

i3solutions’ own answer, stated so you do not have to ask for it. i3solutions is entirely U.S.-based. Every i3solutions employee is U.S.-based, every i3solutions project is U.S.-based, and every technology i3solutions delivers is U.S.-based. Read the quantifiers and the scope answers itself: it is the first of the three above, the firm-wide one. It is also a statement about location and nothing beyond location. It is not a claim about headcount, about personnel status of any kind, about a named office or work site, about whether a subcontractor is ever used on a given engagement, or about where data resides or is processed. Those are separate questions with separate answers, and every one of them is worth putting to any provider, this one included.

The contract terms that make it enforceable

The section above names the functions a commitment has to contain. This one is about the clauses that make those functions survive a disagreement. A function named in a proposal and absent from the agreement is an intention. The terms below are what convert each of them into something you could point at afterwards.

Named individuals, with substitution by consent rather than by notification. The agreement names the people holding the architecture and lead positions, and states that replacing one requires your written agreement. Without this clause, every other term describes a team whose membership the other party controls.

A minimum allocation, expressed as a number. A stated share of each named person’s working week, across stated dates. Seniority that is genuine and thinly allocated is not the arrangement you thought you were buying.

Notice and overlap on rotation. A stated notice period before a named person leaves the programme, a stated period during which the incoming and outgoing people are both present, and a written handover that is delivered rather than promised.

The decision record as a deliverable, not a courtesy. Architecture decisions, carrying their rejected options and the reasons, delivered on a stated cadence and listed as an acceptance condition of the milestone they belong to. This is the single term that changes behaviour most, because a record that is owed gets written while the reasoning is still available to write down.

An escalation end point with a name and a clock. A role at which escalation stops and a decision is made, and a period after which it reaches that role whether or not anybody has agreed. Without the clock, the clause describes a queue.

A remedy that is specific and proportionate. What you are entitled to when the named people are not the people doing the work: re-staffing inside a stated period, a credit, or termination for cause. A term with no consequence attached to it is a preference.

Regulated-environment competence attached to individuals rather than to the provider. Where a compliance regime applies, the agreement identifies which of the named people have delivered under it. Competence held by an organisation and not by the people inside your estate is competence you have not bought.

And drop the terms your own situation already satisfies. If your organisation holds the architecture internally and is buying execution capacity against it, the architecture ownership terms describe an interface rather than a transfer, and should be written that way. If the binding constraint sits on your side, in decisions nobody has made or access nobody has granted, then no clause here moves the date. A term that duplicates something you already hold adds something to negotiate and changes nothing about the outcome.

Related reading

Talk to a senior architect

Bring the arrangement you are being offered and the parts of it that are not written down yet. If the parts that are not written down are the parts you are being asked to trust, that is the conversation to have: Talk to a senior architect.

Frequently Asked Questions

How do you verify senior US-based Microsoft delivery assurance before you sign?

In three places. Inspect first: ask for the named individuals and how much of their working week you have, for one architecture decision record showing the options it rejected, for an instance of the most senior person’s own work being reviewed, and for the rotation and escalation mechanics. Then require the artifacts that prove seniority rather than assert it. Then contract for it, so that every function you were promised has a clause behind it.

What does delivery assurance mean beyond location?

It means the functions that keep a program coherent while people and requirements change: architecture ownership across the whole scope with the decisions recorded, a review standard naming what is reviewed and against what, environment and change control, knowledge capture that runs during the work, an escalation path with a named end point and a time bound, and regulated-environment competence held by the people assigned rather than by the firm.

What should a delivery assurance commitment specify?

It should name one owner for the design across every workstream and where that owner’s decisions are recorded; what is reviewed, by whom and against what standard; who can deploy into which environment and how a change is reversed; how knowledge is captured during the work rather than at the end; where an escalation ends and within what period; and which of the assigned people have delivered under your compliance regime.

Which artifacts prove that a delivery team is senior?

Four documents, one for each behaviour the word is supposed to guarantee: an architecture decision record naming its author and the options it rejected, for design authority; a recorded refusal together with who could have overturned it and whether anybody did, for the standing to say no; two review records pointing opposite ways, one where the most senior person reviews and one where that person is reviewed, for review depth; and an environment access record carrying an account, a date and a change, for direct contact with the estate rather than supervision of somebody who has it.

How is a US-based claim scoped, and why does it matter?

It can be scoped to the whole firm, to one program, or to one practice, and all three are stated in the same words. The difference only appears when work crosses from one capability area into a second, which is where a practice-scoped claim stops covering the program. Establish which of the three applies, and whether any part of the work is performed by a party other than the firm you are contracting with.

What makes a delivery assurance commitment enforceable rather than aspirational?

Clauses rather than descriptions: named individuals whose substitution needs your written agreement rather than your notification; a minimum allocation of each named person’s working week across stated dates; a notice period and an overlap on rotation with a written handover delivered; architecture decision records listed as an acceptance condition; an escalation end point with a named role and a stated period; a specific and proportionate remedy when the named people are not the people doing the work; and regulated-environment competence attached to the named individuals rather than to the provider.