How to plan a software development project

September 24, 2026 · 7 min read

Almost every software project that goes badly went wrong before development started. Not because the planning was skipped, but because it answered the wrong questions — features instead of outcomes, screens instead of processes, what people say they do instead of what they actually do.

Start with the problem, not the solution

The most common opening to a project is a description of a system: "we need a dashboard where managers can see jobs by status." That is already a solution, and it has smuggled in assumptions about who needs what and why. Underneath it is usually a plainer problem — nobody can tell which jobs are late until a customer calls to complain.

Stating the problem rather than the solution keeps options open. The answer to that one may well be a dashboard. It may also be an alert, a weekly report, or fixing the reason jobs go late without anyone noticing.

Write down the process as it actually runs

This is the single most valuable thing you can do before speaking to a developer, and it is harder than it sounds. The official version of a process and the real one usually differ, and the difference is where the software will break.

• Follow one real job end to end, not a typical one — a recent, specific one.
• Note every point where information moves between people or systems, including the ones that involve a phone call or a spreadsheet.
• Ask what happens when it goes wrong: the rush job, the cancellation, the customer who changes their mind halfway.
• Write down who is allowed to do what, and who actually does it when that person is on holiday.

The exceptions matter more than the happy path. Any developer can build the happy path. The exceptions are what determine whether people use the system or quietly go back to the spreadsheet.

Decide what success looks like, numerically

Before anything is built, agree how you will know it worked. "Better visibility" cannot be verified. "A manager can see every job that is past its promised date, without asking anyone" can. So can "order entry takes under two minutes" or "we stop re-keying invoices into the accounting system".

This is not bureaucracy. It is the difference between a project that ends and one that drifts, and it protects you more than it protects the developer.

Separate what you need from what you would like

Everything that survives those questions is version one. Everything else goes on a list for later, and a surprising amount of that list turns out never to be needed once the first version is in use.

Know who decides

Projects stall on decisions far more often than on code. Before starting, name the person who can settle a disagreement about scope without convening a committee, and make sure they have the time. A project with four stakeholders and no decision-maker will move at the speed of the slowest calendar in the group.

Plan for the part after launch

Software is not finished when it ships. Somebody has to own it: apply updates, fix what breaks, decide what changes next. That may be your developer on a support arrangement, or your own staff, but deciding after launch means deciding under pressure.

The same applies to data. What happens to what is already in the spreadsheets? Migrating it is usually a real piece of work, and it is routinely left out of estimates by everyone involved.

What to bring to a first conversation

Not a specification. A description of the problem, the process as it really runs, what success would look like, and what you cannot live without. A firm worth working with will ask questions you had not considered — and will tell you if the answer is to buy something rather than build it.

If you want to see what the stages after planning look like in practice, our process from discovery to support sets out what happens at each one and what you get at the end of it.