TP ThinkingProcess

ThinkingProcess D5 Methodology

There are many improvement methodologies that have been and are used across the world to improve processes and business performance.

Below are listed some of the more common ones. Here at ThinkingProcess we have a generic methodology that we use to develop everything from proposals through to delivery of improvement projects. It has been developed from experience of using DMAIC and PDCA (see below), and provides a basic but rigorous approach that ensures projects start with a clear objective and end with demonstrating that the objective has been achieved.

The table below shows the 5 phases in the D5 methodology and how they relate to DMAIC and PDCA. At this stage I have left in grey an Exploit phase which is equivalent to the Transfer phase of the DMAICT cycle.

D5 Phase Description DMAIC PDCA
Define Clearly define the objective of the project or programme and agree with the sponsor and major stakeholders Define
Discover Discover the background to the problem or opportunity. Gather data and information and analyse and present to show the root causes for the current position  Measure, Analyse
Design Design and test the solution. This may include assessing several options, and piloting agreed proposals  Improve  Do
Deliver Deliver the outputs or changes into the business, embedding them into business operations  Improve, Control
Demonstrate Demonstrate the benefits and objectives have been delivered and close the project  Control  

So why D5? Many improvement methodologies such as six sigma can sound very technical and can be a turn-off for many people. It is also very easy to get caught in the Measure-Analyse phase, getting data from the process or function for the first time, struggling with its quality, and then not being able to see patterns because of the noise. Whilst detailed measurement and analysis is indeed required when performance is high, at low or starting levels of maturity, there is often not detailed data available and the improvements are reasonably easy to find. At this stage the business needs quick wins to further sell the programme, and start to get returns on the early investments made. Bringing measure and analyse together under "Discover" helps projects not get stuck at the data stage if a light touch is required.

Finally PDCA is back in fashion within the Lean community. Deming's approach to testing your changes before implementing them is certainly very sound, but the PDCA does not stress enough the importance of explaining the root cause before devising and piloting solutions. So many projects do not properly establish the cause of the problem, and therefore cannot really justify the solution they want to implement. This is why the Plan stage needs opening out to cover the expression of the business problem followed by clearly explaining the cause(s).