Building Your Internal Implementation Team: Roles, Skills, and Resource Allocation

Your ERP system is only as good as the team implementing it. You can select the perfect software, negotiate a brilliant contract, and secure executive buy-in, but if you staff your project with the wrong people or assign unclear responsibilities, you’re setting yourself up for delays, budget overruns, and user frustration. The difference between a smooth go-live and a painful one often comes down to who’s in the room and what they’re accountable for.

Why team structure makes or breaks your ERP project

Most failed implementations don’t collapse because of bad software.

They fail because nobody knew who was supposed to make final decisions. Or because the finance team never had time to document their processes. Or because IT assumed the business would handle change management while the business assumed IT would.

Your implementation team isn’t just a list of names on a RACI matrix. It’s the engine that drives configuration decisions, manages vendor relationships, resolves conflicts, and keeps your organisation moving forward when things get complicated.

And things always get complicated.

The executive sponsor who actually sponsors

Every ERP project needs an executive sponsor, but not every sponsor understands what the role demands.

This person sits at C-level or one step below. They control budget, remove roadblocks, and make binding decisions when departments disagree. A strong sponsor attends weekly steering meetings, communicates project importance to the wider organisation, and protects the team from scope creep driven by every department head’s wish list.

A weak sponsor signs the initial paperwork and disappears until go-live.

The difference shows up six months in when your finance director wants to add three custom modules, your warehouse manager refuses to attend training sessions, and your project manager needs someone with authority to say no.

Your sponsor should commit 3-5 hours per week minimum. Less than that, and you don’t really have a sponsor.

Project manager versus project owner

These roles sound similar but serve different functions.

The project manager runs day-to-day operations. They maintain timelines, coordinate meetings, track deliverables, manage risks, and keep everyone accountable. This person needs strong organisational skills, ERP implementation experience, and the ability to push back when vendors promise unrealistic deadlines.

The project owner (sometimes called project lead) bridges business and technology. They understand your company’s processes deeply, translate business requirements into technical specifications, and make configuration decisions that align with strategic goals. This person typically comes from operations, finance, or a core business function rather than IT.

Some organisations combine these roles. That works in smaller implementations but creates bandwidth problems in complex projects.

Your IT team’s actual responsibilities

IT doesn’t run the entire implementation, but they handle critical technical foundations.

System administrators manage infrastructure, security, integrations, and technical troubleshooting. They work closely with your implementation partner on server setup (if on-premise), database configuration, user access controls, and system monitoring.

Integration specialists connect your ERP to existing systems like CRM, e-commerce platforms, or legacy databases. Poor integration planning causes more post-go-live headaches than almost any other factor.

Technical analysts handle data mapping, custom reports, and workflow automation. They need to understand both your business logic and the ERP’s technical architecture.

Many Singapore SMEs understaff the IT side, assuming the vendor handles everything. Vendors configure the ERP, but they don’t know your network topology, security policies, or how your warehouse barcode scanners connect to your systems.

Budget for at least 1-2 dedicated IT resources throughout implementation.

Subject matter experts who know how work actually happens

Subject matter experts (SMEs) are the people who currently do the work your ERP will eventually automate or streamline.

You need SMEs from every major business function:

• Finance and accounting
• Supply chain and procurement
• Inventory and warehouse management
• Sales and customer service
• Manufacturing or operations (if applicable)
• HR and payroll

These aren’t senior managers who used to do the work five years ago. They’re current practitioners who understand the messy reality of daily operations, including all the workarounds, exceptions, and informal processes that never made it into your official documentation.

SMEs typically commit 10-15 hours per week during requirements gathering and configuration, then ramp up to 20-30 hours during testing and training phases.

The biggest mistake? Treating SME participation as optional or expecting them to contribute “when they have time” without backfilling their regular duties. If your best warehouse coordinator is supposed to help design your new inventory module but still has to process 200 daily shipments, guess which one gets priority?

