e-Commerce, change management, project & programme management, it, logistics, supply chain & retail

Project Management Methodologies

Current Trends in ERP

The latest versions of ERP systems and the recommended methodologies that come from the companies that provide those systems are moving away from the traditional waterfall project management methodologies. Some of the ERP systems are designed in such a way that to deliver the ERP the built-in project management tools that come with the ERP package need to be used, potentially dictating the methodology to be used.

Agile methodologies are being strongly advocated to rapidly deploy vanilla or templated ERP system. This system is then populated with the business’ data (or sample thereof), key users trained and extensive workshops run with the users to identify changes to the current business practices to fall in line with the solution demonstrated; or changes to the system are identified which are subsequently developed to meet the requirements of the business.

These methodologies can be highly successful, with the business changing to operate with the ERP rather than developing costly changes to the ERP. Changes to the ERP system are typically considered only for legal requirements and those changes which deliver measurable advantage (cost or opportunity) for the business. It should be noted that all ERP implementations require bespoke work regardless of the business’ ability to adapt to ERP. Interfaces to other systems are always regarded as bespoke developments and there will be other areas which need customisation to deliver competitive advantage.

However, compared to traditional requirements gathering methodologies (waterfall), the business has to invest significantly (both in terms of time and cash) in these early stages in the project before a final cost and duration can be accurately estimated. This lack of early clarity can cause nervousness with the senior stakeholders of the business as these measures are traditionally what will be reviewed when making a decision to progress with the programme as part of the business case.

Agile vs Waterfall

Agile methodologies have evolved to overcome a number of problems inherent within the waterfall methodology:

• Typically, waterfall projects report as being on track for the bulk of their projected time and costs with problems only becoming manifest towards the end of the project.
• Waterfall projects typically deliver no business benefit until the project is completed.
• It is the general experience of businesses that project plans and Gant charts rarely follow their initial design, requiring several project re-planning exercises within the lifespan of the project.
• The business environment is subject to change and the existing plans may become irrelevant in the light of that change.

Agile methodologies concentrate on delivering something quickly. In the context of the ERP implementation this could be functional areas such as the sales and marketing function or a procurement function. The business decides on its priorities and the top priorities are targeted for a rapid delivery cycle. This is then repeated until the programme completes. This overcomes the inherent problems within the waterfall methodology.

• Problems are brought to light during each cycle and therefore early in the programme.
• Business benefit is delivered with each cycle.
• Overall re-planning is never required as no detailed up-front plan is prepared.
• Environmental change can be accommodated in future cycles.

Complexity and Dependency

Agile methodologies do not perform well in environments that are highly complex and have a significant number of dependencies both within the programme and to the environment outside of the programme. It can become almost impossible to deliver anything within a short cycle as a result of the complexity and interdependency. Highly integrated landscapes which require a significant number of external interfaces to the ERP typically fit into this category.

In the case of complexity and dependency robust and highly detailed project plans are worth creating. With the acceptance that all programmes suffer problems and complex and highly dependent areas within a programme will suffer more, the project plan becomes a valuable tool to manage these problematical areas. Impact, what-if, critical path analysis and resource allocation can all be handled quickly and easily should the situation becomes fluid.

It needs to be understood that a project plan is a management tool and is not a construct that is put in place at the beginning of a project to be rigidly adhered to. They are valuable tools to manage the delivery of change in a complex and interdependent programme.

Overall Architecture

One of the risks of Agile methodologies is that the overall architecture of the solution could be overlooked. As each business priority is delivered during the cycles it is possible that the interactions between the areas is not fully delivered. An end to end approach to business functions (such as order to cash or purchase to pay) can mitigate this.

Conflicting requirements from delivered business priorities can also result in problems appearing in overlapping areas. Even with an end to end approach this is possible; for example, order to cash and purchase to pay both interact with supply chain and logistics functions and could have conflicting requirements. Using agile methodologies requires a strong and skilled solution architect to identify these areas and to deliver overall solutions.

Cutover

The complexity of the cutover from legacy to the ERP solution, even in a phased implementation, must not be handled with agile methodologies and a robust cutover project plan needs to be developed. The plan needs testing and dress rehearsals to provide confidence that that actual cutover event(s) will be successful. Failure to plan adequately in this area risks extended business downtime of critical business functions.

Prince2

Prince2 has been described as a waterfall methodology, however, this is not the case. The Prince2 disciplines do not dictate any project management methodology and Prince2 is an overarching structure to provide predictable outcomes to projects managed in differing ways. It could be described more accurately as a governance model to allow a programme to be accurately tracked, risks and issues highlighted early and to provide a structure for the continual validation of the programme’s objectives and its continued operation.

The key principles of Prince2 support both agile and waterfall methodologies:

• Continued business justification.
• Manage by exception.
• Learn from experience.
• Manage by stages.
• Focus on products (tangible deliverables).
• Tailoring [the Prince 2 methodology to meet the needs of the project].

