“When a man does not know what harbour he is making for, no wind is the right wind.”  Seneca (4BC – AD65). If you are tackling improvement projects, then to not have a clear idea of why the project you are tackling is important, the goals you are striving to achieve, and how you are going to achieve them is a bit like setting sail from a port with no idea of where you are going, how you intend navigating, and indeed why you are even setting sail in the first place!

In our work with organisations and individuals, the second problem to overcome (after selecting the wrong project to start with), is to not have clear understanding and agreement amongst all parties on the Why, What, Where, When, Who, How, How much of the project. These 8 words represent 7 key questions that need to be answered when setting up a project. If this is not done at the start, then there will almost inevitably end up being problems later in the project.

A recent Green Belt student we know of spent several months working on a project to improve the capability of the weight of a particular component, without completing a proper project charter, before concluding that the capability of the process was of no significant use to the organisation. Several months’ work was wasted as a result.

In Lean Six Sigma, the Project Charter is the document that contains all this information, and completing one will ensure that the key questions of Why, What, Where, When, Who, How and How much are answered.

The format of the document is not important. The content is. There are software products that will contain all the information about the project, and it is fine to use these, as it is to use one from the organisation if a format already exists.

There is no magic in the format, the magic comes in answering the questions: Why, Who, What, Where, When, How and How much. This may of course take a little time, which can be frustrating when everyone just wants to get going, but it will pay dividends in the long run.

 

WHY

The first of the questions to answer is Why - why are we doing this project? If this question is not asked, and answered effectively at the beginning of the project, you can bet that someone will ask it at a crucial stage when resources are required, or changes needed to an established way of doing things. If there is no clear answer then of course there is a high risk that project progress will be slowed, or at worst, stopped completely.

The Problem Statement is the section of the charter that answers the question “Why”.

In Lean Six joomla_khb4b36dh1 we talk about capturing the pain, what pain is the organisation feeling because of this problem? If we take a medical analogy, what pain are you feeling in your back that makes you feel you need to get something done? If the pain is not much, or is only temporary you may not feel a visit is worth spending time on. In the same way, in an organisation we need to define what the pain is. Bear in mind that we are not looking for answers or solutions at this stage, but purely defining the pain being felt.

We can use some of the same questions to help us actually define the problem statement: 

·       Who: does the problem affect?

·       What: symptoms are we seeing

·       Where: is the problem

·       When: did it first occur

Here is an example of a poor problem statement:

 

“With the recent acquisitions within the Gear and Gearbox Division, the company has inherited a number of New Business Enquiry processes. This is leading to confusion, delays, duplicate quotations and (possibly) lost business”

 

It does not address the problem statement questions adequately

Using the 4 questions we can identify improvements:

• Who: Has the problem? The problems are across all customers.
• Where: Is it being experienced? The enquiry processes are in Sales.  
• When: Did the problems start? Since the acquisition occurred.
• What: Data showing how bad this problem is. It is estimated that 30% of quotes are duplicated, and orders worth £30K per annum have been lost, potentially because of this problem.

The statement could therefore be rewritten as:

 

“With the recent acquisitions within the Gear and Gearbox Division, the company has inherited a number of New Business Enquiry processes within Sales. This is leading to confusion and delay across all customers with approximately 30% of quotations being duplicated and possibly business lost because of the problem to a value of £30K since the acquisition 6 months ago”

 

WHO

The second question to ask is “Who”. Who will need to be involved to overcome this problem? Lean Six joomla_khb4b36dh1 is a Team Activity and the Belt will not be able to solve the Problem on their own, in most cases a team will be needed. The team should be carefully chosen. It should be neither too big nor too small & should ideally include the Belt, the process owner or their representative, technical expert, process operators, and potentially suppliers and customers. Other areas to be considered include finance and IT.

It may also be useful to think of the personalities involved in the team, is there a good fit between them? Frameworks such as Belbin or Myers Briggs may be used to assess the personalities and their fit within the team.

A full time team is preferable, as it helps to build better teamwork and prevents conflicting priorities. It will also deliver results quicker. However, full time teams are potentially more disruptive to the business operations and are therefore not always possible. Many successful teams have operated part time.

If you are going to need people on a full time basis, or even on a significant part time basis it is worth ensuring that the people can be freed up to help on the project team. This is easier said than done of course, but it is worth having the debate at the beginning rather than half way through. The easy way out is to leave it not discussed and wait for problems to arise during the project.

The recommendation is to get project stakeholders, such as the process owner and functional heads who will be providing team members to think through how people will find the time to participate in the project. For example, if it is estimated that each team member needs to spend half a day (let’s say 3 ½ hours) per week how will that time be created? Will 6 other colleagues each provide 30 minutes extra cover with the team member providing the additional 30 minutes themselves, or will some extra resource be brought in to carry out a key task that takes half a day to do? There is no right or wrong solution, provided the issue is not ignored with statements such as “the time will need to be found from somewhere”, or “we will just have to find a way”. The end result of this is often delayed projects and frustration all round once the project gets underway.

WHAT

Once the Who question has been answered, the third question to answer is “What”. What is our project objective, and what will be the deliverables? This activity is always best to do in conjunction with the team, although there may be ideas of what needs to be achieved beforehand. Agreeing it with the team will encourage ownership and buy-in from them.

The project objective should relate to the problem statement, and reflect the improvement sought through the project. A useful framework often used to help set objectives is SMART. SMART helps to clearly define the objective by checking it is:

 

·       Specific: to the problem/situation

·       Measurable: and confirmable

·       Agreed: by all parties involved

·       Realistic: a stretch goal but not too far out of reach

