Building the Implementation Team

A Team Is More Than a List of Available People

An implementation can have a full organization chart and still lack the people needed to make it succeed.

The consultant may know the application but not the business process. The process owner may understand the operation but have no authority to approve a change. The architect may support several projects and be unavailable when a critical design decision is needed.

These are team-design problems before they become schedule problems.

Chapter 8 established the conditions for a controlled start. This chapter examines how to build and sustain the team that will carry the implementation from Discovery through Hypercare and Continuous Improvement.

The starting point is the work and the outcome, not the list of people currently free to join. A strong team brings together business knowledge, solution capability, delivery discipline and the authority to act.

All examples and staffing illustrations in this chapter are fictional. They show how to reason about a team, not a universal staffing ratio.

9.1 Design the Team Around the Implementation

Begin with the approved scope, deployment strategy, solution complexity and delivery plan. Identify the capabilities required to produce and accept the major deliverables.

A single-entity rollout using mostly standard processes needs a different team from a multi-country program with complex integrations and extensive data remediation. The number of users alone does not describe that difference.

Review the team through People, Process, Data and Technology. Who understands how work is performed? Who can decide how it should change? Who owns the data? Who can configure, integrate, test and support the solution?

Then examine the connections. A purchasing process may cross procurement, warehouse operations, finance and an external supplier platform. Separate specialists are necessary, but someone must ensure that their decisions form a working end-to-end process.

Create a capability map before assigning names. This makes gaps visible and reduces the temptation to redesign essential responsibilities around whoever happens to be available.

9.2 Establish Customer and Partner Ownership

The implementation partner contributes delivery methods, solution expertise and execution capability. The customer owns business priorities, operating decisions, data meaning and acceptance of the resulting business capability.

That division is not a reason to work in separate camps. It is a basis for productive collaboration.

Pair the partner's workstream lead with a customer process owner or authorized business lead. They should share a view of the outcome while retaining their distinct responsibilities.

For example, the consultant can explain configuration options and their implications. The business owner decides which approved operating policy should apply. The architect assesses cross-solution consequences, and the project manager coordinates the decision within the plan.

A partner cannot compensate indefinitely for absent customer ownership. Equally, assigning work to the customer does not remove the need for clear guidance, preparation and agreed completion criteria.

Make the joint working model visible in the organization chart and responsibility matrix. The business should know whom to approach, and the delivery team should know who can decide.

9.3 Define Roles Before Allocating Individuals

A role describes a contribution to the implementation. A person may hold more than one role, but each responsibility still needs explicit ownership.

Define the expected outputs, decision authority, required capability, time commitment and interfaces for each important role.

Scale the model to the project. A smaller implementation may combine project management and delivery coordination, or assign one specialist to several related functional areas. Combining roles should be a deliberate decision based on workload and capability.

Check for conflicting responsibilities. A person who builds a component should not be its only reviewer for high-risk quality or control decisions. Where the team is small, arrange proportionate independent review through another qualified person.

Titles alone are insufficient. “Lead consultant” can mean business-process authority, technical leadership or senior configuration capability in different organizations. Define what it means on this project.

9.4 Distinguish Delivery, Architecture and Business Authority

The project manager owns coordination of the delivery plan and the controls assigned to that role. The solution architect maintains coherence of the solution. The business owner is accountable for the relevant operating decision.

These responsibilities interact, but they should not be collapsed into one informal approval channel.

Consider a request to introduce an additional approval step. The business owner explains the control need. The functional lead identifies options. The architect assesses effects on integrations, security and maintainability. The project manager coordinates any scope, effort or schedule impact.

The authorized change approver then decides if a material change can proceed under the agreed governance model.

This prevents two common problems: a project manager making design decisions solely to protect a date, and a technical specialist committing the business to an operating policy without authority.

Decision rights should make collaboration easier. They should not require every routine question to pass through several layers of management.

9.5 Assess Capability with Evidence

Certifications and years of experience provide useful context, but the assignment needs evidence of relevant capability.

Ask candidates to explain a comparable implementation: the scope, their actual role, a difficult decision, the alternatives considered and the result. Distinguish personal contribution from the wider team's achievement.

Use a practical scenario where appropriate. A functional consultant might explain how a purchase return affects inventory and finance. An integration specialist might discuss retries, duplicate messages and support diagnostics. A migration lead might walk through reconciliation and exception ownership.

Assess communication as part of delivery capability. Can the person explain an option to a business user without concealing uncertainty? Can they identify when they need help?

Build a simple skills matrix with capability areas, required proficiency, evidence and development actions. Avoid reducing people to an unexplained numerical ranking.

Where a capable person lacks one relevant area of experience, plan mentoring or specialist review. A development opportunity becomes a delivery risk when the support needed to make it work is omitted.

9.6 Select Business Representatives Who Can Represent the Business

