The question we get asked most quietly, usually after the proposal and before the signature, is some version of “how much of my time is this going to take?” It is a fair question, and most firms dodge it. The honest answer is that a custom software project needs more of you at the start, less as it runs, and a specific kind of involvement throughout that has little to do with technical skill.
This is what your job looks like on a project with us. The details differ with other firms, but the shape does not, and any firm that tells you they need nothing from you is describing a project that will not fit your business.
The three people we need
Every project that has gone well for us had three roles filled on the client side. They can be three people or two; they should not be one.
The sponsor. The owner, CEO, or executive whose budget it is and whose problem it solves. The sponsor sets the priority, makes the calls nobody else can, and shows up when a decision is stuck. They do not need to be in the weekly meeting. They do need to be reachable and willing to decide.
The champion. The person who owns the work day to day. Usually a director or operations lead who knows the process being replaced and has the standing to change it. This is the role that decides whether a project ships and gets used. We have written before about why we will not start a project without one.
The people who know the work. The dispatcher, the estimator, the billing lead, the person in the field. They are not on the project team, but they are the ones the design has to fit, and they need a few hours during planning and a few more during testing.
What the start needs
The first few weeks are the heaviest. Our planning step, whether a Validation, Design & Planning engagement for something new or a System Evaluation for something you already run, asks for the people closest to the problem in the room. Expect a two-day workshop with the sponsor, the champion, and the people who know the work, followed by working sessions roughly twice a week for the champion and whoever the topic needs.
This is where the time goes, and it is time well spent. The decisions made here, about what the system has to do, who uses it, and what it connects to, set the budget and the schedule. A champion who gives planning a full day a week for a month saves the project several months later.
What the build needs
Once the work is running, your involvement drops to a rhythm:
- A weekly priority meeting, usually an hour, with the champion and sometimes the sponsor. We show working software, you tell us what is next, and problems surface while they are still cheap.
- Decisions within a day or two. Not every question can wait for the next meeting. The champion needs the authority to answer, or a fast line to someone who does.
- Access. To your systems, your data, and the people who can explain them. More projects slow down waiting on a login than on any technical problem.
- Review of what ships. When a feature is ready, someone on your side tries it on real work and says whether it does the job. Testing at every stage is ours to do. Judging whether it fits your business is yours.
Add it up and the champion is spending three to five hours a week during the build, the sponsor an hour or two a month, and the people who know the work an hour here and there when their part is up.
What the end needs
Launch is the part owners underestimate. The software works; the question is whether the business changes around it. Someone on your side has to own the rollout: training the people who will use it, retiring the old way of doing things, and holding the line when the first week is uncomfortable. We help with all of it. We cannot do it for you, because the authority to change how your team works is yours.
What it looks like when it goes wrong
The failures we have seen on the client side are almost never about effort. They are about structure:
- No champion, so every decision goes to a busy owner who answers on Friday.
- A champion without authority, who has to escalate the same decisions the sponsor thought were delegated.
- The people who know the work were never asked, so the design fits the org chart and not the job.
- Review that never happens, so a month of features sits untested until someone finally looks and has a long list.
None of these are hard to prevent. They just have to be decided before the project starts, which is why we ask about them on the first call.
The short version
Give us a sponsor who decides, a champion with the time and the authority, and access to the people who know the work. Plan for a heavy month at the start and a few hours a week after that. Treat the team as your own. The projects where that happens are the ones we are proud of, and the ones where the software is still in use five years later.