Organisation
Organisation means putting it in writing before building: how you actually work, what the project has to do, 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, under what constraint. It’s the heart of this topic: a specification precise enough to be costed, compared, then carried out, by us or by someone else. You stay free to choose.
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 binder nobody opens.
Documentation. Of what exists, of the choices made, of the procedures. Including picking up 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.
Client-side project support. When the work is handed to others, we stay on your side of the table: writing the tender pack, comparing the replies, 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 topic prevents. The specifications are written by the people who carry them out: every line can be costed, none of it rests on a hypothesis.
Examples of deliverables
- Specifications written so that someone else can carry them out: what's to be achieved, for whom, under what constraint.
- 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: picked up, completed or created.
- Step-by-step procedures, written to be followed without their author.
- A tender pack 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 leave with an estimate that binds us, not an order of magnitude 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’s written to be carried out by whoever you choose.
You write the specifications and you can build afterwards: are you not judge and jury?
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 a written brief. Do you take that kind of work?
Yes, and it’s in fact the most frequent 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 with someone who would do nothing else is that we will tell you if the problem you report comes from elsewhere.
Who will actually write our specifications?
The same person you’re talking to now.
This is the question to ask every time, including our competitors: in many firms the person who sells isn’t the person who produces, and you will never meet the second.
How long does a set of specifications take?
Faster than you’re used to. A brochure site is counted in weeks. A full rebuild too, most of the time.
The limiting factor is almost always the availability of decisions and content on your side, not the production.
Tell us about your project, or your problem.
Describe your situation in a few lines, however it comes to you. You get a first reading 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.