The best-known user is not automatically the right process owner. The most available employee is not automatically the right subject-matter expert.

Business representatives should understand normal transactions, important exceptions, local constraints and the effect of decisions on other teams. They also need access to the people whose work they represent.

A head-office participant may not understand night-shift warehouse work. A regional finance representative may not speak for every legal entity. Identify where additional representation is required rather than assuming one person covers every context.

Separate participation from approval. A subject-matter expert can provide evidence and recommendations while a process owner retains the decision. Make that distinction clear in workshop invitations and action records.

Protect their time with line-management agreement. Participation should be planned as real work, including preparation, reviews, testing and training responsibilities.

When the project asks the business to contribute, it should explain the purpose, expected effort and decision required.

9.7 Use RACI to Clarify Work and Decisions

A RACI matrix identifies who is Responsible, Accountable, Consulted and Informed for a defined activity or decision.

For this chapter's model, assign one accountable role per row. If several approvals are required, separate the decisions into different rows or record the specific approval sequence. This avoids hiding distinct authorities inside a shared letter.

R = Responsible; A = Accountable; C = Consulted; I = Informed. R/A means the role both performs and owns the activity. This selected-role example must be expanded for the actual project, including architecture, security and other required contributors. It does not grant authority beyond the agreed governance model.

The matrix is a working agreement, not a substitute for discussion. Ask the named roles whether they understand and accept the responsibilities.

Use precise rows. “Data migration” is too broad if source cleansing, technical loading and business reconciliation have different owners. Splitting them reveals the actual handoffs.

Revisit the matrix when scope, deployment waves or staffing changes. An out-of-date responsibility chart can create more confusion than no chart if the team assumes its assignments are still valid.

9.8 Plan Capacity by Role and Time Period

A headcount total can hide a shortage in the one role required to complete a critical activity.

Plan demand by role, activity and period. Include preparation, reviews, defect correction, documentation and knowledge transfer. Compare this demand with confirmed project availability after other commitments and leave.

The following illustration shows one week's planned work. Availability is already net of other assignments; the demand includes the project activities listed for that week.

The team has 98 available hours against 102 hours of demand, an aggregate gap of four hours. However, the integration specialist is short by eight hours and the process owner by four. The functional consultant's eight spare hours cannot automatically cover either gap.

The practical response must address the roles: reschedule a dependent activity, secure qualified support, protect additional business time or reduce the authorized work planned for the period.

Do not treat overtime as the default capacity model. If exceptional additional hours are agreed, keep the period bounded and account for fatigue, review quality and subsequent availability.

This connects team planning with the effort and duration distinctions established in Chapter 6.

9.9 Adjust the Team Across the Lifecycle

The same staffing pattern will not fit every stage. Discovery needs business participation and analysis. Solution Design needs architectural decisions and cross-workstream review. Build and Configuration needs sustained functional and technical execution.

Data Migration and Testing increases demand for data owners, test leadership, business testers and defect-resolution capacity. Business Readiness requires change and training capability. Cutover and Go-Live require coordinated operational coverage.

Hypercare needs people who can diagnose real transactions, make controlled corrections and transfer knowledge to support. Continuous Improvement needs business ownership and an agreed route for prioritizing future work.

Plan these transitions in advance. Releasing a developer immediately after build may leave no capacity for integrated-test defects. Bringing a training lead in only after the solution is complete may leave too little time to prepare users.

Use a rolling role forecast linked to upcoming milestones. Refine it as the design and remaining work become clearer, while preserving the approved baseline and recording material changes.

9.10 Organize Collaboration Around End-to-End Processes

Workstreams help manage expertise, but business transactions do not stop at workstream boundaries.

Assign coordination of important end-to-end scenarios. For order-to-cash, the relevant leads need to examine order entry, fulfillment, billing, financial posting and reporting together.

Use shared walkthroughs and demonstrations before formal integrated testing. These reveal whether local decisions fit together while changes are still manageable.

Agree how work is handed over. A development item should carry reviewed requirements, acceptance criteria and relevant design decisions. A test handover should include the deployed version, configuration assumptions and known limitations.

Encourage direct discussion between specialists and business representatives within agreed boundaries. The project manager needs visibility of consequential decisions, but should not become the messenger for every technical or functional exchange.

Capture outcomes in the project records so that informal collaboration produces durable decisions rather than private knowledge.

9.11 Make Multiple Partners Work as One Delivery Team

When several suppliers contribute, each may have its own contract, plan and escalation structure. The customer still needs one working business solution.

Identify an integration owner for the overall delivery plan and explicit owners for cross-party interfaces. This coordination role does not automatically grant authority over another party's commercial commitments.

Agree joint milestones, test responsibilities, access needs, incident routes and the evidence required at handoffs. Confirm how changes in one supplier's work will be assessed by affected teams.

