I started working with Dynamics NAV in 1984. At that time, a small newly established company advertised for beta-testers for a newly developed financial software called PcPlus. The company’s name was PC&C, later known as Navision Denmark and now Microsoft and the financial system Dynamics NAV. Since then I have worked at or with many Navision partners. During that time, I have seen lots of projects that were well defined and well executed. However, unfortunately I have also seen projects that became total disasters. Over the years I have noted, what made the projects work and what made it go wrong. In the following I have listed ten of the biggest issues, as I see them. This post is the first of ten:
Hedge the contract
A lot can happen in the heat of the sales process. The sales process of a large Dynamics NAV implementation can take as much as twelve months and during that time, the customer will try to fit as much functionality as possible into the contract. The sales person tries to close the deal as quickly as possible and get paid for as much work as possible. In the last state of the sales process everybody tries to hedge their bets:
- The customer tries to avoid that the project becomes a money pit where they have no control of the total cost of the project
- The sales person tries to limit the amount of free work that inevitably will follow with a large project and also to keep the discounts at a reasonable level
On the other hand, the sales person tries to land the project as quickly as possible, and that can result in last minute changes to the contract that can have fatal consequences to the economy later. Some of these sentences are from actual projects:
- The new system must be significantly better that the old system
- The new system must be faster than the old system
- The new system must have exactly the same functionality as the old system
- All data must be ported to the new system exactly as it is in the old
All of these “rubber paragraphs” means that it will never be possible to deliver the new system because:
- The new system is good, but it is not significantly better that the old system
- The new system feels slower than the old system (it may not be, but it feels that way)
- The new system will often have the same and more functionality than the old system, but it is operated differently. Especially the reports will look differently and changing all reports can be a time-consuming task.
- The data in the old system might be structured differently in the old and the new system and in that case, it is not possible to port the data to be exactly as it is in the old. E.g. if the old system has customer transaction totals per month and the new shows all transactions.
All of these must be replaced with :
- A measurable statement like “Posting an invoice may not take longer than 1 minute !?!”
- Specifying a specific functionality may prevent the use of some of the new and better functionality
- Skip functionality and specify the processes instead
- Check if reports should be omitted and filtered views, Cues or BI systems should be used instead
- Limit the data to be ported to the new system and keep the old system for history instead
Another pit-fall is selling ready-made packages of vertical solutions. It is a great idea to find certified add-ons for Dynamics NAV. In that way, the development of the add-on is guaranteed and it is tested and approved for Dynamics NAV. But there are a number of questions that must be answered before adding it to the project.
- Is it a registered add-on or is it just a solution made for a previous customer and they now try to resell it?
- Is there a development plan for the coming versions of Dynamics NAV?
- Does the add-on actually exist for the version that will be implemented?
- Is the add-on a live version or is it a beta version?
- Do the different add-ons actually work together?
- If the add-on requires special skills at the customer site. Do they have staff to maintain the add-on later?
In order to prevent the disaster projects, it is therefore necessary to implement a process for all sales, regardless of the complexity or size. This process could include:
- Making sure that the knowledge of the sales people as regards to the functionality of the new versions, possible add-on or vertical solutions are updated
- Introducing a presales consultant early in the process. The presales consultant must be a highly competent and experienced consultant, that can function as a system-architect for all areas of the new system
Breaking down the processes that should be covered by the project into bits that are manageable. For each process, it is necessary to identify:
- Routines (invoices, payments, warehouse shipments e.g.)
- Periodic routines (stock take, reconciliations, VAT settlements and the like)
- Reports (both operational and statistics)
- Exceptions from the normal routines
- Then making a gap analysis determining the missing functionality to support the processes specified
- Identifying reporting demands for each process but also for management up front, so that the system will generate needed data for all reporting
- Documenting the processes that can be made into a test-scripts and later user manuals
Normally the process will be divided into two parts:
- Estimate for a round of workshops to determine the processes in each department end thereby the gap-analysis
- After the workshop round a more accurate estimate will be made to cover all the gaps that were identified in the workshop round
The problem in the first phase is always that the customer wants a “rough” estimate, which is hard to give since every company is unique. The even bigger problem is that the customer will very often hold you to the “rough” estimate regardless of any “scope-creep” that might have taken place during the project.
Some Dynamics NAV partners have special contract department, whose only task is to review the contracts before signature and then later on to review the project. That way a mistake made in one project can be mitigated in coming projects. This department would also be able to assist in the “rough” estimate, given that they hold information on the estimates of previous projects and the final calculation of a company that resembles the customer.
Don’t miss out on the next post: “Keep your employees”