Prices extra work

Hi, We are about to implement Navision 3.7 into our organisation. We have been offered a certain price for the total pakcage. When implementing it may seem that some extra work has to be done for developing some extra modules or parts for it. For me, as an end-user I see no problem, but I’m not the one who can take decisions for approval of extra cost. Maybe the total amount of these extra costs are 10 or 20% of the amount for which we’ve been offered right now. I speak from my experience when I worked somewhere else. They worked with Exact for Dos and switched to Baan for Windows. The software did cost DFL 400,000 and the extra work did cost DFL 1,200,000 ! 1st Question : Is it a regular experienced problem that this could happen ? 2nd Question : should we consider not paying for those cost (believe me, I should pay it right away[;)] for I know that those cost are made to improve the system) ? 3rd Question : How can we prevent that our boss (who has chosen Navision) will flush Navision when we experience problems in processes during some months ? Final Question : How does Microsoft calculate when people in our organisation will support directly in finding a solution for which extra cost must be paid (yeah, I know my English is not too well…) I hope that you can give me some different answers, as I could learn more from them.

Hi Arno The only real way to offer a fixed price and make it work for both sides is if a thorough needs analysis is performed first. In this manner you uncover all of the extra work, and bundle it into the price. Other small items that have been missed are either absorbed by the NSC (it is how we would do it) or you would be charged for them. If no needs analysis takes place the scope of the extra work is unknown, the price offered will be a “best” guess. This then comes down to the contract. However if the NSC offers to do the work for DFL 10,000 without knowing what is really expected and you ask for DFL 200,000 worth of work and insist they do it, the relationship will suffer, and you will probably not get work of the highest quality! Ultimately different countries and NSC’s within the countries will differ in the approaches taken. If you have an agreed price for the implementation this should be for all the work to get you live, code changes, screen changes, form design, etc, but it will depend upon the contract you have signed. To answer your questions 1. Yes it does happen, probably more often in quick sales, or where the product is mis-sold, could be wrong fit, meeting a tight budget etc. (i.e. yes you can have this for DFL X, oh you want that module, that is an extra DFL Y) 2. If you hold off on paying for the extra work, you will not get any future work or the current work paid finished properly (in all probability). If they have done the work, and you asked them to, it only really seems fair you pay them! (But I would say that!) 3. Not sure I understand the question 4. If you mean you find a bug in the “standard” software, well it may already be incorporated in a hotfix, so they have fixed it, and it is your responsibility (and your NSC) to apply these fixes. By reporting these bugs, you will have them fixed (probably) and you are helping everyone. I do not think your NSC would charge you for this if you have a support contract. If it is problems with your modifications, that lies with the NSC not Microsoft. But I may have misunderstood that question!

Great, For question 1,2 and 4 I am pleased to know those answers. As for question 3, I meant that our boss can really be a pain in the … when it comes to the confidence of a new software. If we may experience problems during the first months when its all operational, he may say to Navision that it is worse than our current software. How can we prevent this ? How can I give him the trust that it WILL work, but only after we ALL give it for the 100%…

Hi Arno. The main transfer of knowledge to your boss will come from the staff I guess - if things are not working it is the day to day users that will be complaining. It is difficult to comment, but if I assume you are on a standard well planned implementation there are several phases. The needs analysis will have plotted the business and system requirements, you will then have introductory training, and the modifications and data conversions will be written. Full training will then take place on your data with your modifications. Once this part of the project is complete you will enter a pilot period for the software, say 8 weeks. In this time it will generally be the customers responsibility to plan training scenarios. This will mean you will test the complete system as throughly as possibly before you go live. When you go live you will hit issues, procedures that happen once a year that were missed, etc, but none of this should be mission critical, you will be able to do 95-100% of your business if it is planned well. It is all in the planning and execution. To help your boss you can give him regular updates on the project. Tell him the procedural gaps that have been filled, and when a modification is tested and works, report this to him. This progress reporting will make him see the project development. You can also forewarn him that due to resource and time pressures you cannot test the new system to 100% in pilot and a few issues may arise in the first month, but nothing critical. Of course if you dont do the planning, dont invest the time, when you do go live problems will be apparent, but then this is also the responsibility of your boss as it is the company as a whole that needs to get the software to work. Some bosses will not allow time to test the software, release staff etc, or push for very tight timescales to maximise the return on the investment, and when problems happen they moan, but this I am afraid is not the fault of the software, it is simply business[:D]. Good luck with the roll out - just spend as much time as you can ensuring the modifications work, the software fits your processes and the staff are comfortable using it - that will get you a long way down the successful road.

Arno, I completely agree with Steven (even though you asked for different points of view). With Navision it’s quite normal to have some extra programming costs. If you want to keep these costs under control, it is necessary to divide your wished into must-haves and nice-to-haves. You will find that a lot of things won’t be needed after all, once your people get to knwo the new system. As for your boss, most of the times the focus during an implementation is on costs, both time-wise as money-wise. You should show the benefits of the new system, like improved management information, better stock control and the like.

Dear Arno, I am satisfied that the responses you have received so far cover your concerns. But just a small addition. You (and your Boss) seem to have already selected Navision. You dont mention how you got there. However, you need(ed) to evaluate the software based on the needs. You would probably have different firms give you proposals. What remains anyways, is the entire project management for this implimentation. Your NSC should be able to use a methodology that ensures that requirements and clearly understood and the solutions clearly stated, and agreed. By this, you eliminate or reduce chances of disatisfaction in future. There should clear steps of implimentation and milestones. Risks must be clearly identified at start and handled through very careful planning. Navision uses what is know as “OnTarget Methodology” and it is great. Kind regards, Robert

Dear Arno, Your questions are valid as I have experienced a lot of Navision Customers with comparable problems and questions. As I read your questions, the project for you will be about managing the expectations of your boss and the end users. How can you do this? Many projects are started with very high expectations. Expectations that are not met during and in the end of a project. How come? Here a few reasons - End users are not involved enough in the project. These are the people that will eventually work with the tool. If they do not support the ‘new’ tool, the change of project failure is high. - Management is often not aware of the impact an ERP implementation has on the organisation. Employees in key-positions should take part in the project and be responsible for certain Deliverables of the project. Again, this helps the internally support for the ‘new’ tool. - Project Management is not valued by Management which can result in badly set goals and objectives. In that case it is not clear what will be delivered by the end of project. Project management is seen as not adding value and as a waste of time and money By setting very clear goals and objectives the change of project success will increase. Project management is about creating an environment and conditions in which a defined goal or objective can be achieved in a controlled manner. I gives clarity to all people involved. Further more, a good description of the companies processes can be of good help and will increased the chance for a successful ERP implementation. If you want to contact me, you can at Our company is located in the Netherlands. Kind regards, Stijn