With Microsoft Dynamics NAV 2013 now more suitable than ever for standard deployment, we can truly look at a ranger of implementation methodologies. There are two approaches that are most often discussed: waterfall and SCRUM. Within waterfall, there is the option to adopt a “Rapid” deployment. Companies should be looking at the most effective approach for successful deployment in their organisation; there is no one size fits all!
Waterfall approach: waterfall is a sequence of events that methodically moves the project forwards to the conclusion. Main events are:
• Analysis: workshop requirements, document, gap / fit to standard software, agree developments
• System Build: your software partner goes away, configures the system, making any changes agreed in the analysis. This is then released for testing
• System Migration: If system build is akin to building a house, this phase is the moving in to a finished house; the house may be finished but it won’t be suitable for you until the beds are made and the kitchen stocked! This is where data migration is completed, end users are trained and output documents are tweaked to match your layouts etc.
• Go-Live: that’s it, project complete, system is live!
One of the frequent criticisms of the waterfall approach is that there is no / little room for flexibility once the agreed scope and changes is set at the end of the analysis phase. This is not true. Change request process throughout the project means you can always go back; albeit the ideal is that you don’t and so I would agree that the initial analysis is very important in this approach. The benefits are that once the analysis is complete, you have a definitive project scope, plan and budget. If you take the attitude that you can keep make changes as you go then you have lost the benefit of this approach. Waterfall is successful where you decide on a plan and stick to it.
It is not true that waterfall means you don’t get to see developments until the end as there is an iterative element to the system build phase. For more complex projects the build will be released in stages for testing with end-to-end testing at the end of the phase. For Dynamics NAV, there’s no reason why go-live should mark a “set in concrete” point of system configuration; our clients who leverage the best return on NAV are those who continually review and tweak as required (note, they are not continually tweaking! Look at Enotria, 10 years on NAV). For Microsoft Dynamics NAV projects this is a proven approach the back-bone of the Microsoft SureStep methodology.
A rapid implementation version of the waterfall approach assumes that no changes will be made. At TVision we adopt this approach for our recruitment solution, Agency Time (built on Dynamics NAV, remember, we are 100% NAV!). The stages here are a shortened analysis phase based on software workshops that confirm no changes are required (and / or deals with any gaps) before moving into the system build phase which is also much shorter as it is a standard configuration (some elements of discussion such as how to structure the chart of accounts and analysis codes).
So what about SCRUM? SCRUM works well for the system build phase of projects where the customer’s project team is fully available to the project and keen to set a pace. The great thing about SCRUM is the momentum and focus it creates. In waterfall there can be a sense of naval gazing, with SCRUM decisions are made quickly. The downside, the scope is constantly flexed to meet the timescale and workshop budget available; this means you won’t know what you’re getting until it’s done (of course you could keep going until you get something that fits but this will not reassure a Finance Director looking for certainty of budget!).
To successfully implement Microsoft Dynamics NAV utilising a SCRUM approach would look like this:
• Training: project team training in depth and up front so they have a good understanding of the Dynamics NAV from the start
• Analysis: shortened exercise of confirming broadly the processes in scope for workshops.
• Workshops / Sprints: working through the software, configuring through workshops. The scope is continually flexed to ensure that the pace is maintained; this can mean that elements deemed non-essential for go-live will be put to one side (frequently the view of what is essential for go-live becomes very focused as time progresses).
• System Migration: as waterfall
• Go-Live
• Post go-live review: some 6-8 weeks after go live, reviewing and revisiting to smooth out any issues and / or add process improvements that were put to one side during the sprints.
Dynamics NAV is the ideal ERP solution for a SCRUM approach because it has the flexibility required. Changes post go-live can be easily made (you could re-number the chart of accounts completely in a live system).
I like SCRUM; it suits NAV, it focuses on what’s really required and it means end users can feed into the post live review stage once they’ve had real experience of living with the software (it is surprising how many of the “nice to haves” just disappear once users understand how NAV works). Why don’t more people adopt this method? It takes commitment and courage. Will your stakeholders be happy with the element of unknown? Will your project team have the time and authority needed to push this forward?
At TVision we will advise on best approach for your project and unless you are looking for a rapid, out of the box solution, it is likely that you’ll use elements from both waterfall and SCRUM. Key to any successful implementation is always the right sets of people; you and your chosen partner. We won’t know what is the best approach for you until we’ve met your project team, in the meantime, we can draw on our e3xperience to tell you some of the things that will not work, check out our white paper on common mistakes to be avoided.
