Software Selection for Small Businesses: A Mechanism-First Approach
At TRS Planning, we specialize in helping small businesses scale their processes, generate more revenue, increase transparency, and reduce manual tasks. We often help business owners design, deploy, and operate solutions that enable them to do more work without hiring more people.
One common issue we’ve observed across businesses of all sizes is the selection, deployment, and operation of software.
The Rush to Software Solutions
In many cases, business leaders know that they have a problem and assume that a software product will solve that problem.
Some common problem statements that we hear are:
- “We need something to help us get organized.”
- “Spreadsheets aren’t working for us anymore.”
- “As a business owner, I need to be able to see what my team is working on so I can help move things forward when they get stuck.”
- “I think we’re too busy doing things that don’t generate revenue…”
- “Our reputation with customers is at risk when we are late.”
One reflexive response is for business owners to look for software to deal with one or more of the problem statements mentioned above.
But, the rush to a software solution to solve problems often results in additional cost, lost productivity, and frustration.
Many times, small business owners will consult with other business owners and ask them “What software do you use to stay organized?” They’ll read reviews – and hopefully blogs like this one – to find out what products are available. They might even schedule demonstrations with product sales teams to preview the capabilities of different tools.
We have observed, however, that many clients are operating processes that cannot be improved by simply installing project management or collaborative workflow software. So, when they jump to the decision to purchase a software solution, they later observe a mismatch between their expectations and the actual results.
The Features Comparison-Based Approach
Other companies take a slightly different approach to software selection by adopting a “features comparison” approach. This is also referred to as “requirements-based” approach. They generally begin with the same unvalidated assumption as the “Rush to Software” approach:
“We need a software solution to help address [insert problem(s) here].”
Instead of defining and measuring the OUTCOMES of their processes, these small business owners often compare software features among different products. Many of these product features include interactive, cloud-based status reporting dashboards, resource management, or API integrations with their core business systems (Slack, Quickbooks, Salesforce, Goolge drive or Sharepoint).
Often, they come to us and say:
“We recently bought [insert software product here] – we just need a little help getting it set up…”
While the features-based approach is an improvement over the rush to a software solution approach, underlying process issues are often not addressed.
Don’t get me wrong, software features and requirements SHOULD be considered when selecting any tool. But, tooling requirements and features are only part of delivering work efficiently…
The Mechanism-First Approach
At TRS Planning, we believe in a different approach. We advocate for designing “Amazon-like” mechanisms first. A mechanism is defined as a complete, end-to-end process that reinforces and improves itself as it operates.
Building a mechanism starts with clearly defining the business challenge – in one sentence. And, If you have 2 sentences, you probably have 2 challenges…
After we concisely define the business challenge in one sentence, we work backwards (from RIGHT to LEFT in the Figure 1 below) to understand the desired outputs. And, we make sure that the outputs can be produced by the combination of:
- A tool (the tool could be excel, Google sheets, OR a project management or collaborative workflow solution – it might even be a “home brew” solution they build)
- User adoption (that is, the people doing the delivery work)
- Inspection (usually a “process owner,” that is, someone who will keep an eye on everything, from start to finish, intervene when necessary, and sound the alarm when things aren’t working)
Next, we take into account the inputs that will be transformed by the tool, users, and owner, to deliver the outcomes that meet the business challenge.
Finally, we spend time thinking about HOW we will iterate and improve the mechanism to better deliver the desired outcomes.
We didn’t invent mechanisms at TRS Planning, but we’re good at designing and deploying them.
Figure 1: Depiction of a Mechanism
Ugh…
All this sounds like a lot of work to simply “plug and play” industry standard software that everyone’s using, doesn’t it?
It’s actually not that much work. In fact, we can usually go through our standard list of 25 questions to provide the basis for our design in a 2-3 hours.
Client Case Study: Contractor Onboarding
At TRS Planning we deploy a systematic approach to designing mechanisms. What follows is a step-by-step case study of how we designed a contractor onboarding mechanism as a Proof of Concept (POC) for one of our clients.
- STEP 1: Clearly state the Business Challenge The first step was to clearly define the business challenge that needed to be addressed. We summarized our client’s business challenge in this one sentence:
“We need an intuitive and frictionless contractor onboarding process that reduces our Time to Productivity (TTP) to 4 days.”
- STEP 2: Define the Desired Outputs We identified what the desired outputs of the mechanism would be for our POC. Measuring TTP is relatively easy and standard. But, how would we know if our mechanism was “intuitive” and “frictionless?” We decided that the following measurable outputs would indicate our mechanism’s success at meeting the business challenge.
- Contractors gain access to five (5) core business systems
- Three (3) one-on-one intro calls with named company leaders are completed
- Six (6) one hour initial company training modules are completed
- Four (4) onboarding documents are signed and stored in the HRIS
- Post-onboarding questionnaire is delivered and completed with a calculated score equal to or greater than 4.35; and no individual questionnaire response is lower than 3 (using a Likert scale of 1-5)
- STEP 3: Select the Tool We needed to recommend a tool for our clients to use. Their existing tool was a Google document that functioned as a checklist. We didn’t believe we could enhance that Google document to deliver automated reports on the measurable outputs that they wanted. But, we also knew that our client was using another very common collaborative workflow tool for 2 existing processes: Trello.
We determined that Trello could track and report on the required outputs. We also knew that we could leverage Trello’s “out of the box” automation to reduce manual tasks. And, since it was already in use by our client, this permitted us to avoid additional software costs.
Last, we hypothesized that leveraging an existing tool would help with our next step in designing the mechanism: user adoption.
- STEP 4: User Adoption: A tool will only be effective if it is adopted by the users. Training is one key element to ensure adoption. But, there are other “levers” that we can pull and push to increase adoption.
Since our client’s team for whom we were designing this contractor onboarding mechanism was familiar with Trello, we assumed that we wouldn’t need to train them on the Trello basics. To validate this assumption, we proposed a handful of metrics related to delayed tasks, unassigned tasks, and “stale” tasks.
In the midst of designing our client’s contractor onboarding mechanism, we identified another distinct business challenge that caused us to recommend the establishment of an Operational Framework to solve a Trello data problem: Inconsistent data entry and task assignment in Trello. We theorized that, If implemented, a Trello Operational Framework would support the client’s contractor onboarding mechanism. We spun this off into a supporting effort.
For the onboarding contractors, however, Trello training would need to be added to a newly created training module. This new training module would need to be added to the company’s LMS and it would form the sixth module in the initial onboarding training package.
Finally, we theorized that transparent and company-wide accessibility to reporting would increase adoption by engendering self-policing behaviors while also allowing the mechanism owner to easily inspect reports as it operated.
- STEP 5: Assign an Inspector/Owner: Assigning someone to inspect the outputs and reports of the mechanism is a key component of the mechanisms we build. In any organization the diffusion of responsibility can often put efficiency and desired outcomes at risk.
In our client’s small firm, the HR function was traditionally owned by the firm’s owner. But, when we designed the contractor onboarding mechanism, we recommended the firm assign ownership to the operations manager. We made this recommendation based upon the anecdotal evidence we uncovered during interviews of recently onboarded contractors and key leaders in the company.
Our hypothesis was that the firm owner’s skill-set and interest was focused revenue-generating business functions such as sales and business development. And, since the operations manager was incentivized to get the contractors onboarded within 4 days, their assignment as the inspector/owner made sense.
- STEP 6: Define the inputs The next step was to think about and define the onboarding mechanism’s inputs. We knew that the client leveraged a Google sheet as an Applicant Tracking System (ATS). That Google sheet contained most of the inputs we needed: contractor name, start date, contact information, etc.
By leveraging some free software that ran on that Google sheet, we were able to trigger a process that exported that contractor data to a task in Trello. And that Trello task, in turn, triggered the start of the onboarding mechanism.
- STEP 7: Iterate and Improve: Finally, we needed to ensure that everyone who had a hand in the mechanism – the owner, the staff operating it, and the new contractors – were provided with an easy way to report on the inevitable defects that arise with any newly deployed process.
We designed a simple way for anyone to report process or tooling defects. The defects were to be reviewed, on a schedule, by the designated inspector, who could then determine if those defects were inhibiting the mechanism. If those defects were deemed a priority, the inspector would transition those defects into the organization’s existing Trello operational workflow.
We also designed automated reporting that enabled the mechanism’s owner to make frequent inspections. We designed these reports to be delivered at various times during the onboarding process. And, of course, at the end, too.
Conclusion
By taking a mechanism-first approach, businesses can ensure that they select and deploy software solutions that truly meet their needs. Instead of rushing to a solution or choosing software based on a checklist of features, consider asking us to help you design your mechanisms so that they meet your business challenges.
Reach out to us. We’re ready to help.
A special thanks goes out to David Delk of Delk Consulting who suggested that I generate this blog post.