We are now in the process of implementing a large scale document management system for a construction company. This is an experience that shows the value of good training and documentation as well as setting expectations. The software has been installed and is functioning and now comes the training of the users. We are the reseller of the software not the actual developers, so we base our knowledge on what we’ve learned from installation, use, certifications and documentation provided by the developer.
When training the customers we need to be experts and provide effective recommendations on how to use the software based on the customer’s business needs. Fit the software in the business processes wherever possible for optimal integration. In order to do this we need good resources to educate ourselves on the details of the product. The integration will fail (or not be as effective as it could be) without this knowledge. Your customer will have questions that may get too detailed for your knowledge. Answering these questions with guesses or “knee-jerk” reactions is dangerous and at that point you are no longer the expert in the customer’s eyes. To prevent this from happening the best thing to do is table the questions you aren’t sure about for a later date until you can do more research.
Documentation for the product is very important as it can provide you and your customer for a base on best practices and detailed information on the functionality the system provides. In our case, the documentation was written by the developer. At this point, it would be beneficial to have documentation up to date when the product is released, not during or after the release of the product. This will eliminate confusion in the future. It is also important that before your reseller can sell the product they need to receive certification for sales and service. If these certifications are not available…wait to release the product. It is far better to have the reseller trained and certified on the product before the implementation cycle begins. This will ensure the developer has passed on key knowledge to the reseller in order to not only sell the product effectively, but to support it as well.
Setting customer expectations in the beginning is important no matter what. Set the rules of the game in the beginning. No one likes changing the rules in the middle of the game. Large scale implementations such as the one we are working on now can be complex and confusing. The thing to practice most is communication. Communicate your responsibilities and requirements to all parties and visa versa. This way everyone knows their role and what they need to accomplish in order to achieve a successful rollout.
Micromanagement
Micromanagement is wasted on some. All it can do is confuse and disrupt their thought processes, which leads to an overall feeling of worthlessness. Allow me to illustrate by using an analogy: I don’t call a pizza parlor and tell them how prepare the pizza. I tell them what I want as a final result (large pepperoni). The pizza making professionals will output that final product based on their knowledge of pizza making. They don’t need me to tell them how to spread the sauce. Even if I ordered extra sauce, the professionals know how to put it on the pizza. Just imagine if you called a pizza parlor and told them to start making crust then put the sauce in the middle of the pizza and spread out toward the edges…so on and so forth. Two issues here. One, you’re telling them how to make pizza when they know how to make it. Two, they don’t know what the final product is until you’re finished instructing them how to make it. If you’re incorrect on how to make it the pizza professional will have wasted their time and product and will need to start over.
Some people just need to know what the objective is and they’ll do what they were hired to do to get there. They need a destination before they can pave a road so that they may plan for equipment, time, and best possible route.
I’ll end my rant by saying that while micromanaging may be necessary for some, it’s not for most.