5 minute read
WHY PROJECT MANAGEMENT GREW OUT OF THE NEED TO CONTROL RISK
INNOVATIONS AND INSIGHTS WHY PROJECT MANAGEMENT GREW OUT OF THE NEED TO CONTROL RISK HOW MANY ORGANISATIONS HAVE YOU SEEN THAT DO NOT MANAGE RISK WELL, ESPECIALLY PROJECT RISK?
Consider the recent news headlines – Banking, Health, Infrastructure, Transport, Governments, Travel. They’ve all experienced failures in risk management.
Most organisations have a corporate risk management framework, but this tends to be targeted at controlling executive level risks. And where safety is involved, they can be great at handling the operational risks.
Unfortunately, when it comes to projects, people tend to be poor at evaluating risk. Part of this is down to our brains not being good at probabilities and reacting intuitively when presented with risks. Because of this, risk management tends to play a supporting role in projects, which is a concern as risk management is why project management exists.
Along the way, we have lost sight of the Why of project management, and the What and the How have gained prominence.
Long before project management, the management of risk grew and matured out of the desire to invest in new ventures. The success (although some say failing) of the human race comes from the ability to innovate, change and do things differently. This requires investment in people, time, resources and money. But true success comes from understanding and assessing the risks of a new venture – what are the opportunities and threats?
When risk isn’t considered, we put success down to luck, and failure to lack of common sense – and the extreme consequence of this as “Darwinism in action”.
So how did project management get to where it is today, and what does risk have to do with it?
When risk isn’t considered, we put success down to luck, and failure to lack of common sense – and the extreme consequence of this as “Darwinism in action”.
Project Management started to develop as a discipline to manage certain types of risk in the late 1800s, and evolved over the next 100 years, mainly driven by passionate practitioners from the disciplined background of engineering where there was a focus on increasing precision and measurement – Gantt charts, PERT, EVM, WBS, Monte Carlo Simulations, etc.
From these, the project management standards of today came to the fore and risk was put into a supporting role. Consider PMI®’s PMBoK® with a focus on the Triple Constraints of Time, Cost, and Scope. Risk is lucky to be listed at number eight in the PMBoK top 10, just above procurement.
PRINCE2® “PRojects IN Controlled Environments, 2nd edition”, another heavyweight, was released in 1996 and built on the earlier PRINCE method, which was announced and developed in 1989 by CCTA (the Central Computer and Telecommunications Agency), a UK government support agency.
The purpose of the PRINCE2 approach was to design a framework for managing projects in well-controlled environments, but people tend to focus on the word “Projects”, rather than “Controlled Environments” where risk is a key factor.
Risk does have roles in PRINCE2® as a Theme and an Aspect but it is not one of the seven Principles. But read these again and you will see they are all controls for risk. 1. Continued Business Justification 2.Learn From Experience 3.Defined Roles and Responsibilities 4.Manage by Stages 5.Manage by Exception 6.Focus on Products 7. Tailor to Suit Project Environment Critics of approaches such as PMBoK and PRINCE2 also point out the Project is positioned as the be-all and end-all – a bit like the Big Bang at the start of the Universe, total chaos before and total chaos after – given the performance of many projects, they could argue there is only a marginal improvement between.
The custodians of project management standards recognised these limitations and reacted by extending products to consider Programs and Portfolios, but Projects are still at the core.
In a paper called “Existentialism, Evolution, and the matter of project management enquiry” at the 2011 AIPM Conference in Brisbane, Jon Whitty observed that these embedded standards can objectify “the Project” and constrain the industry, preventing evolution and change. Over the past 20 years or so, these constraints have led to increasing dissatisfaction in how projects are managed. At the core is inappropriate controls being applied to manage investment risk.
Take software development as an example, the traditional waterfall approach does not provide controls for the high level of uncertainty in the design. Or the perceived excessive administrative overhead when project management is applied to incremental change in operations.
This has seen the emergence and evolution of competing ways to manage delivery of investments – Agile, Scrum, SAFe, Lean, etc. The tension between these has drawn battle-lines between the different camps. This undermines the profession and returning the focus to risk is a way to reunite practitioners. We need to get back to why we even consider doing projects.
At the end of the day, project management can be summarised into continually asking “Where’s the risk?” to make sure the right controls for risk are in place to: • Understand why an investment is needed • Clearly define the expected outcome from the investment (this will enable the benefits to be defined) • Assess what could impact/enhance the outcome (risks) • Work out the most effective way to deliver the change (traditional, agile, lean, hybrid, etc) taking into account the risks • Regularly check controls for risk and make sure other factors have not changed, which could change the risks and outcomes
Author: Gary Yorke’s day job is Associate Director with MetaPM providing advice and assurance on strategy implementation and capability development. He is also an active volunteer member of the AIPM. When he can find time, he pursues his interest in genetic genealogy.
