You don’t need a specification or the right technical words to start a software project. Bring us the work, the awkward bit and a rough idea of better. We can work through the questions together.
It is easy to put off talking about a software project until you can explain it properly. There are too many spreadsheets to describe, the process has several exceptions, and half of the useful detail lives in somebody’s head.
That is a perfectly reasonable place to start. The first conversation helps us understand the work and decide what is worth looking at more closely. A few honest examples are useful.
Bring one ordinary job
Choose something that happens regularly and follow it from beginning to end. An enquiry becoming a booking. An equipment request being approved. A paper inspection turning into a report.
Explain it as you would to someone joining the team:
What starts the job, and who picks it up?
What information is needed, and where does it come from?
Who else gets involved before it is finished?
How does everyone know what has happened?
A blank form, a sketch or a screenshot with private details removed can help. You do not need to catalogue every file before we speak.
Point out the workarounds
Show us the extra steps that keep things moving: the second list, the reminder email, the printed sheet carried between rooms, or the person who checks everything at the end of the day.
Those workarounds usually exist for a reason. They can reveal a missing step, an important business rule or something the current system makes difficult.
Include an exception as well as the ordinary route. What happens when a customer changes their mind, a job is cancelled or someone is away? The awkward cases often tell us where useful software could make the biggest difference.
Describe a better working day
“We want to see which jobs are waiting for approval without asking three people” gives us something concrete to work towards.
So does “we want to enter a customer’s details once” or “the person on site needs the latest job notes”. Explain what would become easier, faster or more dependable for the people doing the work.
If there are several frustrations, choose the one you would most like to stop dealing with. That gives the conversation a useful starting point.
Tell us who will use it, and where
An office team, a person visiting customers and someone approving work from home may need different ways into the same information.
Tell us about the computers and devices people already use, including Windows or macOS, phones and tablets. Mention unreliable internet access, shared devices and anyone who should only see part of the information.
Bring the names of the tools the process needs to work alongside. Existing spreadsheets, databases, accounts software and websites may all have a part to play. We can then explore whether a desktop application, mobile app, web application or a connection between existing tools would suit the work.
Share the practical limits
If there is a target date, explain what is driving it. A new contract starting, a busy season or an old system being retired will affect the choices.
A budget range is useful if you have one. If you are still working it out, say so. It helps to know which improvements matter most and which could wait.
Mention the things that must keep working during a change: reports people rely on, information that needs to be retained and times when the team cannot manage disruption. A useful plan makes room for those realities.
Agree what should happen first
The first useful step might be improving one part of the process, trying an existing tool or exploring a small piece of new software. Keep the parts that already work in view.
Before committing to a wider build, we should be clear about the problem being addressed, who needs to be involved, what remains uncertain and how we would judge whether an improvement helps.
For an initial enquiry, describe the records you use. Please leave out passwords and live customer information. A blank form or a made-up example is usually enough to explain the work; we can agree how to share anything more detailed if needed.
One useful page is plenty
If you like something to fill in, start with these six prompts. A sentence or two for each is enough, and gaps are fine.
The job: what are we trying to get done?
The people: who does it, and where do they work?
The current tools: what do we use today?
The awkward bit: what gets copied, checked, delayed or chased?
Better would mean: what would we like to be easier?
The practical limits: what should we know about timing, budget and disruption?
Our practical software examples may help you put a name to the problem. When you are ready, tell us about your project. You can start with the rough version.
