Delivery Management

At the core of nearly every organisation is the need to get finished, high-quality things out the door. Whether it’s software iterations, documents, clothes, cars, or hamburgers, the ability to “ship” a thing is paramount.

I’ve done many types of delivery management in my career: project management, programme management, portfolio management, service management. In every case my aim is to help teams to produce the best possible outcomes for customers in a way that they can sustain indefinitely.

I’ve always been a fan of Google’s SRE Model. It essentially breaks down work into two categories: fighting fires, and preventing fires. Under this model, the system becomes continuously more robust as causes of instability become less numerous and more interesting over time.

It applies beautifully to digital products & services and equally well to delivery of those products & services. Delivery can be brittle, opaque, and anxiety-inducing or resilient, transparent, and confidence-building.

Discoverable, recent, and accurate information form a foundation for stability & growth. There are many principles, tools, and processes for doing this. Some can be almost reflexive habits while others must be careful documented and turned into routines.

For my future reference, here are a few favourites. I may expand on them in the future.

Measurable goals

• Use OKRs of course 😉
• Perform regular OKR check-ins
• Share confidence, rationale, and next actions
• Minimise activity-based reporting

Week notes & newsletters

Regular week notes build accountability and greater understanding of team activity, impact, and capacity by sharing previous work and anticipating future results.

Try this format:

• What have we done since the last week note?
• What will we do before the next one?
• What else should you know?
• Something fun…

Enable self-service subscription management.

Roadmaps

• Consider the 3 Horizons method
• Don’t schedule every activity
• Do include a few hard deadlines if required to sync with other teams
• Use quarterly OKRs to communicate what will change, by how much, and when
• Bucket activities into “Now”, “Next”, and “Later”
• Assign time horizons to each bucket (e.g. 0-3, 4-9, and 9+ months)

Risk

• Risk is everywhere, it’s everyone’s business
• Manage it through everything you do
• Embrace Risk
• Make risk management visible via the backlog & roadmap
• Prioritise and deliver risk stories like any other piece of work
• Avoid risk management theatre (thanks to Jez Humble)
• Test & prove that your escalation procedure works and provides genuine help when needed

Accountability

• Assign a Directly Responsible Individual (DRI) for important things
• Practice Intent Based Leadership
• Practice volunteering rather than assigning things

Decision Logs

I’m a huge fan of decision logs. They allow you to have living documentation of how a system works including both technical architecture and ways of working and all the thinking that went into these decisions. They can include things like plans, designs, decisions, risks, open questions, and working agreements.

Basics:

• Use a simple text file
• Use a descriptive title and serial number for the filename
  • e.g. “DR-001 - Roll-out plan”
• Bonus: use markdown
• Store in version control
• Make them public

Things to include:

• Serial number for easy reference (e.g. DR-001)
• Title
• Date (of first publishing)
• Description of the question, problem, or condition
• Options considered
• Pros & cons (benefits/costs/risks) of each option
• Which option was chosen
• Follow-up actions required
• Signatories (who has agreed to this)
• Updates & changes (date and summary)
• Links to related:
  • Artefacts
  • Work items
  • Decisions
  • Operating procedures
  • Work instructions
  • Runbook items

Team charters & blogs

Every team should have a canonical URL where folks can go to learn about them and their product or service. It should include:

• Team name
• Members (names, roles, super powers, Manual of Me stuff)
• Products or services they run (with links to those pages)
• Areas of responsibility
• Areas which are out of scope
• Current goals (OKRs)
• Current budget & workforce plan (latest estimates, actuals, and deltas)
• Links to all updates & documentation

Runbooks, work instructions, and operating procedures

Use routines to keep teams focused and conserve energy.

• Runbooks: Step-by-step instructions for setting up, operating, maintaining, troubleshooting, and decommissioning a system
• Operating procedures: guidance for decision making and choosing which work instructions to follow (e.g. crisis management)
• Work instructions: step-by-step instructions for completing common tasks (e.g. onboarding)

Visible processes & visible work

• See visual control systems
• Kanban boards
• Ranked backlogs
• Ecocycle plans

Value stream maps

Visualise the flow of work. Understand each part of the process. What is it called? Who does it? How long does it take? At what point in the overall process does it happen? How often does it fail? What does it cost? How much time is spent waiting between parts? How do the different operations and sub-processes connect? Learn more

Patterns & templates

