An Opportunity to Re-start Requires a Transition Plan

I got a call from our VP of Delivery on Wednesday.  One of our west coast customers is just beginning two weeks of end to end system testing, and based on how things are going, they’ve decided that they were going down the wrong road.  Among other decisions, they’ve made some changes to roles on their project team.  They’ve assigned a new internal project manager from their IT department, to allow the former PM to focus on her SME role.  This leadership change will give us the opportunity to transition our management of the project from the current east coast-based engagement manager to someone based on the west coast.  I was asked to help support the transition, as an “ombudsman.”  As Bryan put it, “You’ll at least get a blog post out of it.”

Note that this isn’t a “rescue” of a “failed” project.  We are discussing this among ourselves as an opportunity for a “partial re-start.”  In essence, the customer has learned a lot about how they should do business, and they’re going to implement those lessons learned, with our help.  One of the most valuable benefits of an iterative prototyping methodology like Workday’s is that you can learn a whole lot from actually using a prototype, and then decide to build a new prototype using a very different set of assumptions and decisions.  That’s what’s happening in this case; they’ve learned enough from working with the current prototype that they want to make some pretty significant alterations to the business process workflows, roles, and organization model.  So we’ll use the lessons learned, recycle much of the configuration work we’ve already done, and build a new prototype using the new decisions and a fresh load of data. In a few weeks, we’ll be ready to start end to end testing again.

Naturally, this is going to invalidate our old plan, especially the schedule.  So we need a new plan, but first, we need a transition plan; a structured approach to help us create that new plan over the coming week or so.  The key steps for a transition plan include:

  • If they haven’t already done so, stop work.
  • Get the core team together and do a little “getting to know you” for the benefit of the new members.
  • Review the project scope, including original and any proposed or approved change orders. Any additional changes to consider?  Any components to eliminate or defer to another phase?
  • Review their design decisions, as documented.  What changes are under consideration?  Drive out the reasons for them, in order to support communications with the stakeholders.
  • Review work in progress and completed to date, including re-work planned or anticipated.  Does the test plan need additional work?  Any changes needed related to data conversion, validation, or how historical records will be handled?
  • Review issues, both closed and open.  Any to add, re-open, or re-prioritize?  Have any risks metastasized as issues?
  • Based on the above and potential schedule conflicts, consider a new go-live date.  Clearly document the reasons for the change, to support communications to the stakeholders.
  • Based on the go-live date and other changes, re-plan the schedule.  This only sounds backwards; they need to go live at the beginning of a quarter.  The schedule should enable the go-live date.
  • Based on the new schedule and staffing changes, update the communication plan and determine how you’re going to re-engage the stakeholders.  Get the key meetings on the calendar.
  • Update the training plan, for the new team members.  Get them skilled up!
  • Review and update the roll-out / change management plan.
  • Based on all of the above, review the risk register.  Have any new risks become apparent?  Any new risk strategies to consider?  Any other adjustments to make?
  • Based on all of the above, review and update the budget, both consultant costs and internal hours and costs.
  • Review with the sponsor and executive committee, and ask them to give their full approval before proceeding.

While some projects go exactly as planned, most require at least some mid-course corrections.  And of course, some require more extensive corrections than others.  They key is not to “bull your way through,” or let anyone get caught up in blamestorming, but to lead the project team toward a clearer vision of the end state.  And the way to begin that newly refreshed journey is to stop and take a long, careful look at the map.