Find the process
you actually run.
Two weeks inside one workflow, sitting with the people who perform it. Not the version in the process document. The version with the spreadsheet, the chat-thread chase, and the step nobody owns. It ends with a costed backlog and a working prototype.
Every failed software project
started with a wrong map.
Not bad engineering. A wrong picture of the work. Somebody built to the documented process, shipped it, and discovered on day one that six real steps had no home in the new system. So the spreadsheet came back, and now you have two systems instead of one.
What everyone else maps
- Interviews with managers, who describe the intended process
- The existing process documentation, written once and never revised
- Screens from the current system, which show only what it supports
- A requirements list assembled in a workshop
What we map
- Sessions with the people who actually perform the steps, at their desk
- The shadow tools: spreadsheets, inboxes, chat threads, sticky notes
- Real timing and real volumes, measured rather than estimated
- The exceptions, because exceptions are where the cost lives
Four phases. No workshops.
Observe
We sit with the people doing the work and watch a real run, end to end. Every hop between systems gets recorded. Every "oh, and then I usually just…" gets written down, because that sentence is where the project actually is.
Cost it
Each step gets a time, a frequency, an error rate, and a person. Then it gets a number. This is the part that turns "this is annoying" into "this detour costs $84,000 a year," which is the sentence that unlocks a budget.
Check the plumbing
Can a system actually read your systems of record? Who grants access, and how long does it take? Where does the data go stale? Most plans die quietly here, so we surface it now rather than in week six of a build.
Prototype one thing
We take the highest-value candidate and build it against your real data. Opinions are cheap and a running system is not. You get to click on the thing before deciding whether to fund the thing.
A ranked backlog, not a report.
Here is the shape of what lands in your inbox on day fourteen. Every row has a cost, a verdict, and a price. Notice that not every row says build.
Sometimes the answer is
“don't hire us for this.”
Roughly a third of what we map should be a database rule, a config change, a better form, or a deleted step. When that is the answer, we write it down, hand it over, and stop. You keep the map, the costing, and the prototype.
Why we do this
Because a build sold onto a bad diagnosis fails in month six, and the failure has our name on it. A Map that talks you out of a project protects both of us. It also happens to be the cheapest marketing we run.
What it costs you to find out
Two weeks and one fixed fee, credited in full against a build started within 90 days. Compare that to the cost of discovering the same thing in month four of a six-figure project.
Map questions.
How much of our team's time does this take?
Roughly six to eight hours total, spread across two weeks, mostly from the two or three people who actually perform the workflow. We work around their day rather than pulling them into workshops. Executive time is one kickoff and one readout.
Can we do a Map on more than one workflow?
You can, but we would rather you didn't at first. One workflow mapped properly beats three mapped shallowly, and the first one teaches us enough about your systems that the second is faster and cheaper.
What if we already know what we want built?
Then say so and we will quote the build directly. We are not going to insist on a Map you do not need. That said, if the requirement came from a manager rather than from watching the work, a Map usually changes the scope, and it is a lot cheaper to change scope before the sprint than during it.
Do you need access to our systems?
Read-only access to the relevant systems helps a great deal for the costing and prototype phases, and we will sign whatever your security team requires first. If access is genuinely impossible, we can work from exports and screen sessions, but the prototype gets weaker.
What happens to the prototype if we don't proceed?
It is yours. Source in your repository, documentation included. It is usually rough, because two weeks is two weeks, but it runs and it is honest about what it does.
Pick the workflow that annoys you most.
That instinct is usually right. Tell us which one and we will scope a Map sprint, with a fixed price back in your inbox inside 48 hours.