So far…
In the journey of understanding the modus operandi of Six Sigma in business, we are discussing an imaginary company, the Homeparty Pizzas, run by my imaginary friend Ben.
We discussed the problems of business – top line & bottom line problems, prioritisation of problem areas using Kano Model, application of #Pareto charts for problem analysis and scoping of projects using Project Charter. We discussed the components of project charter viz., objectives, business case and problem statement.
Now..
We will discuss the goal statement in this article and other tools of Define phase in the forthcoming articles.
Goal Statement
Since the team is thrilled to see their actual problems were being verbalised and the energy was running high, I continued my session. As a trainer, I know the training sessions also undergo seasonal changes – within a day. Whenever there are high energy and absorption, we have to cover most of the ground.
“Once we clearly spell out the problem and the current business suffering, then we need to state the goal of the project. What does the team aim to achieve by doing this project?”
“It is a common expectation that the goal statement to have the baseline, current condition, expected condition, entitlement or industry benchmark and timelines with milestones.
What is a baseline?
“Baseline is a measure of our current performance with respect to the problem in hand. We have to collect data about our problem to understand our problem and then we construct a problem statement based on that data, right?
The timeline from the start date to end date of the data collection is called review period. It may of the past 1 year, 6 months 3 months or even of a few weeks. But has to be precise – date to date.
So, the baseline is the average performance of our process with respect to the project y during the review period. This metric – the baseline – will not change at any point in time through our project. Clear?”
Current State or Current Condition
“Okey! The next is current condition. It is the most recent performance level of our process with respect to the project y.
For example, if we consider the number of batch rejections in a month as our project y, then the average number of batch rejections per month for past 12 months or 6 months at the time of initiation of the project is our baseline. And the number of batch rejections happened in (the recent) previous month will be out current condition”.
Abhishek raised his hand trying to share his doubt.
“Sir, I understand the baseline is the line on the bottom in the picture you draw. He pointed out the picture of problem definition in his notepad. We calculate that with our past performance, right?
Then… the current… condition.. is.. the recent month or week performance. Ok… but I do not get why do we need that? Or precisely what is the need for it?”
I got his point.
“Good Abhishek, that’s a valid point. Then I threw the question to the rest, “Any answer to this?”
After a pause, Ben came up, “You said the baseline shall not be changed during the course of the project. But the current condition will change. That means, the current condition will be helpful in understanding the impact of changes, that is to track the improvement during monthly reviews.” And waited for my nod.
“Yes. That’s right”.
Goal Setting
“So we can move on to the next part of goal statement – After understanding the problem and its business impacts, the obvious next step will be setting the goal. This stage is so critical to the success of an improvement project and for the organisation as well”.
Let us look into them one by one, after taking a short coffee break”.
When I was enjoying the coffee with the evening breeze just outside the conference hall, Ben shared that he was very much impressed with the way the tools and techniques built into the system of DMAIC and that he was confident of much more clarity would arrive as we progress. He was very much moved with the way his team was participating and thinking, as he said “I did not know that they are so intelligent and they can think differently! I am really surprised to see their participation throughout! I should really thank you!”
“Ben, you shall thank your problems. The problems really test and then testify the organisation that are designed to excel”.
With some more chats and sips, we entered the hall. Everyone has assembled and waiting for the session in silence. We got into the discussion again.
SMART Goals
“The CEO or the Owner of the organisation would have ventured into the Six Sigma only to solve his problems. So, the Six Sigma team has to meet his expectations. On the other side, making too ambitious goals might put the project under risk of failure even after it achieves an optimum result.
So, we need to manage the ‘goals’ for the success of the project and in turn the organisation”.
“In Six Sigma, we say our goals should be SMART; that is
Specific
The goal shall explicitly say what are we going to measure and what is the expected state.
Measurable
The goal preferably shall be numeric; if not shall be measurable using a scale of assigned numerical values. This is to avoid subjectivity.
Will explain this a little more. If we are measuring the temperature of pizza, and we fix our target as 65 deg C, then it self-straightaway becomes a measurable value. But in case our project y is the taste of pizza, which I believe is non-measurable. If we want to set the goal, we are not supposed to set it as tasty pizzas. It becomes subjective.
To satisfy this criterion, we either we assign a score for the taste on a scale of 1 to 10, where 1 is the lowest taste and 10 the highest taste. Or we can assign classifications like acceptable taste and not acceptable taste. Then we can measure the percentage of pizzas of acceptable taste. We need to set up systems to get the scores from either the customers or with an internal checking.
Achievable
Remember, we cannot solve all the problems at once. And we need to bite how much we can chew. The Six Sigma project teams can take up a significant portion of a problem (business or customer problem), that has to have a right scope or boundary of cause identification and improvement – which a team of 3 or 4 can achieve within 4 to 6 months.
Larger or unclear boundary, meaning the uncertainty of where the team will search for the causes of a problem is a major reason for project failure. The key is to keep in mind the available resources (say 3 to 5 people) and available time 4 to 6 months for completion of project.
Relevant
Next is the goal shall be Relevant. That is, if we work on the chosen project y, then our Project Y shall get improved. Second point is that chosen project y shall be workable and within the authority limits of the project team. For example, in order to reduce defects in the baking process, we should not take a project to improve the reliability of baking ovens.
Time-bound
Obviously, the last but not least – the timelines. Just I said about duration of project. If you plan to complete the project in 4 months, then, when you will be able to complete the 5 stages namely D-M-A-I and C? This is the question to be answered here in the goal statement.
Next
We will see how to build a project charter for the selected projects. We will move on to discuss the other Define phase tools like SIPOC, Process Flow Chart, Communication Plan, Stakeholder Support Analysis in the forthcoming articles.