The project management skills needed for PM5.0

Introduction

In a series of articles I examined why the UK has struggled to successfully deliver major projects. By presenting the results of a portfolio of research programmes undertaken by MIGSO-PCUBED and our industry and academic partners I have shown that modern projects suffer from four issues that increase the risk of project failure:

• the quality of business-to-business relationships across the project’s organisations,
• the speed of decision making to address major risks and opportunities,
• the adoption of modular design solutions to enable agile delivery, and finally,
• the extent of digital integration leading to improved productivity

In each article I have defined actions that can be taken to eliminate the root causes of these failures. In a summary article I defined a new paradigm for project management which addressed the four failures. In this paper I explore what this means for the project leadership team. A new paradigm suggests the leaders of these projects will need a different skillset and I outline what these skills are and how they differ from the traditional project management skills.

PM5.0

In the previous article I also looked at the history of project management and how it evolved in stages in line with the four industrial revolutions that we now recognise (Industry 1.0 to Industry 4.0). That is up until Industry 3.0 when project management got stuck, partly due to the codification of the profession. This leaves us with a gap between the “system of interest” created by the project, which will be an Industry 4.0 system and the project enabling system (i.e., the project management approach) that manages that creation process, which I assert can be classed as no better than somewhere between the second and third industrial revolutions, i.e. PM2.5. In order to successfully deliver modern projects, especially as we move from Industry 4.0 to Industry 5.0 (human-machine collaboration with a focus on the well being of the humans in the system) we need to make a quantum leap from PM2.5 to PM5.0. So, what are the skills required to do this?

Traditional Project Management Skills

The project enabling system for fast, collaborative, highly agile, digitally enabled projects will still have elements of traditional project management techniques, adapted for the PM5.0 environment. Planning, risk management, communications, contract management, stakeholder management and so on are still core skills of the PM5.0 project manager. In fact I would argue that these have been the core skills through the ages: from the pyramids to the moon landing. But I contend that we have overdeveloped these core skills and turned them into professions in their own right. We have professional planners and risk managers, but the plans are still unreliable and unforeseen risks keep hitting our projects. We don’t need 10,000 line schedules that are out of date as soon as resource is allocated to the first activity and we don’t need weighty risk registers that move at glacial pace resitting the fast decisions needed to prevent the risks from impacting.

We need to strip these traditional techniques back to a “minimum viable product” that informs in an engaging way and is accessible to all project team members. The project manager needs to have a feel for what control needs to be retained by the PM5.0 project information management office and what can be handed over to the agile delivery teams to plan, manage and govern in their self-managed units.

This planning cut off point is key to enabling innovation, ownership and motivation. Every project will be different in this respect. The work breakdown structure (WBS) is the tool manage this. Some projects will need to retain high levels of central governance and the WBS may need to be developed to a lower level than for other projects that are less regulated. The key is that the central plans should not be developed to a lower level than the lowest level of the WBS. The work package handed over to the delivery team should be developed using agile methods by the delivery team and reported to the project information management office at the work package level only. ?So the first PM5.0 competency is:

Competence Number 1: The project manager should be competent in classical project planning methods and additionally understand how to cut off the central planning process at the optimal point to enable innovation in the agile delivery teams.

?Systems Engineering and Systems Thinking

A modern major project is almost always complicated and complex. The enabling system that the project manager develops to deliver it needs to be bespoke and able to cope with the complexity of the environment in which it takes place. This is important. Each project enabling system needs to be designed for the project to which it applies. It can’t be taken from a book or imported from a previous project. This process of design is systems engineering and is used to rationalise the complexity into a set of defined system requirements.

The enabling system designed by the PM5.0 project manager interlocks the engineering and project management processes into a homogeneous enabling system. The WBS and Product Breakdown Structure (PBS) are optimised to ensure the WBS is focused on the delivery of the PBS. The tools required to do this, using model based systems engineering methods, are built into an integrated working environment where data is input once and shared by all users.

Competence Number 2: The project manager should be competent in systems engineering and able to develop a bespoke enabling system for their project combining linked processes and integrated tools optimised for delivering the system of interest (the project objective).

?Business to Business (B2B) relationships

The relationships between the various organisations involved in delivering the project are key. The project cannot succeed if one of the critical B2B relationships fails. Most project managers have never studied behavioural economics or psychology and don’t have an insight into what makes groups of human beings interact in a positive way. Most think they can do this instinctively, but they’re wrong. There are 7 dimensions of B2B relationships and most project managers are not aware of five of them. This why project managers will agree that relationships are critical to project success and yet never include it as a risk on their risk register. This is also why there is a sad litany of project failures that can be attributed to B2B relationship breakdown.

The project manager needs to select partners based on competence and behaviours rather than cost and then analyse each dynamic relationship and set actions to ensure they build in a positive way and survive (grow) after each inevitable problem. And so the next competence is:

Competence Number 3: The project manager should be competent in business to business relationships and able to select the right partners for the project, develop relational contracts, deal with problems collaboratively and measure the performance of all critical relationships taking action before they start to threaten delivery.

?Digital Tools

