How to define MVP for ERP software Published on July 4, 2019 How can you define the minimum viable product (MVP) in Enterprise Resource Planning (ERP) software when all of the functionality is so interrelated and highly complex? Sha It doesn’t really matter whether you use Kanban, Scrum or another Agile practice, the aim is the same: to deliver MVP as soon as possible, prove to the business that this solution fits, and then in iterations upgrade it until it’s at a level where customers are satisfied. First you upgrade it to Minimal Marketable Product (MMP) and then to a full scope fully functional product. For ERP software this can be done in several ways, depending on the project specifics. There are many techniques in Agile to help define the scope and the MVP. Define MVP The most straightforward way would be to treat ERP like any other piece of software, defining the full scope and the MVP using story mapping or another technique, and then in refinement sessions throughout the project align the out-of-box functionality and your best practices with the customer needs that are of the highest value. You even can prepare better for refinement sessions because you already have a product to show – just configure it to the best of your abilities and discuss it with the customer. The MVP could include some basic functionality which would allow the customer to “get a taste of” the ERP software either in full or in limited (most valuable to the customer) scope. In the best-case scenario business would be able to start using the software in partial scope (a Minimal Marketable Feature (MMF) or Minimal Marketable Product (MMP)), using old software or other tools like Excel in parallel. As for the MVP, you can treat it as a prototype, proof of concept, beta version or version 0.1 – whatever option brings the most initial value to the customer. There are special techniques for mapping and prioritising the scope, and defining the MVP. An Example We can take as an example the ERP project of a manufacturing company producing water. They would like the ERP to cover all their operations, including manufacturing, warehousing, logistics, finance, personnel, reporting and consolidation. They operate in five countries, or in five cities. You could facilitate a few days’ workshop to define the full scope at a high level. During that you would also define the MVP. In this example it could be a setup of: the item catalogue with basic information basic warehousing – only for accounting inventory quantities basic purchases to make item purchasing possible in the simplest scenarios basic sales to simulate selling of manufactured goods a chart of accounts - only to accommodate purchasing and cost calculations and maybe a simple Bill of Materials to show that the system can convert raw materials into products No data migration. This MVP functionality could be out-of-the box features of ERP with some configured and developed tweaks. You commit to this MVP and deliver it in few weeks. What value does this bring? The customer can test-drive the basic functionality and get a feel of the system. They might notice different features, generate some questions, and cancel previous requirements and generate new ones based on this hands-on experience. In some rare cases, if it delivers better than what they had previously been using (emails and a few Excel spreadsheets, for example), the customer might see the value of the product and even switch over to using this MVP release. What's Next The next release could be a go-live of the smallest plant as a pilot with data migration and a minimum set of features (Excel or other kinds of workaround tools could still be used to get all the work done), and then release by release deliver the scope the customer values the most. Did you notice that customer can play around with the software as early as three weeks after work on the project has started? Waterfall does not usually provide this as an option. Keep in mind that Agile is not suitable for all ERP implementations. Agile is best for those with a medium to high level of uncertainty about the scope of functionality and business specifics. Remember, this is just an example, and a simplified one. We would be delighted to dive into a real example and help you with your scope and MVP definition. Let me know your thoughts and personal experience with defining MVP for your ERP implementation. Can you use Scrum to implement ERP systems? Deploying an ERP system, whether it's Microsoft Dynamics 365 Business Central or Dynamics 365 for Finance and Operations, is a mission-critical project. Traditionally, these projects are meticulously planned and executed to minimise the chances of any downtime or system failures. And, traditionally, that's meant months of analysis and design, lots of plans and specifications, before building anything and then a protracted testing phase before go-live. All very waterfall. Can ERP projects use Scrum? Scrum is a framework for developing valuable products that solve complex problems. There's nothing apparent in the Scrum Guide that prevents Scrum being used to implement Dynamics 365 ERP systems, but there are some challenges. So let's address those first. ERP systems are complex and mission-critical ERP systems are the backbone of most companies. Without them, nothing gets sold, manufactured or shipped, and no one gets paid. ERP systems have lots of modules and features that take time to configure and customise according to the organisation's requirements. There are extensive systems integration and data migration needs too. ERP projects are rarely completed in a few weeks; a few years is more likely. When implementing a new ERP system, there's always an existing system in place. ERP practitioners need to implement the new system and seamlessly cutover from the existing system without missing a beat. Whereas with a CRM deployment there is sometimes no legacy system to replace (unless you're counting Outlook and Excel) and cutovers -- while still important -- are less time critical. ERP failures can cost billions. They make headlines and they can wreck IT careers. ERP customers and consultants have stuck to tradition Since the 1980s ERP projects had followed a waterfall approach with a heavy investment in upfront requirements analysis and planning. Since the mid-1990s, there was a slight shift towards a more turnkey approach with vendors providing industry templates to reduce the planning and discovery effort. The Oracle Application Implementation Method (AIM) and the SAP Accelerated SAP (ASAP) methodologies were devised in the 1990s, with Microsoft Dynamics SureStep (SureStep) arriving in 2006. Cloud ERP deployments and the Agile Manifesto were unheard of back then. Today, SAP has an agile methodology (SAP Activate), Oracle ERP consultants are talking about agile approaches and Microsoft has abandoned SureStep. So perhaps ERP consultants are ready to embrace a new approach. Critical success factors for using Scrum in an ERP project There are four critical success factors in successful ERP projects that I've seen use Scrum: choosing the right project, defining the minimum viable product, embracing agility, and going all in. Choosing the right project for agile ERP If you're an ERP consulting team considering the transition to agile, choose your first project wisely. Pick one project initially; don't use Scrum on all your new projects until you've learned the lessons from one or two. Pick the right sized project; learning Scrum on a smaller project will be faster and safer than a large, complex project. Pick the right client; propose and use Scrum when the client's team has already had some success with it on other projects prior to ERP. Defining the minimum viable product The minimum viable product (MVP) is the smallest set of features you could release into production that would provide value to your users. In some software projects, the MVP is small and can be developed in a few days or weeks. But it's not for an ERP project. You can't implement a new system for accounts receivable in the first release and provide accounts payable in the second release sometime next year. The MVP in an ERP project has got to include all the critical features of the current system. The first release of your new ERP system might take many months to develop using Scrum, but you should still focus on an MVP that is as small as possible. Only include mission-critical features. Deploy the first release as soon as possible, get feedback, and iterate quickly. Embracing agility As ERP consulting firms consider an agile approach, I've seen them send a project manager to an agile training course and expect the project manager to now lead an ERP project using an agile methodology. I've never seen that approach work. A better approach is to work closely with an agile coach. Have the coach facilitate the ERP consulting team's transition to Scrum and train the consultants with a blend of formal Scrum training and on-the-job coaching. Going all in Scrumerfall, upfront design and iterative development, hybrid agile. Some agile practitioners think it's OK to be hybrid, to combine some agile practices with waterfall ones. But I'm with Brett Maytom. I've found that the agile mindset -- like the pillars and principles of Scrum -- are directly at odds with a waterfall mindset. My advice is to go all in. If you're going to use Scrum in an ERP project, use all of it. Don't go halfway and try to use Scrum after your requirements specification has been signed-off. It won't work, your project will likely fail and Scrum will take the blame. Go all in.
