Consulting Value Chain; MANAGE

In a previous post, I discussed the "Deliver" stage of the CVC. Here's a quick re-cap:

Projects will often require a senior role to take on parts of various roles. For example, technical lead and delivery lead. In this module we're assuming that you are taking on the delivery lead role. This is part of how you add value as a senior consultant.

In this post, I'm moving on to the next stage, "Manage".

What happens on conclusion of an IT services project, and why does it matter?  When a project ends, there's normally a set of activities designed to transition the solution delivered by the project to another party.

The detail, scope and approach to those activities is critical. As a senior consultant you'll add real value to your organisation by understanding the process and how to contribute in five common scenarios:

1️⃣ Handover to customer's support team

2️⃣ Handover to customer's Managed Services Provider (MSP)

3️⃣ Handover to your own Managed Services (MS) team

4️⃣ Warranty

5️⃣ On-going advisory services

💡The Project Manager will be responsible for most of this, but as a senior consultant it's likely you'll be involved to some extent.

Let's break each of these scenarios down and look at them in a bit more detail.

1️⃣Handover to customer's support team

This is the simplest scenario. We're upskilling the customer's team and then exiting the project.

Preparation typically includes:

• Impact assessment : what impact will the solution have for the customer's team?

• Requirements assessment: what are the gaps, how will they be addressed?

• Documentation & associated material: what's required to support handover?

• Knowledge transfer & training sessions: how will the KT be handled?

• Side-by-side support: what transitional support is required?

2️⃣ Handover to customer's managed services provider (MSP)

• Potentially a tricky situation. The customer's MSP will usually be very wary about taking on responsibilty for a solution delivered by someone else (often, a competitor). And your company may be very wary about handing over IP (intellectual property) such as documents, templates, tools and so on, to a competitor.

• There's also the question of collaboration: if the MSP drags its heels and delays your project, that will impact your costs, cashflow and margin.

• Relationships matter here. Saying "Hi, here's your new solution!" at the end of the project is not likely to be the path to success. It's important to put ourselves aside, develop relationships and treat the MSP as a customer; the customer expects both sides to be grown-ups and act on its behalf.

• Preparation may be similar to scenario 1️⃣ but tailored for the MSP.   Scoping is even more critical because of the risks described above. You may not even know who the MSP is at the start of the project.

3️⃣ Handover to your own Managed Services (MS) team

In an ideal world, this would be simple: "left hand, meet right hand". But this may be almost as complicated as handing over to a customer MSP.

Your MS business unit is likely highly autonomous with its own procedures, processes and rules. It may zealously follow ITIL practices which you may not know about. It may use call centres and off-shore resources you've never even heard of. Suddenly, the one-line assumption you put in the Statement of Work is revealed to be hopelessly inadquate.

They may also not be as up to date and "cutting edge" as your practice and customers. Maybe they're mostly supporting Windows desktop and Office apps, when you come to them to hand over your latest AI creation.

Again, the key to all of this is to start planning early: ideally in the "Envision" stage; you don't want to Sell something that you subsequently can't Manage. Get together with your MS Solution Architect and work it out. If you can't do that - don't take a guess, escalate!

4️⃣ Warranty

Warranty seems like a complex trap set to catch unsuspecting consultants. Warranty is a guarantee about who will be responsible, under which circumstances and for what period of time in the event of failures (usually bugs, in software solutions).

The terms and conditions around Warranty can be very complex.  Or extremely simple. For example, major software companies often explictly state they provide no warranty (but they may provide support).

If the solution you're Delivering includes custom code or potentially even just scripts and tools, you should check the warranty situation carefully. If you don't know, you should still check carefully.

Here's why ...

If Warranty does apply, your company will typically want to get through the Warranty period as quickly as possible while providing as little "under Warranty" support as possible. You won't say that to the customer of course. You'll proudly proclaim that yes, Warranty applies to your solution components  here, here and here. Or maybe the customer will say "we expect 90 days Warranty" (typically government customers). Either way, if you're "on the hook" for Warranty, there are things you must take into account and build into your handover plan.

5️⃣ On-going Advisory Services

As you know from earlier lessons, as we progress through the CVC, we're looking for opportunities to add value by up-selling, cross-selling and "gap hunting".

💡There are few better ways than Advisory Services to add value

When your company successful delivers a project and smoothly transitions into ongoing Advisory Services, it will be in the best possible position to improve CRR and CLV (which you will hopefully recall from earlier lessons 😉).

And yet, I expect most IT services companies don't routinely and methodically introduce these as a value-add, partly because they don't have a consulting framework (sorry, couldn't resist) and also because they don't know how to articulate the value (again, sorry not sorry). Maybe they don't have a formal offering in any case (big mistake).

But as a graduate from Consultant Academy you will understand how and when to position Advisory Services. And each time the customer signs off (and they often will), the practice manager will look at you and go "wow, nice work, how did  you do that?".

Summary

Whatever the scenario, the activities and effort would usually be scoped during the Sell stage. But, the only constant in IT services projects is change itself. So you must understand how to anticipate and scope the handover activities while also leaving sufficient defensive "wiggle room" to deal with that inevitable change. In the following lessons, we'll look at how to scope and describe the activities.

Imagine having learned these skills and techniques and being able to demonstrate proficiency to an IT services employer (current or new).

How do you think that would affect their perception of you? And how do you think you’d compare against others who haven’t learned these high-value skills?