We have all begun projects where the customer is anxious. The larger or more complex the project, the greater the anxiety tends to be. Customers can be anxious about projects for many reasons including:
- redesign of key business processes and unsure if they will work
- can be career makers or breakers (especially for mid to upper management)
- large monetary amounts involved so greater scrutiny from internal sources (audit, finance, board, etc)
- unsure if business customers will accept the new solution
- executives may be unsure staff is capable of executing on a large project
So how do we fix the situation as the risks mount the longer the project proceeds without dealing with the reasons for the anxiety. I think there are three main focuses to reducing the anxiety within a customer for commercial software implementations and two for custom development projects. I plan to address the first area in this post and the other two in a subsequent post.
The first step applies to commercial software and is to educate the customer on the software to be implemented. This education should include vendor available product training focused on the options for configuring the product. Focusing on the configuration options vice end user screens enables the customer to see the flexibility the product encompasses thus building their confidence the product can be configured appropriately for their unique environment. Trainers should focus on these options and resist the temptation to determine what is "best" for the customer. Ideally, this training should occur during the initial weeks of the implementation to provide a solid foundation in the product for subsequent requirements gathering or prototyping activities whichever approach is chosen.
While the customer is off at training, the implementation team can install the software in a development environment. This does require the pre-planning to ensure the hardware is available at this early stage and can typically be requested as a pre-requisite to the implementation team coming on-site. If the vendor has a demo instance or reference implementation that was used during the sales cycle, this will work best as it answers the question "Will the software work at my site." This enables the implementation team to meet the customer with the first task completed, demonstrate value, and demonstrate the sales presentations are reproducible in the customer environment. These two items have enormous value in making the customer less anxious.
The implementation team can also quickly schedule demonstrations of the functionality in more depth than demonstrated in the sales cycle. In this case, allow the customer to steer the conversation to those areas where either concern was identified during the sales cycle or where functionality was not completely understood. The presenter who is usually the senior technician can also use this opportunity to demonstrate the flexibility of the product and the technician's expertise. Gaining confidence in the senior technician helps to overcome the second typical concern which is can the implementation team execute a successful project. This is also the opportunity for the project manager to take center stage and also applies to custom development.
At some point during these demos or the first few days of the implementation, I typically like to brief the implementation methodology in its raw form including the template project plan. Since the briefing is typically to the executive level, the first couple levels of the work breakdown structure are deep enough. Highlight the threads such as training, design, testing, all areas where the implementation team will interact with the customer, and how the solution comes together during the later project phases. This will ease anxiety by demonstrating the project manager has done this before, the implementation/development team will work with and collaborate with the customer to ensure the best solution, and the project manager is focused on ensuring the customer can operate and maintain the solution once live.
After initial demonstrations in the sandbox environment, deliver the product documentation to the customer and encourage them to read through it and walk through the various configurable options in a sand box environment. As with any new material, reviewing the documentation with an environment available to work in will increase the knowledge retained during the activities and reinforce what was demonstrated. As the customers gain confidence with the software through trying the different options, their confidence in the emerging solution will grow and their anxiety reduced. The side benefit is the customer can be more collaborative during the project since they are more knowledgeable so the collective intelligence of the project team is greater and that will reap benefits throughout the project.
The second post will focus on development models and which work best as well communication. Stay tuned.
Comments