Project Management: Finding out Why

14 July, 2014

Anyone who listens to the news will be familiar with government ministers ordering enquiries into events in their departments “so that this will not happen again”. There is never a goal of finding out who caused the problem and holding them accountable. The result of this sort of analysis is weighty standard operating procedures, because more and more checks and balances are added to ensure the problem will not happen. However, the most likely problem is that the original checks and balances were ignored.

In any environment, when things go wrong, we need to determine the root cause. Even when there is a culture of not blaming anybody for mistakes, we still need to find out why. Project Managers will be familiar with this concept from the Closing process group of the Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Managers are advised to hold Project Post-Mortems to learn lessons from the work already done. If some of your team members had a difficult project, the Project Manager needs to create a secure environment where they can recount their experiences candidly and we can learn from their mistakes.

It is often the case that the recommended procedure was ignored. If this is the case, then training will lead to better results than tampering with the procedure. When faced with problems on the project – poor estimates, scope creep, ineffective communication, etc. – the Project Manager needs to get to the root of the problems. Once the cause has been identified, what happens next depends on the organizational culture and the leadership style of the Project Manager.

The principal difference between the amateur and the Project Management Professional (PMP)® is the understanding of integration. The different knowledge areas are not distinct fiefdoms in the PMP’s® eyes – techniques that have proved useful in one area may provide insights into others. In this instance, the Project Quality Management area provides a very useful technique that can be used as the basis for risk identification and finding the causes of problems on the project.

The Ishakawa, or Fishbone Diagram, has been used since the 1960’s to find causes of variation in manufacturing processes. It has also been applied in product design to help complete the requirements list. In manufacturing, the causes of any variation can be traced to a series of causes beginning with the letter “M”, i.e.:

  • Manufacturing. This relates to the technology being used. Often machines drift from their original calibrations, or have tolerances that introduce unacceptable levels of variation.
  • Method. The manufacturing process – how work is ordered in its passage through the factory.
  • Material. Poor quality raw materials can render the best manufacturing processes useless. Another form of material to consider is information – is everyone on the project getting the necessary information at the right time?
  • Man Power. Although now frowned upon by the politically correct, man power refers to physical work. Poor ergonomics can lead to accidents and conditions like repetitive strain injuries. Human error can be eliminated with practices like poka-yoke – idiot proofing. From a project management perspective, this “M” could refer to “Mind Power”, where mistakes are made during cognitive tasks.
  • Measurement. Just as the manufacturing process is fallible, so too is the measurement process. How reliable is this? Are we flagging too many spurious errors or, worse, endorsing flawed products?
  • Mother Nature. This refers to the environment. Light, heat, dust and noise can all take their toll on the workforce and the machinery.

The interesting feature about this list is that none of these factors exist in a vacuum. A lot of dust in the environment can cause problems with Manufacturing and with Man Power, not to mention delicate instruments used in Measurement. So, for instance, we might identify a problem that our automated quality checking machine is rejecting many items that prove perfectly acceptable on manual inspection. Instinctively, we might blame a faulty instrument. But if the instrument is tested and proves to be working properly, we need to go back another level and determine why a working instrument is giving false results.

This type of analysis is called the Five Whys. Keep asking why until the root cause is identified. Using Ishakawa diagrams, every time you find a cause, turn that into the effect and again find the cause, until you arrive at the root cause. In our dust example, we start with:

Effect: Products failing for no reason -> Cause: Instrument giving wrong results

Then we subject the test instrument to the same analysis:

Effect: Instrument giving wrong results

-> Cause: Instrument not calibrated properly

-> Cause: Instrument incorrectly mounted

-> Cause: Dust affecting readings

Now we have a variety of possibilities and each needs to be analysed in turn. We can take action by inspecting the instrument and its mounting and we can try out the instrument in a different environment (without the dust). In the end we should be confident that a particular cause (or combination of causes) led to the undesirable effect.

Project Managers need to be aware of the complex relationships between cause and effect. A phenomenon like scope creep can be due to poor requirements gathering during scope planning, ineffective stakeholder engagement (not managing expectations) and/or poor communications. The important point of this analysis is not to jump to conclusions. There is a very real danger of confusing correlation with causality - just because two things always happen together, does not necessarily mean that one caused the other. Ancient thinkers termed this sort of logical fallacy “post hoc ergo propter hoc” – after this, therefore because of this. Make sure you have the root cause before taking action.

Velopi’s Project Management Professional training courses cover Project Quality Management and Ishakawa Diagrams. If this is an area that is of interest to you then please get in touch – we run these courses in Dublin, Cork, Limerick and Galway for your convenience.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital