Software Delivery Management (SDM) Ecosystem

Guides

Software Delivery Guides

Practical guidance for clarifying software requests, estimating the full change, making investment decisions, and carrying the original need into delivery.

All software delivery guides

Use the guide that matches the question blocking the request or delivery decision.

IT project training costs

How to estimate internal training costs for IT projects

Estimate internal training costs for IT projects by counting who must learn the new work, who designs and delivers the training, and what else stops while they do. Convert design, trainer, and learner hours with a loaded rate, then add backfill, vendor materials, and first-month support. Write assumptions and exclusions beside the number.

Missed engineering estimates

Why do engineering estimates always miss deadlines

Why do engineering estimates always miss deadlines? Because they size only the code. Story points and a hallway date ignore training, process change, and incomplete requests. Freeze the first-release boundary, estimate business and technical effort against it, write assumptions, and treat a yes as a paired commitment—not a developer calendar promise.

Business-IT alignment

How to align technology with business goals

How to align technology with business goals: write the business outcome on the software request, size business and technical effort together, fund the work against that goal, and keep the original outcome attached through requirements, the sprint, and testing. Alignment is a recorded yes on one thread—not a strategy offsite or a steering slide.

Software project intake template

software project intake template

A software project intake template collects the current problem, the people affected, the outcome that would make the change worth doing, a reachable owner, and known constraints. It does not ask a department manager for a charter, WBS, or solution design. Review for a complete story, then stop—planning comes after.

Clear project scope

How to get a clear project scope from business stakeholders

How to get a clear project scope from business stakeholders: refuse to estimate a slogan. Write the current path, who is stuck, what better looks like in the first release, what is deliberately out of scope, and who can answer follow-up questions. If a stakeholder cannot name those five facts, the scope is not clear yet—and a workshop will not invent them.

Software discovery phase

How to run a software discovery phase

How to run a software discovery phase: start from a complete software request, ask project-specific questions on that same record, close the answers that would change the build, estimate business and technical effort, and record a yes before anyone opens a sprint. A kickoff week, a sprint zero, and a Definition of Ready checklist are not the phase.

Scope before sprints

How to stop scope creep before developer sprint planning

Stop scope creep before developer sprint planning by freezing the first-release outcome, writing exclusions, and recording a yes before anyone opens a backlog. In Scrum, protect the Sprint Goal and park mid-sprint adds on the Product Backlog. Sprint planning slices approved work; it does not invent the product.

Requirement drift

How to stop requirement drift between product managers and developers

Stop requirement drift between product managers and developers by keeping one source for the problem, the first-release outcome, and the reviewed answers. Trace every story to those answers, put new decisions back on that record the same day, and have QA verify the original thread—not a ticket written from memory.

Requirements vs backlog

Why a requirements document and the sprint backlog become two sources of truth

A requirements document and the sprint backlog become two sources of truth when stories are written from a paraphrase instead of from reviewed answers. The BRD stays in Confluence; Jira holds the work. Keep one thread from requirements onto stories so the board is a view of the spec, not a second spec.

Intake into Jira

Why copying intake forms into Jira backlogs kills project context

Copying intake forms into Jira backlogs kills project context because the work item is a new document. Tracker fields flatten the problem, the people, the exclusions, and the owner into a summary. Keep the intake as the living thread and treat any Jira issue as a pointer, not the spec.

QA and the Jira ticket

Why QA tests the Jira ticket instead of the original request

QA tests the Jira ticket instead of the original request when the tester can only open a work-item description. That description is a paraphrase of intake. Verify the same answers the business user wrote, plus the reviewed requirements that followed, so a green test does not bless the wrong product.

JSM software intake

Why Jira Service Management is the wrong software intake

Jira Service Management is the wrong software intake because a portal form creates a service ticket, not a complete software request. The requestor’s people, constraints, and owner die in a work item. Keep JSM for frontline support, access requests, and catalog items. Put software change on a thread that can be estimated, approved, and tested. Production issues that need more than a ticket belong in Foundry.