The change manager nobody thinks they need

Change management isn’t just “being nice to people who don’t like change.”

A change manager develops communication strategies, identifies resistance points, creates adoption plans, and measures user engagement throughout implementation and beyond. They work with department heads to address concerns before they become blockers.

Singapore organisations often skip this role, assuming technical training is enough. Then they’re surprised when go-live happens and half the team keeps using spreadsheets because “the old way was faster.”

The most successful implementations I’ve seen all had one thing in common: someone whose entire job was making sure people understood why we were changing, what they’d gain, and how we’d support them through the transition. Technical training teaches people how to click buttons. Change management gives them a reason to care.

For implementations affecting 50+ users, budget for a dedicated change manager. Smaller projects can assign this to the project owner, but don’t let it become an afterthought.

Training coordinators and super users

Your vendor will provide system training, but they won’t understand your company’s specific workflows, terminology, or edge cases.

Super users are department champions who receive advanced training, then support their colleagues during and after go-live. They’re the first line of support for “how do I…” questions and help identify issues that need vendor escalation.

Select super users based on:

• Strong understanding of current processes
• Respect from colleagues (people actually listen to them)
• Patience and teaching ability
• Willingness to commit extra time

Plan for one super user per 10-15 end users, depending on complexity.

Training coordinators develop internal training materials, schedule sessions, track completion, and adapt vendor training to your specific configuration. They work closely with super users to create job aids, process guides, and quick reference materials in language your team actually uses.

Data migration lead and team

Data migration is where good intentions meet messy reality.

Your data migration lead coordinates the extraction, cleaning, mapping, and loading of data from legacy systems into your new ERP. This includes customer records, vendor information, product catalogues, pricing, inventory levels, open orders, and historical transactions.

This role requires:

1. Deep knowledge of your current data structure
2. Understanding of data quality issues (and there will be issues)
3. Ability to make judgment calls about what data actually needs to migrate
4. Technical skills for data transformation and validation

Most organisations discover their data is messier than expected. Duplicate customer records. Products with inconsistent naming. Pricing stored in three different places with three different values.

Allocate 15-20% of your total project timeline just for data migration activities. Trying to rush this phase creates problems that haunt you for years.

The implementation partner relationship

Your vendor’s implementation team isn’t part of your internal team, but the relationship determines success.

You need a clear division of responsibilities:

Your Team Handles	Vendor Team Handles
Business requirements definition	System configuration and customisation
Process documentation	Best practice recommendations
Data extraction and cleaning	Data import tools and validation
User acceptance testing scenarios	Technical testing and bug fixes
Change management and internal communications	System training and documentation
Integration requirements	Technical integration development
Go-live decision making	Go-live technical support

The best implementations happen when both teams respect each other’s expertise. Your vendor knows the software. You know your business. Neither can succeed without the other.

Assign one person (usually the project manager or project owner) as the primary vendor contact. Funnelling communication through a single point prevents mixed messages and ensures nothing falls through cracks.

Building your team structure step by step

Here’s how to staff your ERP implementation in the right sequence:

1. Secure executive sponsorship first. No sponsor, no project. Get commitment before you do anything else.

2. Hire or assign your project manager. This person builds out the rest of the team structure and timeline.

3. Identify your project owner. Choose someone with business credibility and strategic thinking ability.

4. Map required SMEs to your implementation scope. If you’re not implementing HR modules, you don’t need HR SMEs yet.

5. Assign IT resources based on technical complexity. Cloud implementations need less infrastructure support than on-premise.

6. Add change management and training roles. These often get pushed to phase two, which is too late.

7. Select super users from each department. Do this early so they can participate in configuration decisions.

8. Recruit your data migration team. Start data assessment immediately, even if migration happens months away.

Contractor versus permanent staff considerations

Should you hire contractors or use internal resources?

Permanent staff advantages:

