When an owner reads a software proposal for the first time, their eye goes to the roles that are not engineers. A delivery lead. A business analyst. Sometimes a designer. The instinct is understandable: I am paying for software, so I want to pay for people who write software. Can we cut the rest?
You can. Firms that quote a fraction of our price often have. Here is what those two roles do, and what a project looks like without them, so you can decide with your eyes open.
The business analyst: making sure the right thing gets built
A business analyst turns what your business needs into what an engineer can build. That sounds simple until you watch it not happen.
Without one, requirements arrive as a conversation, a bullet list, or a screenshot of the spreadsheet. The engineer interprets them. The interpretation is reasonable and wrong in three places nobody noticed. The wrong places get built, demonstrated, and rebuilt. The rebuild is billed, or absorbed and paid for elsewhere, and the schedule slips a month.
With one, someone sits with the people who do the work, writes down what the system has to do in a form both sides can read, asks the questions that expose the exceptions (“what happens when the customer pays twice?”), and keeps that record current as decisions are made. Engineers build from it once. When a disagreement about scope comes up, there is a document instead of two memories.
On a project with any complexity, the analyst is the cheapest person on it, because every hour they spend saves several hours of engineering that would have gone the wrong direction. This is also why our planning step, the Validation, Design & Planning engagement, is heavy on analysis and light on code. Finding the exceptions before the build is where the money is saved.
The delivery lead: making sure it gets built at all
A delivery lead runs the project. They are your single point of contact, they run the weekly priority meeting, they keep the backlog honest, they know what is slipping before it slips, and they make sure nothing falls between the chairs. When you need a decision from us, they get it. When we need one from you, they ask once, clearly, and track it.
Without one, the engineers coordinate among themselves and with you as best they can, in between writing software. Nobody is watching the whole. Problems are discovered when someone trips over them. Your questions go to whoever answered last time. The project has no one whose job is the project.
We will say plainly that this role is where most of the failures we have seen in our own history would have been caught earlier. A schedule slipping a little each week, a risk everyone assumed someone else was watching, a client contact too busy to review: a delivery lead’s entire job is to notice those in week two and say so.
”But my firm does not charge for them”
Some do not, and it is worth understanding why. Either the work is not being done, in which case you will pay for it in rework, or it is being done by the engineers, in which case you are paying senior engineering rates for project coordination and getting less engineering. Neither is a discount. The proposal is just quieter about where the cost went.
What they are not
A delivery lead is not a layer between you and the team. You can talk to anyone on our projects directly, and the lead’s job is to make that easy, not to route it. A business analyst is not a gatekeeper who slows down changes. They are the person who makes changes safe, because the consequences of a change are visible in the requirements before it is built.
How we size them
Roles roll on and off as the work needs them. A small utility might need an analyst for two weeks and a delivery lead at a light touch. A multi-system modernization needs both, full time, for the duration. The proposal shows which, and the Deep Dive is where we decide together. If you want to challenge the sizing, do; we would rather explain it than have you wonder. Just do not cut the roles and expect the project to run itself. Projects do not.