From need to delivered product: my working methodology

“I need a website”, “we would like to automate our files”, “our tool no longer does what we want”: a project almost always starts with a poorly worded need. Between that sentence and a delivered, validated product in production lies a series of steps that I have learned to make explicit. This article describes them in order, with the documents that go with them (quote, contract, amendment), then explains how I can step in: on one step, on part of the scope, or on the whole.

Overview of the delivery cycle

Here is the full sequence, from the first exchange to the life of the product:

1. Stated need (often vague);
2. Needs analysis: rewording, questions, objectives;
3. Structured functional need, then functional specifications and an acceptance test plan;
4. Technical specifications;
5. Breakdown into tasks, scheduled in dated delivery batches;
6. Implementation by the technical team, with the client’s validations along the way;
7. Validation by the product owner, batch by batch;
8. Delivery to pre-production, then functional acceptance testing;
9. Final sign-off by the client, which triggers payment of the balance and go-live;
10. After delivery: fixes, new versions, maintenance.

1. From a vague sentence to a structured need

The first step is business analysis. The analyst listens, rewords, asks questions: who uses the tool, to do what, with which data, under which constraints, and above all what result would count as a success. They also bring out what nobody said because it is “obvious” to those who live it. The result is a structured functional need: objectives, a scope, use cases and an order of priority between the essential and the nice-to-have.

This is the least visible step and the most profitable: a misunderstanding corrected here costs a conversation; the same misunderstanding found at acceptance costs rework. I discuss it at more length in specifications and requirements analysis: why they matter.

2. Functional specifications, and the acceptance test plan from the start

The structured need is then translated into functional specifications: for each feature, a description, a priority and an acceptance criterion, that is, how we will establish that it works. The items the client must provide (texts, images, access) and the third-party components used are listed too, as is what is deliberately excluded.

I write the acceptance test plan at this stage, not at the end. It lists the test scenarios that will make it possible to say “this is compliant”. This choice has two effects: it forces each requirement to be verifiable, and it fixes the scope. What is in neither the specifications nor the test plan is not in the project, unless agreed in writing.

3. Technical specifications

Technical specifications answer the question “how?”: architecture, technologies and versions, hosting, third-party services and APIs, security, personal data. They are intended for the technical team and for whoever will run the product. The client does not have to master them, but must know their consequences: hosting to arrange, a subscription to take out, a compatibility constraint.

4. Breaking down into tasks and planning dated batches

The project is split into short, verifiable tasks, in an agile spirit: progress is made in small increments rather than through one big final deliverable. These tasks are grouped into delivery batches, each with a target date. The schedule also identifies who must provide what and when: handing over content and access, validating mock-ups or specifications, delivery for acceptance, end of acceptance, go-live.

The dates are landmarks that hold as long as everyone does their part: if the client is late providing content or a validation, the schedule shifts accordingly. I prefer to say so at the start rather than discover it along the way.

5. Implementation, validations along the way and developer feedback

During implementation, the client is not kept away until delivery. Intermediate deliverables (mock-ups, site structure, specifications, prototypes) are submitted for written validation, within an agreed period and with a defined number of correction rounds. What is validated is not reopened without changing the scope.

For their part, the developers report continuously what they notice: an ambiguous specification, an unforeseen technical constraint, a risk to the schedule. This feedback is handled straight away, through the product owner, instead of piling up until the end. The product owner then validates each batch delivered by the technical team before it is presented to the client.

6. Delivery to pre-production and functional acceptance

Each batch is delivered to a pre-production environment, separate from production, where the nature of the project allows it. The client carries out functional acceptance there, following the test plan. The anomalies they report are classified by mutual agreement:

• blocking: an essential feature is unusable and there is no workaround;
• major: a feature is degraded, but a workaround exists;
• minor: no significant effect on use (display, wording).

Blocking and major anomalies are fixed and redelivered for a new check. Minor anomalies can be recorded as reservations, lifted afterwards. Acceptance is formalised by a report: pronounced without reservation, with minor reservations, or refused.

7. Final sign-off, payment and go-live

The client’s final sign-off closes the implementation phase. It triggers payment of the balance and the go-live, on an agreed date, after a backup of what already exists. Source code, documentation and administration access are handed to the client. Domain names, hosting and third-party accounts are taken out in the client’s name, and the client remains the holder. Payment terms are set out in the quote and the contract; amounts depend on each project and are established on a quote basis.

8. And after delivery?

• Out-of-scope fixes: a request outside the validated scope is not an anomaly. It is priced in a supplementary quote or formalised in an amendment that states what is added, changed or removed, and the effect on price and schedule. A broader need leads to a new contract.
• New features and later versions: they follow the same cycle, starting from the existing product.
• Long-term maintenance: a recurring services contract describes precisely what is subscribed to: corrective maintenance, security updates, backups, monitoring, hosting and domain name management, search visibility follow-up, small enhancements. An initial inventory sets what is taken over.

Without a recurring services contract, security updates and monitoring of the product remain the client’s responsibility. I always state this at acceptance, so that a site does not age with nobody looking after it.

The documents that mark out the project

Document	What it is for
Quote	Describe the service, the steps, the billing method and the conditions, before any commitment
Delivery contract	Frame a development or automation project: purpose, specifications, schedule, acceptance, intellectual property
Amendment	Change a contract in progress: scope, schedule, price
Recurring services contract	Organise maintenance and follow-up after go-live

How I can step in

A project does not have to be entrusted in full. I can work:

• upstream only: needs analysis, specifications, acceptance test plan, possibly so that you then hand the implementation to another team;
• on implementation from specifications you already have;
• on acceptance and supplier follow-up, to check that what is delivered matches what was requested;
• on the whole cycle, from the vague need to maintenance.

In every case the same principle applies: a written scope, traced validations and a clear criterion for saying the work is done. My way of working is also presented on the how I work page.