The following points I can definitely say about this:
1. The implementer themselves do not know the capabilities and limitations of their programs. So whatever they promise, take it with a pinch of salt.
2. The vision of the software in your mind will be different that you see actually, even if you have given that vision to the implementers in writing.
3. Once committed, they would try to thrust upon their vision to you. Any request for change will meet a resistance in the following way
- Can be done in the next build
- that will change the structure of the logic.
- This is your wish list, wish lists keep on coming.
- But that is what we discussed initially, and you have agreed to it.
- But you also have to do some work to run the system.
- this is a problem of formatting, can be done when logic is closed.
4. Building an issue list doesn't help. There will be key issues which keep on pending, the minor issues will be corrected.
5. There will be no white box testing at their end. They expect you to envisage all scenarios and give the result to them in black box testing. Every issue list will meet a resistance.
6. If an issue is corrected, then a new issue is created in correcting the first one. Then you have to fight your way to get that issue corrected.
7. Dates and deadlines are never met.
8. If there are n steps to complete a process, with an ERP application, it will take at least n+2 steps. They say this is logical.
9. The biggest drawback here is that they have a one-fix-for-all solution with them. They try to fit all scenarios with that solution, with the result that they lose touch with the reality.
10. There are no error message which are intelligent, no user friendly tips, to start with. Every singly error message, you have to point out to them.
11. They will not document for you, will not train your staff. You have to do this that, yourself.