Save your decision-making energy for the things that really matter. Turn your good decisions into reusable patterns and templates for things like:

• New work items
• Newsletters
• Customer service emails
• Meeting minutes
• Decision logs
• FAQs
• Any repeatable process such as:
  • Team member onboarding/offboarding
  • Deployments
  • Code reviews
  • User research sessions
  • Customer onboarding
  • Agile ceremonies (backlog refinement, retrospectives, demos)
  • See runbooks, operating procedures, and work instructions above

Budgeting

• Practice agile budgeting
• See Beyond Budgeting & Bjarte Bogsnes
• Use “last best estimates” and update them frequently
• Share actuals frequently and accurately across the org
• Perform frequent re-forecasting & blameless gap analysis
• Redistribute funds between teams as necessary
  • This reduces fear of over/under spend

Prototypes, diagrams, sketches, & models

All models are wrong, but some are useful – George Fox

Building consensus

Use artefacts to build consensus and remove assumptions. Remember, building shared understanding is hard.

• Work in the open as much as possible
• Share & refine ideas via requests for comments (RFCs)
• Start building consensus with one person (via a one-to-one conversation)
• Bring conversations to a public forum when you have at least one person on board
• If a decision gets made, memorialise it in a decision record, proposal, or RFC

Update-ability

The moment information is out of date, it becomes obsolete and untrustworthy. The best defence against obsolescence is easy of updating.

• Default to things being editable by everyone
• Keep an audit trail of all changes
• Use version control (keep a history of changes)
• Write release notes for everything
• Consider using semantic versioning for everything
• Maintain quality (even for documents) with:
  • Pairing
  • Linting
  • Automated tests
  • Pull-requests

Discoverability

• Everything should have a canonical URL
• Link every mention of a thing to its canonical URL
• Link to detailed information, don’t duplicate
• Default to everything being open and visible
• Only lock things down when absolutely necessary
• When things move, mark the old version as obsolete and clearly sign-post to the new one (think 301 redirects)

Email

Use email sparingly, people get too much and things get lost. Use email as a way to point someone to a living document or live conversation

Realtime chat

• For rapid, asynchronous conversations between humans
• Have a public channel for the team to share information and receive questions from outside the team
• Have a private channel for the team (only if necessary)
• Create new channels for specific topics, archive them when the topic is no longer relevant
• Use naming conventions to aid discoverability e.g. “team-proteus” for a specific team or “club-music” for a special interest group or “ticket-355” for a specific story or ticket
• Record short videos as an alternative to:
  • Lengthy messages
  • Difficult-to-schedule live conversation
  • Quick live demos of work in progress (or issues)

Releases

• Write release notes even if they’re minimal. It’s important to know what’s new
• Communicate via your newsletter, public chat space, and any other channels you have.
• Link releases to specific work items (tickets) in the release
• Assign a semantic version number to each release
• Include the version number somewhere in the app so people know what they’re using

Specifications & requirements

Use a single system & language understandable by every stakeholder and team member (engineers, machines, business people, customers, and designers)

• Use Behaviour Driven Development
• Use spec by example (see the book)
• Cross-link between specifications
• Version control your specs

Meetings

Thanks to Peter Senge & The Fifth Discipline

• Don’t meet without an agenda
• Differentiate presenting from decision making
• Replace live presentations with videos that:
  • Are succinct and tightly produced
  • Include closed captioning, multi-lingual translation, and speed control
  • Can be watched on-demand
  • Follow this guidance and especially:
    • Make it big
    • Make it clear
    • Spend an hour of prep for every minute of presentation
  • Differentiate between decks which are backdrops for live presenters vs reports to be read
• Hold optional live Q&A sessions later
• Debrief at the end of every meeting
  • What should we keep next time?
  • What should we change?
  • Try a ROTI
• Keep 10 min between meetings
• End on time
• Record, transcribe, and summarise all meetings with AI
• Capture actions and decisions from every meeting (see Decision Logs)
• Understand the difference between debate, discussion, and dialogue.
  • Debate: one right answer; I’m going to prove I’m “right”
  • Discussion: Union of our ideas and answers, many possibilities
  • Dialogue: Discovery of new possibilities that no-individual could anticipate
• Balance advocacy with curiosity
• Reserve time to design and plan for larger meetings that require facilitation
• Learn & use Liberating Structures

What’s missing?

What other important tools allow for good delivery management at the product, programme, or portfolio level?