·       Time-bound: specified when it will be achieved by

 

Consider the following scenario:

You work for an agency supplying temporary workers. You take a call from have an irate customer, who says that the last workers provided by the company were “all wrong” and they want the situation rectified. They need this done urgently, with replacement workers and assurances that this will not happen again or they will have to cancel their contract with you, which is worth £1m per year. Having pacified the customer and agreed to provide some replacement workers, you set up a project and agree the objective with your team as follows:

 

“We need to improve our process performance to a level that the customer finds acceptable”

 

Is it SMART or not? How could it be improved?

 

WHERE

The fourth question is “Where”, where are the boundaries of the project. Scoping defines what is inside and what is outside the project brief. For example, does improving sales include considering new products or not? Does the project include sales processes or not?

A useful way of defining the project scope is to use a scoping tool called In Frame/Out Frame. This helps to visualise the scope of the project.

Draw a large square “picture frame” on a flip chart (or use tape on a wall) and by writing potential project items on post-it notes and then sticking them either inside or outside the frame this helps the team identify what falls inside the picture of their project and what falls out. This may be in terms of scope, goals, and roles.

During the project, watch out for “scope creep”, moving the goal posts (moving the target or limits), or the project expanding into something unmanageable or undeliverable in the agreed time scale. Also “effort creep”, the project sucking more and more resource from the organisation, or “feature creep” adding features or requirements that were not present at the start.

 

 

WHEN

The fifth question is “When”. When does the project start and finish. Improvement projects are not the same as projects such as building a new office block. Building a new office block has been done plenty of times before, so mostly we know what activities need to get done and the order in which they need to get done. We can therefore use standard project management approaches such as critical path analysis and work out clear timelines and plans for the whole project.

With Lean Six joomla_khb4b36dh1 projects, once the project is into Analyse, we aren’t sure what is going to happen, and once into Improve and Control we have little idea what we are going to do! If we already know what to do then it’s not a Lean Six joomla_khb4b36dh1 project. So, why bother planning at all? Put simply, management will need some kind of timing plan to sanction the project; it’s generally not acceptable to have an open ended project with no end point defined.

All projects need some kind of plan to help keep on track as much as possible, but the phrase “A carelessly planned project will take three times longer to complete than expected, a carefully planned one only twice as long!” may well apply!

The best we are able to do with a Lean Six joomla_khb4b36dh1 project is to estimate the timing, and plan as much as we can knowing that we can’t define everything up front.

As mentioned previously, techniques like Critical Path Analysis are not that useful as too many items are unknown at the start of the project. A technique which works much better in improvement projects is called Milestone Planning and Activity Scheduling, or MPAS for short. MPAS involves the team brainstorming all activities which may be involved in the project, and then grouping these into milestones.

Defining milestones enable the project to be broken down into smaller more manageable chunks. A milestone is the point at which a significant event within the project has been achieved, for example when all activities within the Define phase have been completed. Milestones can be defined starting the sentence with the word “when”. There are some obvious milestones in DMAIC of course, these being when the activities for each of these phases have been completed. There may be other milestones within each of the phases, joomla_khb4b36dh1 defines several milestones for each of the 5 phases within DMAIC.

Within each milestone there will then be a number of activities that need to be carried out. For example, if a milestone is defined as when all customer requirements have been captured, activities within that milestone could be to identify which customers are to be surveyed, organize the survey, collect the responses and analyze the results.

The team should brainstorm all the activities they think may be involved in the project. The team will probably be much clearer about the earlier phases of the project at this stage, this is to be expected.

 

 

 

 

 

It is a good idea to use post-it notes or similar as this enables activities to be grouped, moved or changed much more easily during subsequent stages. The post-its can be stuck to a wall or ideally a large horizontal planning sheet such as the back of wallpaper.

Each post-it note represents an activity, and they are grouped under the relevant milestone. The key to scheduling using MPAS is that the detailed planning for each Milestone is ONLY done for the activities within that Milestone, and not for the whole project. Subsequent milestones are only planned as they approach. This is a more suitable approach where the activities involved develop only as a project progresses.

HOW

The sixth question is “How”. For most Lean Six joomla_khb4b36dh1 projects the answer to this question is using the DMAIC methodology. Other aspects that need to be considered as part of this question is what frequency should the team meet at, and how will project reporting be done.

HOW MUCH

The seventh and final question is “How Much”. Most lean joomla_khb4b36dh1 projects result in significant benefits for the business. Care is needed, however, to identify and quantify them, and where possible turn them into financial benefits.

• Quality improvements – may lead to reduced material costs or inspections
• Delivery improvements – may lead to reduced cycle time and labour requirements
• Efficiency improvements – may lead to reduced cost per unit
• Revenue increases – may lead to increased margins or reduced COS

Hard verses Soft Benefits:

•       Hard savings:  “flow” to the bottom line

•       Soft savings - all other types of savings not falling into the “Hard savings” category

•       Balance sheet benefits

•       Non tangible benefits

The potential benefits and how they are calculated need to be verified with key stakeholders such as Finance at the start of the project, not at the end. That way, once the project is concluded, there will not be arguments about whether the benefits that are being claimed are real or not.

Projects should have a clearly defined measurement for each of the key areas contained within the objective, for example, on time delivery if the project involves improving customer service.

As mentioned at the beginning of the article, it is not the filling in of a particular format of project charter that is the magic, the magic comes from thinking about and answering the questions of Why, What, Where, When, Who, How and How much. Do this, and your projects will have a far greater chance of success.

 

Did you miss the last blog instalment? You can view it here: What is Lean Six joomla_khb4b36dh1?