SDLC Planning Phase: Steps, Deliverables and an Example

The SDLC planning phase is the first of the seven phases of the software development life cycle. It's where a team decides whether a piece of software is worth building at all, and agrees how it will know the project worked.

It ends with a decision, go or no-go, made by whoever is paying.

The worked example carries on with that post's invoicing tool for a small plumbing firm, where invoices start life in a Word template and late payers get a phone call. It's invented.

What the planning phase is for

The planning phase exists to make the start-or-stop call while changing your mind still costs almost nothing.

Moving the scope line now costs an edit to one page. The same move in development costs rework, and in testing it can cost the release date.

I'd rather kill a project after a week of planning than in month three of development.

Planning also gives the later phases something to check against. A request that turns up halfway through the build is in scope only if the brief says so, and the success measure says whether the shipped software worked.

The project should trace back to something on the product roadmap, or to a problem someone senior has named. If it traces back to neither, I'd treat that as the first sign of a no-go.

Inputs and the deliverable

The planning phase takes in a problem and the evidence for it, and hands out a one-page brief with a go or no-go decision attached.

Most of the inputs are things you collect rather than write:

• The problem, in the user's words - from interviews, support tickets, sales calls or a complaint from the owner.

• How the work gets done today - watched if you can, described if you can't.

• Your records - whatever data will give you today's number for the thing the project is meant to improve.

• The constraints - a budget ceiling, a date the business can't move, rules the software has to follow.

What comes out is the brief. It names the problem and why it matters, what's in scope and what's out, a rough budget and timeline, the main risks and one success measure.

Bigger companies often want a longer business case. I'd write the one-page version first anyway, since a sponsor who doesn't finish the brief can't really decide on it.

Who leads the planning phase

The product manager usually leads the planning phase, and the person paying for the project makes the decision.

• Product manager - runs the interviews, writes the brief and asks for the decision.

• Sponsor - the owner, a department head or a client. Makes the go or no-go call.

• Users - the people whose work will change. At least one of them should read the brief before it goes to the sponsor.

• Engineering lead - gives the rough estimate and names the technical risks.

• Project manager - turns the budget into a timeline and flags the dates that can't move.

The split between you and the project manager is the difference between a product manager and a project manager in miniature. You own why and what. They own when.

The steps in the planning phase

The planning phase runs in six steps, and the order matters less than finishing all of them before the brief goes out.

1. Name the problem. Write it in the user's words, with a number in it if you can. "Payment takes too long" becomes a problem you can plan against once you know how long.

2. Measure the baseline and set one success measure. If your company runs OKRs, the success measure should read like a key result.

3. Draw the scope line. List what's in and, just as carefully, what's out. The out list is the one that protects you in month two.

4. Look at the options. Build, buy, change the process or do nothing. Price at least one off-the-shelf product, even if you expect to build.

5. Estimate and list the risks. This is the feasibility check. Engineering gives a rough budget and timeline, as a range, and each risk that could sink the project gets an owner.

6. Write the brief and ask for the decision. One page, to the sponsor, with the date you need a yes or a no by.

A no-go isn't a failure of planning. Often the right answer is to cut the scope and bring the brief back. Sometimes it's to stop.

The diagram as text

• Name the problem, in the user's words.
• Measure the baseline and set one success measure: today's number and the target.
• Draw the scope line: what's in and what's out.
• Look at the options: build, buy, change the process or do nothing.
• Estimate and list the risks: a rough budget and timeline, as a range.
• Write the brief: one page, to the sponsor.
• Go or no-go: the sponsor decides. A no-go goes back to the scope line: cut the scope and bring the brief back, or stop.

Planning in agile versus waterfall

In waterfall, planning happens once and fixes the scope, budget and dates for the whole project. Agile plans at several levels instead, and expects the plan to change.

A waterfall plan is detailed because every later phase runs against it, and changing it means a formal change request. That cost is deliberate. It suits work where a late change is expensive anyway, which is where I'd still pick waterfall over agile.

Agile teams still plan. The Agile Manifesto values responding to change over following a plan, while saying there is still value in the plan.

What changes is how much gets fixed up front. The Scrum Guide's Product Goal describes a future state of the product for the team to plan against. Sprint Planning then lays out the work for each sprint, timeboxed to a maximum of eight hours for a one-month sprint.

On an agile project I'd fix the problem, the budget and the success measure in planning, and leave the feature list loose.

The invoicing tool at the planning phase

For the invoicing tool, the planning phase ends with a one-page brief that the firm's owner signs.

The PM spends a morning with the office manager, watching her build an invoice from the Word template and ring a customer who hasn't paid.

Then the PM pulls the last few months of invoices and works out the average number of days from job complete to payment received. That average is the baseline. The success measure is the same number, lower.

Pricing a couple of off-the-shelf invoicing apps shows the owner what buying would cost next to the build budget. An engineer gives a rough estimate as a range.

The brief gives one reason, that payment takes too long. It puts creating, sending and tracking invoices in scope, writes payroll and accounting down as out, and adds a rough budget and the days-to-payment measure.

Adoption is the biggest risk. If the office manager keeps using the template, nothing changes, so the brief names her as the first user.

Tax rates, PDF layouts and the payment provider aren't in it. Those wait for the requirements phase and its short requirements document, and for design.

Common mistakes in the planning phase

Most planning mistakes come from treating the phase as paperwork to clear before the real work starts.

• Starting with the solution - "We need an app" is a solution. "Customers pay us late" is the problem, and an app is one of several answers to it.

• No baseline - Without today's number, nobody can say after launch whether the project worked.

• Treating the estimate as a promise - A planning estimate is a range for a go or no-go decision. Turn it into a deadline and the team pads every estimate after it.

• No out-of-scope list - Anything not written down as out will be asked for later, and someone will say it was always in.

• A decision that was never in doubt - If nobody could have said no, the phase was a formality.

• Planning for too long - The plan only has to be good enough to start. Detail that the first sprint will change is wasted.

What AI changes in the planning phase

AI makes the desk research behind a brief cheap, but the baseline and the decision still come from people who know the business.

OpenAI's prompt list for product teams has ChatGPT research how the top five competitors in a space structure their pricing tiers, from public sources with URLs, and summarize recent regulatory guidance for a feature by region, with citations.

Anthropic's help center, updated in October 2026, says Claude's research feature runs several searches that build on each other, across the web and your connected tools, on paid plans. Start it in Claude Mobile and it searches only the web, with no error or other sign that your connectors were skipped.

Open every link behind a number before that number reaches the sponsor.

A web search won't find the baseline. The invoicing tool's days-to-payment figure sits in the firm's own invoices.

If the project you're planning is itself an AI project, the brief needs two success numbers, one for quality and one for efficiency, each with today's baseline next to it. Getting both signed by the person who will run the new workflow day to day, before the build starts, is one of the moves I'd make for de-risking a first AI project.

A planning phase checklist

Before the brief goes to the sponsor, check it against these questions.

• Can someone outside the team say what problem it solves, in one sentence?

• Does it give today's number and the target for one success measure?

• Is there an out-of-scope list?

• Did you price at least one alternative to building?

• Is the estimate written as a range?

• Does each named risk have an owner?

• Has at least one future user read it?

• Does the sponsor know the date you need a decision by?