Case Study Sample: A Troubled ERP Implementation at a Mid-Size Manufacturer

Model Answer

Introduction and Context

Priorswood Precision Engineering Ltd is a fictional mid-size UK manufacturer, used here to illustrate a case study in enterprise resource planning (ERP) implementation. Based in the East Midlands and employing approximately 340 staff across two sites, Priorswood manufactures precision-machined components for the automotive and industrial equipment sectors, operating a make-to-order production model with a complex bill of materials and a supply chain spanning around 120 active suppliers. Eight months ago, the company went live with a new, integrated ERP system intended to replace a fragmented landscape of separate finance, production planning and inventory systems that had accumulated over two decades and were increasingly unable to support the business’s growth and reporting requirements.

The implementation, planned over fourteen months and delivered with the support of an external systems integrator, went live broadly on schedule but has, six months on, failed to deliver the benefits set out in its original business case. Production planners report that the system’s material requirements planning output is frequently unreliable, requiring manual cross-checking against spreadsheets the implementation was intended to eliminate; the finance team has identified recurring data quality problems in stock valuation; and a significant minority of shop-floor supervisors continue to operate informal parallel processes rather than relying on the new system alone. Staff turnover in the production planning team has also increased since go-live, which several remaining staff attribute directly to frustration with the new system. The board has commissioned this case study to diagnose the underlying causes of these problems and to recommend a remediation plan capable of realising the benefits the original business case anticipated.

The analysis applies Markus and Tanis’s (2000) ERP experience cycle, a widely used framework for understanding the distinct phases of an ERP implementation and the errors typically made at each, to trace how decisions taken during Priorswood’s project and shakedown phases have shaped the problems now being experienced, before applying DeLone and McLean’s (2003) updated information systems success model to structure a diagnosis of why the system, despite functioning technically, has not translated into the organisational benefits anticipated. As with the other cases in this series, Priorswood Precision Engineering Ltd is a fictional construct created for academic illustration and does not describe any real company; the pattern of problems described, however, is consistent with difficulties widely reported in the ERP implementation literature, where a majority of projects are reported to fall short of their original benefit expectations in the period immediately following go-live (Nah, Lau and Kuang, 2001; Ram, Corkindale and Wu, 2013).

The choice of systems integrator is itself relevant to the diagnosis that follows. Priorswood selected its integration partner through a conventional competitive tender weighted heavily towards licence cost and delivery timeline, with comparatively less weight placed on the integrator’s specific experience of make-to-order manufacturing environments; the integrator’s standard implementation methodology, developed principally around discrete and process manufacturing clients, was applied to Priorswood with only limited tailoring to its customer-specific bill-of-materials variants. This is a governance decision taken at the chartering stage, in Markus and Tanis’s (2000) terms, and its consequences, examined in detail below, illustrate how procurement choices made months before configuration work begins can constrain the quality of decisions available later in the project.

Case Background

Table 1 summarises the key stages of the Priorswood implementation and the approximate time and budget position at each, illustrating that the project was delivered close to its original schedule and budget in narrow project-management terms, even though the benefits case has not yet been realised.

The project phase itself, covering system configuration, data migration and testing, was delivered close to schedule and budget, and formal user acceptance testing was completed and signed off prior to go-live. However, the volume of user acceptance testing was concentrated heavily on core finance and procurement processes, reflecting the systems integrator’s standard implementation methodology, with comparatively limited testing time allocated to the production planning module, which project documentation shows was the area facing the greatest configuration complexity given Priorswood’s make-to-order model and complex bill of materials structure. Data migration for finance and inventory master data was validated thoroughly, but a full data-quality audit of legacy bill-of-materials and routing data, much of which had been maintained inconsistently across the previous fragmented systems, was not completed before go-live due to time pressure in the final weeks of the project phase.

Training was delivered through a standard programme of classroom sessions covering core system navigation and standard processes across all user groups in the four weeks before go-live, but did not include role-specific scenario-based training addressing the particular exceptions and edge cases production planners regularly encounter given Priorswood’s make-to-order model, where standard bill-of-materials logic frequently requires manual adjustment for customer-specific variants. Several production planners report that the training they received did not equip them to handle these exceptions confidently, contributing to their continued reliance on informal spreadsheet-based workarounds since go-live. No dedicated post-go-live hypercare or super-user support function was retained on-site beyond the first four weeks, after which support reverted to a standard helpdesk ticketing process with the systems integrator, which several staff describe as slow relative to the pace of problems they were encountering in the early stabilisation period.

