The Problem Isn't Always Scope Creep
A lot of people think software projects take longer than expected because clients keep asking for new features.
And sometimes that's true.
But after spending the past two years building Sokana360, a maternal healthcare platform for Sokana Collective, I started noticing a different problem.
We weren't always adding new features. Sometimes we were going back and changing decisions we'd already made.
For example, we'd have a meeting, discuss how a business process should work, agree on the requirements, and then I'd implement it. A few months later, we'd revisit that same process and decide it needed to work differently.
Now I have to go back into the system, change the logic, and make sure those changes don't affect everything connected to it.
That's where the rework starts.
Recently, I went back through two years of project history, including emails, meeting notes, requirements documents, and development decisions. I wanted to understand why certain parts of the platform kept needing revisions.
What stood out wasn't necessarily how many new features were being requested.
It was how often decisions we'd already made were being revisited.
And looking back, I can see where I could have managed that process better.
One Business Rule That Changed Three Times
Let me give you an example.
Sokana360 manages several parts of the organization's operations, including family intake, doula onboarding, client assignments, contracts, and billing.
We also integrate with QuickBooks.
One of the decisions we had to make was when a family should be created as a customer in QuickBooks.
That sounds pretty straightforward.
But think about how the organization operates.
A family fills out a request form because they're interested in receiving services. Someone reviews the request and matches the family with a doula. The family and doula meet, discuss the services needed, and decide whether they want to move forward.
If everything works out, the family signs a contract.
So at what point should that family become a customer in the accounting system?
Here's how that decision evolved.
March 2026: We agreed that the customer should be created in QuickBooks after the contract was signed.
April 2026: We changed the requirement so the customer would be created when the family was matched with a doula.
July 2026: I documented the operational workflow in a discovery report, which described creating the customer after contract signing.
October 2026: During a live pilot testing session, we revisited the workflow and agreed that the customer should only be created after the contract was signed.
Why?
Because not every family that gets matched ends up becoming a paying client.
Some families have an interview and decide not to move forward. Others stop responding.
If we're creating accounting records for everybody who gets matched, we're putting people into QuickBooks who may never actually receive services.
Now we're adding unnecessary records to the accounting system.
So we went back to the original decision.
The problem wasn't that anyone intentionally made a bad decision.
The problem was that we didn't have one place where the current business rule was documented, along with why we made that decision.
We had meeting notes, emails, and requirements documents.
But those decisions weren't always being checked against one another before development started.
That's a requirements management problem.
The Same Thing Happened With Doula Onboarding
We ran into something similar with the onboarding process for doulas.
On October 12, we discussed removing certain document uploads from the platform, including W-9 forms, direct deposit information, and background checks.
Nine days later, during our live pilot, we had people from different parts of the organization testing the system.
This included administrators, people involved in HR-related workflows, and doulas who would actually be using the platform.
As we walked through onboarding, the group identified a need to collect those documents through the system.
We also discussed adding uploads for CPR and HIPAA training certificates.
So now we're revisiting a decision we'd made just nine days earlier.
But here's what I found interesting.
The people involved in those two conversations weren't exactly the same.
Someone responsible for program operations might look at a process differently from somebody handling HR or payroll.
And the doula who's actually going to use the system has another perspective.
All three are looking at the same workflow, but they're approaching it from different responsibilities.
So before making a decision about how that workflow should operate, we need to understand what each person is responsible for.
Who collects the document? Who reviews it? Who needs access to it? What happens after it's approved?
Once those questions are answered, then we can determine how the software should support the process.
Otherwise, we risk implementing something that works for one person but creates additional work for somebody else.
Why Reversing a Decision Creates More Work
When someone requests a new feature, you're adding functionality to the system.
But when an existing requirement changes, you're potentially modifying functionality that other parts of the application already depend on.
Let's go back to QuickBooks.
If the system is designed to create a customer when a family is matched, there's backend logic responsible for detecting that event.
There may also be other processes connected to it, such as notifications, billing workflows, and client status changes.
Now suppose we change the rule so that the customer isn't created until the contract is signed.
I have to go back and review how that workflow was implemented.
What triggers the customer creation? What other processes depend on it? What happens to records that may have already been created under the previous rule?
And once those changes are made, I need to test the affected functionality again.
That's called regression testing.
Basically, we're making sure that changing one part of the application didn't break something else that was already working.
The other issue is engineering time.
Let's say I spend several days implementing a requirement. Then a few months later, we decide it needs to work differently.
Now we're spending additional time revising something that was already built.
Sometimes that change is absolutely necessary.
But the effort still needs to be accounted for.
Looking back, I wasn't consistently treating these reversals as separate development work. They often became another task that needed to get done.
Over time, that makes it difficult to understand how much engineering effort is going toward building new capabilities versus revisiting previous decisions.
I haven't calculated the exact financial cost of those changes. That would require reviewing development hours, code history, and individual implementation tasks.
But I can identify the pattern that was creating rework.
Sometimes the Requirements Aren't the Real Problem
One of the biggest lessons I've learned from building Sokana360 is that organizations don't always have a single, clearly defined way of doing their work.
And that's understandable.
A lot of business processes develop over time.
One person manages something through email. Another person tracks it in a spreadsheet. Someone else has their own way of handling the same information.
As long as everybody can communicate and get the work done, the process may seem fine.
But when you start building software around those processes, you have to define exactly what happens.
For example, let's say a family gets matched with a doula.
What happens next?
Does the administrator contact the family? Does the doula reach out first? Does the family receive a scheduling link? Who checks whether the interview happened?
And what happens if nobody follows up?
Those questions matter because the software needs to know when to send notifications, when to update a status, and when someone needs to take action.
During our October 21 pilot, we spent time discussing that exact workflow.
We walked through the different stages a family moves through, from submitting a request to being matched, interviewed, signing a contract, and eventually completing services.
We also discussed who should update those stages and how long someone could remain in a particular stage before a reminder was triggered.
That conversation revealed parts of the operational process that needed to be defined more clearly.
And that's something I want to emphasize.
Sometimes what looks like a software requirements problem is actually a business process that hasn't been fully worked out.
You can't expect the technology to make those decisions for the organization.
You need to understand the process first.
Then you can determine which parts should be automated and which parts still require somebody to make a decision.
What Happened When Real Doulas Tested the Platform
Another thing that stood out during the pilot was how quickly actual users uncovered problems.
Before the meeting, I'd already tested the doula onboarding process myself.
Users could create accounts, fill out profiles, upload documents, and submit information for approval.
From a development perspective, much of the functionality was working.
But then the doulas started using it.
One doula clicked Add Certification because she thought that was how she was supposed to enter her first certification.
The system already had a certification field available. Clicking Add created another empty entry, which then interfered with saving her information.
Another doula tried uploading a picture of her certification, but the system didn't accept the file type.
Another participant completed her profile and uploaded her documents but didn't realize she needed to go back and manually mark the profile as complete.
These weren't complicated technical problems from the user's perspective.
They were people trying to complete a normal task.
And that's what made the session valuable.
As developers, we know how the system is supposed to work because we built it.
The user doesn't have that knowledge.
They see a button, read an instruction, and make a decision based on what they think should happen.
If the interface doesn't clearly communicate the next step, they can get confused.
For example, if I have a button that says Add Certification, but the user is supposed to fill out an existing field first, I need to make that distinction obvious.
Otherwise, the interface is creating confusion that doesn't need to exist.
This is why I believe real user testing needs to happen throughout development, not just when you're getting ready to launch.
A user can uncover something in a few minutes that you may overlook after spending hours working on the feature.
And the earlier you discover it, the easier it usually is to correct.
Having a Project Management Tool Isn't Enough
I've used Notion to manage the development work.
And while it helped organize tasks and project information, I realized that having a project management tool doesn't automatically mean you're managing requirements effectively.
For example, a decision might be made during a meeting.
Another decision gets confirmed through email.
A few weeks later, somebody brings up a change during another conversation.
If those decisions aren't being tracked in one place, we can end up implementing something that conflicts with an earlier agreement.
Now imagine that happening across multiple workflows over two years.
You can see how the complexity starts building up.
The issue isn't necessarily the tool.
It's how decisions are being managed.
We need a process that makes it clear what the current requirement is, who approved it, and whether it replaces something that was previously agreed upon.
That's one of the changes I'm focusing on as I move into the Fractional CTO role.
My responsibility isn't just making sure the software gets built.
It's also making sure we have a reliable process for deciding what gets built and how those decisions are communicated.
What I'm Changing Going Forward
After reviewing the project history and what happened during the pilot, there are several things I'm putting more emphasis on.
1. Keep One Record of Important Decisions
Every important technical or business requirement needs to be documented in one place.
Not just what we decided, but why we decided it, when it was approved, and whether it replaces an earlier decision.
For example, if we change when a customer gets created in QuickBooks, that new decision should reference the previous rule.
That way we're not unknowingly reversing something that was already agreed upon.
And if we decide that changing the requirement is the right move, that's fine.
At least we're making that decision with the full context.
2. Get the People Who Do the Work Involved Earlier
If we're building a workflow involving HR documents, somebody responsible for HR needs to be involved.
If we're working on billing, we need input from whoever handles the financial process.
And if we're building an onboarding system for doulas, we need doulas testing it.
The objective isn't to have everybody making every decision.
It's to gather the information from the people who actually perform the work, understand the dependencies, and have the appropriate leader approve how the process should operate.
That alone could prevent a lot of unnecessary revisions.
3. Define What Finished Means Before We Start Building
For each requirement, I want a clear description of what the system should do.
For example:
When a family signs a contract, the platform creates a customer record in QuickBooks. A family that has only been matched with a doula should not have a customer record created.
That's specific.
Now we can test it.
Instead of simply asking whether the QuickBooks integration works, we can ask whether it follows the approved business rule.
Those are two different questions.
4. Test With Real Users Earlier
I want to move toward shorter testing cycles.
When we build a workflow, we should get it in front of the people who will use it before adding more complexity.
Let them try it.
Watch what happens.
Where do they get confused? What information is missing? Are they clicking something we didn't expect?
Then take that feedback and determine what needs to change.
A lot of those problems are easier to address when you're working on a small part of the application rather than trying to revise an entire workflow close to launch.
5. Evaluate Changes Before Implementing Them
Requirements are going to change.
That's part of developing software.
But before making a change, I want to understand what it's going to affect.
Does it change the database? Does it affect another module? Will an integration need to be updated? Do existing records need to be handled differently?
And how much additional engineering work will it require?
The point isn't to make stakeholders afraid to request changes.
It's to help everybody understand what the change involves before we commit to implementing it.
6. Separate Maintenance From New Development
This is another important lesson for me as a consultant.
Maintaining an existing application and expanding its functionality are two different responsibilities.
Maintenance includes things like monitoring the system, fixing defects, updating dependencies, and keeping existing workflows operational.
New development involves introducing additional features, integrations, or significant changes to how the system operates.
When those activities are mixed together, it becomes difficult to understand where the engineering time is going.
So I want to track and report them separately moving forward.
That gives leadership a better understanding of what it takes to operate the platform and what it costs to continue expanding it.
What I Would Do Differently Today
Looking back over the past two years, I don't think the lesson is that requirements shouldn't change.
Some of the changes we made were necessary.
We had to address healthcare data security, improve onboarding, refine document management, and make the platform better support the organization's operations.
Those were valuable improvements.
But if I were starting this project again, there are things I would approach differently.
I'd spend more time mapping out the actual business workflows before implementing them.
I'd involve the people responsible for those workflows earlier.
I'd make sure there was one person responsible for approving the final requirements.
And whenever a previously approved decision needed to change, I'd document the impact before going back into development.
I'd also bring real users into testing much earlier.
Because one thing this experience has reinforced is that you can build software according to the requirements and still end up with something that doesn't fully support how people actually work.
And the longer you wait to discover that, the more effort it can take to correct.
Final Thoughts
After spending two years building Sokana360 and now stepping into the Fractional CTO role at Sokana Collective, I see software development differently than I did at the beginning of the engagement.
Writing code is important, but it's only one part of the work.
You also have to understand the organization, its operations, the people who use the system, and the decisions behind the requirements.
And when those decisions change, you need a process for managing that change.
Otherwise, you can spend a lot of time going back and revisiting work that was already completed.
For me, the biggest lesson is this:
The goal isn't to stop requirements from changing. It's to make sure we understand why they're changing, what those changes affect, and whether we're actually solving the underlying problem.
That's the approach I'm taking into the next phase of building Sokana360.
Next Step
Have a workflow you want to improve?
Bring it to a 30-minute call. We’ll discuss where work gets stuck and what to try next.