How much of your team’s time a project really needs

The unpriced half of the budget

Every proposal you receive prices one side of the work. The vendor’s engineers, their weeks, their rate. Nowhere in that document is the number that determines whether the project lands: how many hours of your own organization it consumes, from whom, and in which weeks. That number is real, it is larger than most buyers expect, and it is the most common reason a project that was on schedule in month one is three weeks late in month three with nobody able to explain why.

The mechanism is simple. Engineers build against what they are told. Every hour your people do not spend telling them is an hour the engineers spend guessing, and guesses are cheap to make and expensive to unwind. When a delivered system “does not match how we actually work,” that is nearly always what happened: the questions were asked, the answers were slow, and the build proceeded on assumptions because standing still costs money too.

What follows is what we see across engagements, stated as ranges. Your numbers will differ. The point is not the precision; it is that the line item exists at all, so you can staff it deliberately instead of discovering it in week five.

Five kinds of time, and they are not interchangeable

Decisions. Small in hours, enormous in effect. A project generates a stream of questions where two reasonable answers exist and only your organization can choose. Left unanswered, they queue, and a queue of decisions is a stopped project. Budget one to two hours a week from the sponsor, plus availability inside a day for the unplanned ones.

Domain answers. How the work is actually done, including the exceptions. This is the expensive one because it can only come from your busiest people, and it cannot be delegated to someone who has read the process document. Four to eight hours a week early, tapering to two or three once the model of the domain is right.

Access and environment. Accounts, network, credentials, a copy of data somewhere an engineer may legally work on it. Low in hours, brutal in calendar time, and almost always on the critical path in week one.

Data and output review. Somebody who can look at a hundred rows of output and say which ones are wrong. There is no substitute for this and it is the single highest-value hour your organization contributes. Two to six hours a week through the middle of the project.

Acceptance and rollout. Real users, doing real tasks, before you call it done. Concentrated at the end, spread across more people, and the phase most often compressed when the schedule slips — which is exactly backwards.

What it looks like per role

Take a mid-sized engagement as the reference case: two to three vendor engineers, ten to fourteen weeks, building something that will be used by a real team rather than demonstrated to an executive. These are the ranges we plan against.

Your role	Hours per week	When it peaks	What only they can supply
Sponsor / decision-maker	1–3	Weeks 1–2 and at each gate	Trade-off calls, priority when two things cannot both fit
Domain expert	4–8 early, 2–4 later	Weeks 1–4	The exceptions that are most of the real job
Data owner / analyst	4–10	Weeks 1–5	Which field means what, which system wins a conflict
IT, security, identity	2–6 total, front-loaded	Week 0–2	Access, and the constraints that shape the architecture
Reviewer of output	2–6	Middle third	The judgment call on whether an answer is right
End users for testing	1–3 each, 5–10 people	Final third	Whether it survives contact with a real Tuesday

Added up, a project of that size typically consumes somewhere between a quarter and a half of one full-time person across its life, concentrated unevenly. A useful planning heuristic: for every four to five hours of vendor engineering in the first third of a project, expect roughly one hour of internal time. That ratio falls as the build settles and rises again at acceptance.

Two things push it higher. Replacing an existing workflow rather than adding a new one roughly doubles the end-user and change-management load, because people have to unlearn something. And any project touching regulated data adds review cycles that are calendar-heavy even when they are hour-light.

Hours and calendar days are different currencies

The most damaging item on the list above takes almost no effort and stops everything: access. Provisioning a contractor account, granting network access, arranging a data extract into an environment where an outside engineer may lawfully work — the sum of human effort is often under a day. The elapsed time is routinely one to three weeks, because it crosses three teams and each one has a queue.

Plan those two quantities separately. A project plan that says “access: 4 hours” is describing effort and hiding a two-week dependency. Start access on the day the contract is signed, not the day the engagement starts, and ask for the normal turnaround in days rather than a promise that it will be handled. If the answer is that nobody knows, that is itself the schedule risk, and it is better priced now than discovered on day three with a team already billing.

The single-threaded expert

Nearly every engagement has one person who knows how the thing really works. They are senior, busy, well-regarded, and their calendar is the project’s true schedule. Nothing in the plan says so.

Find them in week one and say the quiet part out loud: this project depends on you for roughly six hours a week for the first month, and your manager needs to know that. Then reduce the dependency deliberately. Record the sessions where they explain the domain. Have a second person sit in, not to contribute but to absorb. Ask the vendor to write down the domain rules as they understand them and get the expert to correct the document rather than re-explain from scratch, which is an order of magnitude cheaper on their time.

