What a partner brings
Experienced partners have run many projects, so they know where problems arise, which design choices cause trouble later, and how to sequence the work. They bring specialists you could not justify hiring full time, and capacity to move quickly. They also bring an outside view that challenges assumptions. This is most valuable in the design phase, where mistakes are expensive to reverse.
- Experience with common pitfalls and proven approaches.
- Specialist skills such as integration, data migration, or industry knowledge.
- Capacity to deliver within a defined timeline.
What an in-house team brings
Your people understand the business, the exceptions, the politics, and the history. They will live with the system for years, so their ownership and skills matter long after the project ends. Building internal capability also reduces long-term dependence on outside help. The risk is that internal staff are usually busy with their day jobs, so project work competes with operations, and their experience with implementations may be limited.
The hybrid model
Most successful projects combine both. A partner leads design, handles the technically demanding parts, and reviews the internal team's work, while internal staff handle data cleanup, testing, training, and day-to-day decisions. Define the division of responsibilities clearly, so nothing falls between the two. Include knowledge transfer from the start, with internal staff shadowing partner work and documenting what they learn.
Managed and advisory services →How to assess your own capacity honestly
List the hours each team member can truly give, taking into account their regular responsibilities and likely interruptions. Compare that with the work involved: requirements, design decisions, data, testing, training, and change management. Note the skills you already have and the ones you lack. If the capacity gap is large or the skills gap is in a critical area such as integration or accounting design, lean toward more partner involvement.
Consulting and advisory services →Cost, risk and the hidden costs of each path
Partner fees are visible; internal costs are not. Internal time, rework from avoidable mistakes, delays, and the opportunity cost of staff pulled from operations are real costs. Conversely, a partner relationship has its own risks: dependence, miscommunication, and knowledge that leaves with them. Compare scenarios on total cost and risk, not on the invoice alone, and decide where outside expertise most reduces the risk of costly mistakes.
Decisions to settle before choosing
- Critical skills. Identify the areas where a mistake would be most costly and ensure experienced people cover them.
- Ownership after go-live. Decide who will administer and improve the system, and build capability accordingly.
- Division of work. Write down which tasks the partner and your team each own.
- Knowledge transfer. Plan documentation and shadowing as part of the project, not as an afterthought.
A realistic way to proceed
- Weeks 1 and 2. Assess capacity and skills, and define the scope and critical risks.
- Weeks 3 and 4. Discuss models with two or three partners, comparing how each would divide the work.
- Week 5. Choose a model, write the responsibility split into the plan, and define knowledge transfer.
Pitfalls to avoid
- Assuming the partner will handle everything. Business decisions, data, and adoption remain your responsibility.
- Assuming the team can fit it in. Without protected time, project work loses to daily urgencies.
- Unclear responsibilities. Tasks without a named owner do not get done. Write the split down.
- No knowledge transfer. A system nobody inside understands becomes a dependency.