For example, an external platform change may require interface updates, new test data and regression testing in the enterprise application. A local completion report is insufficient if those dependent activities remain unplanned.

Maintain a shared dependency view, while respecting each party's contractual boundaries. Bring commercial owners into decisions that change those boundaries.

The aim is clear coordination without pretending that different agreements have become one agreement.

9.12 Establish Working Agreements for Distributed Teams

Distributed delivery requires explicit arrangements for communication and continuity.

Agree overlap hours for collaboration, expected response times for different types of requests and the location of work records. Consider time zones, local holidays and operational shifts.

A handover between locations should state what was completed, what remains, which version or environment was used and what decision is needed next. “Please continue” is not enough.

Rotate inconvenient meeting times where practical rather than placing the same burden on one group throughout the project. Record decisions for people who cannot attend.

Distinguish an urgent operational incident from a routine project question. Constantly labeling requests urgent erodes the team's ability to respond when urgency is real.

Review whether the working arrangement is effective through missed handoffs, delayed decisions and rework. More meetings are not necessarily the answer; clearer information and ownership may solve the problem.

9.13 Build Trust and Address Conflict Early

A team needs to be able to report a problem before it becomes expensive.

Leaders establish this expectation through their response. If raising a risk results in blame, people learn to delay the conversation. If a concern receives a fair review and a clear decision, early reporting becomes useful.

Set expectations for respectful challenge. A consultant should be able to question an unnecessary customization. A business representative should be able to explain why a proposed standard process fails an essential operational need.

Bring disagreement back to evidence, outcomes and constraints. Separate the person's intent from the delivery question. Record the decision and unresolved consequences through the agreed governance route.

Do not confuse a supportive environment with an absence of accountability. Missed commitments still need examination, corrective action and follow-through.

A dependable team combines openness about problems with clear ownership of the response.

9.14 Onboard for Context, Not Only Access

New team members need to understand why the project exists, what has been agreed and how their work connects to the rest of the solution.

Provide the relevant scope, process context, architecture decisions, delivery plan, standards and open risks. Explain the role's authority, expected outputs and escalation route.

Assign a named person to support the initial transition. Use a walkthrough of a real project scenario and ask the incoming colleague to explain it back in their own words.

Give them a bounded first assignment with a review point. This exposes missing context early and helps calibrate support without making the person responsible for a critical deliverable before they are ready.

For privileged access, confirm the role requirement and the approval process. Access should follow assigned responsibilities and change when those responsibilities change.

Onboarding is complete when the person can contribute safely and understands when to seek help, rather than when every orientation meeting has been attended.

9.15 Reduce Dependence on Single Individuals

A project is vulnerable when only one person understands an integration, data rule or critical configuration.

Identify these concentrations of knowledge before planned leave or staff changes. Assign a qualified backup and allocate time for paired work, documentation and independent execution.

Knowledge transfer should include the reasoning behind decisions, known limitations and recovery steps. A folder of documents is useful, but it does not prove that someone else can perform the work.

For example, the backup integration specialist should be able to inspect a failed message, explain its business effect and follow the approved recovery procedure in an appropriate environment.

Plan overlap for role transitions and confirm the replacement's readiness. A change of name in the resource plan does not transfer capability instantly.

Treat support-team involvement as part of this continuity plan. Sustainable implementation reduces the business's dependence on the original project team.

9.16 Measure Team Effectiveness Through Delivery Evidence

Utilization shows how time is assigned or consumed. It does not, on its own, show whether the team is producing accepted outcomes.

Review indicators such as deliverable quality, rework, decision turnaround, blocked work, dependency fulfillment and the readiness of people receiving handovers.

Interpret those measures in context. A high defect count may reflect weak build quality, stronger testing or newly clarified requirements. Investigate the cause before using the number to judge a person.

Avoid ranking individuals by raw ticket counts or hours worked. Different roles and task complexities make such comparisons misleading and can encourage activity that does not improve the implementation.

Discuss performance issues privately and specifically. Identify the expected output, the evidence of the gap, the support required and the next review point.

Use team-level evidence to improve the working model as well. Persistent delays may arise from unclear decisions or overloaded business owners rather than individual effort.

9.17 The Delivery Leader's View

A delivery leader builds a team that can make progress without depending on constant intervention.

That requires clear responsibility, suitable capability, realistic capacity and permission to act within agreed boundaries. It also requires knowing when escalation is necessary.

Before adding more people, ask what is actually constraining delivery. The answer may be specialist capacity, incomplete inputs, excessive work in progress or a decision that only the customer can make.

Before removing someone from the plan, examine the remaining lifecycle work and the knowledge they hold. A short-term saving can create a larger gap during testing or hypercare.

The next chapter, Governance and Decision-Making, develops the mechanisms through which this team makes timely, accountable decisions. The team must first have the people and authority needed to use those mechanisms.