How a software project runs from proposal to delivery

One of the first questions from an organisation that wants software built is how the process will run. What they will see and when, what will be expected of them, and when the work will count as finished.

In this post I describe the steps a project goes through from the first meeting to maintenance. The steps are not the same length in every project. In a small piece of work, several of them fit into a single meeting. But none is skipped, because a skipped step comes back as a surprise at the end of the project.

First meeting

We don’t talk about price at the first meeting. We try to understand what is wanted, how the work is done today and what needs to change. Who will use it, what data it will handle, which systems it will talk to.

At the end of this meeting we sometimes say there is no need for custom software. If an off-the-shelf product does the job, saying so from the start saves everyone’s time.

Discovery

If the need is not yet clear, we suggest a short discovery phase. A few workshops, a look at the existing systems and data, mapping the workflow step by step. The output of discovery is a written document: scope, user roles, integrations, data, known risks and unknowns.

This is the cheapest phase of the project and the one that saves the most money. Correcting a misunderstood need in a document is far easier than correcting it in code.

Proposal

The proposal is based on the discovery document. For each work package it sets out what will be done, how long it will take, what is expected of the organisation and against which criteria it will be accepted. What is out of scope is also written down separately. Who keeps the source code and intellectual property, and how maintenance will work, are settled here.

Design

Before writing code, we design the data model, the permission structure and the main screens. We show the screen mock-ups to the organisation’s real users. Objections raised at this stage are far cheaper than those raised later.

If personal data will be processed, this is also the stage where we decide which data is collected and why, who can see it and how long it is kept. These are not features to add later. They are part of the architecture.

Development

We run development in short cycles. At the end of each cycle the organisation sees a working version in a test environment. If something has been misunderstood, it is noticed within a few weeks.

Automated tests run on every change. If a test fails, that version does not move forward. We explain how we do this on our own site in a separate post.

Testing and acceptance

Acceptance is carried out against the criteria written in the proposal. For each feature, concrete criteria of the kind “in this situation it gives this result”. The organisation tries these criteria with its own data, any points that do not match are recorded and fixed.

When acceptance criteria are not written down, the “does it work?” argument is inevitable. We explain why in our post on acceptance criteria.

Go-live

Go-live is not a day but a small plan. If data is being migrated from the old system, trial migrations are done in advance. How to roll back if something goes wrong is written down. Users get short training, and questions are answered quickly in the first weeks.

Maintenance

After delivery, security updates, infrastructure upgrades and small improvements carry on. The scope of maintenance and how quickly a problem will be dealt with are put in writing at the proposal stage.

The source code, documentation and deployment steps are handed over to the organisation. That way, if the organisation one day wants to carry on with another team, it can.

The organisation’s role

Every one of these steps needs a counterpart on the organisation’s side. Someone who knows the workflow, can answer questions quickly and can try out interim versions. What slows projects down is usually not a technical problem but the lack of this counterpart.

In short

First meeting, discovery, proposal, design, development, acceptance, go-live and maintenance. The steps get shorter or longer depending on the size of the project, but none is skipped. Having in writing what will be delivered at the end of each step is what keeps surprises away at the end of the project.