25 things a software vendor will never tell you

However, according to the 2016 Panorama Consulting Report on enterprise software, only 57% of respondents considered their new software a “success”.

By following these 25 steps, you help build trust and ensure a successful Microsoft Dynamics AX project outcome.

1. There are serious resource shortages in the Dynamics AX world. Vendors will play ‘bait and switch’, putting their best people into the sales pitch or project launch and gradually swapping them out for less capable staff. The hard-won knowledge transferred to their team during the sales cycle is largely lost. Insist on the seller/doer model – the reseller commits a core team from start to finish, with free-of-charge on-boarding time for replacements.
2. Secrecy has no place in an implementation project. You should declare your budget up-front and challenge the vendor to say whether project objectives can be met within that constraint. Too good to be true? Don’t be afraid to challenge low as well as high estimates. Inevitably, something will have been missed.
3. Dynamics AX partners will have completed a large numbers of projects and understand well the appropriate budget and timeline for a set of project objectives. Do set a budget, or a timeline or ambitious objectives, but don’t dictate all three without advice from an experienced practitioner.
4. Make sure that the vendor has some substantial investment in the timely and accurate delivery of your system – insist on a reasonable element of success-driven payments for the major milestone deliveries, but be fair about levels of risk and reward.
5. Avoid the temptation to start the project with a lengthy sales cycle, trying to understand all requirements in order to obtain highly accurate estimates and commitments from vendors. Although this looks like an attractive idea at first glance, this detailed RFP approach is more likely to contribute to project failure, because the RFP and formative design will be based on as-is functions and processes which may be swept aside when improved by the new functionality.
6. Do the right work at the right time. Earlier is not necessarily better – it is much more beneficial to establish project scope and build a function map with sufficient depth to guide the future project in the pre-sales period.
7. Don’t be over-concerned about finding a vendor with experience of the latest version for your project. The Dynamics AX family has evolved through 16 full and part versions over a 27-year period. Most practitioners will have worked through at least two or three versions and should know how to adapt to the latest release. In practical terms, there is a 2-year cycle to each major release and as most large projects take about 2 years to complete you will never find anyone with project experience on the current version. Just assure yourself that the vendor is able to adapt to change.
8. Many vendors will do anything to duck their responsibility to your company. Never agree to a contract where the RACI chart does not include the partner.
9. Microsoft Dynamics AX resellers are experts at extracting the truth from reluctant process owners. A day spent on functional analysis without your vendor’s input is a day wasted – they will have to go over it again properly and pose the awkward questions that your staff may not be brave enough to ask. Worse still, your subject-matter experts will resent having to cover old ground.
10. Beware consultants who rush straight into the solution design without having a complete understanding of the whole business function (including the unhappy path). Missed requirements can cause a complete redesign – these last-minute changes cost ten times more to fix than timely requirements, because everything has to be recoded and retested.
11. Interview every design stream lead and ask them the tricky questions about your processes. Find some little-known Dynamics AX functions (on TechNet) and ask them to design a process that uses the function. If they say that development is required, you have an amateur on your hands.
12. Challenge the reseller team to explain the difference between a function and a process. (A function achieves a business objective. A process is the system’s way of doing it.) If they can’t get that straight, then your project will never meet expectations.
13. Prepare for requirements workshops with business scenario descriptions and use-cases. Anyone can document a sell/pay/pick/despatch process – you need to tackle all the nasty cases that burn money and time when badly handled. This is where your main ROI will come from.
14. Never agree to a vendor’s implementation contract without stated deliverables and a price for each deliverable – one for each business objective. Do not accept vague promises to ‘help’ you deliver, ‘assist’ your team or ‘manage’ the objectives. You are paying the vendor to design, build, configure, populate, rectify, deliver, implement and guarantee the performance of your system – accept nothing less.
15. Resellers make a sizeable margin on licence sales and may be encouraged to sell into Microsoft quarterly targets. There is no sensible way to predict your client licence requirements before analysis, design and organisational change are fully defined. It is perfectly feasible to start the application build on a 10-user system and add more seats on a just-in-time basis. You will be paying Microsoft support fees on all licences from day one of their purchase, which has zero ROI – do not allow the reseller to pressure you into buying licences ahead of time.
16. A functional stream lead must map out and agree business functions before designing the solution.
17. The design must be written in plain language (no unexplained acronyms) and include 1) A scope diagram and appraisal of the as-is processes in place. 2) The to-be business scenarios and test cases. 3) The functional requirements schedule. 4) An implementation schedule stating how the requirements will be met (standard/configuration/training requirement/workaround/development). 5) A clear and concise specification for each designated item.
18. Do not allow the reseller to start work on anything until your process owners have signed off the specification – no excuses.
19. You must resource your project properly. Ask in your office for anyone with 50% time to spare to put their hand up… Do not delude yourself that a major software project can be accomplished solely by process owners and super-users who already have a day job. Yes – you must put your best people into the design effort.
20. Do your data cleansing NOW. The single greatest cause of a go-live postponement is poorly planned and executed data migration. If you can’t sort out your data when the pressure is off, you don’t stand a chance when the heat is on.
21. Good people are expensive and vendors will want to spread their best people across several projects. They will not deliver optimum output on the odd days they are working for you. Insist that a team is put in place and stays in place for major work sprints.
22. Gear up adequately for the huge testing effort needed when your software build is delivered. If you can’t test software, configurations, migrated data and security settings promptly as they are being delivered, your warranty will have expired long before you find the defects.
23. Ensure that the vendor’s system can capture concise data for each business objective/work-stream, and insist on Monday-morning progress reports. These must state the percentage complete/time to finish. You must challenge slippage as soon as it occurs. Reserve the right to replace team members who don’t keep up.
24. Scope creep is poison to a time/budget constrained project. This is a simple equation – contain scope without exception or make sure you have a lot of time, money and a forgiving project board to manage the consequences.
25. Do not ignore project management – you will require a good project manager and so will the reseller – be prepared to finance both. Your project manager must be assertive and empowered to act decisively in order to get the project home. There is no space for sacred cows in an ERP implementation.