Evaluating a Software Vendor, the Project Manager's Role and an Onboarding Playbook

Teams that run into trouble with external engineers rarely have a talent problem. They have a selection problem or an onboarding problem. Both are fixable, and neither takes much budget compared with the cost of a failed engagement.

Evaluating a vendor

Look for evidence of process, not slogans. Ask how work moves from requirement to release. Good vendors can show you artefacts: a backlog with acceptance criteria, architecture decision records, test reports, release notes and a risk log. If a vendor cannot show examples from past work (suitably anonymised), treat that as information.

Talk to the people who will do the work. Interview the proposed lead, architect and key engineers, not only the sales team. Ask them to walk through a past problem: what they decided, what went wrong and what they would change.

Check references that resemble your situation. Industry, scale and regulatory context matter. Ask references what happened when something went wrong, because that tells you more than a smooth story.

Understand the governance model. Ask about quality frameworks and delivery standards in use, such as CMMI or ITIL practices, and how they appear in day-to-day work rather than on a certificate wall. Ask who is accountable for delivery and escalation.

Clarify security and IP. An NDA before sensitive material is shared, IP assignment in the contract, access through your own accounts where possible, and a clear offboarding procedure.

Probe time zones and communication. Ask which working hours will overlap with yours, how handovers are written and who is reachable when something breaks.

Read the commercial terms for flexibility. Notice periods, replacement terms and how scope changes are handled. Pricing should be explained in terms of scope, duration and the seniority of the people involved.

What a good project manager does

A project manager is not a status-report secretary. In a healthy engagement they:

• Turn goals into a plan and keep it honest as facts change.
• Run sprint planning, reviews and retrospectives so the team keeps learning.
• Surface risks early, with options, rather than late with excuses.
• Protect the team from churn and shield your stakeholders from noise.
• Keep scope, budget and time visible and negotiate trade-offs openly.
• Own the relationship between the client and the team, including the awkward conversations.

If you are engaging a dedicated team, insist on meeting the project manager before you sign. If you are using staff augmentation, decide who on your side plays this role, because someone has to.

An onboarding playbook

Before day one

• Grant access to repositories, trackers, chat and environments, using least privilege.
• Prepare a short pack: product overview, users, architecture diagram, coding standards, definition of done and a glossary.
• Name a buddy for each newcomer.

Week one

• Walk through the product as a user would see it.
• Run the system locally and deploy to a test environment. Fixing the setup guide as you go is a valuable first contribution.
• Introduce the team and agree the communication rhythm: daily check-in, weekly demo and where questions should go.
• Assign a small, real task with a clear finish line.

Weeks two to four

• Increase task size gradually and pair newcomers with existing engineers on reviews.
• Hold a short retrospective at the end of the first sprint to ask what is unclear, slow or missing.
• Share the why behind the work: customers, constraints and the roadmap, not only tickets.
• Agree how performance will be assessed and give feedback early and often.

By the end of the first month

• The team should be able to take, deliver and review work independently.
• Documentation gaps found during onboarding should be fixed.
• Both sides should review whether the model, team shape and working hours are right, and adjust.

Common mistakes

• Treating external engineers as a ticket queue. People who understand the purpose make better decisions.
• Skipping access preparation. Days lost waiting for permissions set the wrong tone.
• No single decision-maker. Conflicting priorities from several stakeholders slow every team.
• Judging too early or too late. Review after two sprints with clear evidence, and act on what you find.

In short

Select a vendor on evidence, give the team a capable project manager and invest a few weeks in onboarding. The return shows up for the remainder of the engagement.