By applying Agile development and project management methods we can improve overall customer satisfaction by increasing customer interaction throughout the project without sacrificing scope control and quality.
The Agile methodology helps the customer to gradually understand and accept the new system whilst providing constructive feedback and suggestions to the implementation team throughout the project.
This article will focus mainly on the high-level phases of Agile. A later article will discuss the detailed project management and the resource management side of Agile.
The term Agile originates from Agile Software Development which is a software engineering methodology that focuses on interactive development and regular working releases.
The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The above makes sense not only in a software development but also in ERP implementations. In order to ensure the Agile manifesto applies to an implementation we need to apply an Agile project management method.
Agile Project Management
There are several Agile project management methods but let’s have a closer look at Scrum as an example. There are many flavours of Scrum as it was originally made for product development but from a high level we can say there is three phases in a Scrum project lifecycle:
· Pre-game Phase – project initiation with requirements and high-level planning
· Development Phase – multiple development cycles (Sprint’s) delivering working product releases
· Post-game Phase – project go-live with deployment and documentation delivery
In this phase the business and non-functional requirements are put into a prioritised list of features called the Product Backlog – essentially forming the project scope and high-level project plan.
The Product Backlog should only define what is needed:
So no huge scope or requirements document but merely a list of customer needs. In my experience this makes sense as it is impossible to define all requirements up-front – even for an out of the box solution especially when the make of the future system is unknown.
The original Scrum methodology states that anyone on the project can update the Product Backlog with new requirements and any defects or issues encountered. On an ERP project – where the team is huge and defects and/or issues can run into the 100s – I would refrain from this approach and rather treat the Product Backlog as being under change control to avoid scope creep. The defects and issues could be places in a separate Issue Backlog or similar.
This phase contains multiple development cycles – each called a Sprint. Each Sprint delivers a product release with new features as defined in the Sprint Backlog, which is a subset of features from the Product Backlog and any previous defects or issues to be resolved from the Issue Backlog:
Each Sprint contains analysis; design; build; test and delivery.
Each ERP Sprint would encompass:
· Sprint Backlog – subset of Product Backlog features
· Application Design – configuration planning
· Configuration – cloning if needed; configure and unit test items in Sprint Backlog
· User Acceptance Test – user test and acceptance of items in Sprint Backlog
Multiple Sprint cycles can operate in parallel if they are delivering independent features. For example can customisations be considered as an independent Sprint cycle.
The number of Sprint’s will vary depending on project size and complexity. But for example a minor project could be arranged like this:
1. Core features – chart of accounts; ledgers and user security
2. Basic features – sub-ledger transactions; posting; reporting and journals
3. Advanced features – intercompany, multicurrency and consolidation
4. Development -customisations; interfaces and data migration
Where Sprint 4 could be run in parallel with Sprint 3 if the customisation is independent of these features.
So a small implementation is around 4-5 sprints.
Each Sprint cycle duration would be around 3-4 weeks.
In accordance to the Scrum methodology each Sprint requires the user to test and accept the delivered features. So the Scrum methodology provides a rolling User Acceptance Test (UAT) ensuring a more balanced approach to acceptance and project completion.
The user also incrementally learns about the system and can therefore better provide constructive feedback for both the current as well as the next Sprint cycle.
Commercially this is also good approach as each Sprint is having an UAT the payment milestones would naturally match the Sprint cycles.
This phase deploys the last Sprint release into production and the documentation is delivered.
This is similar to a normal implementation project where the last tested configuration is deployed.
The documentation can be generated automatically or manually as on a normal ERP implementation as part of each UAT:
The benefit of Agile/Scrum is that the go-live leap should be smaller as the UAT has been a progressive experience rather than a big bang.
The Phased Implementation – Looking Back
Still to this day the normal way of implementing ERP systems is to use the phased implementation model with a known method like Oracle Application Implementation Method (AIM); Oracle Unified Method (OUM) or similar.
The typical waterfall phases are:
Several environments are delivered from design to production with the final test being the User Acceptance Test (UAT) for final signoff before going live.
The phased implementation models are characterised by complicated project plans and documentation flows. It is often unclear what is a deliverable and what is a work product and how this tie in with the commercial contract.
Anyone who has been a part of a large phased implementation knows the following symptoms:
· Requirements are missed
· Loads of paper being produced
· Deadlines are missed
· Communication failures
· Payment disputes
· Fear of going live
Some newer implementation methods are leaning towards being agile – like the Oracle Business Accelerator (OBA) which speeds up the delivery of the first working instance but the remaining phases are still similar to AIM.