# How to Plan a Software Project: 7 Steps Before Kick-off

> To plan a software project, define one measurable goal, collect users and requirements, cut scope to the must-haves, estimate effort as a range, pick a delivery approach with named decision-makers, list the top risks, and set milestones that each end in a go or stop decision. Revisit the plan at every milestone instead of defending it.

- URL: https://go-projects.de/en/planning/plan-a-software-project/
- Language: en
- Updated: 2026-10-19
- Publisher: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Ask a developer why their last project went over budget and you rarely hear "the code was hard". You hear "the requirements kept changing" or "nobody could tell us what done meant". Those are planning failures, and they show up at every scale.

The large-scale numbers are sobering. McKinsey and the University of Oxford looked at more than 5,400 IT projects in 2012. Projects with budgets above $15 million ran 45 percent over budget on average and delivered 56 percent less value than predicted. Your project may be a fraction of that size. The failure patterns are identical.

Most of them can be dealt with before the first commit. That doesn't take a 60-page project charter. It takes seven decisions, written down where everyone can see them.

## What has to be settled before kick-off?

Steve McConnell's "cone of uncertainty" is the most useful mental model here. At the initial concept stage, even skilled estimators can be off by a factor of four in either direction: a project estimated at six months might take six weeks or two years. Once the product definition is approved the range shrinks to roughly half to double. When requirements are complete, it's about 0.67x to 1.5x. McConnell's point is that the cone does not narrow on its own. Someone has to answer the open questions.

So before anyone commits to a date or a fixed price, these questions need written answers:

- What problem are we solving, and for whom?
- How will we measure success: a number, a date, a change in behaviour?
- What is explicitly out of scope for the first release?
- Who makes product decisions, who releases budget, who signs off?
- Which existing systems must we integrate with?
- What happens if half the budget is gone and a third of the work is done?

Teams almost never ask the last one. It matters most.

## The seven steps at a glance

**Seven steps to plan a software project**

1. **Define the goal** One sentence on the problem, one measurable success criterion with a date.
2. **Collect requirements** User groups, their tasks, integrations. As **user stories** or a **requirements document**.
3. **Cut the scope** Must, should, could, won't. Release one contains only musts.
4. **Estimate** Two methods, a range, contingency shown as its own line.
5. **Choose approach** Agile, sequential or hybrid. Decision rights made explicit.
6. **List risks** Top five, each with an owner and a countermeasure.
7. **Set milestones** Every milestone ends in a go, change or stop decision.

### Steps 1 and 2: goal and requirements

Good goals fit in one sentence and contain a number. "Modernise our booking process" is a wish. "By 31 March, 70 percent of repeat customers book without phoning us" is a goal, and it gives you a filter for every feature request: does this help hit 70 percent, or is it just pleasant?

