Monthly Automation Value Summary Template

Monthly Automation Value Summary Template

About This Template

A one-page monthly summary for programme sponsors and senior stakeholders. Distribute at the start of each month covering the previous month. Keep it to one page — executives who receive a two-page summary will skim it; executives who receive a one-page summary will read it.

The purpose is continuity of signal: evidence that the programme is delivering, problems surfaced proactively, next steps communicated clearly. It is not a status report on what the team did — it is a report on what the programme delivered.

---

Network Automation Programme — Monthly Value Summary

Period: [Month YYYY] Prepared by: [Name, Role] Distributed to: [Programme sponsor, relevant stakeholders]

---

Programme Snapshot

	This Month	Last Month	Programme Start
Automation coverage	[%]	[%]	[baseline %]
Change lead time	[days]	[days]	[baseline days]
Change failure rate	[%]	[%]	[baseline %]
Incidents attributable to changes	[n]	[n]	[baseline n/month]

---

Value Delivered This Month

Changes and deployments:

• [n] changes deployed via pipeline
• [n] changes blocked by automated validation before reaching production
• [n] change-related incidents (target: [target])

Operational outcomes:

• [Specific operational improvement — e.g., “14 BGP session recoveries handled automatically, zero on-call pages”]
• [Specific time saving — e.g., “Quarterly compliance report generated in 2 hours vs 3 days previously”]
• [Specific new capability — e.g., “New Singapore branch provisioned in 4 hours”]

Engineering hours recovered:

• [n] hours/month from automated tasks that were previously manual
• [Describe the top 1-2 sources of time recovery]

---

Cumulative Progress

Since programme start [Month YYYY]:

• [n] changes deployed through automation pipeline
• [n] changes prevented from reaching production by automated checks
• [n] engineering hours recovered from manual tasks
• [n] compliance incidents prevented
• [£/$ n] estimated operational cost savings (if tracked)

---

What Did Not Go Well

[Be direct. If a metric deteriorated, say so and explain why. If a milestone slipped, say so. Sponsors who receive summaries that only report good news will stop reading them.]

• [Issue 1 — what happened, why, and what the response is]
• [Issue 2 if applicable]

---

Programme Health

Milestone	Status	Notes
[Phase/milestone name]	[On track / At risk / Complete]	[Brief note]
[Phase/milestone name]	[On track / At risk / Complete]	[Brief note]

Programme phase: [Current phase and % complete]

Next month’s priorities:

1. [Top priority — specific and deliverable]
2. [Second priority]
3. [Third priority if applicable]

---

Decisions or Support Needed

[If the programme needs sponsor input, a decision, or removal of an obstacle — state it clearly here. Do not bury it in the narrative.]

• [Decision required: description, options, recommendation, deadline]
• [Obstacle to remove: description, what is blocking, what support is needed]

---

Adapting This Template

Frequency: Monthly is appropriate for most programmes. If the programme is in a particularly active phase (e.g., first production deployment), weekly summaries may be warranted temporarily.

Length: One page is a constraint, not a guideline. If the summary requires two pages, the executive version should still be one page — with a detail appendix for those who want it.

Tone: Write for someone who is supportive of the programme but has limited time. Lead with outcomes, not activities. “We deployed seventeen changes” is an activity. “Change lead time dropped from 8 days to 2 days, and we have had no change-related incidents in ninety days” is an outcome.

When things go wrong: Proactive disclosure of problems, with a plan, builds credibility. Sponsors who discover problems independently — rather than from this summary — lose confidence in the programme’s transparency. Never omit bad news from this summary.