“Failing to plan is planning to fail”, so the saying goes. That’s why the first phase of any Six Sigma project is the Define Phase.
During the Define Phase, the project leader (usually a Six Sigma Black Belt) works with the stakeholders to understand the goal of the project, puts together a plan for achieving that goal, and identifies a team capable of delivering that plan.
Over the course of many Six Sigma projects, I refined this process down to a few key tasks which set the project up for success. In this post, I’m going to share them with you in the hope they help you get your projects started in the right manner.
Deliverables of the DMAIC Define Phase
The following documents make up the key deliverables for the Define Phase of a Six Sigma DMAIC project:
- Project Charter
- Project Plan
- Risk Assessment
- Stakeholder Analysis
I’m now going to discuss each of these in turn and share my method for getting them done quickly and efficiently.
Project Charter - What is the goal of the project?
When I first trained as a Black Belt, I was given a template that we had to fill in for the project charter. It comprised of 6 sections:
- Opportunity Statement - describes the problem.
- Goal Statement - describes the goal of the project.
- Scope - defines the boundaries of the project.
- Team - defines team member roles and responsibilities.
- Plan - outlines the tasks to be done and a schedule for completion.
- Business Case - describes the benefit to the business of solving the problem.
Each of the six sections came with a list of questions that were to be filled in. Furthermore, the goal statement was to be a SMART goal (Specific, Measurable, Attainable, Relevant, Time-bound).
This was all well and good, but in practice I found the template wasn’t all that helpful. Throughout the business I discovered people’s understanding of each section was different - even those who had received formal Six Sigma training.
I therefore developed my own process for completing the project charter. Many of the elements are the same, but the process I used to get them was far more effective than sitting everyone down in a conference room and trying to fill in a template.
Clarify the goal of the project
As we already know, DMAIC is the Six Sigma methodology used to fix problems with existing processes. Therefore, my first involvement with a project would be when a sponsor approached me about a problem in their area and asked me to run a project.
I would then sit down with the sponsor to clarify the problem and their expectations for the project. This was often done one-to-one in an informal meeting. I had a small set of documents ready to print that I would take with me to the meeting. We would work through them together to fill them in before anyone else got involved in the project.
This was key. As the project leader this initial meeting allowed me the time to fully understand what problem the sponsor was experiencing and to ask my own questions. It also helped me to understand what they were expecting in terms of deliverables so I always knew how my performance as a project manager was being assessed.
Only once I was happy I understood the problem would I meet with anyone else.
“The foundation on which all good projects are built is a clear understanding of the scope. Without it a project manager will struggle to deliver successfully.”
~ Richard Newton, The Project Manager: Mastering the art of delivery
Here are the questions I would work through with the sponsor:
What is the problem you are experiencing?
What I was trying to determine here is the metric that the sponsor wanted to improve. It’s a fairly safe bet that if a sponsor asks you to run a project, it’s because they’re not currently meeting one of the goals against which they are measured.
What is the overall objective of the project?
Here I’m trying to establish what the sponsor thinks will happen when the project is complete. This is important because ultimately that’s how my success as a project manager will be assessed. In theory the objective should simply be that the key metric we already identified is achieving or exceeding the target. However, sponsors don’t always think the same way as we do so it’s worth having the conversation to be clear.
Another question you could ask here is “How are you going to measure success at the end of the project?”.
What event marks the end of the project?
This is a question I used to scope out the project. It turns the objective from above into something more concrete (an event) that we can aim for. As an example, if the objective was to reduce the percentage of scrapped parts off a process, here I would turn that into an event by saying the percentage of scrapped parts was below target for 3 consecutive months. This is a clear goal that everyone can get behind and it will be obvious when it is achieved. It creates a clear end boundary for the project and prevents projects that never seem to end. If 6 months later the scrap has increased again, the project doesn’t continue to run. It’s likely something in the process has changed and a new project may be required.
Is the project team responsible for the deliverables or the business benefits?
Leading on from the previous question, I always asked this. Basically the intention here was to clarify whether we were being tasked with implementing a known solution (set of deliverables) or improving the process by any means we could come up with (business benefits). It’s an important distinction.
From a pure Six Sigma perspective it should be the latter option. We shouldn’t be thinking about solutions until the Improve Phase. However it was very common in my experience that a sponsor already had a solution in mind and were looking for someone with project management experience to implement it.
The reason I always liked to make this distinction clear was as follows: If I hadn’t been involved in selecting the solution and was just responsible for implementing it, I couldn’t guarantee it would deliver the business benefits. Obviously I would try my best to make sure it did, but I always made it clear that we had effectively skipped straight to the Improve Phase without doing the necessary data measurement and analysis. For that reason, as long as the solution was implemented successfully (on-time, on-budget etc), it was not my responsibility if it then failed to deliver the expected business benefits.
What from your viewpoint can flex?
Anyone who has some project management training will be familiar with the project management triangle, or triple constraint. This refers to three constraints put on a project which are speed, quality and cost.
Speed is how quickly the project will be completed. Quality is a measure of how effective or reliable the solution is. Cost obviously refers to how expensive the project is to complete.
A common request when discussing the project management triangle is to “pick any two”. In other words, which two of those three constraints are the most important to you as the sponsor? Having this discussion during the Define Phase forces the sponsor to recognise the fact that they can’t have “the moon on a stick” as they say (all three). Managing their expectations at this early stage forced them to prioritise and made things much easier throughout the life of the project.
If they want it done well and done quickly, it won’t be cheap.
If they want it done well and done cheap, it won’t be quick.
If they want it done cheap and done quickly, it won’t be done well.
In my experience, the sponsor was rarely willing to compromise on the quality of the outcome, so this discussion became a trade-off between cost and speed more often than not.
During periods of austerity, I have run projects where there was hardly any budget at all. I therefore made it clear to the sponsor that it would likely take much longer to complete the project to the same high standard they expected. This was because we were having to wait to use internal resources when we could have outsourced earlier had the budget been available.
Are there any other constraints on the project?
Although we covered the main constraints in the previous question, I always asked this as an open ended question to get the sponsor to think about the potential challenges we might face in running the project. Normally they were in a more senior position in the business and knew about things that might not be common knowledge throughout the company. It could be as simple as the fact that someone you would expect to rely on as a valued member of the team has handed their notice in and will be leaving, or they may be sent abroad on business and be unavailable to participate. It could be a whole host of things that you may not be aware of, but that could affect the success of the project. Therefore asking this question of the sponsor early on helps to identify any potential issues so they can be managed.
How will decisions be made?
This will vary from company to company, sponsor to sponsor, and project to project. Therefore I always made a point of clarifying up front who was responsible for making the decisions on the project. Often this related to budget, in which case the sponsor would decide the appropriate level of authorisation to spend the money. However it also affected things like whether we would wait for formal gateway reviews to make decisions, or whether an informal one-to-one was sufficient to get the go-ahead.
Can you allocate all of the resources required to complete the project?
The intention of this question was to determine if other stakeholders needed to be involved during this early stage. If the project only concerned a specific department it was likely the sponsor could allocate the people and budget required for completion. However, if the project affected multiple departments, or we needed support from other teams it was crucial to get everyone together and make sure they were all in agreement that this was an important project and worthy or the resource investment. Otherwise you ended up trying to run projects where some of the team members were being given other priorities and were unable to commit to the plan.
How high is this project in your overall priorities list?
I never assumed that my projects were the highest priority for a sponsor. Sometimes they were, and sometimes they weren’t. Knowing how important any particular project was in the grand scheme of things helped me know when I needed to push things as urgent and when I had to step back and let others take priority.
Is there anything else you think I should know about this project?
Similar to the earlier question about constraints, this is an open-ended question designed to get the sponsor to think about anything they might know that would be useful to share. Sometimes there isn’t anything, but often they will share something which later comes in handy.
Project Plan - What work needs to be done, who will do it and when?
Whereas clarifying the goal of the project tends to work better as an informal meeting between the project manager and the sponsor, creating the project plan should definitely be a team effort.
The first thing to do is to get the right people involved. These might be different than the team members who end up executing the plan, although often they are the same individuals. You’re looking for the people with the process expertise that can help you identify what tasks need to happen.
Once you have the right people in the room, you can create an outline of all the tasks to be performed in the project. I recommend starting this at a high level to avoid becoming bogged down in details. You can always go deeper later and amend the plan.
After this is complete, there should be a reality check that the tasks you have outlined will deliver the desired outcome. If not, go back and make the necessary changes.
Create a Work Breakdown Structure (WBS)
You can now create a work breakdown structure and add as much detail to the plan as required. This is best done using a project management tool like Microsoft Project or Primavera.
The work breakdown structure should include:
- task name and description
- task dependencies (this task can’t start until task XYZ has been completed)
- task duration - how long it will take to complete the task
- task owner - the person responsible for completing and reporting back on progress for that task
Another item that I used to include in my project plans was any planned holidays, whether they were national bank holidays or simply team member vacations. There is no point using a tool to plan when tasks will be carried out if the person responsible for completing the work is going to be out of the office during that time. This doesn’t have to be complicated. In fact the more simple you make it, the better. Just remember to plan for people taking holidays, especially during the summer!
Add contingency to the plan
It’s also important to include contingency in the plan, because as we all know, things seldom go according to plan!
In the end, I used to add both visible and invisible contingency to the plan. The invisible contingency was included by adding 10-15% onto the duration for each task. The visible contingency was a single task at the end of the plan which equated to 15% of the overall plan duration.
When I presented the plan to the stakeholders at the end of the Define Phase I would tell them the projected completion date based on the overall plan, including the 15% visible contingency. I would then explain that I had included the contingency to cover unforeseen events such as team member illness or delays from suppliers etc. Often this was the subject of much debate. Some stakeholders were okay with it and respected the fact I was being realistic. Others asked me to take it out of the plan and work to the earlier date. When that happened, I always made it very clear that the slightest delay on any task would put the project deadline in jeopardy. In reality, I still had the invisible contingency in the plan, but they did not know that.
I realise this might sound sneaky but the truth is it’s an important part of managing your stakeholder’s expectations. I would much rather deliver a project early because we were over-cautious in the planning than fail to deliver on time. To that end, I would always try to maintain the contingency as a buffer instead of relying on it. As Parkinson’s law states, a task will expand to fill the time allotted to it. So whenever I was discussing the plan with team members we worked to the earliest deadline.
Risk Assessment - What can go wrong and how do we manage that?
Performing a project risk assessment doesn’t have to be complicated. I’m a big fan of keeping things simple.
The important thing for me is to remember that this isn’t a document you create for the sake of it. Believe me, there were plenty of those that we were supposed to create based on our training. After running a few projects I quickly learned which ones could be ignored and which ones were important. The risk assessment falls into that latter category.
A risk assessment is simply an exploration of what could possibly go wrong during the project, how you would detect that it was happening and the steps you would take to manage the situation. It’s a living, breathing document that changes throughout the course of the project in the same way the project plan does.
I always started my risk assessments by listing the top 10 reasons that projects fail:
- The goal is not properly defined.
- Changes to the goal are not properly controlled.
- Project not planned properly.
- Project not led properly.
- Project not resourced as well as planned.
- No contingency built into the project plan.
- Expectations of stakeholders not managed.
- Progress against plan not monitored and controlled.
- Project reporting inadequate or non-existent.
- Belief that when the project runs into trouble it can be solved by working harder or throwing money at it.
As you will no doubt have noticed, much of what we’ve already covered (and will cover later) in this post is about managing these very risks. The Define Phase of a DMAIC project is as much about setting the project up for success as it is about defining the problem. That’s just good project management.
Further to the above 10 risks, you’ll want to consider the potential risks across various categories including:
- Health & Safety
- Political
- Economic
- Social
- Technological
- Legal
- Environmental
Once you have identified what the possible risks are, it’s easy to feel like the risk assessment is complete. However, identification is only the first step. Next you need to assess them based on both severity and likelihood. In other words, how serious would it be if this risk actually happened, and how likely is that it will happen. We used to assign a severity score from 1-10 with 1 being low risk and 10 being the most serious. We also assigned a likelihood score from 1-10 with 1 being least likely to happen and 10 meaning it’s guaranteed to happen. To calculate the risk score we simply multiply the severity score and the likelihood score together. That means the risk score can range anywhere from 1 (highly unlikely to happen and not serious if it does) up to 100 (it will happen and will be extremely serious when it does). We then sort the risks into descending order of risk score and focus on the highest numbers first.
Once you have identified and assessed the risks, the next step is to manage them. Obviously how you do that will depend on what the risks are. The corrective actions you put in place should reduce the severity or the likelihood of occurence, or both. Suffice to say, that prevention is generally better than cure. So if there is something that can be done to prevent a risk from occurring, takes steps to make that happen as far as is reasonably practical. Otherwise, make sure you have early warning indicators in place so that you can detect when a risk starts to occur.
Stakeholder Analysis - Who needs to be kept in the loop?
The final document we need to put together to complete the DMAIC Define Phase of our Six Sigma project is the stakeholder analysis. In it’s most basic form, this is a communication plan which outlines how the important people will be kept up to date with the project.
