The pathfinder playbook

The first live projects test more than software. They reveal how quickly the business can approve data access, whether users have time for testing, and who takes responsibility when a release has a problem.

We call these projects pathfinders. Each should deliver something useful while testing a part of the delivery process that later work will depend on.

Choose projects that teach you different things

A small, feasible use case can exercise scoping, approval, testing, and release without a long build. A more demanding one can test process redesign and adoption. A project with difficult data can expose unresolved ownership or access questions.

If generative AI is part of the plan, include a use case that tests retrieval quality, output evaluation, and human review. Those requirements may differ from the forecasting or reporting work the team already knows.

You do not need a separate project for every category. Select a manageable set that tests the delivery steps you need to establish, and avoid choosing complexity just to test the process. Each project still needs its own business case.

Assign the receiving team before the build

Name the production owner and agree the support arrangements. Decide which parts of delivery internal staff will lead and where they will work alongside a partner.

Write operating instructions while the work is happening. Include data sources, monitoring, access, release procedures, and the steps to take when performance changes. Have the people who will use those instructions check them.

Increase internal responsibility as the team becomes ready. Different skills may develop at different speeds; the handover plan should reflect that.

Review the project and the delivery process

At each review, assess whether the project still has a sound case: what testing shows, what costs have changed, and whether users and support teams are ready.

Then examine how the work moved. Where did the team wait for a decision? Was an approval clear enough to act on? Did a handoff lose context? Did a data issue arrive later than it should have?

Assign someone to fix the recurring problems before the next project reaches the same point. That might mean changing an intake question, naming an approver, or updating a release checklist.

Leave a process the team has used

By the end of the first set, the delivery guide should describe how the work actually runs. Check that the internal team can take a use case through review and release, and can investigate a failure using the documentation provided.

Any remaining support from a partner should have a defined purpose. The next project should begin with fewer unanswered questions about how to deliver it.