I worked at a large ERP implementation many years ago. The client was a large and well known hospital. They had already kicked the first group out of the place and were working on kicking out the second group when I rolled off another project and started to look around, desperately as it were, times were tough, for another engagement. Well they were so fed up with the other consultants that they accepted me on board. What they didn't like was consultants telling them how they should be doing business on Oracle. I got the message early and often. They wanted to be in charge. I remember that the new project manager came in right after me and he wanted to know what I thought about the project. I was upfront as usual and said that of course I was more than happy to cede the control that I never wanted to the client. He was a little surprised but he came around to the idea eventually. Why fight with the client when they have the high ground? Seems obvious to me that if the client wants the hill, they get the hill. (Eventually the adage "It's not a hill I'm willing to die on" became the project motto.) In many implementations the client is not willing to take control. To the contrary they want the consultant to bear the risk and the burden of the system design, test, training, everything. Project management and the users are only to happy to give the consultant the bulls-eye to wear around. After all, if it works, the consultant leaves and the client's people take the rewards. If it doesn't work the consultant sticks around and takes the blows and the client's staff remains protected. Most consultants strangely are happy with this arrangement. They get to be the big shot for a while and everyone pays homage to their wisdom, whatever that may be. But the hospital folk wanted to take the glory from the start. None of the previous consultants were willing to cede it, so they all got the boot. Now the client was willing to bear the risk of the new system, but of course they really did not want the burden of the implementation work. That was still ours. When it came to system design I would lay out the application for them and they would pepper me with questions. What we called the 'Stump the band" approach. They answered questions very hesitantly; they did not like answering questions, frankly. Questions made them feel less powerful. Eventually I began asking myself the questions, in the form of "one of the things I was asking myself earlier when we covered this point...." This was acceptable and they would jump right in and participate, then. Eventually they would hit a wall and would have no further ideas on how to proceed. Then they would ask the question: So, how should we set this up, optimally, you know? Now, it looked like a trap and it felt like a trap so I handed the ball right back to them: You understand your business model better than I do. They wanted control after all, they had to stick with it and see it through to a design conclusion. Amazingly, they often deliberated for several days more than necessary but in almost every case came up with excellent design decisions. And they were empowered by the process (not that they needed more power, this crew). This implementation was not perfect, none of them ever are. But as a learning experience it could not be matched. It was the exact opposite of every implementation that I had done up to that point. But it became a model to work with over time, and, hopefully, perfect. The concept is to give the client the ability to ask the good questions, empower them, let them design the system, let them make the decisions and take some of the risk. It's a process that sharpens the mind and stiffens the back. The result is a well designed system. This is how, in our humble opinion, a good consultant consults. Working with small and medium sized businesses on NetSuite implementations is no different, from our point of view. However I must say that there is a lot less persuasion required to bring the client along as the decision maker. People in SMBs are used to responsibility and normally never shrink from the system design challenge. | 
