Evaluating Team and Delivery Risk

Most funding decisions that go wrong do not go wrong on policy. They go wrong on execution: the work is late, thinner than described, or never arrives. That makes delivery history one of the highest-value things a representative can examine, and also one of the easiest to examine badly. Reputation is cheap to acquire and cheap to lose unfairly. This lesson replaces reputation with a procedure that produces the same reading whether you know the team socially or have never heard of them.

• Separate each delivery claim from the artefact that would verify it.
• Distinguish delay, disclosure failure and non-delivery, and date each one.
• Find evidence of correction rather than evidence of contrition.
• Record absence of history as missing evidence, not as negative evidence.

Begin by extracting every delivery claim in the proposal into a list, in the proposer own words. Then, beside each, write the artefact that would settle it. This is a mechanical step and it is where most of the value is: a claim such as "we built the analytics tooling used across the ecosystem" resolves into a question with a checkable answer - which tooling, at which URL or repository, and who besides the team uses it? A claim such as "we have five years of experience in the space" resolves into nothing checkable at all, which is itself worth recording.

Label each claim with one of four outcomes: verified, partially verified, unverified, or contradicted. Reserve contradicted for cases where the artefact exists and disagrees with the claim, and describe the disagreement factually. Unverified means you looked and did not find; it is not an accusation, and it is honest to say that a claim may be true and simply undocumented. Record the date you looked, because repositories move and sites go down, and a reader six months later needs to know when your snapshot was taken.

Weight artefacts by how hard they are to fabricate and by who else has an interest in them. A live service with independent users is strong. A repository with a long commit history from several contributors is strong. A screenshot in a slide deck is weak. A testimonial from a party related to the proposer is weak unless the relationship is disclosed, in which case it is at least honest. None of these weights are moral judgements about the people involved; they are statements about how much the evidence can bear.

Software is late. It is late in well-run organisations with experienced teams and generous budgets, and it is late for reasons that are frequently outside anyone control: a dependency changes, a specification is amended mid-flight, a contributor becomes ill. A reviewer who treats any slippage as disqualifying will systematically reject honest teams who publish real dates and reward teams who publish nothing. That is the opposite of the incentive the ecosystem needs, and it is worth stating explicitly in your own notes so that you hold yourself to it.

What carries signal is the pattern around the delay. Three questions do most of the work. First, disclosure lag: did the team announce the slip before or after external parties noticed, and how long after they knew? Second, revision behaviour: did the revised date hold, or was it revised repeatedly by small increments - a pattern that often indicates the team does not know the size of the remaining work? Third, scope behaviour: did the deliverable quietly shrink to meet the date, and was the shrinkage disclosed as such?

Distinguish these clearly from non-delivery, where the work never arrived and funds were consumed. Non-delivery is a materially different finding and should not be softened into "delayed" simply because the team still describes it as forthcoming. Equally, non-delivery on its own does not establish dishonesty. Projects fail for many reasons and the reviewer is not equipped to determine intent. Record what happened, note whether unspent funds were returned or accounted for, and stop there.

The composite deliberately mixes strong and weak evidence, because real histories do. The output is not a verdict on the team. It is three labelled rows, a dated snapshot, and one specific question that the proposer can answer in a sentence.

The most predictive thing in a delivery history is not the absence of failure but the presence of correction. A team that missed a date, published a plain account of why, and then changed something concrete - added a staging environment, split milestones into smaller units, hired a second reviewer, moved from private status updates to public ones - has demonstrated a capability that a team with an unblemished but shallow record has not demonstrated at all.

Test for correction the same way you test for delivery: ask for the artefact. A post-mortem document, a changed milestone structure in the current proposal compared with the last one, a repository showing a new CI step introduced after the incident. "We have learned from this and improved our processes" is a sentence, not evidence, and asking what specifically changed is a fair and non-hostile question. Where a team can point to the change, record it as a strength with the same rigour you apply to weaknesses.

Consider two requests of similar size. Team A has three prior deliveries, one of which slipped badly and was openly documented, and one of which was cancelled with unspent funds returned and accounted for. Team B is new, has no prior public delivery, and has therefore never missed a date. A checklist that scores "missed deadlines" as a negative and has no row for "no evidence either way" will rank Team B above Team A. That ranking is an artefact of the checklist, not a finding about the teams.

The correct treatment is to record Team B as an unevidenced execution profile: you have less information, so the range of plausible outcomes is wider in both directions. That is a genuine consideration for how much money to release at once - which lesson four addresses through tranches and acceptance evidence - but it is not a character finding, and new teams must be able to enter the ecosystem or it ossifies. Say what you know, say what you do not, and let the mitigation carry the uncertainty.

• Accepting a delivery claim because the team is well known, or rejecting one because they are not.
• Treating any slippage as disqualifying, which penalises teams who publish honest dates.
• Failing to distinguish delay, disclosure failure, scope drift and non-delivery.
• Recording UNVERIFIED as though it meant FALSE, or implying that a gap proves concealment.
• Inferring fraud from delay. A reviewer is not positioned to determine intent and should not imply it.
• Describing unverified security review status as "unaudited" or "insecure", which is an assurance you cannot give.
• Omitting the date of your check, leaving later readers unable to interpret your snapshot.
• Scoring a history numerically, which hides the evidence a later reader needs to disagree with you.

You can convert a narrative history into a dated, labelled evidence table: each claim in the proposer own words, the artefact that would verify it, whether you found it and when, and a factual label. You can characterise slippage by disclosure lag, revision behaviour and scope behaviour rather than by its length alone, and you can identify concrete evidence of correction. The table is reproducible by a stranger and applies the same standard to teams you know and teams you do not.

History constrains expectations; it does not predict this delivery. Teams change composition, scope differs, and past success on a small build says little about a large one. You cannot see private context - an illness, a funding gap, a dispute - that may explain a failure entirely. You cannot determine intent, and should not try. And an unverified claim may be perfectly true; you have established only that you could not check it on the date you looked.

Convert every delivery claim into an artefact question, then label it verified, partially verified, unverified or contradicted, with a date.

Read slippage through disclosure lag, revision behaviour and scope behaviour, not through length alone.

Look for a changed process after a failure; that is evidence of learning, and an apology is not.

No history is missing evidence, not bad evidence - carry that uncertainty in the mitigation, not in a character judgement.