Consulting Value Chain: DELIVER

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

Given the thousands of hours that an IT services company may spend on bids (Proposals and RFx) and the related costs, it might seem strange that most of them don't have a methodology for creating winning bids. Nor do they have a way to ensure that methodology is followed, for example through consistent upskilling. Strange, but true.

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

In the Deliver stage, we implement the solutions and services we've designed and sold in previous stages. Most IT pros work in this stage of the Consulting Value Chain.

In this module, we're not focusing on the actual technical work - that's clearly far too broad a subject for any course or programme. The focus here is on senior roles (because that's where you want to get to - right?) who may be involved directly in delivery, or non-delivery roles such as Solution Architect who may not be involved directly but were engaged during the previous stages of the Consulting Value Chain. We'll refer to those non-delivery roles as "Pre-sales" roles in this module.

Although by now we're delivering a hopefully clear scope of work, the way in which we do this, and the skills we bring into play, will make a huge difference.

Transition-in: pre-sales to delivery

In the Sell stage, we talked about "transition", from pre-sales to delivery. This is a critical activity which sets up the delivery team for success. If it doesn't happen, or if it's not thorough enough, the delivery team is likely to struggle. In this module we're assuming that the transition has been planned and sold as discussed in the Sell  stage.

The pre-sales role:

Using information discovered in previous stages, Engage, Envision, and Sell, the pre-sales role should meet with the delivery team and:

1️⃣ Explain the customer's context, objectives and challenges

2️⃣ Identify key customer stakeholders' needs and challenges

3️⃣ Describe the solution and implementation approach

4️⃣ Walk the delivery team through the Statement of Work

5️⃣ Review possible risks, constraints and dependencies

The project scope should also include enough effort for the pre-sales role to prepare for and attend the internal and customer kick-off meetings. Depending on the complexity of the project, the pre-sales role may need to contribute more time and effort to ensure the project starts smoothly.

The senior consultant role:

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.

Projects are usually managed by Project Managers (if there's no PM on a project, either it's a very small and simple project, or something has gone badly wrong in an earlier stage!).  So it's useful to understand how you'll work with the PM.

Essentially, both roles should care about:

➡️ Project budget and scope.

➡️ Cashflow (timesheets, milestones, invoicing)

➡️ Risk & Issue Management

➡️ Technical Change Management (TCM)

Although the responsibilities of each role differ, they are complementary:

How Project Managers & senior consultants can work together

On projects, the senior consultant is in a unique position to identify further business opportunities and to help the customer get more from their investment.

In general, on a delivery project:

1️⃣ You MUST:

• Review the Statement of Work  as part of the transition-in.

• Be fully familiar with the solution, scope, risks, dependencies, constraints.

• Understand the customer's rules for implementing technical change.

• Carefully manage completion of timesheets for yourself and team.

• Look for opportunities to avoid or reduce "bench" time on the team.

2️⃣ You must NOT:

• Offer to "fix" something that has been completed and accepted by the customer. This must be addressed by the PM, through a Change Request.

• Offer to change something from the design and scope described in the Statement of Work. This must be addressed by the PM, through a Change Request.

• Implement changes outside of the agreed technical change management process. Changes must always follow an agreed change process. If it doesn't exist, that's a risk.

3️⃣ You should:

• Look for further business opportunities. For example maybe the customer is struggling to create a test plan.

• Discuss any such opportunities with your manager. For example "looks like the customer is struggling to create a test plan".

• Try to anticipate the customer's needs and discuss with the PM.  For example "they don't seem to have a decent test plan; we could offer to help develop that through a Change Request so that the project isn't delayed".

💡The customer has engaged your company to deliver the project because they need the help. Assume they "don't know what they don't know"; you're the experts. Add value by anticipating their needs and looking out for further opportunities to help. Bring any such opportunities to your manager and PM, without affecting your scope of work.

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?