Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 2 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.
At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.
With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.
We say that ERP implementations are not software development. It’s true, but it might be irrelevant.
We say that with ERP we don’t start from scratch. We must know all the requirements up front because anything we do impacts tens or hundreds of functions. If we just add things incrementally, we might need a lot of rework. So we need a “big picture” up front, we need to design everything in such a way that this huge ERP structure doesn’t collapse.
But no matter what we do, the requirements will change. ERP implementations take 20 months to complete (on average). Do you think your business is going to be exactly the same in 20 months as it is today? Me neither.
ERP implementations start with a fit/gap analysis which detects the gaps between your requirements, and system standard functionality, and then specify how these gaps will be closed. If the specifications are cast in stone, and if you stick to it, after 20 months you’ll might get a system which is not fit anymore.
Recent Panorama’s survey shows that only one out of five companies have realized more than half of expected benefits of the ERP implementation. More than half companies who have implemented ERP have experienced operational disruptions after go live. This is devastating.
From my experience, this has a lot to do with requirements lifecycle.
On the other hand, Standish group’s research over past fifteen years has shown a steady trend towards more predictable and successful software development projects. In 1994, average software project cost overrun was 180%; in 2004 it was 56%. In 1994, average time overrun was 164%; in 2004 it was 84%. In 1994, only 16% of projects came in time on budget; in 2004 it was 29%. Standish group attributes this improvement largely to increased adoption of agile methodologies. Yes, sure, ERP is not software development. But yet…
Where are we with ERP? Still rowing up the waterfall. With today’s turbulent economy, it’s more like rowing up the Niagara Falls. Today, you can’t tell for sure what you are going to do or need in 2 months, let alone 20. Plus, with liquidity issues everywhere, you must make sure that your investment is sound, and that it delivers the expected return; you can’t gamble with 20% chance of achieving 50% of expected benefits.
Adopting an agile approach in implementing ERP might be a solution. In my next post I am going to share some thoughts and ideas about a possible agile approach with ERP that have been haunting me for a while.
Business Applications communities