Software makes a process faster and more consistent. It does not make it correct. If approvals currently take four handoffs because of an old reporting structure, automating them gives you four automated handoffs, permanently encoded in code that is now expensive to change.
Map what happens, not what is supposed to happen
Current-state mapping done in a conference room produces the official version of the process. Current-state mapping done by watching produces the real one – including the spreadsheet someone maintains privately because the system cannot do what the job requires. The workaround is not a failure of discipline; it is a requirement in disguise.
Redesign before you encode
Target-state design means fewer steps, clearer ownership, and faster handoffs, with each change tied to an outcome you can measure. Then it gets a RACI matrix so responsibility is unambiguous, and plain-language SOPs so a new hire can follow it without a mentor. Only then is it worth building.
Plan for resistance, because it is predictable
Teams resist new software when it makes their day harder before it makes it easier, or when nobody explained why. That is a schedule problem, not an attitude problem: communication sequence, training, a pilot group, and a feedback loop that visibly changes something. Adoption is designed, not hoped for.
We run process consulting in parallel with the build – typically six to eight weeks – with a 30-day post-launch review to confirm the redesign survived contact with reality. It is the layer most software firms skip, and the reason projects deliver results instead of deliverables.