If they are unavailable for a stretch — leave, quarter close, an unrelated crisis — that is a schedule event and should be treated as one. It is far better to move a milestone than to let a team build for three weeks on an unverified understanding of the domain.

What underfunding actually produces

It does not produce a stopped project. That would be easier to see. It produces a project that keeps moving on assumptions, and the assumptions are load-bearing by the time anyone checks them.

The build encodes a guess about the exceptions. The main path is right and the twenty percent of cases that are most of the work are wrong. This surfaces at user testing and costs a redesign.

Output goes unreviewed until the end. A system producing plausible answers nobody has checked is not progress; it is unmeasured risk accumulating at full billing rate. Two hours a week of review from someone qualified to judge is the cheapest insurance available.

Decisions get made by the vendor. Not maliciously — a blocked engineer picks something to keep moving, and the choice reflects what is easy to build, not what your business needs. You are paying full rate for someone to make your policy decisions with less information than you have.

Acceptance becomes a negotiation. When users first see it in the final week, their objections arrive at the moment there is no budget to act on them. The same objections in week six would have been ordinary scope adjustments.

Paying money instead of time does not work

The obvious response is to buy more vendor. It is worth being clear about where that helps and where it does not. More engineers speed up work that is specified. They do nothing at all for work that is blocked on a decision, an answer, or an access request — and in the early weeks, most of the critical path is exactly that. Adding people to a project that is waiting on you makes the waiting more expensive without making it shorter.

There are two legitimate substitutions. A vendor can do more of the discovery themselves, sitting with your practitioners and writing the process down, which converts eight hours of your expert’s explanation into two hours of correction. And some organizations second a business analyst into the project full-time as a dedicated bridge, which genuinely works and should be priced honestly as a person you have removed from other duties.

How the load moves through the project

The shape matters more than the totals. Front-loading is not a preference. An hour in week two changes what gets built; the same hour in week ten can only change what gets fixed.

Booking it so it actually happens

Put names and hours in the contract. Not “the client will provide subject matter expertise” but “Priya, 6 hours per week, weeks 1–4.” A named commitment survives a competing priority; a generic clause does not.

Hold a standing slot. Thirty to forty-five minutes, same time each week, with the expert and the engineers. Cancel it when it is not needed. Recovering a cancelled slot is trivial; finding an hour in a busy calendar from scratch takes days.

Batch the small questions. A shared list answered once a day beats interruptions, and it beats a weekly meeting where a question asked on Tuesday blocked work until Friday.

One decision-maker, named. Two sponsors with different priorities is not redundancy; it is a queue with a lock on it.

Tell people’s managers. The most common failure is not refusal. It is a good employee quietly trying to absorb eight hours a week of project work on top of a full job, and going slower at both.

If you genuinely cannot supply it

Sometimes the honest answer is that the expert has no hours this quarter and none of this is available. That is a legitimate constraint and it has a legitimate response, which is to reduce the scope rather than the quality. Build the part of the system that needs least domain judgment. Take a longer schedule with a lighter weekly draw. Or wait a quarter.

What does not work is running the original scope with a tenth of the internal input and hoping. That produces a delivered system nobody trusts, which is the most expensive of the available outcomes because you pay for the build and keep the problem.

The mistakes we are called in to fix

• Internal time absent from the budget, then improvised out of people’s evenings
• Access started on day one instead of at contract signature, losing two weeks immediately
• One expert carrying the project invisibly, with no backup and no reduction in their day job
• No weekly output review, so quality is first measured in the final fortnight
• Users introduced at acceptance, raising in week eleven what they would have raised in week five
• Two sponsors with different priorities, and an engineering team resolving the tie
• More engineers added to a project blocked on decisions, raising cost and not speed

Before you sign

• Named people with weekly hours, in the statement of work
• Access requests submitted at signature, with a turnaround in days
• A standing weekly slot on the calendar for the whole engagement
• One named decision-maker, and a stated response time for blocking questions
• Somebody assigned to review real output every week from week four
• Managers of the committed people told what was committed
• Cover for leave and quarter-close in the plan, not in the risk register
• End users identified by name for the testing window

Bottom line

The vendor’s invoice is the visible half of a software project. The invisible half is your own people, and it usually runs between a quarter and a half of one full-time person across a mid-sized engagement, front-loaded and concentrated on your busiest staff. Every hour of it that you do not supply gets spent anyway — by an engineer, guessing, at your expense. Price it, name the people, start access early, and protect the weekly review. Projects that do this are not merely more pleasant to run. They are the ones where the delivered system matches the work.

Frequently asked questions