The intense industry debate of Waterfall vs Agile largely settled in favor of Agile in recent years. Transitioning to Agile has in fact been considered fundamental to an organization aspiring to undertake Digital Transformation journey. ERP implementation projects, including the implementation of Microsoft Dynamics 365 Finance, Supply Chain, or Dynamics 365 Business Central, have however remained largely waterfall, or CRP (Conference Room Pilot) – which we consider only a variation of waterfall. The waterfall vs Agile debate draws very strong reactions from the ERP practitioners – and for very solid reasons. Most practitioners rule out the possibility of Agile being a practical approach for ERP implementations.
Along with this strong opposition from practitioners of waterfall is however the overwhelming industry data showing that adoption of waterfall methodology is one of the key reasons for ERP implementation projects to fail. According to McKinsey – three-fourths of ERP transformation projects fail to stay on schedule or within budget, and two-thirds have a negative return on investment. Adoption of waterfall has been identified as one of the 5 key reasons for this failure.
Several inherent characteristics of an ERP implementation project make the adoption of copy-book Agile methodology a non-starter. The challenges of ERP implementation projects however continue to be serious enough for the industry to strive for a more reliable approach.
I discussed the subject with over a dozen seasoned practitioners in the last several weeks. The discussion outcomes however remained invariably unstructured. Before attempting to conceptualize a possible solution, I therefore felt a strong need to bring a structure to the conversations. This blog is an attempt to do just that. While I have started building a solution framework – which is likely to overcome several limitations of the Waterfall/ CRP and Agile (for ERP projects), this blog stays short of discussing that. The recommended approach – a hybrid-Agile will be the topic of an upcoming blog. To make this blog easier to read, I have structured it in a Q&A form, and I invite the believers and non-believers to share your thoughts.
1. Why are we spending time on this in the first place?
- Because we need to increase ‘certainty’ of project success
2. Why Agile?
- Absolutely no reason, except that it’s emerged as a very creditable alternate to Waterfall. And adoption of waterfall has been identified as one of the key reasons for ERP projects to fail.
3. Will copybook Agile work for ERP?
- No
4. What characteristics of an ERP project make usage of copybook Agile impractical?
- ERP projects are usually fixed cost, often result of a tender/ bid process, with presumably fixed scope and time. Copy-book Agile fixes Time and budget, the scope stays flexible.
- ERP projects start on top of a standard software, which might be a 70 – 80% fit. Agile (e.g. for a custom developed software) starts with discovery of User Stories for the entire system.
- When Agile says scope is flexible, it also says time and budget are fixed. New user stories can be added, only by swapping out something else. Scope creeps and CR are not accepted within the same sprints.
- Agile needs sprints to be user tested, and may be even put in to production. ERP requires an integrated system level testing before it can be put into production. The process of cut-over is very critical and significant for the organization, and usually can’t be done piece-meal.
- Agile asks for 100% dedicated team, and a dedicated customer side product manager, both of which become hard in practice.
5. What problems are inherent in the waterfall approach?
- Users are pushed in to identifying the system functions (requirements) at a time when they have very little clue of what’s right to expect. They also do not have sufficient idea about what to convey to the consulting team, and what’s not ok to assume.
- BPS/ FRD become very long, documentation intensive, and invariably incomplete, exercises. Many parts of these documents remain ‘write-only’.
- Teams progress to next stages of the project, assuming that the ‘incomplete’ FRD/ BPS is actually the ‘complete’ requirements description.
- Breaking a project in to horizontal layers (phases) results into communication gaps – which aggravate as the project progresses. Gaps in what the users convey, gaps in what a Business Analyst (BA) understands, gaps in what a BA documents and conveys to developer, etc.
- Documentation becomes extremely heavy, and at a stage everyone – users and consultants – get fatigued to a point that little attention is paid to it.
- Often – test scenarios and test cases remain grossly incomplete. Discovery of what’s not working starts to emerge when end to end testing starts at UAT stage. Most initial rounds of UAT bomb.
- The fundamental approach is oriented towards business processes, e.g. Purchase to Pay. Several users, across departments, could be involved in completion of a process. As a result, getting a signoff becomes challenging.
- Users usually get access to the system first time at pre-UAT stage – when it is considered to be ready for them. ERP Systems like Dynamics 365 are elaborate, sophisticated, feature and functionality rich, and learning takes significant time. This causes project delays, and hampers UAT. This also prevents users from providing meaningful early feedback.
6. So, what’s nice about Agile:
- Instead of focusing on ‘scope’, users are focusing on identifying ‘what they do’, and ‘why’ (user stories)?
- It’s easier for users to identify the Acceptance criteria for the functions they perform, test, and give signoff. These acceptance criteria do not have dependence on other user stories.
- As against having to detail out all system requirements at the start of a project, User stories are detailed ‘just in time’. This allows users more experience and time in thinking about their user stories, and acceptance criteria.
- User gets to test the developed functionality soon after providing details, minimizing communication gaps.
- Users involvement remains sustained, making testing and feedback easier.
- Slicing the project vertically, instead of horizontally, and getting the users to test & accept slices as the project progresses, significantly reduces the chances of any large-scale project failure.
- In case of changes in the project team (e.g. attrition), impact of a member moving-on can get localized and minimized.
- Since user stories are detailed just in time for the sprint, documentation can stay lean.
- Since Acceptance Criteria are identified for user stories up-front, development gets testing-led. This significantly reduces surprises & errors in the final system.
7. What can be the problems/ risks with Agile?
- When progressing a Sprint at a time, there can be a risk of sometimes missing the big picture of overall System Architecture. This can become particularly important in systems that have heavy customizations, and integrations.
- In a typical ERP project, 70 – 80% of the system is standard. Why should effort be wasted in creating/ documenting user stories for this section?
- A full ERP is a massive system. Attempting to write user stories for the entire system will be mammoth exercise. Products like Dynamics 365 do not currently bundle with it set of standard user stories (process set is bundled).
- Even if users try, they will never be able to come up and list all the features and functionality of an ERP system in the form of user stories. A user may not even know what all to expect. Hence, focusing on only the user provided stories will cover the system partially.
- Users will resist this hard work. They are likely to tell the consulting company that it’s their job to create user stories and identify Acceptance criteria.
- Since projects are fixed cost, project scope is still important to identify.
- Customers will always try pushing more in the scope, tossing timelines and budgets. The ‘eat-all-you-can’ approach in a fixed cost project hurts the project.
- Almost every business function impacts finance. An end to end system testing is therefore essential before a system can be put in to production.
- Since putting ERP systems in to production require ‘cut-over’ from old to the new system, partial usage of the system may not be possible. This means – testing and release of sprints may not be good enough to push it in to production.
- Issues like system performance surface only during stress testing, or when the users actually start using the system. This might result in revisiting architecture, and redoing parts of the system that were already completed.
- Customers will come up with additional requirements, and even be ready to categorize them as CR. They are however very likely to push it within the project before going to production. This impacts timelines.
8. How about CRP approach?
- CRP appears to be a variant of waterfall. A product presentation approach is taken for gathering requirements. After this, the methodology is like waterfall carried out in a short number of releases.
- Multiple iterations to the same process/ business flow are a common occurrence in CRP. This is because the users are looking at a new product and trying to map their processes to it at the same time. They face challenge in understanding, analyzing and identifying gaps – all in parallel. User feedback often remains incomplete, and surfaces much later in the project. This results in to friction between teams.
- Post a CRP session, consultants ask users to sign a gap-fit document. Users stay extremely apprehensive, and this signoff is invariably delayed – significantly.
ERP systems continue to be the backbone of every organization. These projects continue to consume significant budgets, and their success is vital for any organization embarking on a digital transformation journey. This is a collaborative effort pulling thoughts and experiences of several practitioners in pursuit of identifying an approach that enhances chances of project success.
