Ask What Happens When The Estimate Is Wrong | Vetting An ERP Implementation Partner

You have three firms on a shortlist to implement your ERP, and all three interviewed well. That is not luck. The questions you asked them are the questions everybody asks, and they have answered them a hundred times. So the interview did not tell you very much. Here is a question that has no rehearsed answer. Ask each firm what happens when the estimate turns out to be wrong. Not whether it might be wrong. It will be. Somewhere in a nine-month implementation there is a requirement nobody wrote down. Ask who pays for it. Everything on screen in the next few minutes is an illustrative example. Invented company, invented numbers, nobody's real documents. Start with the questions you were going to ask anyway, because they are worth asking. Walk me through your discovery and your statement of work. How do you handle data migration and deduplication. Show me an integration and a piece of custom code you have built. What does adoption support look like after go-live. Who, specifically, will be on my project. Those five are a good filter. They will eliminate a firm that has never done this. What they will not do is separate the three firms that have. Every one of them has a discovery deck. Every one has a migration methodology. Every one has a named team, at least on paper. Predictable questions get prepared answers. You need something they cannot prepare for. An estimate is a prediction about work nobody has done yet. There is nothing wrong with that. The question is what the contract does when the prediction misses. Time and materials says the buyer absorbs it. You pay for the hours it actually takes, which is honest, and it means every hour of somebody else's learning curve lands on your invoice. Fixed price says the vendor absorbs it, in exchange for a scope drawn tightly enough that most changes become change orders. Which moves the argument rather than settling it. Choosing properly between those two is a question about how well defined your requirements are, and it is worth doing carefully. But notice what neither answer tells you. Neither one tells you whether the firm will stand behind its own number. There is a third shape, and almost nobody offers it. The firm estimates, commits to the number, and if they estimated low, they absorb the difference. Same scope, same plan, different owner of the variance. Ask which of the three you are being sold. Ask it in those words. Here is the artifact that shows you the answer before you sign anything. Ask to see the output of a discovery they have already done for someone else, redacted. You are not reading it for the prose. You are looking for one thing. Are there estimates attached to individual requirements. Not a project total. A line for each requirement, with hours against it, and a note on what it depends on. A firm that estimates at the line level has to understand the work at the line level. A firm that hands you one number for the whole programme has either done that decomposition privately, or has not done it at all, and from the outside you cannot tell which. If the discovery deliverable has no line-level estimates, the total on the last page is a guess wearing a suit. You will hear three answers to the estimate question, and two of them are the same answer. The first. We bill hourly, so you only pay for what you use. That sounds like fairness. It is a transfer of risk to you, described as a discount. The second. We will scope it as we go. Same answer, without the invoice attached yet. The third one sounds smaller than it is. It goes something like: we will put the estimate in writing, and if we are wrong about our own scope, that is ours to absorb. When you hear it, ask the follow-up. Has that ever actually happened, and what did you do. A firm that has genuinely absorbed an overrun will tell you the story, in detail, with a number in it. It cost them something and they remember it. A firm that has not will answer in the present tense and change the subject. One more, and it is the shortest. Ask for a name. Not the account manager, and not the certified team on the capabilities page. The person who is accountable when two systems that were supposed to talk to each other do not, three weeks before go-live. If the answer is a role, or a pod, or a practice, there is nobody. Accountability is a property of people. It does not survive being spread across a team. Write the name down. A firm that cannot give you one before you sign will not find you one afterwards. So: three questions, and not one of them is about the software. What happens when the estimate is wrong. Show me a discovery deliverable with estimates on the requirements. Give me the name of the person who is accountable. We are CodeStringers. We implement, integrate and operate Zoho-centered business systems. How we handle discovery and estimates is set out on our site, in more detail than the end of a video can carry. If you are working through that shortlist right now, ask those three before you ask about features. The features are all fine. The variance is what costs you.