Confession of an experienced consultant from 20 NAV/BC implementations

I recalled them all and counted them. It’s 20 (I swear figure is not rounded anyhow) In 11 years and in 6 countries. What am I talking about? The companies I have helped to get live on NAV/BC where I have played significant role in the project team, lead large partner teams (up to 15-20 people) throughout the whole implementation process or did it all as a ‘one man’ show.

It had been hard job every time regardless of complexity of the customer. Lot of sweat, sleepless nights and never-ending brain verification that I have done the most I could have done. I’ve heard things like “Success Story” “Great Success” but to be honest in most cases it didn’t look like these nice words a week before project go live or week after go live day.

During go live weeks I’ve experienced screaming, shouting, crying, upset lorries drivers waiting for paperwork as no papers coming out of the system correctly. What went wrong? What guarantee’s a successful go live? Nothing! It’s the finest very small details (very often missed during analysis and UAT) which can make it to great success or other way round great disaster to end up in reversal to previous system (I’ve experienced it once, we managed to get back on track after 6 months, I will come back to it later in the blog post and explain how it could have been avoided).

You can be MVP or quickest keyboard typer on the Earth.. But if company order intake goes to thousands of the documents daily you can’t do input yourself. This means that regardless of how experienced with business software implementations you are is not a key factor.

So, what are the key factors in my experience?

To me it is a balanced team on both sides of the project delivering key success. An achievement ingredient which will make sure that there is consistency and rightly managed responsibilities of ownerships in both teams.

With the NAV/BC reseller team you obviously need an experienced consultant, experienced developer and somebody who oversees the budge spent and successfully communicating with the project sponsor on customer side. Microsoft Sure Step methodology proposes the structure but none of partners I met before truly follow. They made their own versions which works for them (which don’t necessarily mean it works for the customer) Microsoft current implementation bible is called ‘Design to Success’. Amazing reading, I can strongly recommend.

With the customer this is not that simple as it depends on the project size and the complexity. With the small companies (let’s say 5 NAV/BC users) you will need somebody with extensive business experience and internal product/service knowledge. This is very rarely personnel with experience in IT or IT skills (you literally need non IT personnel). It should be somebody who is in company for a long time and been through different positions within business and know the company end-to-end. This person can very clearly define what the company requirement is and can easily communicate with the project sponsor. So… this is second person, somebody needs to pay this right? It’s not just that though! If the solution is implemented right the benefits can be enormous and ROI can be an unbelievably short. Companies needs system for a reason. One more thing to consider in these small projects is who will manage daily project tasks (e.g. internal resource bookings, approve partners invoice etc.) The internal Project Manager is required (in theory it could be one of already mentioned roles) However in reality people most of the time people need to do their daily job too so they cannot do full time implementation task as job.

With larger implementations (40+ NAV/BC users) the list mandatorily start on following position which very often is not present in the beginning of the project: ERP MANAGER or Business System Manager etc.. (Which is responsible for the system internally) The example of responsibilities of this role is new users onboarding, testing new modifications, managing the communication with involved 3rd parties. The idea here is someone in an organisation that knows the process end-to-end and can communicate with anybody internally about finest detail of department complexities whenever required. Then you need internal PM and group of key users per department. The project sponsor might be Steering Committee instead within bigger implementations. It really varies however this is minimum. Very often you might need Business Analyst, potentially Application developer (to write reports and similar tasks)

So.. if you have a great team how it can go wrong?! The problem can be non-realistic plan and inexperienced project managers not understanding project complexity and the task. I’ve seen so many stupid presales project plans. Things like; stage 0.5; 10 years of NAV code reworked in 5 months; implementation 400+ user system in 9 months scales. Guess what? It wasn’t a fairytale few weeks or months after Go live. Customer-partner relationship no longer exists they have probably gone elsewhere already.

Next thing to step ahead success is stop classifying BC Implementation (or reimplementation) as an IT project and don’t let IT department to represent key users (they can’t know the detail BC partners need) Even if you are IT company, this is not IT project. I’ve seen few IT designed systems that were not great as you can imagine.

The next key ingredient to success is to start selling to customer their system ownership as soon as possible. I very often use words like “I’m not going to be here forever” and before go live you must achieve self-efficiency in shortest possible time to be productive and get real gains from new solutions as quickly as possible. Without getting benefits quick the project might not meet expectations. If you need your partner daily two months after go live obviously something went wrong. Employees upset on both sides, budget blown, customer-partner relation completely gone.

How to avoid it then? Presales and project management needs to be done by expert with implementation experience. Create middle-man (email forwarder) doesn’t bring benefit to anybody. This is where you miss required detail. Why would you pay for somebody who does not have answers and just forwarding email to get the answer.

The other key project stage In MB365 we call it Parallel Runs (known generally as UAT) People need to have allocated time to test the system (I haven’t met key user saying “I have loads of time”, all I hear, “we can’t, we don’t have time, we don’t have capacity”) . Whole chain of the roles needs to be prepared to work in parallel with old system and try replicate daily transactions. It will be hard, but better at this stage than later on after go live, right? In my experience this project stage needs to take from 6-8 weeks regardless of project size. Only minor development should be happening at that time as you are close to go live, you should be nearly there (there are obviously exceptions)

Example of the project MB365 Parallel run Plan:

The most important key ingredient is right ratio of onsite presence throughout the whole project. You will find very often in this industry lazy well-paid people which just don’t want to go onsite as it can be all done remotely. No you can’t (however obviously you might find exceptions) Thought that you can design system remotely or from board room without going to see the shop floor at least once is wrong. Analysis workshops in larger implementations should be happening onsite too! With right mix of users described above. Onsite consultancy support for go live at least a week or two is absolute must. If partner is telling you they can support you go live remotely, they are not the right partner to me and you facing incoming disaster. That’s how the reversal of the system happened.. I wasn’t there when I should have. I won’t do same mistake again. It’s not about system knowledge and telling users what they do wrong you can do that remote. You must be there delivering positivity, driving an emotion cool point with great customer process knowledge as a communication channeler with the project sponsor or steering committee.

One thing which indirectly influences need of partner to make great job to make it success is how Microsoft pays our CSP commission. In olds NAV days, if I would have sold NAV, I get example 30% of license cost paid upfront (30 user system; 2k per user; £60.000 licences cost; £20k commision) without any need of doing great service afterwards, my commission is in the bank. I can send there new people without required experience and however it happens it does not matter I still have my cash. With BC subscription model it doesn’t work this way. During implementation phase get you 1 license each (Essential, Device, Team member) which give me more overhead than profit. My due diligence is to get you live on minimum viable product without compromising end user comfort as quickly as possible, let you can start sharing benefits of D365 platform. Once you are happy, then we are all happy!

The blog post is longer than I originally expected.. I hope you enjoyed content and hopefully I have shared some of my best knowledge which I love to do. I’m working hard on getting more customers in MB365 name, so if you about to start digital transformation get in touch! We can help! Check our packages solutions, MB365 can get you live in 10 months. Thank you for your time. I will expand on soon in next blog post how we do the project we are the next generation partner with unique project implementation methodology.

Confession of an experienced consultant from 20 NAV/BC implementations. What have I learned? How to avoid failed implementation? Where it often goes wrong? If you have few minutes please read my new blog post. Any feedback comments most appreciated.