How to Calculate Your Operational Baseline
Fourteen months ago, you bought a tool. It came recommended by a colleague, a friend, or something you discovered on the internet and researched yourself. You paid for the implementation, sat through the training, and watched your team use it for a couple weeks. Sleeping at night felt easier because you could see whether things were in-progress or blocked, handoffs seemed to be solved (less dropped balls), and things seemed to be working. Finally.
About two months in, there was a pretty big miscommunication on a client project that confused you, but the team handled it and everyone moved on. Over the course of the next four months, these multiplied, and suddenly handoffs were a point of friction again. Your Operations Manager did some digging and realized half of our team was running their projects in the tool you bought and in their spreadsheets or to-do lists.
You open the tool and click on a few tasks at random.
Those customized fields and tags you spent four hours designing? Empty.
Later that week, in your leadership meeting, your Chief of Staff floats the idea that maybe this tool is just the wrong tool.
You can accept that maybe a different tool would be better, but it still doesn’t make sense. There’s no clear moment to point to where the tool stopped working, people just stopped using it. But why?
Why good systems stop working
This is a rather simple truth. And it has nothing to do with you building the tool “the wrong way”. The system stopped working because reaching 100% complete on the “building” portion was equated to the finish line.
You built out a beautiful tool, implemented new processes, and then checked the box. Done!
Here’s the part to remember: a system is a set of agreements made a specific moment, and that moment will always be ever changing. Whether the change comes from new clients, new vendors, new services, or a week where you have to put out a really big, unexpected fire. All of those changes create reasons for your team to build workarounds in the system, instead of working through it.
This isn’t because your team is undisciplined. One person starts doing a workaround, then two people do it, and six months later, there’s an entire side system you aren’t privy to, but things “aren’t working”.
This is typically where, like in the leadership team example, people draw the conclusion that the parent variable, the tool, is wrong.
The tool is completely fine. But the finish line is very far from the moment the build is complete. That’s what we need to help you tweak.
Building a system and maintaining it are two different jobs
Over the last three weeks, we've walked through the first three steps of our delivery methodology at The 128 Collective.
You capture the work to understand what it actually is and where it lives. You connect the work so it moves without a person carrying it. You clarify the work so everyone is moving toward the same definition of done.
Control, the fourth and final stage, is what makes those three survive contact with a busy quarter.
It's the least exciting of the four, but it's the one that determines whether the other three were worth doing.
A captured process that nobody maintains is a document. It’ll live and die in SharePoint.
A connected handoff that nobody monitors reverts to a meeting. Nothing valuable is done in that meeting.
A clear definition of done that nobody checks becomes three definitions again inside a quarter. And then the integrity of the definition of done dissipates.
So here's your question this week: what's the last process you rolled out? Who owns it now, and when did they last look at it?
How to properly maintain a system
Assign an owner to the system
There’s a difference between the people who own their work and an owner who owns the way work gets done.
Ownership of a process is a real job with real hours attached. It sounds a little strange, but when it doesn’t exist, it defaults to leadership, which means it happens when leadership has capacity, which means it happens roughly…never.
The tell? Process improvements only occur after something goes badly wrong.
Hold your systems accountable to metrics
How can you track when teams start using tools if you don’t have a metric to signal that adoption is slipping? Your owner from our first tip would measure this. Many tools have metrics built in specifically to track things such as logs in, tasks created, custom fields used, etc.
If the first indication that your systems aren’t working is an unhappy client, you're not managing your systems.
Create a recurring cadence
We refer to this as a “forcing mechanism”. When you introduce change, a forcing mechanism is typically something that creates vulnerability and accountability, and it accelerates adoption rate. The simplest way to do this without striking fear into your team is to create a recurring moment where everyone looks at the process on purpose.
This could be as simple as updating project progress as a team in a Monday morning standup, until it becomes a habit, and then you delete the meeting, turn it over to your team to update, and if they stop updating it, the meetings get put back on the calendar.
Draw the line at exceptions
This is the one that actually kills you.
It’s also the least natural to enforce. Because no single workaround is unreasonable.
“The client needed it fast.”
“They didn't have access yet.”
“It was one time.”
Each exception has a fair justification, but none of them get logged, so nobody can ever uncover the pattern unless they spend hours digging.
Drift happens when a hundred defensible decisions to go around the system, made by people doing their best.
The Cost of Bad Systems
The first three posts asked you to count hours and margin points. This one asks you to count the thing you already paid for. Let us explain.
Say you spent $12,000 on a project management implementation. Add roughly 90 internal hours configuring it, migrating data, and training the team. At a $65/hour blended rate, that's another $5,850.
Total build cost: $17,850.
It held for about five months. Then the exceptions started, adoption slipped, and you drifted back to status meetings and manual updates — the exact coordination overhead the system was bought to eliminate. For a delivery team of eight, that's roughly 16 hours a week of coordination, or $1,040 weekly.
Seven months of drift: $31,200.
So the decay cost you $49,050. The build you already paid for, plus the leak that came back while nobody was watching.
And you're now looking at quotes to do it again.
That's the real expense of skipping Control. Not the system you lost — the fact that you're about to buy the same outcome a second time, with the same maintenance gap that killed the first one.
To be fair: systems should change. A process that looks identical two years later probably isn't being used, it's being tolerated. Deliberate change is healthy.
This isn't deliberate change. This is a system you stopped looking at, that changed without you.
What Good Actually Looks Like
Same as the last three weeks, "good" here is simple (which, intentional simplicity, is one of our values at The 128 Collective):
The system has a named owner with time allocated to it. Not "we all own this." That sounds a lot nicer but for this to work you should assign one person, with hours on their calendar to do the job.
Adoption is visible without asking. You can see whether the process is being followed without convening a meeting to find out.
There's a standing review and a place exceptions get logged. Every workaround gets captured, so the pattern shows up before the $$$ compounds.
The third one is the one people tend to opt out of, but that’s where all of your leverage lives here. Logged exceptions are your best source of process improvement, because they tell you exactly where your system doesn't fit reality. Most firms throw that data away in real time and then pay a consultant to go find it a year later (we’ve been on both sides of this and we want to help you avoid it).
What’s the point of systems?
Capture, Connect, Clarify, Control.
Four steps, four blog posts, named failure modes, and a running tally that adds up to real money you could be putting back into your company’s pocket.
But the methodology isn't the point we’re trying to make.
The point is that if your delivery margin is less than favorable, it’s less likely the obvious players of pricing, talent, or tooling. It's structural; structural problems hide between rows on your P&L. They show up as a quarter that came in softer than it should have, on work your team executed well.
You've now got four questions to sit with:
If the person who "just knows how this works" took two weeks off, what would stop?
Which handoffs on your team depend on a person to move them?
The last time two teammates disagreed about scope, how long did it take to resolve and who resolved it?
Who owns your processes, and when did they last look at them?
Write down your answers. That's your operational baseline.
It shows you the most obvious areas to start working on, as soon as today.
If you'd rather not do it alone, that's what we do.