As Bill Gates said: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." Digitalisation is never the answer to an inefficient process. Focussed process improvement action is the answer to an inefficient process and that must be planned and executed before any automation takes place.

The chosen digital tools used to enable major projects must therefore be able to integrate with each other to enable efficient processes to be automated and allow the people to focus on continuous improvement and innovation.

Many of the latest digital tools available to the project manager are very difficult to integrate with other digital tools. This is partly because the developer is trying to protect their intellectual property by hiding the inner workings of their tools and partly because there is no “Microsoft” of the project management world, providing an integrated solution. Many different suppliers provide partial project management solutions. There are CAD tools, PLM tools, BIM tools, planning tools, risk management tools, cost management tools, etc. but none of them connect seamlessly to the others, resulting in multiplicity of data and silos of information, inaccessible to the users who need to make decisions based on that information.

In many ways it is better to choose legacy tools, because they tend to be more configurable, more connectable and have more third-party support. The demands of integration and collaboration require the project leaders to be aware of and comfortable with, all the digital systems used on the project, not just the ones used by the project controls team. They need to be confident that they have been chosen for their ability to integrate not on their performance on isolated functions (organisational silos) of the project.

Competence Number 3: The project manager needs to be competent in the design of integrated digital systems and able to produce a coherent project digital strategy which satisfies the needs of the engineers, asset managers and project managers in a single, integrated, shared and accessible common working environment.

?Lean Governance

Projects make slow decisions due to their overly-complex governance arrangements, which take longer to agree a major change than the window of opportunity available to make it. For some reason, project managers include decision making durations in their schedules that are unlikely to ever be achievable in practice. Clearly all project stakeholders should work together to attempt to simplify the governance process, but crucially the project manager should assess this process and confidently predict how long it will take for different decision types. This duration should, then be included in the schedule and the project end date recalculated appropriately.

If this is later than the date required by the client, the project manager should use lean techniques to remove waste from the governance process and increase its efficiency. This can then be offered to the stakeholders to resolve the conflict between the governance requirements and the desired end date. The project manager must insist on this. Either the end-date needs to accommodate an inefficient governance process or the governance process needs to change (or both). The project manager must not include unachievable decision making durations in their schedules.

The project manager also apply lean techniques to ensure the cut off between central control and the self-managed agile delivery teams is optimised and a minimal number of decisions are passed between the delivery teams and the central control unit (the project information management office).

Competence Number 4: The project manager needs to be competent in lean techniques and able to remove waste and inefficiency from their decision making processes.

?Agile Delivery Teams

It is not possible to define all the requirements for a major project upfront, nor to freeze the design before build commences. The systems being delivered by major projects are by definition complex and requirements will inevitably be discovered as the project progresses. All major projects set out to fix the scope, time and cost and inevitably end up compromising on all three, often delivering a system which is difficult to operate to the asset manager, later than the operator needed and at a cost which is unaffordable to the client.

This iron triangle of time, cost and scope needs to be broken or at least turned upside down. Cost and time are the most important factors for a project. Late and over cost projects end up being cancelled or have scope forcibly removed (HS2 for example). It is possible to reduce scope by delivering in modules and not compromise on performance if carefully managed by the project team rather than uninformed outsiders. They key is to know what the “minimum viable product” is for the project and secure that for less than the available time and cost and then incrementally build in additional features until either time or scope runs out and the product needs to go live. This is an agile approach and requires the design to be modularised and delivered by a modular organisation of agile delivery teams.

However, the governance requirements need the high level project to look conventional (or waterfall) so that it can be managed by a gated process, with reviews and staged financial release. Therefore the project needs to be delivered in a “hybrid” way, with a combination of waterfall and agile elements. This leads to the fifth competency:

Competency Number 5: The project manager needs to be competent in Agile project management and able to develop a modular design delivered by a modular organisation of agile delivery teams. They need to be able to define the optimum cut off point between the agile and waterfall elements to ensure efficient governance and design innovation.

?Leadership

The project manager is not the leader of the project. Neither is the chief engineer. The greatest projects were delivered by a “duopoly” of two people working in harmony; one focussed on the management of stakeholders and one focussed on the product. Boulton and Watt developed the steam engine, and they couldn’t have done it without the other. Rolls or Royce would never have got a vehicle to market. Jobs and Wozniak/Ives plus Gates and Allen kick started the fourth industrial revolution. Paxton designed the Crystal Palace, but Fox built it. Great engineers who also managed their projects didn’t have a great track record. We think of Brunel as the archetypal project manager/engineer, but did you know many (most) of his projects ran late and over budget, even resulting in the bankruptcy of some of his clients. In fact its hard to find successful project manager/engineers. In the early stages of the industrial revolution Brindley and Telford could make that claim and in Brunel’s time Robert Stephenson had a reasonable project management record. However, there’s no definitive evidence that the project manager should lead the project and I would argue there’s more compelling evidence for the duopoly.

