Building, Changing, and Maintaining as a Causal Factor
Building, changing, and maintaining systems commonly creates risks. The root problem is the failure to recognize and manage those risks.
THE IDEA
Summary
- Building, changing and maintaining is a very commonplace causal factor for problems. However, note it's not the building, maintenance or change itself that is the root cause; it's the ability to see and manage these risks.
- Reliability‐Centred Maintenance offers a ‘gold standard’ framework against which to judge maintenance in your organisation, but you can also apply the principles to areas such as ‘skills fade’.
- Recognise that there is no such thing as the right project management framework. Prince II has its strengths and weaknesses, and Agile has its strengths and weaknesses.
- Recognise the dilemma when pushing project tasks into the future. It may be necessary to postpone certain tasks in the short run, but they may ‘pile up’ to create a bigger and more extensive list of issues towards the end of the project. Consequently, contingencies need to be made over the whole length of a project, not just at the beginning.
- Don't assume the most significant risks and issues in a project are down at the operational level; they may be hiding in plain sight at the most senior levels of the project or steering group.
- Be aware of the group dynamics when consulting users on a new project plan or in a project management team, steering group or committee.
- Pay attention to the cumulative number of change programmes and projects in the organisation and across different areas.
- If initiatives are scaled back or stopped, promote the positive aspects of making ‘hard choices’ and remember the insight, ‘In our modern world, it takes courage to slow down, to stop or even to turn around’.25
When to use it
Implementing a new software system across multiple departments, requiring careful change management and risk assessment.
Planning a construction project where delays in one phase may cascade and require contingencies for later phases.
Managing a portfolio of change programs to avoid overwhelming the organization with cumulative risk.
Making the decision to stop or scale back a failing initiative, and communicating that decision positively.
FROM THEORY TO EVERYDAY LIFE
In practice
Software Development Feature Creep
A software team continuously adds new features without proper change management, leading to technical debt, increased bug rates, and schedule overruns. The root cause is not the change itself but the failure to assess and mitigate the risks of accumulating changes.
Manufacturing Maintenance Deferral
A factory defers routine maintenance to meet short-term production targets, eventually causing a major breakdown that halts operations for weeks. The inability to manage the risk of deferred maintenance was the actual cause of the failure.
A MOMENT TO REFLECT
Put it to work.
Think of a recent project where tasks were postponed. What were the eventual consequences? Could better risk management have prevented them?
How does your organization manage the risks of change and maintenance? Are there blind spots, especially at senior levels?
Consider a time when a change was implemented without proper risk assessment. What went wrong and how could a structured framework have helped?
CONTINUE THE CONVERSATION
Source texts
- Beyond the Five Whys Root Cause Analysis and Systems Thinking (James C. Paterson)