Requirements can be captured two ways. Traditional projects use a [software requirements document built from a template](https://go-projects.de/en/planning/software-requirements-document-template/). Agile teams prefer [user stories with clear acceptance criteria](https://go-projects.de/en/planning/how-to-write-user-stories/). Either works if someone who actually does the job is in the room while they are written.

### Step 3: cut the scope

This is the uncomfortable part, because nearly every wish list is too long for the budget. The Agile Business Consortium, which maintains the DSDM framework, recommends that must-have items take no more than 60 percent of estimated effort. The rest is room to manoeuvre when things slip. The mechanics are covered in our piece on [MoSCoW prioritization](https://go-projects.de/en/planning/moscow-prioritization/).

### Step 4: estimate honestly

An estimate is a probability statement, not a promise. "Four months" usually means "four months if nothing goes wrong". Say "three to six months, with an 80 percent chance of finishing under five" instead. Our overview of [software estimation techniques](https://go-projects.de/en/estimates-and-budget/software-estimation-techniques/) walks through methods and a worked example.

### Steps 5 to 7: approach, risks, milestones

Whether Scrum, a sequential plan or a hybrid fits depends mostly on how stable your requirements are. Roles matter more than labels. Somebody must be able to answer product questions within a day or two. When that person is missing, developers wait, and idle time is billed at the same rate as productive time.

Keep the risk list short. Five entries, each with a countermeasure. Usual suspects: an integration with a legacy system whose documentation nobody has seen, one key person going on leave for three weeks in August, privacy questions nobody raises until the week before launch.

## Template: the one-page project brief

Rather than a long plan, many teams do better with a one-page brief that every stakeholder signs. Here is an example for a field-sales app:

| Field | Example |
|---|---|
| Problem | Field reps log orders on paper; re-keying takes two days on average |
| Goal | 90% of orders captured digitally by 30 June |
| Out of scope | Offline mode, warehouse system integration (phase 2) |
| Budget range | $70k–$95k including 15% contingency |
| Product decisions | Head of inside sales |
| Sign-off | Two field reps plus the IT lead |
| Top risk | Undocumented ERP API, to be clarified by week 3 |
| Stop rule | If no pilot with real orders runs by 50% of budget spent |

The stop rule looks pessimistic. It prevents the most expensive mistake there is: carrying on because so much has already been spent.

## Where plans usually break

Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects for Harvard Business Review in 2011. The average cost overrun was 27 percent, which sounds survivable. The danger was in the tail. One project in six was a "black swan", with an average cost overrun of 200 percent and a schedule overrun of almost 70 percent. Plan for the average and you have not planned for the cases that sink you.

The tail cases tend to share a few traits:

1. Scope grows quietly. Each addition is small; together they are huge. A proper [change request process](https://go-projects.de/en/running-the-project/change-request-process/) is the antidote.
2. An estimate became a commitment. Someone named a number under pressure, and it hardened into a deadline.
3. Product decisions stall. The team builds on assumptions that get reversed later.
4. Nobody defined acceptance, so the final weeks become an argument about what "done" means.

We look at these patterns in more depth in [why software projects fail](https://go-projects.de/en/running-the-project/why-software-projects-fail/).

## Treat the plan as a working document

The common mistake is to write the plan once, get it approved and then defend it against reality. Better: a fixed rhythm. After every milestone, or every four weeks at most, the budget owner, the business lead and the tech lead look at three figures. How much budget is spent? How much of the prioritised scope is finished and accepted? Has the estimate for the remainder changed?

When budget burn and progress drift more than 15 percentage points apart, treat that as a signal. Don't push the team harder. Cut scope or renegotiate the envelope.

If you'd rather compare notes with people who do this for a living, OnlineBuilders describes [how it takes its own platforms from concept to operation](https://onlinebuilders.biz/how-we-work), which is a handy benchmark for your own plan.

Your next step: write the one-page brief for your project today. If the "out of scope" row stays empty, your planning is less finished than it feels.

## Step by step

1. **Define the goal** Write one sentence on the problem and one measurable success criterion with a date.
2. **Collect users and requirements** Name the user groups and capture their tasks as user stories or in a requirements document.
3. **Cut the scope** Sort requirements with MoSCoW and limit the first release to the must-haves.
4. **Estimate as a range** Use at least two estimation methods and report a range with a confidence level.
5. **Choose the approach and roles** Pick agile, sequential or hybrid, and name who makes product decisions and who signs off.
6. **List the risks** Write down the five biggest risks with likelihood, impact and a countermeasure.
7. **Set milestones with decisions** Give each milestone a testable outcome and a go, change or stop decision.

## FAQ

### How long should planning take before development starts?

For a three-to-six-month build, two to four weeks of discovery is common. Steve McConnell's cone of uncertainty suggests most of the narrowing happens in the first 20 to 30 percent of a project's calendar time, so skipping it just moves the work later, where it costs more.

### Do agile teams still need a project plan?

Yes, though it looks different. Instead of a Gantt chart listing every task, you need a product goal, a prioritised backlog, a rough release plan and a budget with a stop rule. Agile changes how often you replan, not whether you plan.

### What should a software project plan include?

At minimum: the problem, a measurable goal, what is out of scope, a budget range with contingency, who decides and who signs off, the top risks, and milestones. Everything else is detail that can live in the backlog or the requirements document.

### Who should be involved in planning?

Someone who owns the budget, someone from the business who does the work the software will change, and someone who can judge technical effort. Without the technical voice, dates get promised that nobody could check.

Photo: RyanT27, CC0 (https://commons.wikimedia.org/wiki/File:Clipboard_on_a_table_with_steps_listed_on_it.jpg)