Change management activity ran alongside the technical workstream but was scoped narrowly, focused on communicating the go-live date and high-level process changes rather than assessing readiness at the level of individual roles. A pre-go-live readiness survey was conducted for finance and procurement staff, whose managers reported high confidence, but no equivalent survey was extended to production planning, where managers’ confidence in staff readiness was, in retrospect, assumed rather than tested. This asymmetry mirrors the testing and training gaps identified above, and meant that the function best placed to flag the specific risk of inadequate exception-handling training, production planning’s own line managers, was not systematically consulted before go-live.

Analysis

Two complementary frameworks are applied: Markus and Tanis’s (2000) ERP experience cycle, to trace how decisions taken during the project and shakedown phases have produced the problems now observed, and DeLone and McLean’s (2003) updated IS success model, to structure a diagnosis of why the system has not yet translated into organisational benefit despite functioning technically.

Markus and Tanis’s ERP Experience Cycle

Markus and Tanis (2000) divide the ERP implementation experience into four phases: chartering, in which the business case and system are selected; project, in which the system is configured, data migrated and the organisation prepared for go-live; shakedown, the period from go-live until normal operations stabilise; and onward and upward, the longer-term period in which the organisation extends and optimises its use of the system. The framework’s central argument is that problems experienced during shakedown are typically not new problems but the delayed consequence of decisions, or omissions, made earlier in the project phase, becoming visible only once the system is in live use and cannot easily be revisited without disruption to ongoing operations.

Applied to Priorswood, the incomplete data-quality audit of legacy bill-of-materials and routing data during the project phase is a clear example of this pattern: the decision to prioritise finance and inventory data validation under time pressure, while reasonable given the project’s schedule constraints, deferred rather than eliminated the underlying data-quality risk, which has since surfaced during shakedown as the unreliable material requirements planning output reported by production planners. Similarly, the concentration of user acceptance testing on core finance and procurement processes, rather than the more complex production planning module, meant configuration issues specific to Priorswood’s make-to-order exceptions were not identified and resolved before go-live, when they could have been addressed with comparatively limited disruption, but instead became visible only once planners were relying on the system for live production decisions. Markus and Tanis (2000) note that shakedown-phase problems of this kind are typically harder and more costly to resolve than the same issues would have been during the project phase, precisely because the organisation is simultaneously trying to operate the business and fix the system, a dynamic clearly visible in Priorswood’s continued reliance on manual workarounds six months after go-live rather than a clean resolution during a dedicated stabilisation period.

The withdrawal of dedicated on-site support after four weeks is also significant in Markus and Tanis’s (2000) terms, since the framework emphasises that the length and intensity of the shakedown phase is highly sensitive to the level of support available immediately after go-live; organisations that under-resource this period, as Priorswood appears to have done relative to the complexity of its production planning requirements, typically experience a longer and more disruptive shakedown than those that retain intensive support until stabilisation is genuinely achieved, rather than withdrawing it against a fixed calendar date regardless of the organisation’s actual readiness.

DeLone and McLean’s IS Success Model

DeLone and McLean’s (2003) updated information systems success model proposes that IS success depends on the interaction of six dimensions: system quality, information quality, service quality, use, user satisfaction, and net benefits, with weaknesses in the earlier dimensions propagating through to reduce use, satisfaction and, ultimately, the benefits realised. Applied to Priorswood, the case suggests system quality is broadly adequate, the software itself functions as configured and has not experienced significant technical failure, but information quality is compromised by the unresolved bill-of-materials and routing data issues identified above, directly reducing the reliability of the material requirements planning output planners depend on. Service quality, particularly post-go-live support, is also weak, given the withdrawal of dedicated support after four weeks and the comparatively slow standard helpdesk process now in place.

These weaknesses in information and service quality are, in DeLone and McLean’s (2003) model, sufficient on their own to explain much of the reduced use and user satisfaction Priorswood is now experiencing: planners who have learned through direct experience that the system’s output cannot always be trusted, and who cannot quickly resolve the exceptions they encounter through existing support channels, rationally continue to rely on the parallel spreadsheet processes the implementation was intended to eliminate, since doing so is, from their individual perspective, the more reliable way to complete their work. This pattern is consistent with Petter, DeLone and McLean’s (2013) observation that use and user satisfaction in ERP contexts are driven less by the overall sophistication of the system than by users’ direct, repeated experience of whether it reliably supports their specific tasks, meaning that even a single, persistent data-quality problem in a critical module can undermine confidence in the system considerably more broadly than the scope of the underlying technical issue alone would suggest. Because reduced use, in turn, is a precondition for net benefits in DeLone and McLean’s (2003) model, Priorswood’s failure to realise its expected benefits six months after go-live is, on this analysis, a largely predictable consequence of the information and service quality gaps rooted in the project phase, rather than a separate or unrelated problem requiring an independent explanation.

