The Initial Sponsor Conversation

Picture the scene. You’re about to walk into the office (real or virtual) to meet with your project sponsor for a project validation discussion. Your sponsor is the head of operations and has a reputation for straight talking and always being right. You’ve seen an email on the project brief but it’s not exactly clear so you’re hoping to find out more.

The highlights of this conversation are,

Sponsor: “Thanks for coming in. We’ve got a problem that we need help to resolve. We must reduce costs in our supplier base by about $2m a year because they’re way too high, unsustainable and hurting margins. I’d like you to look at this. Jim in procurement will help you with what you need, can you go and speak to him? I expect you’ll end up rewriting contracts or rationalising the number of suppliers we have and try to leverage volume-based cost savings. You might also look at the headcount in procurement, personally, I think it’s far too big a team for what we do. We’re already halfway through the year and it’s got to be done by the end.”

So, you go to speak with Jim.

Jim: “Yeah, I heard about this pipe dream of theirs. Do you know we have over 2000 active suppliers? They all have different contracts and clauses. Some of them have delivery agreements that last years! How on earth do you renegotiate that number of contracts? Frankly, it’s madness. Even if I had people with time to work on this, I can’t make changes. I need the business to sign off on changes as it’s their service to their customers that will be impacted. My team are always complaining about the process between us and operations as it’s always failing, takes forever and is littered with issues. I’d much rather you focussed on automating that.”

Traumatised by these ‘conversations’ you contact your LSS expert, talk them through the conversations and ask advice. Your expert gives the following feedback.

LSS Expert: “Well, there’s a business need there (need to reduce costs by £2m a year, margin impacts), but it’s very broad and lacks scope (2000 suppliers). There’s a concern that we might be trying to drive cost out at the detriment of service quality (it’s Ops service to their customers that will be impacted). We won’t know that for sure until we get into the project, but I’d want to keep a close eye on that risk as the project develops.

You’ve been asked to use Jim but clearly, he doesn’t have the authority to make changes to contracts (I need the business to sign off), if that proves necessary. Nor does it look like he can release resources to the team (even if I had people).

I don’t like the way your sponsor and Jim have articulated potential solutions either (rewriting contracts, rationalizing suppliers, volume-based cost savings, headcount reduction and automation). DMAIC projects are always undertaken when the solution is not known but where we have a clear problem. I don’t see that the problem (other than the high cost) has been truly defined. Maybe that’s enough, but it doesn’t sit well given we know the scope is too broad.

Did your sponsor or Jim define any processes? No? OK, so that’s a gap as well. We should clarify what the process is between ops and Jim’s team that keeps failing to see if that’s in scope. Aside that the proposed automation is another solution, there’s little point automating a bad process.”

Is This DMAIC Project Valid?

Oh dear. This potential DMAIC project has hit many of the common issues that turn great lean six sigma projects into bad ones. In the below list of ‘common things that doom my project from the start’, how many can you tick off based on the previous dialogue?

• Project is not relevant to customer’s or business needs
• Project scope is too broad
• Process start and end points not clear
• Authority to commit time and/or resources is not present
• Authority to make changes to the process is not present
• Data collection problems – too much or too little
• Process doesn’t cycle frequently enough to effectively monitor
• Problem written as a solution – Lean Six Sigma projects are based on creativity and an open mind
• Process improvements made in one area at the expense of another
• Automating bad processes so that defects occur more often

I’d like to say this never happens, but the above example comes from real life. Real project, real people (albeit ‘Jim’ is someone else!), real practitioner attempting project validation on their first LSS project, and myself. After multiple conversations with the sponsor, we did get to a reasonable project charter and the practitioner ultimately delivered benefit. We decided that contract renegotiation was out of scope – that was a ‘just do it’ activity to be jointly run by Ops and Procurement. The LSS project was focused on streamlining the supplier contracting and contract renegotiation processes and was to be completed ahead of the ‘just do it’ element. Subsequent projects would look at other aspects of the overall supplier management process.

Preventing Poor DMAIC Project Validation Conversations

Having initial project validation conversations with sponsors can be difficult, especially if they are strong characters and more senior. To avoid these becoming one way or confrontational, I like to send my sponsor this checklist ahead of our project validation meeting with a note that says “Looking forward to exploring the project with you soon. Ahead of our meeting, could you please read and consider the attached project validation criteria list? We know that past projects that define these items well are more likely to succeed and deliver greater benefits. I’d like to discuss them with you and get your input on how you think the project intent meets them today. Thanks!”

And this is the form I send.

	Project Validation Criteria	Response
1	The project is related to a key business issue	Y	N	?
2	I can get customer input on the issue	Y	N	?
3	Management feels this is a high priority	Y	N	?
4	I can identify the process’ start and end points	Y	N	?
5	There is opportunity for measurable improvement	Y	N	?
6	The process has frequent cycle times	Y	N	?
7	I can identify waste or defects in the process	Y	N	?
8	The problem is stated as a goal, not a solution	Y	N	?
9	The project is scoped so it can be completed on time	Y	N	?
10	I can identify the process owner	Y	N	?
11	The project sponsor has the authority to commit time and resources	Y	N	?
12	The process is not slated for change by another initiative	Y	N	?

Having this list with you as you discuss a project for the first time can be a real help. It’s not necessarily the case that you quiz your sponsor question by question and answer everything straight away. More often, it’s the ability to extract these items from conversations and probe further to ensure that the coverage and depth of understanding is sufficient.

Guide Your Sponsor

We need to recognise that not all sponsors fully appreciate the nature and nuances of DMAIC projects. Many leaders, quite frankly, don’t care how things get done, so long as they do. Every now and then, we will come across this type of project that, from the sponsor’s perspective ‘needs doing’, but from our perspective as practitioners of DMAIC, is not for us in this guise. In these situations, it is up to us to guide and advise.

For instance, a common problem is that sponsors may not fully appreciate the value of a specific scope. When I discuss scope with my sponsor, I’ll talk about it in terms of processes and their start and end points. Then I’ll ask about products or services (value streams) that flow through those processes and the outputs that are created. Which teams/geographies/sites will we include? Market segments? Customers? Suppliers? Often, we’ll generate a SIPOC – I highly recommend that – to bring these elements together coherently.

Very often when you have this detailed discussion on scope, you can bring in other questions from the project validation criteria form as well. Here’s a couple of examples, “will we be able to see the waste and defects in this process?“, or, “how is this process measured today that defines its performance relative to our intended goals?“

At the end of this conversation with your sponsor, it’s not uncommon to have several maybes and a few no’s. That’s OK, it just means there’s some follow up to do before you can get properly underway.

Keep DMAIC Project Validation Practical

Let’s also stay practical and agree that not everything must be a ‘Yes’ before you start your project. Many DMAIC projects start with some ambiguity and uncertainty. I’m always OK with that so long as it doesn’t feel critical. As the project leader, it’s part of our role to manage this.

The Yes or No or Maybe column on the right is not a tick box exercise. You own the completion of that column and ‘ticking’ the relevant answer needs deep thought based on reasonably detailed dialogue. After all, the more you test the purpose and structure of your project at this stage, the more robust your project will be and the greater its chances of success. You’re the one on point to make it happen, not your sponsor.

Invest the time with your sponsor to define your DMAIC project well.

A well-defined project = happy team + happy sponsor + happy customers.