Don’t Be The Victim Of A Customer Project Handover Gone Wrong!

I am a big fan of cop and legal dramas and have watched endless TV episodes of Law and Order, The Good Wife and The Closer, where brave public servants help victims of a variety of crimes. But, something is missing! I think it is time someone pitched a new television show about projects. This new show would address the crimes that occur during a troubled software implementation engagement, perhaps called “Project Handover Red!”.

If you work in a big ticket software, technical support organization then you and your team members have likely been the victim of a customer project handover gone wrong.  This is not as serious as other crimes, but addressing a red, project handover is of critical importance.

A “project handover” is the point in time that a customer installing a large ticket software product moves from their “project phase” to their “production support phase”. In the project phase, the professional services organization manages the customer engagement. The activities focus on planning, testing and implementation.  In theory, when the customer moves to the “production support phase”, the project phase is completed. This means that software defects were addressed, the customer has gone “live” and the software is working as designed.

Unfortunately, this is not always the case. Often times the customer is moved to production support too soon. This results in frustration, long work hours, both employee and customer dissatisfaction and, at times, financial penalties.

How can you fight the crimes that occur during a troubled software implementation engagement? Lieutenant Reynolds recommends the following steps.

1) Define the laws of the handover.

Start by clearly defining the project handover process itself. Partner with your sales and professional services organization to map out and agree on the sequence of events leading up to and immediately following the project go-live. This will help ensure that the handover is successful.

2) Assign a division to the process and traffic cop to each project.

There should be one handover process owner, and in my opinion, it should be the professional services organization. More specifically a Project Manager should own the successful completion and handover of an individual project. When there are multiple owners to the steps in a project, no-one takes accountability for the overall project handover’s success.

3) Involve the entire squad at the start of the shift.

Involve technical support and engineering at the beginning of the project. The more that the support teams knows about the customer and their project, the more successful they will be in supporting the live customer. Bringing them in at the very beginning, allows the support team to provide advice or input. This also allows them to plan far ahead for success, e.g. appropriate staffing.

4) Build project handover activities in the scope of the project hours.

When the professional support team calculates the full project hours and resources required, they must include the tasks and time for a successful project handover. If not, team members may skip many of the success steps and the handover will have problems. The project team will quickly move on to new, billable work.

Taking a step back, the hours required for project handover tasks are not material compared to the hours required for all of the other project steps. But, the small investment will have major returns! The customer will be much happier with the outcome of their project. Customer satisfaction, will lead to customer loyalty. This will lead to more billable engagements and new business referrals.

Taking short cuts in this area can have major, negative ramifications, while investing in them can have a measurable, ROI.

5) Like a good District Attorney, negotiate the details of when the customer is ready to hand over.

Before the customer nears go live, the project team and the support team should meet and discuss the criteria for allowing a project handover to occur. There should be some standard criteria for all customers. For example, no open Severity 1 (outages) tickets, no open Severity 2 (critical) tickets and less than 10 Severity 3 (ongoing support) tickets.  This criteria will vary depending on your product and business needs.

Since all software has product defects, and some are more important than others, it may not be realistic to address every issue before the project changes hands.

6) Like a good lawyer, negotiate the details of who will handle any open tickets.

Agreeing on the number of open issues is one step, but it is equally as important to determine who will do the work to close out the open issues. It may be helpful to walk through each open ticket and agree on a go forward business owner. For example,  the project team will close out certain types of tickets, while production support will take over a different type. This work assignment will vary depending on your product, policies and business roles.

7) Submit your paperwork on time.. and don’t leave anything out, or the Sarge will be mad.

A successful project handover requires that the customer is ready AND the internal staff members are ready. More specifically, your handover activities must include tactics for information transfer from the project team to the production support team. They must also include details about the customer’s environment, software customizations and anything else that you consider pertinent. This information transfer may happen at the time of handover in the form of training or documentation. You should also consider processes that will support ongoing questions, months after the customer is in production.

If your company can ensure consistent, successful customer project handovers, than your company will reap many benefits. This includes increases in customer satisfaction, customer loyalty, new business and employee engagement. Why not start the crime fighting process right now?

© 2012 – 2016, Marci Reynolds. All rights reserved.