A further, complementary perspective comes from the user-resistance literature. Klaus and Blanton (2010) argue that resistance to enterprise systems is best understood through a psychological-contract lens, in which employees form informal expectations, during the project phase, about how a new system will change their day-to-day work, and resist the system once its actual behaviour post-go-live violates those expectations, independent of the system’s objective technical quality. Applied to Priorswood, production planners who were told during training that the system would replace their spreadsheets, and who then found themselves needing those spreadsheets within weeks of go-live to manage exceptions the system handled poorly, plausibly experienced exactly this kind of psychological-contract violation, which helps to explain why frustration and turnover in the production planning team have been concentrated so specifically in that function rather than distributed evenly across the organisation. This reading does not compete with the analysis above so much as extend it, since psychological-contract violation and reduced information quality here trace back to the same underlying root: incomplete testing and validation of exactly the module where planners’ expectations were later broken.

Key Issues

Synthesising the two frameworks, four key issues emerge.

First, unresolved legacy data quality: incomplete validation of bill-of-materials and routing data during the project phase has surfaced during shakedown as unreliable material requirements planning output, directly undermining information quality and, through it, user trust in the system.

Second, under-tested production planning configuration: the concentration of user acceptance testing on finance and procurement processes left Priorswood’s most complex module, production planning, comparatively under-tested against the make-to-order exceptions planners encounter daily, meaning configuration issues are being discovered and resolved live rather than before go-live.

Third, insufficient post-go-live support: the withdrawal of dedicated on-site support after a fixed four-week period, rather than against evidence of actual stabilisation, has left staff without the responsive help needed to resolve exceptions confidently during the critical early weeks of live use, extending rather than shortening the shakedown phase.

Fourth, a resulting erosion of user trust and adoption: the combination of unreliable information and weak support has led a significant minority of staff to maintain informal parallel processes rather than relying on the system alone, which in turn means the master data those parallel processes were meant to replace remains inconsistently maintained, reinforcing the original data-quality problem in a self-sustaining cycle.

These four issues are best understood as a reinforcing cycle rather than a list of independent faults. Incomplete data validation and under-tested configuration originate from the same chartering- and project-phase decisions; insufficient post-go-live support then prevented either issue being resolved quickly once it surfaced during shakedown; and the resulting erosion of trust has caused staff to maintain the parallel processes that keep the underlying master data poorly maintained, feeding back into the original data-quality problem. Diagnosing the four issues separately is necessary to identify distinct points of intervention, but any remediation plan that addresses only one or two of them in isolation, for example improving support without also completing the data-quality audit, risks leaving the cycle intact and the remaining issues unresolved.

Recommendations

Five recommendations follow, sequenced to address the most foundational issue, data quality, before the adoption and trust issues that depend on it being resolved.

1. Complete a full bill-of-materials and routing data-quality audit. Commission a structured review of all production master data, correcting the inconsistencies deferred during the original project phase, directly targeting the information-quality weakness identified as the root cause of unreliable planning output.

2. Reinstate dedicated, scenario-focused support for production planning. Provide targeted, on-site super-user support specifically for the exceptions and make-to-order variants planners regularly encounter, addressing the service-quality gap identified through the DeLone and McLean (2003) analysis, with support retained until stabilisation is demonstrated through defined metrics rather than withdrawn against a fixed calendar date.

3. Deliver supplementary, role-specific training. Design and deliver scenario-based training addressing production planning exceptions specifically, rather than standard system navigation alone, closing the gap between the original generic training programme and the actual complexity of planners’ day-to-day tasks.

4. Formally retest the production planning module against real operating scenarios. Conduct a structured post-go-live testing exercise using real, complex Priorswood orders rather than the standardised test scripts used during the original project phase, identifying and resolving configuration issues the original, finance-weighted testing programme did not surface.

5. Actively retire parallel spreadsheet processes once data quality is restored. Once recommendations 1 to 4 are in place and evidenced through improved planning output reliability, formally withdraw support for informal parallel processes and require planners to work from the system directly, closing the self-sustaining cycle in which parallel processes both result from and perpetuate poor master data quality.

Implementation should prioritise the data-quality audit and reinstated support, recommendations 1 and 2, since these directly address the root causes identified through both frameworks, with training and formal retesting, recommendations 3 and 4, following closely behind; retiring parallel processes, recommendation 5, should be sequenced last and only once the underlying data and support issues are demonstrably resolved, since withdrawing planners’ fallback processes before then would remove their only currently reliable means of completing production planning tasks.

