I’d like to add a Project Manager’s perspective to Elliot’s post, The process traditionally chosen to manage an ERP project, a , has caused many projects to fail . This is not just in the “over budget / behind schedule” sense, but also refers to the “that’s what we asked for at the beginning of the project, but that’s not what we really need now” type of failure. While waterfall's fundamental tenet of breaking projects into sequential processes still holds value, those projects that fail are the ones that do not have the foresight to consider the changing needs that can emerge both before and after Go-live.
Why all the failure? Of course there have been many successful ERP projects, but everyone loves to focus on the failures. Here’s my take:
1) Companies bite off more than they can chew. They’ve got the budget approved for a new ERP and want to spend all the money now. This results in a bloated requirements list… do you really need to replace all your spreadsheets? And if yes, do you have to replace them all now, or can you wait until the next phase?
2) Bloated requirements lists typically lead to extensive customizations. There’s a massive amount of information on the internet on the evils of extensive ERP customizations, so I won’t go into detail.
3) Extensive customizations typically lead to projects that take too long. And when a project takes too long, not only is everyone burned out at the end (and so has no appetite for looking at phase two), it is also the case that quite often the requirements listed at the beginning of the project are no longer relevant.
How can we help? Elliot refers to a – at Catapult we like to follow that spans the life of your solution rather than just focusing on the initial implementation. At a high level here are the steps:
PIA (pre-implementation analysis): This mini project lets us gather your current requirements, and match them to NAV’s out of the box functionality. We review both the gaps and fits and plan out your implementation, breaking it down into phases. Ideally phase 1 only includes the “minimum viable solution.” Always keep in mind that most ERP solutions have built-in best practice business processes; instead of asking “Why doesn’t the software do XXX our way?” ask “Why aren’t we doing XXX the best practice way?”
Phase 1 steps:
1) Design / configuration: flip the switches in the system to fit your business and design the "must have" customizations.
2) Development: build any "must have" customizations and/or reports.
3) Data migration: extract, clean and move data from your legacy system to your new system.
4) Testing
5) Training
6) Go-live: transfer your financial opening balances from your legacy system to your new system and turn it on.
Breathe: take some time to let your team rest, and let your users really get to know the product.
Phase 2: Analysis. Review the original requirements list, add any new (or changed) requirements since the PIA, and re-prioritize to develop the scope for this phase. In concept the remaining steps are the same as in Phase 1, but will vary depending on scope.
Repeat 3 and 4 above as needed to realize your vision.
We would love to hear your feedback or discuss how we can help your business Catapult. Get in touch with Jeff: jeff@catapulterp.com
by Catapult ERP
 |
More Posts By Catapult
- Draft Your Month End Close Checklist with Dynamics NAV
- The Benefits of NAV on Azure for Small and Mid-Size Businesses
- Insights from NAV Azure Migrations
- Planning an Upgrade to NAV 2015? Here’s Your Guide!
- 3 Keys to ERP and CRM Success After Go-Live
Related Posts
- The Importance of Assumptions in Effective Project Management
- Five Things a Business Analyst Is (and Isn’t) in an ERP Project
- Video Testimonial: Clients First & Dynamics NAV, Keeping the Railroads Moving
- Telltale Signs You’ve Outgrown QuickBooks: Part 4
- Microsoft NAV 2016 Version Upgrade! Never Worry!!