• Deep knowledge of company processes and politics
• Available for long-term support after go-live
• Invested in getting it right because they’ll live with the results
• No ramp-up time to understand company culture

Contractor advantages:

• Bring ERP-specific experience from other implementations
• Available for intensive project phases without long-term commitment
• Can fill skills gaps your permanent team lacks
• Easier to scale up and down as project needs change

Most successful teams blend both. Use permanent staff for roles requiring company knowledge (project owner, SMEs, super users) and contractors for specialised skills (project manager with ERP experience, integration specialists, data migration experts).

For Singapore businesses, understanding how to prepare your organisation for ERP implementation success helps clarify which roles need permanent versus temporary staffing.

Time allocation and resource planning

Here’s the uncomfortable truth: ERP implementations fail when team members are expected to do implementation work “in their spare time.”

Full-time dedication (100% allocated):
– Project manager
– Project owner (during peak phases)
– Data migration lead (during migration phases)

Significant commitment (40-60% allocated):
– SMEs during requirements and testing
– IT system administrators during technical setup
– Super users during training development

Moderate commitment (20-30% allocated):
– Executive sponsor
– Change manager
– Training coordinator

Periodic involvement (10-20% allocated):
– SMEs during non-peak phases
– Department heads for approvals and decisions
– End users during testing

If you can’t backfill these people’s regular duties, your timeline needs to account for reduced availability. A project plan assuming full-time SME participation when they’re really only available 10 hours per week is fiction, not planning.

Skills matrix for each role

Different roles need different capabilities. Here’s what to look for:

Executive Sponsor:
– Strategic thinking and decision-making authority
– Political capital to drive organisational change
– Budget control and resource allocation power
– Ability to communicate vision and importance

Project Manager:
– ERP implementation experience (ideally in similar industries)
– Strong organisational and time management skills
– Risk identification and mitigation capabilities
– Vendor management experience
– Conflict resolution abilities

Project Owner:
– Deep business process knowledge
– Ability to translate business needs into requirements
– Cross-functional perspective
– Decision-making confidence
– Technical aptitude (doesn’t need to code, but should understand system logic)

SMEs:
– Current hands-on process experience
– Detail orientation and documentation skills
– Willingness to challenge “we’ve always done it this way” thinking
– Ability to envision process improvements
– Communication skills to explain nuances to technical teams

Change Manager:
– Stakeholder management experience
– Communication and presentation skills
– Understanding of change psychology
– Ability to measure and report adoption metrics
– Empathy combined with persistence

Common staffing mistakes that derail projects

Mistake 1: Treating implementation as an IT project

ERP implementations are business transformation projects with significant IT components. When IT leads without strong business partnership, you get technically sound systems that don’t match how people actually work.

Mistake 2: No dedicated resources

“Everyone will contribute 10% of their time” sounds collaborative but results in nothing getting done. Someone needs to wake up every morning with this project as their primary responsibility.

Mistake 3: Choosing availability over capability

The person who has time isn’t always the person who should do the job. That junior accountant might be available, but if they don’t understand your full financial close process, they’ll miss critical requirements.

Mistake 4: Ignoring succession planning

What happens if your project manager leaves mid-implementation? If your star SME gets promoted? Build redundancy into critical roles and document everything.

Mistake 5: Underestimating change management needs

Technical skills get you to go-live. Change management gets you to actual adoption and ROI. Skimping here costs you later.

Scaling team size to project complexity

Not every implementation needs a 15-person team.

Small implementations (single module, under 25 users):
– Executive sponsor
– Project manager/owner (combined role)
– 2-3 SMEs
– 1 IT resource
– 2-3 super users

Medium implementations (multiple modules, 25-100 users):
– Executive sponsor
– Project manager
– Project owner
– 4-6 SMEs across functions
– 2-3 IT resources
– Change manager (can be part-time)
– Training coordinator
– 5-8 super users
– Data migration specialist

