Consider an ERP proposal with a recognizable partner name, certified consultants and an attractive headline price, but no confirmed functional lead or technical lead. The procurement decision is not yet whether the price is acceptable. It is whether the supplier has demonstrated who will deliver the work and under what conditions.
Use credentials to build the shortlist, then verify the proposed people, their availability and the delivery responsibilities before signing. Francesco Perrotta cautions that a large partner's reputation does not automatically translate into a well-delivered project. He describes some partners struggling to allocate personnel because they have too many projects.
This is a supplier-verification exercise after the decision to proceed. If that investment decision remains unresolved, first use the framework for deciding whether to improve or replace your ERP. Here, the task is narrower: establish whether a particular proposal represents a credible delivery commitment.
Evaluate the people who will do the work
Perrotta's advice is to investigate a consultant's actual experience, not just the résumé. He emphasizes the competence demonstrated in an initial conversation and the ability to discuss projects the person has completed. Turn that observation into a working session with the proposed delivery leads, rather than another sales presentation.
Ask the functional lead to explain a critical business process using your operating context. Ask the technical lead to identify its data, integration and environment dependencies. The project manager should explain how decisions, unresolved requirements and delivery risks will be controlled. Assess the reasoning, including the questions they ask before recommending a solution, rather than fluency with product terminology alone.
Use a hypothetical scenario: an external application sends a transaction to the ERP successfully, but the business posting fails. Ask the team to explain how it would investigate, who would own reconciliation, how an exception would reach the business owner, and who would authorize recovery. For proposal evaluation, the important distinction is between demonstrating message transfer and accepting responsibility for the complete business outcome.
A convincing answer identifies boundaries and unresolved assumptions. A weak answer promises that “the integration team handles it” without naming that team or describing its authority. If the proposed leads cannot attend the evaluation, ask when you can assess them and make the unresolved staffing decision explicit before approving the supplier.
Separate credentials, references and contextual fit
In a manufacturing-focused ERP selection webinar, a speaker explicitly offering a vendor perspective recommends checking partner authorization, certifications and similar-industry implementation experience. Treat this as vendor-influenced manufacturing advice, not a universal rule that only a particular partner category can deliver.
For your procurement, verify what the claimed status actually establishes for the selected product and scope. Separately ask the team to demonstrate configuration, integration and business-process understanding. The webinar distinguishes product expertise from domain expertise, including understanding how departments connect and where master data originates. A badge and a process walkthrough answer different questions; neither should substitute for the other.
References should also test the proposed team, not merely the firm's history. Dreher Consulting's partner-vetting method specifically calls for reference conversations with customers served by the same delivery consultants. Ask which proposed people worked on the reference project, what they owned, and whether they remained involved when difficult issues arose.
Then examine relevance: which workflows, integrations and customer responsibilities resembled yours? Ask what required escalation, how substitutions were handled, and what the customer would clarify in the next contract. If confidentiality prevents a detailed reference discussion, agree an alternative way to verify experience. Do not silently treat a firm-level case study as evidence about an individual consultant.
Apply the same scrutiny to ERP-vendor professional services and independent implementation partners. The webinar presents both as options and raises external-system integration knowledge as a consideration. Where product access is decisive, request evidence of the proposed team's escalation route. Where adjacent applications dominate the risk, request evidence of interface expertise and handoff ownership. Neither organizational model deserves an automatic preference.
Convert proposed staffing into an availability commitment
Perrotta's warning about overcommitted teams points to a distinction worth checking: competence and availability are separate questions. His account concerns partners with too many projects and customers unable to reach the person they need. Interviewing a strong consultant therefore should not close the staffing review.
Request a resource schedule identifying the functional leads, technical lead, project manager and other critical specialists. For each, ask for planned involvement by phase, expected start, allocation, competing commitments and backup coverage. Distinguish confirmed assignments from roles that remain subject to recruitment or another project's completion. “Access to our expert pool” is not the same answer as an assigned person with a defined role.
Next, reconcile the resource schedule with the agreement. An eFutures CFO paper on implementation partner selection describes a provision requiring notification and client approval before key personnel are substituted. Discuss that mechanism with procurement and legal counsel rather than assuming it exists in the proposal.
Ask how replacement competence will be assessed, who supplies handover, and how any resulting schedule or commercial impact will be agreed. Absolute promises that nobody will ever leave are less useful than a workable substitution process. If an essential lead is unavailable, require an assessed replacement or a revised delivery plan before treating the proposal as ready for approval.
Test responsibilities when the plan stops being convenient
The manufacturing webinar makes risk management concrete by asking what happens when customer data is missing or unclean, a department is unavailable, or someone on either side falls sick. Use those disruptions to test the proposed methodology. A diagram of project phases does not answer how the team will respond to a blocked dependency.
Request a responsibility schedule covering data extraction and cleansing, process decisions, business-user participation, testing, training and acceptance. For each dependency, record the supplier owner, customer owner, required input and decision route. If a finance lead cannot attend a design workshop, establish who can decide whether to reschedule, delegate or proceed with an explicitly recorded assumption.
Also ask for an escalation route that separates delivery decisions from commercial disputes. Identify who can resolve a cross-workstream issue, who can authorize additional work, and who receives a risk that the project manager cannot resolve. Request an example of the decision record the team would use, with confidential information removed where necessary.
Compare fixed-price delivery and staff augmentation as responsibility models, not cost winners. For a fixed-price proposal, test which deliverables and assumptions support the price, how acceptance works, and how changes or customer delays affect obligations. For staff augmentation, establish who directs the consultants, coordinates dependencies, accepts their work and owns the integrated plan. Prefer neither until the proposed allocation of responsibility matches your internal capacity.
If your organization wants supplier accountability for defined deliverables, ask whether the fixed-price terms actually provide it. If you want specialists working under your program leadership, test whether that leadership has the time and authority to supervise them. An unresolved scope does not disappear under a fixed price, and buying specialist capacity does not by itself establish delivery ownership.
Use an evidence checklist before approving the supplier
Keep the final comparison focused on evidence that can change the award decision. Use the following as an editorial decision aid, not a validated scoring model. Record each unresolved item with an owner and an agreed resolution before contract approval.
- Named leads: Have the proposed functional, technical and project leads demonstrated relevant competence?
- Relevant references: Can customers confirm what those people actually delivered in a comparable context?
- Availability: Are assignments, phase involvement and unresolved staffing dependencies explicit?
- Substitution: Is there an agreed approval, replacement and handover process for key personnel?
- Customer obligations: Are data, business-user availability and decision responsibilities assigned internally?
- Acceptance and change: Is it clear what constitutes completion and how disputed or additional work will be handled?
- Escalation: Do both parties know who can resolve delivery blocks and commercial consequences?
Keep supplier approval separate from permission to enter live operation. At contracting, establish who will prepare readiness evidence and participate in the release decision. Use the separate ERP go-live readiness review when assessing whether people and support capacity are ready to operate.
Before signing, reconcile the proposal, staffing schedule and statement of work in a joint review with the proposed delivery leads. Resolve any mismatch between the people presented, the availability offered and the responsibilities accepted.
If you are evaluating implementation partners or need functional consultants and developers, talk with Digiventi's ERP specialists about the roles, dependencies and delivery responsibilities your project requires.
