Mark Gibson; PgMP, PMP, IBM certified Executive Project Manager

Education Strategies for Enterprise Software Implementations - Part 2

In the initial post of this series, we discussed the use of formal classroom training and its value in the education strategies for commercial software implementations.  In this second and final post, we will review the opportunities later in the project and the opportunities intrinsic to certain methodologies.

Formal Demonstration

After formal training, the requirements definition or gathering process can begin.  By using the formal training as the foundation, the customer team has a better understanding of the available options within the commercial package.  The project manager can reinforce the classroom training and supplement the requirements process by using the software to demonstrate and illustrate the functionality under discussion with the group.  This begins the transition from understanding the software in theory to understanding and collaborating with the implementation team on how best to configure the commercial software to the customer business.  The side benefit is increased acceptance of and understanding of the solution by the customer as they participate in and help to define the solution.

Prototyping

If a prototyping-based approach is chosen by the project manager, this affords good opportunities to integrate the training and development into a single activity.  Education on the screens and functionality will naturally occur when the end users define the solution operation.  The key is to use functional prototypes so the details of the screens are known vice demonstrating wire frames which leaves some doubt.  When implementing a commercial package, the focus is on the options available for configuration so the focus initially is more on the administration screens which govern the operation of the end user screens.  Once the available options are known and the mechanics of configuring, then the focus can shift to how the end user screens operate with any given configuration.  This process is iterative by nature so the knowledge is re-enforced of how to configure the commercial software to achieve a desired end user experience.

Testing

One of the final opportunities to educate the end users before the traditional pre-deployment training.  The initial testing phases including a traditional system test or user acceptance training afford chances to both flush out the details of the functionality but also reinforce what has been learned to date by exercising the features of the solution.  Besides the project team, this form of education can be expanded to other groups to increase the set of end users who are proficient in the solution.  This is especially important in a widely distributed set of sites or when the decision of acceptance is made by a group larger than the project team.  Similar to the prototyping approach, exercising the screens will naturally result in the accumulation of knowledge and proficiency on the solution.

Playground

Finally, the use of a training or playground environment is a traditional manner to educate customer on their emerging solution.  This environment is typically independent of any formal development or testing environment so the individuals looking for education are not impacted by the instability of the development and testing environments.  This also affords an environment for other traditional activities such as test planning.  When using a playground environment, it tends to be easier to provide some structure such as use cases or a test planning activity initially.  Once more proficiency is gained, the freedom to exercise the functionality in a more ad hoc fashion can be carefully managed.

The education opportunities defined in both part 1 and 2 of this post identify options for a project manager in either a custom development or commercial software implementation.  The use of any number of these suggestions is a project specific decision.

Other recent posts include:

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

Leadership Question: Does the PM work for the resources?

Podcast: Interview on Resuscitating a Red Project Team

After publishing this post, I received a request by Samad Aidane (@samadaidane) to expand upon the ideas and techniques described therein.  It also contains some additional ideas on the "Do Project Managers Work for the Resources" and "Basic Tenants for Project Management" posts. 

 This Interview on Resuscitating a Red Project Team was conducted on February 19th by Samad Aidane (Guerilla Project Manager Blog).  I hope you all enjoy.

Anxious Customer: Options on what to do! - Part 1

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.