Four steps, and the last one is where projects die.
Most of what follows is unremarkable. The part worth reading is step four, because it is the one that gets cut when a budget tightens, and it is the one that decides whether any of the rest of it mattered.
What an engagement actually looks like
I come and look
The first visit is not a pitch. I spend it with the people who actually do the job, because that is where you find out how a business really runs as opposed to how the org chart says it does. The owner knows what the business is supposed to do. The person who has done the same task every day for fifteen years knows what it actually does.
I show you what I found
You get a plain-language account of where the work is getting stuck and what it is costing, in the order I would fix it. Some of what surfaces is not a software problem at all. You will hear about that too, because a recommendation you cannot check is not worth much.
I agree what is worth doing
Not everything found is worth fixing, and the order matters more than the list. I pick the smallest piece that proves the approach, and I tell you what I think it is worth before you commit to the rest of it.
I build it, and I stay
The same person who sat with your dispatcher writes the code. Then comes the part most projects skip: rollout, training, and the weeks afterward where people either adopt the thing or quietly go back to the spreadsheet. A system no one uses is not a delivered system.
Worth fixing and worth building are different questions
Plenty of what turns up in discovery is worth fixing. Much less of it is worth building software for. A tool you already pay for that no one configured will close a gap this month; a custom module for the same gap closes it next quarter and then needs looking after for a decade.
So the plan you get separates the two, and it says which is which before you have spent anything.
I'll tell you when the answer is don't build it.
A consultant who only works in one technology will recommend that technology every time, because it is the only recommendation he can deliver. Not being limited that way is what makes "don't build it" something I can actually say to you rather than a line on a website.
It costs me the project. It is also the reason the two engagements on this site have run seven years each.
The engagement does not end at delivery, because that is not where the risk is.
I have watched a well-built system go quiet because the person who championed it moved on and no one inherited the job of making sure it was used. That is written up in full in the second case study, including my share of it. It is the reason I now stay through the weeks after go-live rather than handing over a login and an invoice.