Organisation
Organisation means putting it in writing before building: how you actually work, what the project needs to achieve, what already exists. You know what you're ordering; whoever builds knows what they have to deliver.
When people call us
- You have to get quotes from suppliers and there's no written brief.
- "Nothing is documented: it's all in one person's head."
- Three tools do the same thing, each in its own way, and nobody has decided which one is authoritative.
- An earlier project delivered something other than what you expected.
- You're changing tools, and nobody can describe what the old one actually does.
- You're being asked for written procedures, for a certification, a buyout or an inspection, and nobody has ever written them down.
What we do
Specifications. The document saying what’s to be achieved, for whom, within what constraints. It’s the heart of this area: a specification precise enough to be costed, compared, then carried out, by us or by someone else. You stay free to choose. For a website, that document is the requirements document: it decides what every quote will cost.
Process mapping. Who does what, with which tool, in what order, and where it gets stuck. We describe the work as actually done, not the theoretical version: it’s the gap between the two that derails projects.
Processes and rules of use. Once the work is understood, putting it in order: who does what, where the data lives, what gets validated and how. Short rules you can actually apply, not a folder nobody opens.
Documentation. Of what exists, of the choices made, of the procedures. Including taking over a system nobody ever documented: we read what’s there and we write it down, so the knowledge stays in the company rather than in one head. It is also what makes a reversibility clause work: you only get back cleanly what was written down.
Client-side project support. When the work is handed to others, we stay on your side of the table: writing the tender documents, comparing the quotes you receive, and following the work through to delivery.
Code has become the cheapest and least risky part of a project. What’s expensive is building the wrong thing, and that’s exactly what this work prevents. What a website costs is decided there too: by what you ask of the site, before you choose who builds it. The specifications are written by the people who carry them out: every line can be costed, none of it rests on guesswork.
Examples of deliverables
- Specifications written so that someone else can carry them out: what's to be achieved, for whom, within what constraints.
- A map of the processes: who does what, with which tool, and where it gets stuck.
- Written rules of use: where the data lives, who validates what, which tool is authoritative.
- Documentation of what exists: taken over, completed, or written from scratch.
- Step-by-step procedures, written to be followed without their author.
- Tender documents ready to send, if the work is carried out by others.
- A comparative analysis of the replies received: what each quote covers, what it leaves out, and a recommendation.
Questions
How do you price a set of specifications?
It depends on what you want to achieve, and that’s exactly the first thing we talk about. We talk, we scope, and you receive a quote that binds us, not an estimate that will move three times.
What we can say straight away: we’re not the cheapest option, and that’s not what we’re trying to be.
Does a written brief with you always end in the work that goes with it?
No. We will tell you what we see, that’s the minimum, but the order of priorities stays yours, and “nothing for now” is a valid answer.
Most of our engagements widen over time; none begins with an obligation. The website audit, as it happens, is ordered online without talking to us, and the action plan that comes with it is written to be carried out by whoever you choose.
You write the specifications and can build afterwards: isn't that a conflict of interest?
The question is fair, and here is how we answer it.
First, an audit concluding “what you have holds up, leave it alone” is a normal deliverable here, not a failure. Next, we have no technology to push: we resell no licences and we’re affiliated with no vendor, so nothing pushes us towards one solution rather than another. Finally, a scoping exercise can be used to get quotes elsewhere: the specifications are yours, and they are written so that someone else can carry them out.
We only need the specifications written. Do you take on that kind of work?
Yes, and it’s actually the most common case. A fix, a migration, an audit, a feature: we take it.
The whole chain is what we can do, not what we require. The only difference from someone who does nothing else is that we will tell you if the problem you report actually lies elsewhere.
Who will actually write our specifications?
The same person you’re talking to now.
Ask it every time, our competitors included: in many firms the person who sells isn’t the person who produces, and you will never meet the second. It’s the first of the questions to ask every supplier before you sign a quote.
How long does a set of specifications take?
Faster than you’re used to. A brochure site takes a matter of weeks. So does a full rebuild, most of the time.
The limiting factor is almost always how quickly decisions and content come from your side, not production.
Guides in this area
Tell us about your project, or your problem.
Describe your situation in a few lines, however it comes to you. You get our first take, in writing: what we understand, what we would do, where to start. Not an automatic acknowledgement, and no sales follow-up: an answer you can use, even if it stops there.