Five ways to beat the project transition blues

'It’s not the plan that’s important, it’s the planning.' — Dr. Gramme Edwards

Transitioning any complex work from one group to another has been an age-old problem.  In IT consulting, it is no different. Consider the transition of a sales pursuit team to a delivery team. The sales pursuit team is often firing up if not fully involved in the next pursuit when the transition commences, and the typical result is "throwing the ball over the wall" to delivery to figure it out. Delivery has smart people, so they will manage, right?

Wrong. Do not fall into this frequently encountered trap.

In a new project, it is vital to communicate and confirm the initial assumptions and their nuances during project transition. Otherwise, they will often blow up into big events. For instance, I have seen the case where the type of JavaScript used for development project was assumed to be open-ended, so the delivery team decided to try Facebook's ReactJS, but the client had a standard around Google's AngularJS. Four developers starting building out the product under ReactJS and four weeks later discovered the AngularJS requirement, requiring a messy conversion or full-scale rewrite. That was a completely avoidable loss of potentially 640 hours!

It is not just communicating the known nuances, but also discovering the unknown assumptions not identified during the sales process. For instance, if the client has a corporate standard for zero bug tolerance and the pursuit team believed that was for Severity 1 (critical) and Severity 2 (high) bugs only, there may be a big surprise in the total work needed for delivery due to the time for bug squashing, impacting budget and schedules. There are many further examples, including current environment, level of technical debt, current architecture, nonfunctional requirements, etc.

Therefore, transition is critically important.

How do you mitigate and even resolve most transition challenges?

First, be aware this is not a "one and done" effort. This is a recurring process. As shown in the graph below, the amount of time for a transition will spike at first and then decline over time. This is because we are human, and for complex projects, we will need time to think about all the variations, combinations and permutations of the people, processes and technologies involved. We are collectively starting “at the stupidest point of the project”.

Graph of transition time x effort

Typical transition time for complex projects

There are tools and processes to help. Here are five major themes to be successful in transition.

1. Start slowly and cautiously, then move fast

Once approved for delivery, hold a major kickoff meeting, first an internal one between the sales and pursuit teams, and then an external kickoff meeting with the client. These meetings should be thorough and should cover the following major areas:

  • Client and consulting cultures and stakeholders.
  • Type of engagement.
  • Process assumptions.
  • How progress will be tracked and measured.
  • A determination of major issues, risks, assumptions, constraints and dependencies.
  • A checklist for logistics, administration and initial project and team setup.

2. Keep continuity active between sales and delivery

This is where things usually break down. Both teams assume “they got it,” and the sales pursuit team goes on to the next pursuit.

Hence, recommend that sales and delivery leadership request additional meetings and transition activities over the next several weeks. This is for the delivery team to summarize assumptions made and challenges encountered to ensure they fall in line with the original project expectations and bridge any discovered gaps.

This should include the following:

  • Regular checkpoint meetings showing progress metrics.
  • Full oversight from the pursuit lead in delivery events.
  • A comparison of ongoing delivery findings and decisions with pursuit assumptions.

3. Focus on trust, communication and transparency

We all say these traits are important, but without trust, communication and transparency, those are frequently missed “hidden elephants” when small and manageable that then grow too big for the engagement to handle. If anyone in the delivery teams identifies a lack of trust, communication and transparency, it is time to “press the red button” and escalate quickly. Bad news does not improve over time.

4. Always question assumptions

The mindset of asking, “Why are we building the product this way?” should be included in both pursuit and delivery teams. When determining how the product will be built, the transition from who, what and why may get lost due to that loss of continuity from sales to delivery. This is critical throughout the entire delivery cycle, but especially at the start of delivery.

5. Track progress with the right metrics

Choosing what to track may seem simple, but can actually be one of the more challenging decisions to make during product delivery. Choosing the right metrics to follow and ensuring the metric is properly populated and measured is critical to knowing the overall performance. Metrics should enlighten delivery successes and challenges, not hide them.

The sales pursuit team should conduct a formal disengagement once the delivery team has shown a point of stabilization. Derive this from when issues, assumptions and delivery metrics show consistency and predictability. Naturally, I will give the consultant’s answer on when that happens: "It depends." However, it will be clear when that happens.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Fall 2018 digital issue of CIO