Software can make a real task look solved long before the work is actually working.
That is the trap I ran into at Northpoint. We had implemented a system that could have supported our accounting, but we had not adapted our work to use it that way. Residents, owners, and teammates still experienced the company through old habits, side systems, and spreadsheets. We had changed the software under the company without changing much about how the company worked.
The question was no longer just whether the system had the right feature. It was whether we understood the job well enough to build the work around it.
That changed my question. Instead of asking, “How do we get more out of the system we already have?” I began asking: What has to be true about our organization for this technology to actually work?
A feature does not change the work by itself
A software demonstration can make a feature look simple. It can show a request being entered, a task being assigned, or a report being created.
The evaluation also has to account for the work between tools and people. In our technology consolidation, I looked at handoffs, the cost of connecting systems, and whether we could see enough of the work to support the team. That did not mean every specialized tool had to go. A separate product may do a particular job well enough to justify its extra handoff, training, and support burden. The question is whether that tradeoff helps this operation deliver the result it needs.
The harder question is what happens after that screen. Does the right person know the task is theirs? Do they have the information they need? What happens when the normal path breaks? Can someone see the problem before an owner, resident, or vendor has to chase it down?
The system may be capable of the work. Your company may still need clearer decisions, better information, training, or a different process before people can use that capability well.
Watch the work before you automate it
I used to ask for the process document. Now my first question is whether we have watched someone do the work.
People can describe a process clearly in a meeting and still leave out the parts that make it work. The exception that needs a manager. The decision someone makes from experience. The spreadsheet they check before they move to the next step. The message they send because the system does not tell the next person what changed.
Those details are not proof that a system has failed. They are clues. They tell you what needs to be understood before you automate, remove, or redesign anything.
For one important task, watch the normal path and one situation that commonly goes wrong. Ask the person doing the work to explain what they look for, who they involve, and how they know the task is complete. You will usually learn more from that than from a feature list.
Ask what job the workaround is doing
Spreadsheets and side systems can be frustrating. My first instinct was to get rid of them.
Some of them needed to go. Some existed because people had not been trained on the core system, or because an old habit had survived a change. But some were filling a real gap in how we had designed the work.
Deleting a workaround before understanding it can remove a capability instead of removing complexity.
Before you remove one, ask a plain question: What job is this doing that our intended system is not?
The answer may be a missing setting, a training need, a better process, or a legitimate reason to keep a separate tool. The point is to learn the reason before deciding what to do with it.
Make the first move small enough to learn from it
Big changes create a lot of pressure to defend the original plan. A small, real test creates room to see what happens and adjust.
Pick one meaningful use. Put it into operation with the people who will actually use it. Watch what changes. Compare what happened with what you expected. Then decide whether to adjust it, expand it, or stop.
That does not remove risk. It keeps one wrong assumption from becoming a company-wide problem before you have had a chance to learn from it.
Bring the right questions to the demo
You do not need a formal procurement process to have a useful conversation about a new tool. Bring one piece of work, ask to see the normal task and one real exception, write down what you actually saw, and choose the next small test.
The Bring This to the Demo note is a short worksheet for doing that. It helps you keep the conversation tied to the work your team needs to do, rather than the feature that looked best in the demo.
Supporting sources
- Year One, Episode 2, We Cut 14 Software Tools Down to 1 — I discuss my experience weighing handoffs, implementation tradeoffs, and cases where a specialized tool may remain the better fit.
- Year One, Episode 5, Property Meld to AppFolio: The Hardest Maintenance Migration — I discuss my experience choosing a system and then helping the team use it.