I am a big fan of cop dramas and have watched endless TV episodes of Law and Order, Southland 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, which addresses 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 and activities focus on planning, testing and implementation. In theory, when the customer moves to the “production support phase”, the project phase is completed, software defects 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, resulting 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 that you….
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, that will 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, and 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.
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, and plan far ahead for success, e.g. appropriate staffing.
4) Build project handover activities in the scope of the project hours (could not think of a clever police analogy)
When the professional support team calculates the full project hours and resources required, the tasks and time for project handover must be included. If not, many of the success steps will be skipped and the handover will have problems, as the project team is rushed 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, which 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 is not realistic to assume every issue has been addressed 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, e.g. 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 and 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 and 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 including increases in customer satisfaction, customer loyalty, new business and employee engagement. Why not start the crime fighting process right now?