Deep Dive: Tech Implementations in Clubs

Deep Dive

As a reminder, each week you’ll receive The Shortlist - five quick, relevant stories and every other week, a Deep Dive like this one.

By Tahoe Lillelund

Every day I work on implementation projects to set up the databases for my clients. With over 60 successful go lives, here is what I have learned.

I am going to break this down based on the three lessons. The goals of the project should be achievable and in a timely manner. It’s very important for the client to do their due diligence to make sure the software can properly achieve their desired requirements in the way they want them done. No software is perfect, so you will lose some functionalities you are used to, but hopefully you gain features where it matters most.

Business Analysis: The Step Everyone Underestimates

This is the project analysis and should be taken very seriously. The work and details you do at the beginning of the project will determine your process going forward. It’s important to have the necessary stakeholders who will be in charge of the project attending the kickoff call. From the client/customers side you should have the key decision maker (founder/CEO) and the SPOC (single point of contact). The SPOC will be the person on the client’s side who is in charge of detailing all the requirements, gathering data, and all the internal resources needed for the project. It doesn’t need to be one singular person, but the fewer the people the better in order to increase speed and efficiency. There should be a defined objective, scope, and timeline at the end of the business analyst. The objective could be something like “I currently use spreadsheets for all my business work, but I want to move to an ERP to make it easier for myself and the team.” The scope is going to be the details of what the project will look like, this is what the project will be achieving. For example, I want to implement Inventory, sales, CRM, purchasing, and website. These are all the requirements that need to be achieved by the software. 

The SPOC needs to have knowledge of how the business runs, ability to make key decisions, be the change manager inside their organization, and have access to all the necessary resources or information. 

On the software side, there should be a Business Analyst (BSA) and often a Project Manager (PM). The PM keeps the project organized, tracks the bigger picture, and makes sure the build stays aligned with the scope. When only one person handles everything, it is easy for them to get buried in details and lose sight of the overall goal.

For the client, the Business Analysis phase can feel slow, but that is the point. This is where you identify how your business actually works, what needs to change, and where your current systems fall short. Most companies benefit from this exercise even outside of an implementation, because it forces them to look closely at their process and uncover inefficiencies.

The Process

The repeatable process I have learned to run is a combination of Agile methodology and the quickstart methodology. What does that mean? Running an efficient implementation process with a clear start, middle, and end. As we talked about in the section above, the business analysis is where you define what the scope of the project will be.

The best way I’ve ever heard this explained is the “skateboard analogy.” If your current software is your house and your new system is the school you want to get to, the ideal way to travel is by car. But building a car takes time, resources, and a lot of decisions. You don’t start with the fully finished version; you start with something that moves.

That’s the Minimum Viable Product (MVP): the skateboard.

In software implementations, the goal is to get something usable into your team’s hands as quickly as possible. Early usage creates familiarity, raises better questions, and exposes the real requirements faster than any theoretical planning session.

The MVP means stripping your scope to the most critical workflows, the things the business cannot operate without.

For most of my clients, that core looks like, receiving customer orders, processing and fulfilling those orders, and invoicing customers. 

That’s the skateboard.

It gets you from point A to point B without bells and whistles. A customer wants to buy, you record the order, you fulfill it, you invoice. Simple. Reliable. Fast to implement.

Everything else, automation, optimization, advanced reporting, integrations comes after you’re rolling.

Client Commitment Makes or Breaks Everything

It is easy for a consultant to take a requirement, configure the system, and call it progress. But that approach does not help a client who just invested in new software. Some clients come to me and say, “here is what we want. Go build it and let us know when it is finished.” My response is always the same: that is not how successful implementations work. If the designated SPOC is not willing or able to engage, we need to find someone who is.

When a consultant builds everything alone and hands it over at the end, the client is forced to learn the new system at the most critical moment. Go live becomes the learning phase instead of the operating phase. Internal questions pile up because no one understands why certain decisions were made. Stakeholders feel uncertain because they have not seen progress or participated in shaping the workflows.

The teams that stay engaged throughout the build are the teams that succeed. They learn as the system comes together. They ask better questions. They develop comfort with the new processes long before go live. Most importantly, they take ownership of the system because they helped build it.

Implementation does not work when it becomes a handoff. It works when it becomes a partnership.

Conclusion: Where Implementations Truly Succeed

After more than 60 go lives, I’ve learned that the success of a project rarely comes down to the software. It comes down to three things that show up every single time: a clear business analysis, a simple and repeatable process, and a client who stays involved from start to finish.

Business analysis is where everything starts. When clients map their workflows honestly, bring the right people into the room, and define what the project really needs to achieve, the build becomes much easier. When they skip this step, the project gets messy fast.

The process itself is not complicated once the scope is set. Build the MVP, get something usable into the team’s hands, and improve from there. The clients who move the fastest are always the ones who start using the system early, ask questions, and adapt along the way.

But the biggest difference is commitment. Projects fall apart when clients disappear for weeks, wait until they go live to learn the system, or rely on the consultant to make every decision for them. The teams that succeed show up, stay curious, and take ownership of how their system is built. When both sides treat it like a partnership instead of a handoff, the software becomes something the whole organization understands and trusts.

That has been the real pattern in every project I’ve worked on. Software is important, but the people and the process matter more.

Further Reading

• The Shortlist: Control, Culture, and Competitive Edge

• The Streaming Wars Come for Football

• The Business Case for Women’s Football