So forget the “project manager is king” leadership model. The recently published International Centre for Complex Project Management (ICCPM) leadership standard[1] is the best I have seen to-date. This captures many of the skills I have already mentioned above and requires the project manager to “exercise contextual leadership awareness” demonstrating emotional intelligence, the ability to operate in different modes (situational leadership), leading with sensitivity and develop high performing relationships. Add to this the need to build a partnership relationship with the chief engineer allowing either to take the lead based on the project context and I think we have the right model for the PM5.0 leader.

?Guidance for Project Leaders

The purpose of our research and the objective of these articles is to provide advice and guidance to project leaders but this one is tough. The reality is that you’re probably the wrong person to deliver your project. Let me explain. Project management was made redundant in 1969 when the US DOD issued their guidance on systems engineering, but project management refused to step aside, codified itself and became profession.

Let’s delve deeper. Project enabling systems evolve in line with industrial revolutions. Technology drives evolution in all fields. Even fields you wouldn’t associate with technology. Take art. The high renaissance was driven by the invention of oil paints. The impressionists were given wings by portable easels, oil paints in tubes and trains. It’s the same in the delivery of engineering systems. Before the first industrial revolution projects were delivered by lordly command. Pyramids, great walls and palaces were built using indentured or slave labour without consideration of cost control or scheduling. During the first industrial revolution in the 17th and 18th centuries, civil engineering was invented. This was the first project Management approach (or PM1.0). The institution of Civil Engineers was founded in 1818 and projects were delivered using civil engineering principles. Industry 2.0 arrived in the early 20th century and Fayol, Taylor and Gannt invented the principles of project control. When Industry 3.0 arrived in the 1960s systems engineering was invented (and sent men to the moon), but civil engineering systems continued to be built using PM2.0. Eventually civil engineers codified project management, invented the iron triangle and formed the Association for Project Management (note the title: not the Association of Project Managers) in 1972.

I joined Rolls-Royce Submarines in 1985 and there were no project managers, but there was a history of extremely successful project delivery. There were Associate Project Engineers (APE) that used systems engineering principles. APEs were very senior, technical experts and board direct reports normally. The idea of a manager role offered by the title Project Manager was enticing and they explored the idea of project management and started to adopt the title. Then in accordance with the principles of project management they started to drop their technical responsibilities and appointed chief engineers to work for them. Then projects started to fail. In 2002 I was asked to transform our project delivery approach and this history was interesting to me. It was clear that the systems engineering approach worked well for nuclear reactors and the APM Body of Knowledge (first developed to manage highways projects) did not.

I have now seen that this evolution from project engineers to project managers has occurred in many organisations and PM3.0 never found a foothold (in the UK anyway). We now find ourselves in Industry 4.0 and PM2.0 refuses to budge. Projects continue to fail and as system complexity increases (e.g., Crossrail) the less likely it is that PM2.0 approaches can cope.

Other sectors have embraced Industry 4.0 and their enabling systems are compatible with the modern technology they are trying to deliver. Agile, lean and systems based solutions are used in media, telecoms, IT, financial services and other high technology sectors enabling them to deliver rapid transformation of their systems.

The next wave of major projects will be delivered in Industry 5.0; a human-machine system focussed on the wellbeing of the individual. It’s imperative we don’t attempt to use PM2.0 to deliver these projects. We need PM5.0. Some elements of PM2.0 will be retained, but extensive new techniques using lean, agile, systems thinking and neuroscience will be incorporated. I would call this approach System Delivery.

So project management needs to be replaced by system delivery but our current major projects are led by experts in PM2.0. That’s why the first step for leaders of major projects is to recognise they are the wrong leaders. And then what? The truth is there aren’t any PM5.0 leaders around and precious few PM4.0 leaders with a major project background. So current project leaders need to build a team around them that can develop a PM4.0 (PM5.0 if you’re brave enough) enabling system bespoke for their project. To do this they should embrace the ICCPM leadership competency framework for themselves and explore the principles of the neuroscience of leadership. They should develop an interest in B2B relationships, agile, lean systems engineering/thinking and digital system and allow their team to upskill them as necessary.

Many people I have spoken to tell me that they get all this and are already doing it. I believe in measurement and if you’re doing something, I’ll see it in the metrics. So the first step for major projects leaders is to look at the metrics of your enabling system. Ask your planner how many lines are on the schedule. Have a look at the risk register and see what you’re doing to mitigate the risk of relationship breakdown. Look at your WBS and identify the PBS inside it. Look at your employee retention rate for the project. Look at your forecast cost at completion history. Look at your forecast commercial operation date history. I think you may be surprised.

And finally an example. Network Rail. I would point to some examples of best practice in Network Rail. The Staffordshire Alliance focussed on B2B relationships (probably the most powerful of the PM5.0 techniques) and delivered remarkable project success, exceeding all metrics. However, Network Rail generally uses PM2.0. In fact they use it very well. They have the highest P3M3 score in the UK: 4.6 P3M3 is measure of how well project management is used in an organisation. Yet in 2022 it missed 73% of its project milestones.

We’re about to embark on a quarter of a century of asset renewal in the UK worth hundreds of billions of pounds. It's time for a change.

[1] https://iccpm.com/resource-centre/complex-project-leadership-competency-standards-2023/