Skip to content

Plan Phase

The plan phase turns an agreed scope into a design, a list of stakeholders and a schedule. When it is finished, the platform team knows what to build, and the customer knows what to arrange before the preparation starts.

flowchart LR
    a["Agreed scope<br/>(contract or project approval)"] --> b["Kick-off"] --> c["Workshop"] --> d["Design document<br/>or discovery sheet"] --> e["Gap analysis<br/>(if needed)"] --> f["Plan and prerequisites<br/>confirmed"]

Steps

# Step Result
1 Confirm that the scope is agreed. In the managed model, start only after the contract is signed. A start date
2 Plan the kick-off and the workshop and send the invitations. Meetings in the calendars
3 Hold the kick-off. Shared understanding of process, people, timeline and dependencies
4 Hold the workshop. Design decisions, recorded
5 Write the design document, or complete the discovery sheet. Input for the deployment
6 Agree on any gap between the design and the standard platform. A decision per gap: build it, or leave it out
7 Confirm the prerequisites with the customer. A dated list of what is arranged by whom

Kick-off

At the kick-off the platform team and the customer go through the process, the people needed for each activity, the answers to the intake questionnaire, the timeline and the dependencies. The meeting is usually held by the main implementer and the delivery lead (the engagement lead).

Invite these roles from the customer side:

  • Azure architect
  • network specialist or engineer
  • DevOps specialist or engineer
  • Azure specialist or engineer
  • security specialist
  • project or delivery manager

Workshop: design or discovery

Two forms are common. Pick the one that fits the size and complexity of the customer.

Form Use it when Output
Design workshop (high-level design, HLD) The customer needs a full design with a document they own afterwards A design document
Discovery workshop The platform is delivered in a standard way and the choices are a fixed set of questions A filled-in discovery sheet that maps directly to deployment values (mapping)

A design workshop usually runs for about two days with two or more experienced Azure architects, depending on complexity. The design document follows within a few weeks. After the customer accepts it, the customer owns the document and keeps it up to date.

Topics to decide, whichever form you use:

  • which Azure regions to use, and whether the platform is single-region or multi-region
  • the firewall SKU and how ingress traffic is handled (Application Gateway and WAF, or not)
  • connectivity to other networks: site-to-site VPN, point-to-site VPN, ExpressRoute, BGP
  • DDoS protection, Bastion and other optional features (feature flags)
  • Azure DevOps or GitHub for repositories and pipelines
  • the management group structure and the subscriptions (see Prerequisites)
  • the IP plan for the hub, the job runner network and the spokes
  • log retention, alert receivers and the security contact
  • who approves production deployments, and the PIM model for the platform team
  • the operating model and the service levels that apply

Gaps

Sometimes the customer needs a service or configuration that the standard platform does not offer. Do a gap analysis and estimate the work. Let the customer decide whether to invest in the gap. If they do, plan it as a separate item, and describe it in the design document as a deviation from the standard. See Building new functionality for how new features reach the code repository.

Keep your workshop template current

After each workshop, update the template (questions, default answers, newly found gaps) so the next one starts from the latest knowledge. Review the template regularly with the people who own the product.

Meetings during the implementation

Meeting Purpose Frequency
Kick-off Align on process, people, planning Once
Workshop Make the design decisions Once, or in parts
Stand-up Platform team and the customer's project lead check progress and impediments Daily or every other day
Steering committee The customer's responsible person and the delivery lead discuss risks, issues and decisions. Use the report template. Per period set in the plan
Technical hand-over Show the result and close the project Once, at the end (Hand-over)

Output of the plan phase

Before you start the prepare phase, check that you have:

  • [ ] the design document or discovery sheet, accepted by the customer
  • [ ] the filled-in mapping for the first hub values
  • [ ] the list of stakeholders and their roles
  • [ ] decisions on every gap, with an estimate for the ones that will be built
  • [ ] confirmation of each item in Prerequisites, with an owner and a date
  • [ ] the IP plan for the hub and for the job runner network
  • [ ] a schedule for the preparation, deployment (including a maintenance window if the customer has existing traffic), validation and hand-over