In Part 1 of this post, several options for reducing customer anxiety were identified and explored. In this final segment, two options are explored to reduce the anxiety of a customer and move forward with a project that is successful from the eyes of both the project manager and the customer.
In continuing the themes of providing value and collective intelligence, this post begins with the early stages of requirements gathering and development.
Get working software in front of the customer early and often
Nothing makes people more comfortable than to see something working. This is especially true in the project management world today where some methodologies mandate large upfront documents to define requirements, architectures and the like. These documents may serve purposes but do little to alleviate the trepidation inherent in large commercial software implementations or customer development efforts.
Where I prefer to start on commercial software implementations is to install the core product software in a development or playground environment as soon as possible and preferably the first week. This enables the customer the first win of getting their development environment established and validating the software will run on their hardware. If this is a Software as a Service (SaaS) implementation, the same concept applies although this is typically more about access than installation.
In those instances where the vendor has a reference or demonstration dataset used by the sales force, getting that environment running and/or granting the customer access enables the customer to see and work with the software. We all know the horror stories about vaporware and sales demonstrations that were less than totally above board. Getting the customer in front of the software initially and being completely open about its capabilities enables all parties to speak from first hand knowledge. This environment is also well suited to the playground described in my post on Education Strategies.
Once this environment is established, it also serves as a prototyping or demonstration environment during subsequent project phases in implementation models using prototyping techniques or where document based requirements gathering sessions are used. The greater the knowledge level of the customer on what the software can do, the more the anxiety will be reduced as it is the fear of the unknown that is most difficult to deal with and the greater the number of people available in the collective intelligence arena. Even when gaps in a commercial product are identified, these are knowns that can be dealt with and the customer can make informed decisions vice a position of not knowing.
When possible, provide incremental updates on functionality that is either fully configured or fully built to support the production needs of the customer. By demonstrating steady progress and providing the customer the avenue to both explore in depth and make adjustments to the eventual production system, the customer is able to gain confidence in not only the project team, but also the emerging solution. It is very difficult for a commercial software customer to know how they will want a commercial package configured to meet their needs. It is much easier for a vendor project team to build a working prototype, then demonstrate to the customer how functionality could work. This enables the customer to work with the product, prototype options, and gain comfort the only question is how the system will meet their needs and not whether it will. In these circumstances, the customer is in a better decision making position as they can see and work with the emerging solution before making a final decision on configuration.
The risks the project manager faces are in terms of cost and schedule. Controlling the pace of working through the functionality and getting final decisions from the customer on configuration are key to delivering on time and within budget. I have found that timeboxing the prototyping efforts similar to the iterative approach timeboxing works well. This affords the project team and customer experts a set period of weeks to work out how any subset of functionality should work. The PM should also allow time at the end when all subsets are in the environment to ensure proper and effective operation of all subsets in a consolidated fashion.
In custom development projects, the same concept applies but in this instance, the custom screens are delivered incrementally. With each subsequent delivery, the customer becomes more familiar with the emerging solution. PMs should allow time in each subset to incorporate the feedback. A critical idea is to ensure the feedback is incorporated in a rapid and predictable timetable. A great deal of trust is lost when feedback is received and not incorporated. Rapid feedback incorporation builds the trust and knowledge the project team is interested in building the best solution and the customer has good ideas about how to ensure that. Regression time and risks are reduced when the release plan starts at the beginning of the business process and works through all use cases until the end. For example, login is always the initial subset built as end users log in first. With the delivery of additional subsets, the starting point for testing is always logging in so the regression testing is naturally conducted. The same applies for all the main use cases. I will address release planning in a future post.
Communicate early and often
Open communication and transparency are two key tenants in
my post and of the Enterprise 2.0 approaches and they are critical to building customer confidence and therefore reducing anxiety. This begins with the initial meeting of project manager and customer team and continues throughout the entire project. It is better to over communicate than under communicate. At the outset of the project, the PM will quickly get a feel for the frequency and depth of communication desired by all customer project team members and executives.
Initial meetings should always be in person so each party can see the face of the person with whom they will make the journey. Face to face communication is typically more effective as it is perceived to be more personal and people are easier to trust when they have met face to face. The PM should strive to have status meetings face to face and whenever bad news is to be delivered.
Early in the project, basic strategies are being formulated and negotiated and define the initial opportunities to establish the relationship. Having these face to face also builds trust and repoire. More importantly, is for the PM to define and elaborate on all the basis behind the methodologies being recommended and all the strategies developed. Past experiences and how they either do or could relate to this unique situation enhance the transparency of the PM and rationale behind the current set of decisions and all future decisions. Transparency is all areas should be immediate, never wavering, and absolute.
This transparency is most difficult when issues arise especially issues with a vendor product, but is also the more important time to be transparent. Concealing a problem is a difficult thing for a customer to overcome if the PM is not the one identifying the issue. In my experience, it is better to go to an executive with a problem and that the PM is working on the solution than to have the executive find out about the issue before the PM is able to brief them. Ideally, presenting a solution with the corresponding solution or set of solutions is best but not always possible.
When presenting issues and solutions, additional trust and confidence is built when multiple options are presented for the solution. This demonstrates several ideas including the PM is thinking through the solutions, has interest in the feedback of the customer, and is creative in their thinking to recognize multiple options for a solution.
In summary, customers are anxious for many different reasons and rightfully so. Relieving and overcoming this anxiety is critical to building a successful relationship and managing a project that is successful from the eyes of all parties. In this post, we discussed getting functionality in front of the customer early and often and to communicate early and often as ways to build trust, demonstrate value and progress, and reduce anxiety.
Other recent posts include:
Education Strategies for Enterprise Software Implementations - Part 2
PodCast: Interview on Resuscitating a Red Project Team
Anxious Customer: Options on what to do Part 1
Resuscitation of a Red Project Team
Have Multiple Releases: A Different Approach to Maintaining the Branches