Using Prince2 within an ERP programme continues to be desirable and will improve the chances for project success and accepted delivery. Splitting the ERP programme into several individual projects and applying the pertinent project management methodologies that are appropriate to stages of these projects provides a robust strategy for the delivery of the ERP.

Consideration should be given to the following areas for managing as separate projects, depending on programme size and complexity:

• Data migration and cleansing.
• Integration.
• Testing.
• Training.

As has been detailed earlier, up to 70% of ERP programmes fail. Aside from project governance the main reasons for failure are the areas listed above and should be planned carefully as a result.

Cost Benefit and Other Considerations

The current trends in ERP make a traditional cost benefit analysis difficult, since the actual costs are unlikely to be known early enough for this to justify the initiation of a project. Estimates can be used, using costs for similar projects for the shortlisted ERP software for consideration. However, with new methodologies, tools and changes to the required expertise these models are likely to have wide tolerance ranges built into the business case.

There is benefit in also considering other measures when deciding to initiate a programme to support a business case with wide tolerances:

• Capability. Will the delivered solution bring new capabilities or reduce weakness in business areas that will significantly increase the value of the business?
• Sturdiness. Will the solution reduce the risk of business loss due to downtime?
• Agility. Will the solution deliver rapid response to unknown future conditions?

Success criteria for the programme need to be documented to represent all of the influencing factors for starting the programme, ideally weighted according to the importance of the factors. Doing so will allow the business case tolerances of the standard cost benefit model to be viewed in the context of other important benefits.

Business Benefit Realisation

As has been discussed, the trends within ERP are to deliver business benefit early within the programme. Careful consideration needs to be given to actual business benefit that will be yielded when delivering the solution in phases.

Typically, businesses have key areas that give them competitive advantage. However, it is often these areas that require the most customisation making earlier delivery less likely. The same is also true for new capabilities. Business benefit also comes from automation of tasks but introducing phased solutions can reduce the effectiveness of the interaction between differing business functions or systems. Interfaces, that will not be required in the completed solution, will be needed to overcome this, but at additional cost.

Existing Landscape

A detailed understanding of the existing business landscape will help target those areas where early business benefits can be realised and prioritised accordingly. Discrete systems or business units within the existing landscape are often good candidates for early implementation within the programme lifespan. Complexity and dependency can be analysed to highlight those areas where agile may prove problematical.

Enabling functions, which improve efficiencies, as other functions are delivered should also be given key considerations. The finance functions are at the heart of any ERP and are a good candidate for the first of a phased ERP delivery. Most finance functions can be easily managed with vanilla ERP systems once configured and if the legacy finance systems are stand-alone there will be no requirements for temporary interfaces to maintain business efficiency.

Phased Implementation Costs.

Extra costs around a phased implementation of an ERP must be given careful consideration in both the prioritisation of the phasing as well as the scheduling of the phasing. It could be worth delaying the phases that would deliver the most business benefit until some enabling functions are in place so as to reduce the wasted spend associated with phased implementation.

Executive Considerations

Senior executives and managers within the business should consider the strategic business objectives and plans in conjunction with any proposed ERP programme. How is the business primarily targeted to increase in value? M & A? Increased sales? Improved margins? Lower operating costs? Where will the bulk of the value be realised?

Timing of the programmes within the business needs to be considered. Should the ERP programme be delayed until a time of greater business stability? Should other business programmes be delayed or accelerated to provide a window of stability for the ERP programme? Delivering an ERP in a highly changeable environment risks significant variability from projected costs and timelines and if no other options remain these risks should be planned for accordingly.

Resourcing for the project is likely to require skill sets not currently within the business. Unless individuals within the business have been an integral part of the delivery of an ERP programme in the past, external resources will be required. New technologies introduced with the ERP will also require expertise.

Business involvement in the programme should not be underestimated. Ideally a dedicated team of existing business resource will be allocated to the project and backfilled accordingly. There will be significant time required from these individuals and several activities are likely to take up 100% of their time while being executed:

• Workshops and system demonstration.
• Training.
• User acceptance testing (and preparation).
• Cutover dress rehearsal.
• Data cleansing and validation.

Poor business engagement in any programme is a cause of programme failure. Time dedicated to the programme from the business shortens the time for two-way knowledge transfer.

Both business knowledge of the ERP and partner knowledge of the business increase over time. Rapid partner understanding of the business and business understanding of the ERP improves quality within the programme and lowers programme risk.

Organisational change is needed in all ERP projects. An ERP primarily delivers its benefits via the organisation, with some roles disappearing, some roles changing and new roles appearing. An early appreciation of the organisational design requirements and subsequent business communication reduces go-live staff turnover risk and improves business engagement.

Big i Consulting Ltd.



We use google analytics cookies on this website.
By using this site, you agree that we may store and access google analytics cookies on your device

Close this entry