Team decisions / Partner selection
Choose the team you can see working.
A nearby location can make coordination practical, but it does not establish engineering quality or delivery ownership. Evaluate the people proposed for your work, how decisions move between teams and what happens when a change, incident or departure interrupts the plan.
Start with your working relationship
Turn a supplier claim into something you can inspect.
Choose a nearshore development partner by checking relevant capability, actual working overlap, delivery evidence, supplier risk, continuity and the full commercial arrangement. Use the same brief for each candidate and record what remains unproven. Geography is one operating constraint; the proposed team and responsibilities determine what you are evaluating.
- A company capability is not a team assignment
- Ask which people or roles are proposed, who employs or contracts them, who leads their work and what remains subject to hiring or substitution. A strong demonstration by another team is background evidence.
- Nearby does not specify working overlap
- Put the actual working hours, decision windows, holidays and escalation coverage on a dated calendar. Test the arrangement with the people who will need to exchange decisions.
- A good trial leaves open questions
- A bounded exercise can reveal how a team works. It cannot establish long-term reliability or settle contract, security and staffing conditions that were outside its scope.
Six diligence areas
Ask for evidence that changes the selection decision.
Scale the effort to the work's importance and exposure. Let suppliers protect confidential client material through redaction or an agreed demonstration; do not require them to disclose another customer's secrets.
Relevant people and capability
01Buyer question: Can the proposed contributors handle the difficult parts of this work?
- Useful context
- The brief identifies the systems, constraints and judgments that matter.
- Request
- Proposed roles, relevant experience, availability assumptions and the substitution process.
- Try together
- Discuss one design tradeoff with the intended technical lead and contributors.
- Buyer responsibility
- The client's technical owner assesses relevance and remaining support needs.
- Inspect
- Explanations tied to actual artifacts, including limitations and lessons from failures.
- Unresolved concern
- The sales team demonstrates expertise that the assigned team has not shown.
- Before starting
- Confirm who is assigned, what is conditional and how replacements are reviewed.
Working overlap and communication
02Buyer question: Can decisions move without either team repeatedly waiting overnight?
- Useful context
- Both sides know which discussions need live participation and which can be asynchronous.
- Request
- Dated working hours, holiday coverage, response expectations and escalation contacts.
- Try together
- Exchange an unclear requirement, a written decision and a review request using the intended tools.
- Buyer responsibility
- The product owner supplies timely business answers and names a deputy.
- Inspect
- A clear question, recorded assumptions and a decision another colleague can follow.
- Unresolved concern
- An office time zone is offered instead of the assigned team's actual schedule.
- Before starting
- Agree decision windows and exception handling, including seasonal clock changes.
Delivery and quality
03Buyer question: Can this team turn a requirement into an explainable, maintainable change?
- Useful context
- The exercise includes the integration and failure behavior relevant to the real project.
- Request
- A redacted change history, review example, test evidence and release explanation.
- Try together
- Trace a small change from question through review, failure handling and acceptance.
- Buyer responsibility
- The technical lead sets acceptance evidence; the business owner accepts behavior.
- Inspect
- Tests address the actual risk and a colleague can explain why the change is safe to proceed.
- Unresolved concern
- Only a polished screen is shown, with no review or failure evidence.
- Before starting
- Agree the review process, release authority and treatment of defects.
Supplier, access and data boundaries
04Buyer question: Do we understand the entities and systems involved in delivery?
- Useful context
- The buyer has classified the information and access needed for the proposed work.
- Request
- Contracting entity, subcontractors, processing locations, access needs and relevant assurance evidence.
- Try together
- Walk through an access request and a hypothetical security incident with the responsible contacts.
- Buyer responsibility
- Security, privacy and commercial specialists assess the actual arrangement.
- Inspect
- Controls apply to the proposed service and there is a named route for reporting changes or incidents.
- Unresolved concern
- A certificate or regional label is treated as proof that every requirement is satisfied.
- Before starting
- Resolve material gaps before access and maintain checks through the relationship.
Continuity and ownership
05Buyer question: Could another authorized team maintain the work if a contributor or supplier left?
- Useful context
- Repository, environment and operating responsibilities are explicit from the start.
- Request
- Account ownership, replacement cover, build instructions, dependency records and handover responsibilities.
- Try together
- Have a receiving engineer explain or reproduce a change from the supplied artifacts.
- Buyer responsibility
- The application owner accepts the handover and assigns ongoing operation.
- Inspect
- The receiving person can use the materials without relying on an undocumented private account.
- Unresolved concern
- A single person holds essential context or transition is postponed until termination.
- Before starting
- Agree a workable transition plan and specialist review of rights and contractual obligations.
Commercial and responsibility fit
06Buyer question: Are the proposals pricing the same work and the same ownership?
- Useful context
- The buyer distinguishes supplied capacity from responsibility for an accepted delivery outcome.
- Request
- Scope, assumptions, exclusions, change treatment, internal effort and transition costs.
- Try together
- Apply the same scope change and contributor replacement scenario to each proposal.
- Buyer responsibility
- The budget and commercial owners assess affordability and the proposed terms.
- Inspect
- The price basis matches the work, dependencies and responsibilities each side can control.
- Unresolved concern
- A lower rate conceals missing review, management, testing or support responsibilities.
- Before starting
- Resolve exclusions and change rules before using the headline price to decide.
Keep a selection record
An unanswered condition is still unanswered after scoring.
For each candidate, record evidence, scope, date and the next decision. Use evidenced, conditional or unresolved labels. Decide essential conditions before comparing preferences so that an attractive price cannot hide a missing owner or unacceptable exposure.
| Area | Evidence to attach | Condition to record | Decision owner | Do not assume |
|---|---|---|---|---|
| People | Proposed team's relevant work | Assignments still conditional | Engineering lead | A company portfolio proves staffing |
| Communication | Calendar and decision exchange | Uncovered decision windows | Product owner | Proximity provides coverage |
| Quality | Reviewed change and failure test | Untested integration or operation | Technical lead | A demo proves maintainability |
| Supplier risk | Entities, access and control scope | Outstanding specialist review | Risk owner | A badge settles requirements |
| Continuity | Receiving engineer's handover check | Missing rights, access or context | Application owner | Files alone constitute transfer |
| Commercial fit | Comparable scope and cost basis | Exclusions and change assumptions | Budget owner | Rates represent total cost |
An illustrative working exercise
Follow one renewal change through the handoff.
Suppose an account-renewal workflow must send exceptional renewals for approval. The following exercise is a suggested evaluation method, not a client case or a requirement to commission a pilot. Agree scope, compensation, rights and evaluation criteria if asking for new work.
- 01
Give each candidate the same boundary
Supply a synthetic renewal record, the existing interface and the requested approval behavior. State the available buyer support and what the exercise will not test. Keep private customer data and production access out of the example.
- 02
Leave a real question to resolve
Ask how an exception threshold should apply when a renewal changes midway through review. Observe whether the team identifies the policy decision, explains the implementation choices and seeks an answer from the owner.
- 03
Inspect the proposed change
Review the design, or a bounded implementation if agreed, with the intended contributors. Ask how they would test the rule, prevent duplicate approval requests and explain the change to a maintainer.
- 04
Interrupt the handoff
Consider an unavailable approval service and an absent reviewer. Follow what is recorded, who is notified and how the request resumes. Keep technical recovery separate from permission to approve the renewal.
- 05
Write the selection decision
Attach the observed artifacts to the comparison record. Note which people participated, remaining conditions and who can resolve them. Select, request specific further evidence or decline; do not turn a limited exercise into a blanket endorsement.
From selection to operation
Carry the evidence into the agreement.
NCSC guidance treats supplier assurance as a lifecycle activity spanning assessment, selection, contract terms, ongoing review and termination. The checks below are practical applications to this software-team scenario.
- Reconfirm the assigned team
- Record changes between the selection exercise and mobilization. If the proposed lead or contributors change, revisit the evidence that depended on them rather than assuming the replacement has been evaluated.
- Make buyer obligations visible
- Name the people who supply business decisions, review work and authorize releases. Match those responsibilities to realistic capacity on your side. A supplier cannot compensate indefinitely for an unavailable owner.
- Keep assurance specific
- Check the relevance, date and scope of supplier evidence. Track changes to subcontracting, access and operating arrangements. NIST's SP 1326 publication overview identifies supplier due diligence as covering more than foundational cybersecurity alone, including provenance and stability.
- Practise a manageable transition
- Choose a small maintenance task for a receiving colleague and repair missing context early. The Sourcing Playbook's transition guidance supports planning responsibilities and handover before contract end; its public-sector procurement rules are outside this article's scope.
Questions before choosing
Make the answer specific to the proposed work.
These questions help separate a workable arrangement from a persuasive presentation.
- What should we check first in a nearshore partner?
- Start with your work and retained responsibilities, then check the proposed people and relevant evidence. Establish essential conditions for access, ownership and continuity before comparing rates or softer preferences.
- How much time-zone overlap is enough?
- There is no universal number. Identify the live decisions, review sessions and incident coverage your work needs, then check whether actual schedules support them. Include holidays and seasonal clock changes, and test asynchronous handoffs for the remaining hours.
- Should we always run a pilot?
- No. Existing artifacts, technical discussions and references may answer a proportionate question. A bounded exercise is useful when material uncertainty remains and its scope, cost and ownership are agreed. It provides evidence only for what was actually tested.
- Does a European location settle data protection or security?
- No. Assess the specific entities, people, processing locations, subcontractors, systems and access involved. Ask appropriate specialists to review your requirements and the actual arrangement. This article makes no compliance determination.
- How do we compare a cheaper proposal fairly?
- Normalize scope, responsibility, duration and assumptions. Include your own management and review effort, testing, tools, support and transition. Ask how each proposal handles the same change scenario, then keep unresolved exclusions visible beside the price.
Source basis
Sources behind the control model.
- 01
NIST
SP 1326: due diligence assessment quick-start guideJuly 2026 final publication overview and abstract reviewed. Establishes the breadth of ICT supplier due diligence; the full guide was not used for detailed assessment instructions.
- 02
NCSC
Embed cyber security controls throughout the contract's durationLifecycle guidance for supplier risk, controls, monitoring and termination. It informs assurance questions, not a claim that a particular supplier is secure.
- 03
GOV.UK
The Sourcing PlaybookSelected testing, supplier assessment, commercial and transition sections reviewed. Page updated June 2026 but contains older procurement-reform wording. Used for operating principles only, not current legal requirements.
- 04
GOV.UK Service Manual
Working with contractors or third partiesGuidance on relevant skills, team integration, necessary access and knowledge transfer. Government service context, not evidence of regional supplier performance.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD