A familiar pattern: a team is frustrated because requests get lost, reports take days, and nobody can see where anything stands. Someone proposes a new platform. Six months and a significant budget later, the team is using the new system alongside the old spreadsheets, and the original frustration is still there, now with a license fee attached.
The software was rarely the problem. The purchase was made before anyone agreed on how the work should run. A tool can only automate a process that exists. If the process is informal, inconsistent, or disputed, the tool inherits all of that and adds configuration on top.
Why the tool gets blamed
When a system underdelivers, the review usually points to adoption, training, or the vendor. Look closer and you tend to find three earlier gaps.
- No shared picture of the current process. Different teams described the work differently during requirements, and the vendor configured to whichever description was loudest.
- Requirements written as features instead of outcomes. "Needs a dashboard" is a feature. "The operations lead needs to see every request older than five days, by owner, every Monday" is an outcome a system can be tested against.
- No owner for the process after go-live. The project team disbanded, and nobody had authority to change the workflow when it needed adjusting.
Each of these is an operating problem, and each can be addressed before a contract is signed.
Start with how work actually moves
Map the process as it runs today, not as the procedure document says it runs. The most useful map comes from walking a few real items through from start to finish: a request, an approval, a monthly report. For each step, note who touches it, what information they need, where it waits, and what they do when something is missing.
Three things usually surface quickly. The first is waiting. In most processes the work itself takes a small fraction of the elapsed time, and the rest is items sitting in a queue or an inbox. The second is workarounds: the side spreadsheet, the standing phone call, the person everyone knows to ask. Workarounds are evidence of exactly where the formal process fails. The third is decision points nobody owns, where an item stalls because two people each assume the other will act.
Workarounds mark the places where the formal process stopped working.
Fix what does not need software
A good share of what a map reveals can be fixed without a new system: one intake point instead of five, a clear rule for who approves what, a folder structure people actually follow, a fifteen-minute weekly review of aging items. These changes cost little, take effect quickly, and make the remaining requirements much sharper.
They also often reveal that existing tools can do more than the team is asking of them. Many organizations already pay for platforms with workflow, forms, and reporting features that were never configured.
Then write requirements a vendor can be held to
Once the process is agreed, requirements can get specific. Instead of listing features, describe the scenarios the system has to handle, the people who will use it, the data it needs to hold, and the reports leadership will rely on. Include volumes and exceptions: the rush request, the item that needs two approvals, the record that has to be kept for seven years.
Specific requirements do two things. They make vendor comparisons meaningful, because every vendor demonstrates against the same scenarios. And they give you acceptance criteria, so the project is finished when the system handles the agreed scenarios, not when the vendor declares it live.
Name the owner before go-live
Every process needs someone with the authority to change it. Before launch, decide who owns the workflow, who can approve configuration changes, and how issues get raised and resolved. Put reviews on the calendar at thirty and ninety days. The first weeks of real use will show where the design was wrong, and an owner with authority can fix it before workarounds take hold again.
A short checklist before you sign
- Can two people from different teams describe the current process the same way?
- Have you walked real items through it and seen where they wait?
- Have you fixed the problems that do not require software?
- Are requirements written as scenarios, with volumes and exceptions?
- Is there a named owner for the process after launch?
If the answer to any of these is no, the purchase can usually wait a few weeks. Those weeks tend to produce the best return on the whole project.