Large implementations (full ERP suite, 100+ users, multiple locations):
– Executive sponsor
– Steering committee (3-5 senior leaders)
– Project manager
– Project owner
– 8-12 SMEs across all functions
– 3-5 IT resources including integration specialists
– Dedicated change manager
– Training team (2-3 people)
– 10-15 super users
– Data migration team (2-4 people)
– Communications specialist

Scale these numbers based on your specific situation. A manufacturing company implementing production modules needs more SMEs than a services firm implementing finance and CRM.

When to bring in external expertise

Some skills are hard to find internally, especially in Singapore’s competitive talent market.

Consider contractors or consultants for:

• Project management if nobody internal has ERP implementation experience
• Integration development for complex connections to legacy systems or third-party platforms
• Data migration if your data situation is particularly messy or you’re consolidating multiple systems
• Change management if this is your first major transformation and internal HR/comms teams lack experience
• Industry-specific expertise for specialised requirements (regulatory compliance, industry best practices)

The decision often comes down to how much ERP implementation really costs, including whether temporary expertise provides better value than permanent hires you may not need post-implementation.

Governance structure and decision-making authority

Clear governance prevents the “too many cooks” problem.

Steering Committee (meets monthly or bi-weekly):
– Executive sponsor (chair)
– Department heads from major affected areas
– Project manager
– Senior vendor representative

Responsibilities: Budget approvals, scope change decisions, escalated issue resolution, strategic direction.

Project Team (meets weekly):
– Project manager (chair)
– Project owner
– SME leads
– IT lead
– Change manager
– Vendor project lead

Responsibilities: Day-to-day decisions, progress tracking, risk management, resource coordination.

Working Groups (meet as needed):
– Functional SMEs
– Super users
– Technical specialists

Responsibilities: Detailed configuration decisions, testing, documentation, training development.

Document decision-making authority clearly. Who can approve a process change? Who decides if a customisation is necessary? Who has final say on go-live readiness?

Ambiguity here creates bottlenecks and frustration.

Measuring team effectiveness throughout implementation

How do you know if your team structure is working?

Track these indicators:

• Decision velocity: How long does it take to resolve questions and make choices?
• Milestone achievement: Are you hitting planned dates or constantly rescheduling?
• Issue resolution time: How long do problems sit unaddressed?
• Vendor relationship quality: Is communication smooth or constantly fraught?
• Team morale: Are people engaged or burning out?
• Scope control: Are you adding features or staying focused?

If decisions take weeks instead of days, you probably lack clear authority structures. If milestones keep slipping, you might have resource allocation problems. If people are working weekends regularly, your time estimates were unrealistic.

Address team structure problems early. Waiting until you’re three months behind schedule makes fixes much harder.

Preparing your team for post-implementation life

Your team’s role doesn’t end at go-live.

Plan for ongoing support:

Hypercare period (first 4-8 weeks after go-live):
– Keep most team members at high availability
– Rapid issue response and resolution
– Intensive user support
– Process refinement based on real-world usage

Stabilisation phase (months 2-6):
– Gradual return to normal duties
– Super users handle most day-to-day questions
– Project team addresses larger issues
– Begin measuring benefits realisation

Continuous improvement (ongoing):
– Regular system optimisation
– New feature adoption
– Process refinement
– Periodic training refreshers

Some team members transition to permanent ERP support roles. Others return to their original positions but maintain system expertise. Plan these transitions deliberately rather than letting everyone disappear the day after go-live.

Your team is your competitive advantage

Technology is increasingly commoditised. The major ERP platforms all offer similar functionality. Your implementation partner probably works with your competitors too.

Your team is what makes the difference.

The right people, with clear roles, proper support, and genuine authority, turn a software purchase into business transformation. They make smart configuration choices, manage change effectively, and build something that actually works for your organisation.

Invest in getting your team structure right from the start. It’s the foundation everything else builds on.