Understand the work.
We start with the people who will use the software. What are they trying to do, what information do they need and where do they get stuck? Existing systems and ways of working belong in that conversation.
HOW WE WORK
From the first agreement to everyday use.
We build your software and keep it running. We start by understanding the work, agreeing what the software needs to do and discussing what will be needed after delivery.
Agree what the software should do.
We describe the expected behaviour in plain language, including exceptions and the boundaries of the engagement. You can help shape the solution without first having to write a technical specification.
Build and assess.
We build the solution and discuss with you how to assess the result. The agreed situations, observations and limits of the assessment make clear what you are looking at.
Run and develop further.
We run the software we build. Use, changes and responsibilities therefore belong in the conversation from the start.
FROM ABSTRACT TO CONCRETE
“What should happen when the usual path doesn’t work?”
Read about verificationUnderstand the work
Behind every feature is a question about the work.
‘We need a dashboard’ sounds like a clear brief. It still leaves one question unanswered: what decision does someone need to make with it?
Who is waiting for information today? What do they do when something is missing? What happens if a decision arrives a day late? These questions reveal the problem the software needs to solve and the change that would matter.
An existing form, a blank job sheet or an account of a difficult handover can be enough to start. People doing the work often know exceptions that never made it into the process document. Both perspectives belong in the conversation.
What we mean by MSP+
The partnership continues beyond the first version.
We only build software that we also run afterwards. We call that combination MSP+: development and operations with one partner.
Your software becomes part of everyday work. People start using it, questions change and new needs emerge. That is why use and operation belong in the conversation during development. We consider what you need now and how you can move forward afterwards.
Before we start, the agreement sets out exactly which parts we run, when we can be reached and what happens if you stop. Dependencies and documentation are part of it too.
An illustrative work situation
The job is marked complete. Is the work actually finished?
Someone marks the job as complete. Scheduling needs to move on, but the office still lacks information. The ‘Complete’ button turns out to contain several different agreements.
The usual path
What information must be present before the job is finished? Who can make that decision, and who needs to know?
The exception
What happens if materials are missing or the customer cannot be reached? Distinguish completed work from paused work and work waiting on someone else.
The boundary
Does this first step also need to change invoicing, or will that remain in the existing system for now? A clear boundary prevents one question quietly becoming an entire project.
This fictional situation makes the questions concrete. It is not a customer case or a software demonstration.
From conversation to agreement
Make the choices visible before moving ahead.
A shared understanding of the process is the starting point. Its boundaries and responsibilities deserve as much attention as the features you want.
What belongs in the first step?
Name the work that needs to improve, the people involved and the situations that remain outside the scope. Keep the first step specific enough to discuss.
Who decides the open questions?
Some decisions concern technology; others concern policy or everyday working agreements. Identify who can answer each question and which decisions are still missing.
What will help you assess the result?
Discuss the examples, outcomes and conditions that matter. A screen that looks right does not answer every question about the process.
What happens after the first version?
Changes, operation, handover and responsibilities belong in the conversation. The actual arrangements need to fit the engagement and the organisation.
QUESTIONS & ANSWERS
Useful to know before you start.
Do we need a requirements document already?
An existing document helps you trace decisions, but a concrete process question is a useful starting point too. Describe what happens now, who is involved and what needs to change. You do not need to have resolved every open question.
What if the process changes during development?
Make the change explicit: which rule changes, for which situations and from when? Consider work already in progress too. The effect on scope, timing and cost then needs a separate agreement.
Does our existing software have to be replaced?
A custom software question does not automatically imply replacement. The difficulty may sit in one missing step or handover. First establish what existing systems can do, what integration is possible and where the real limitation lies.
A GOOD START
Where does work get stuck?
Start with one situation.Get in touch