Asana Forms software intake

Why Asana Forms are the wrong software intake

Asana Forms are the wrong software intake because a completed Form creates tasks, not a complete software request. Custom fields collect what that project asked for so a team can assign owners. The people, constraints, and owner die in a task list. Keep Asana for campaigns. Put software change on a thread that can be estimated, approved, and tested.

Handoff friction

Product to engineering handoff friction

Product to engineering handoff friction starts when discovery is exported into a new brief, a Jira epic, or a ticket list. The packet looks complete and the original answers do not travel. Reduce it by keeping one thread from intake through reviewed requirements. Do not automate a cleaner paste. The handoff is the bug.

Definition of Ready

definition of ready agile

Automating the Definition of Ready for agile teams means blocking work that is not complete enough to pull—not pasting a Jira checklist. Map each DoR item to a gate on the request: finished intake, reviewed answers, both estimates, a recorded yes, then Delivery Planning readiness.

Anti-PMO playbook

Anti-PMO playbook for software intake

An anti-PMO playbook for software intake assigns the person closest to the work to describe the problem, names a reachable owner, and reviews for a complete story—not a charter. Structure the path as problem, people, owner, and constraints. Then stop. Discovery and estimates come after someone can understand the request without a project manager in the room.

Agile jargon

Why agile jargon kills stakeholder alignment

Agile jargon kills non-technical stakeholder alignment when standups, velocity, and story points become the only shared language. Replace ceremony words with facts: what is broken, who is stuck, what better looks like, and who can answer questions. Alignment happens when a stakeholder can read the request and recognize their own work.

Real English

How to move a software project using only real English

Move a software project from definition to delivery in real English by keeping one living record: the original problem, the people affected, reviewed answers, and a reachable owner. Do not translate the request into a new dialect at each handoff. Testers and developers should read the same words the requestor wrote.

SaaS intake form examples

SaaS intake form examples that work collect the current workflow, the workspace or tenant that hurts, who is blocked, and a reachable owner. They do not start with a feature wishlist or a preferred vendor. Copy the prompts, then stop—scoring, sequencing, and tickets are later jobs.

Agile product hierarchy templates

Agile product hierarchy templates give every increment a parent: a theme names the product bet, an epic is a slice with exclusions, and a story is a testable change that serves that epic. Without the hierarchy, the board becomes a flat list and the first increment loses its edge.

Intake process

project intake process

A software project intake process moves a complete request through automatic readiness, early IT triage, and Intake Review. IT recommends Standard Discovery, Lightweight Discovery, Existing Solution Review, or Not an IT Project. Ready for Discovery is not investment approval; approval follows discovery and Business and IT estimates.

Business requirements

how to write a BRD

A business requirements document (BRD) states why a software change is worth doing: the current problem, who is affected, the outcome that would make the work succeed, and the constraints that already apply. It is not a design, a backlog, or a launch date. Write the BRD from the original request, keep it reviewable, and stop before anyone invents tickets.

Product requirements

how to write a PRD

A product requirements document (PRD) turns a reviewed business why into what the software should do: first-release behavior, who uses it, what is out of scope, and how you will know it worked. It is not a backlog dump and it is not a replacement for the original request. Write the PRD on that same thread, then review it before anyone opens tickets.

Project request form

project request form

A project request form for IT collects a software change in everyday language: what happens today, who is affected, who owns follow-up, and what cannot move. It is not a ticket title, campaign brief, or service-desk catalog item. Write those facts before anyone books a kickoff.

Software business case template

software business case template

A software business case template records two numbers on the original request: the business estimate for training, process change, and adoption, and the IT estimate for the build, integrations, and cutover. Write assumptions beside each number. A slide that only prices development is not a case.

IT project approval process

An IT project approval process is how an organization records yes, no, or not yet on a software change after the request is complete and both estimates exist. The decision cites that record. A phase gate, a hallway promise, or a slide vote is not the process.