Implementing this plan is not without cost. A data-quality audit of the scope required will draw on staff time from the same production planning function already under pressure, and the board should expect a short-term dip in planning throughput while the audit is under way, a cost considerably smaller than the ongoing cost of unreliable planning output six months after go-live. Reinstating dedicated support will similarly require extending the contract with the existing systems integrator or building equivalent internal capability, adding to the original £1.85m project cost; the board’s central decision, however, is not whether to spend further, but whether to spend now, in a targeted way, to secure benefits already committed to, or to allow the current workaround to become permanent, at which point the original investment case would need to be considered to have failed.

Conclusion

This case study has examined the causes of the difficulties experienced at Priorswood Precision Engineering Ltd, a fictional mid-size UK manufacturer, six months after going live with a new ERP system. Applying Markus and Tanis’s (2000) ERP experience cycle indicates that the problems now visible during shakedown are largely the delayed consequence of decisions made earlier in the project phase, particularly incomplete data validation and testing concentrated away from the system’s most complex module, rather than new or unrelated failures. Applying DeLone and McLean’s (2003) updated IS success model suggests these information and service quality weaknesses are sufficient, on their own, to explain the reduced system use, weak user satisfaction and unrealised benefits the board has observed, without needing to invoke any deeper technical failure in the system itself.

This distinction matters for how the board interprets the six months since go-live. It would be a mistake to read the current difficulties as evidence that the ERP system itself was the wrong choice, or that the implementation programme failed in any conventional project-management sense; on the metrics of schedule and budget summarised in Table 1, the project succeeded. The more accurate reading, and the one this case study has sought to substantiate, is that project success and system success are separate constructs, and that Priorswood’s board approved a business case whose benefits depended on data-quality and support commitments that were, in practice, only partially honoured once delivery pressure intensified in the final weeks before go-live.

The recommendations proposed therefore centre on resolving the underlying data-quality and support gaps before addressing adoption directly, reflecting both frameworks’ shared implication that use, satisfaction and benefit are downstream consequences of information and service quality rather than problems that can be solved through user communication or mandate alone. The broader implication for Priorswood, and for organisations undertaking comparable ERP implementations, is that a project delivered on time and close to budget, as Priorswood’s project phase was, provides no guarantee of benefit realisation if data quality and support are under-resourced in exactly the areas of greatest operational complexity, a distinction between project success and system success that this case study has sought to make explicit through the frameworks applied above. As with the other cases in this series, Priorswood Precision Engineering Ltd and the figures presented are fictional constructs created for academic illustration and do not describe any real organisation.

References

• DeLone, W.H. and McLean, E.R. (2003) ‘The DeLone and McLean model of information systems success: a ten-year update’, Journal of Management Information Systems, 19(4), pp. 9–30.
• Davenport, T.H. (1998) ‘Putting the enterprise into the enterprise system’, Harvard Business Review, 76(4), pp. 121–131.
• Hong, K-K. and Kim, Y-G. (2002) ‘The critical success factors for ERP implementation: an organizational fit perspective’, Information & Management, 40(1), pp. 25–40.
• Klaus, T. and Blanton, J.E. (2010) ‘User resistance determinants and the psychological contract in enterprise system implementations’, European Journal of Information Systems, 19(6), pp. 625–636.
• Markus, M.L. and Tanis, C. (2000) ‘The enterprise system experience – from adoption to success’, in Zmud, R.W. (ed.) Framing the Domains of IT Research: Glimpsing the Future Through the Past. Cincinnati, OH: Pinnaflex Educational Resources, pp. 173–207.
• Nah, F.F-H., Lau, J.L-S. and Kuang, J. (2001) ‘Critical factors for successful implementation of enterprise systems’, Business Process Management Journal, 7(3), pp. 285–296.
• Petter, S., DeLone, W. and McLean, E.R. (2013) ‘Information systems success: the quest for the independent variables’, Journal of Management Information Systems, 29(4), pp. 7–62.
• Ram, J., Corkindale, D. and Wu, M-L. (2013) ‘Implementation critical success factors (CSFs) for ERP: do they contribute to implementation success and post-implementation performance?’, International Journal of Production Economics, 144(1), pp. 157–174.
• Robey, D., Ross, J.W. and Boudreau, M-C. (2002) ‘Learning to implement enterprise systems: an exploratory study of the dialectics of change’, Journal of Management Information Systems, 19(1), pp. 17–46.
• Soh, C., Kien, S.S. and Tay-Yap, J. (2000) ‘Enterprise resource planning: cultural fits and misfits: is ERP a universal solution?’, Communications of the ACM, 43(4), pp. 47–51.
• Somers, T.M. and Nelson, K.G. (2004) ‘A taxonomy of players and activities across the ERP project life cycle’, Information & Management, 41(3), pp. 257–278.