Person / 01
Ten checks for the proposed developer
Record the evidence source and the date for each check. Use proposal required when the current person or term has not yet been confirmed.
-
Proposed person identity
Record the full name, proposed role, employing or supplying entity, and person who confirmed the proposal.
- Ask whether the person is an employee, contractor, subcontractor, or candidate for direct employment.
- Confirm that the interview and final proposal refer to the same person.
- Keep identity documents only when there is a valid business and legal basis.
-
CV and project relevance
Match each important requirement to dated experience that the named person can explain in an interview.
- Ask what the person personally owned on each relevant project.
- Distinguish hands-on implementation from support, observation, or team membership.
- Do not treat a company case as proof that this person worked on it.
-
Interview access
Interview the proposed person with the buyer roles that will review, direct, and accept the work.
- Use questions based on the buyer's real system boundary.
- Ask the person to explain trade-offs, failure modes, testing, and escalation.
- Record who attended and which questions remain unanswered.
-
Credential scope
Verify any claimed credential against the named person, current status, product scope, and evidence the buyer is allowed to inspect.
- A partner-directory entry describes an organization, not the assigned person's credential.
- A team total does not prove that the proposed person holds a relevant credential.
- Credential evidence supports one check; it does not replace the interview or work evidence.
-
Allocation and start condition
Put the person's planned weekly allocation, competing commitments, notice period, and start conditions into the proposal.
- State whether the allocation is exclusive, shared, or variable.
- Identify approval, notice, onboarding, or background-check dependencies.
- Do not turn a provider's general sourcing speed into a promise for this person.
-
Work location and hours
Confirm the person's work country, local time zone, daily overlap, holidays, travel assumptions, and daylight-saving changes.
- Record overlap as specific clock hours for the buyer and the person.
- Confirm whether meetings outside the normal window require advance agreement.
- A supplier office does not prove where the proposed person works.
-
Continuity and absence cover
Name the documentation, review access, and temporary cover that reduce dependency on one person during planned or unexpected absence.
- Keep decisions, code, tests, runbooks, and open risks in buyer-approved systems.
- Name who can review urgent work while the person is absent.
- Confirm what cover is included, optional, or unavailable.
-
Substitution and escalation
Define who may propose a replacement, what evidence the buyer receives, who approves it, and how unresolved issues escalate.
- Do not assume a replacement has equal experience or immediate availability.
- Require a new CV, interview, location check, access approval, and handover plan.
- Name commercial and technical escalation contacts without treating them as allocated delivery staff.
-
Handover and knowledge transfer
Set the artifacts, walkthroughs, recipients, timing, open-risk log, and final access checks required when the person leaves.
- Define a minimum repository, test, documentation, and ticket state.
- Schedule live walkthroughs early enough for questions and corrections.
- Confirm final invoices or termination steps do not block access to buyer-owned artifacts.
Person / 02
Use evidence states that show what is missing
A positive provider statement is not the same as buyer inspection or a signed commitment. Keep the state next to the claim.
- SeenBuyer-inspected evidenceThe buyer viewed the document, interview, sample, or permitted verification result and recorded its date.
- PublicPublicly statedAn official page makes the statement, but it may describe the provider or a general process rather than the proposed person.
- ProposalProposal requiredThe buyer needs a written person-specific commitment covering identity, allocation, location, hours, or substitution.
- OpenNot evidencedNo adequate source has been inspected. Keep the item open rather than converting an assumption into a fact.
Person / 03
Tie the interview to the real work boundary
A generic quiz can test recall. A route-specific discussion tests whether the person can work inside the buyer's ownership, access, and release model.
System reasoning
Ask for a safe technical walkthrough
Describe one relevant module or integration boundary. Ask how the person would inspect it, isolate risk, test a change, document assumptions, and decide when to escalate.
Delivery behaviour
Ask how work becomes releasable
Ask what evidence belongs on a ticket, who should review a change, how a failed acceptance check is handled, and what the person needs from the buyer.
Evidence limit
Ask what the example cannot prove
A strong answer separates direct experience, team experience, assumptions, and areas that need another specialist. Record those limits with the strengths.
Working model
Test the proposed collaboration window
Confirm the normal workday, overlap, ceremonies, response expectations, planned leave, and escalation route with the person, not only the account contact.
Person / 04
Treat substitution as a new verification event
A continuity clause should explain the process. It should not state that an unknown replacement is automatically equivalent.
- 01
Notice
Record who gives notice, the expected timing, and any urgent exception.
- 02
Evidence
Receive the proposed replacement's CV, role evidence, location, hours, and allocation.
- 03
Approval
Repeat the interview, access, conflict, and buyer approval checks that matter to the role.
- 04
Transfer
Set an overlap period, artifact list, walkthroughs, open-risk review, and acceptance owner.
Next field tool
Put the verified plan into contract and access terms
Use the contract and exit checklist to connect the named person to the legal counterparty, IP terms, data boundary, repository controls, privileged access, offboarding, and exit artifacts.