By Robert Buttrick
Disputes relating to so-called ‘agile project management’ and ‘traditional project management’ are now joined by discussions on ‘hybrid project management’, presumably on the basis that this is a sort of compromise.
Disputes often arise when there is no common understanding of what those terms they use actually mean. If people are talking about something and have a basic misunderstanding those conversations are fruitless.
This article takes the view that there is no such thing as ‘hybrid project management’, ‘agile project management’ nor of ‘traditional project management’. There is simply ‘project management’.
Delivering successful projects
Fundamentally, what is needed are successful projects, being those that deliver the desired outcomes and realize the expected benefits. Most projects of any worth need a range of different deliverables and outputs to achieve their objectives. For example, in the digital sector, software for a new application, its operating systems and platforms (such as for development, verification and validation, training as well as live operation), buildings and facilities (such as power and ventilation), data transmission, training modules, user facilities and equipment. This could be associated with physical infrastructure, such as for water supply, power supply, rail, air travel and roads. A single project usually has many distinct deliverables and outputs.
Project management is the discipline which sets out the practices needed for achieving a successful project. Three sets of practices are needed:
- planning and control practices, which include topics such as risk management, issues management change control and reporting.
- solution delivery practices, which are focused on the delivery of the outputs, integrating them and putting them into use; practices such as requirements management, design, development, verification, transition and change management.
- management or integrative practices, which draw information from the solution delivery and planning and control practices to gain insight into progress and actions needed to keep the project on track to achieve its objectives.
These three groups of practices are well documented and can be found in BS 6079, ISO 21502 and in GovS 002 and its supporting guide, The Teal Book.
A project cannot be successful if the basic output is inadequate or poorly put into practice, regardless of how well the project is directed and managed. The management, planning and control practices can be generic for all projects, subject to tailoring. While the solution delivery practices can be generic at a high level, at a practical level of ‘doing the work’, they need to suit the specific deliverables and outputs being developed and associated risk. For example, the method for designing and building a steel framed structure is different to that used for developing a software module. In both cases, however, the same project management approaches can be used.
Hybrid, agile, traditional – a fruitless conversation?
The words ‘hybrid project management’ did not appear until people started questioning other peoples’ assertions on ‘agile project management’ and its supposed superiority over ‘traditional project management’. Again, conversions are taking place without a common understanding of what the terms mean and so discussions can easily become muddled and even confrontational! It seems to boil down to:
- agile being about adaptive, iterative, incremental;
- traditional being about linear, predictable;
- hybrid being a mix of agile and traditional.
Agile, however, is also interpreted as:
- techniques, defining how specific tasks are undertaken, many of which are not unique to ‘agile’
- behaviours and mindsets, which emphasize the culture required for success, again, not unique to ‘agile’.
Getting out of this fruitless loop of conversations needs people to take a different perspective and separate ‘project management’ from the delivery or development processes and methods needed for each type of deliverable and output.
Changing the mindset
The project lifecycle is key
Projects can be phased in whatever way is suitable to meet the business or strategic need. Phases are about delivering the outcomes when needed and managing risk; they are not necessarily related to the delivery approaches used. Phases are represented by the project life cycle. You can iterate activities within a phase and build a solution incrementally in progressive phases or within a phase. This has always been the case for people who use the project life cycle properly.
Work is done in work packages
Delivery or development methods for a specific deliverable are used within a work package, by a work package manager and their specialist teams. The development approaches used for a deliverable could, for example, be Scrum for a piece of software or one of the myriad of design and installation standards and codes used in the construction industry. Regulated industries, such as air and rail have defined, mandatory practices for developing and assuring the outputs. Some of the approaches could be described as ‘linear’ and others as ‘iterative’ or whatever; but it doesn’t matter. The appropriate development approach should be used for each deliverable in a work package. A phase can have many work packages and so many different development approaches can be used in a single project. This has always been the case.
The project manager’s challenge
The challenge for the project manager is to:
- plan: define a lifecycle which respects the overall delivery target, dividing the work into work packages, understanding interdependencies and risks
- control: gather meaningful data from every work package manager to gain insight into progress to date, the prevailing issues and risks and the outlook for the future.
This is why project management practices need to be tailored, as the data from the work package managers can differ depending on the deliverable, such as function points in software to cubic metres of concrete in a structure. The project manager has to understand how progress is tracked for each type of deliverable and output and then be able to pull all the progress data together to understand the current status and outlook for the project as a whole.
Understanding this means changing to a mindset which differentiates between ‘project management’ and ‘delivery/development processes and methods’. To do this the manager needs to realise that (see Figure 1):
- a project management approach is not the same as a method for developing a deliverable or output;
- a project lifecycle is not the same as a ‘cycle’ used in iterative development.
Figure 1 Time driven and logic drive work
The terms’ iterative’ and ‘incremental’ are often seen, along with ‘adaptive’ as ways of adjusting a programme or project’s scope to manage complexity and reflect emerging requirements or changes in the environment/context. However, ‘iterative’ and ‘incremental’ when used in relation to a ‘life cycle’ should be differentiated from ‘iterative’ and ‘incremental’ when used in relation to a delivery approach. Within a delivery approach, the output can be developed iteratively and either ‘stored’ for later release or released as soon as it is completed. Regardless of how an output is developed, it can be released for operations or put to use in many ways, as shown in the examples in Figure 2. It is therefore possible to have a project deploying its outputs in one release or a number of increments, where some of those outputs are produced using so-called ‘linear’ development approaches. In this way, all projects can be adapted to the circumstances and emerging needs.
Figure 2 Examples of incremental development and deployment
A word of warning on single deliverable projects
There might be people thinking that considering a project management approach as separate to a delivery approach does not make sense to them. If a person is working on a project which has a single type of deliverable, using a single delivery approach, the project management and delivery approach can be so close as to be seen as one and the same; this is because a project management approach always needs to be tailored to reflect the objectives of the project and the work being undertaken. In such a case, planning and control techniques for the project are often taken directly from the planning and control techniques in the delivery approach. This is what we see in many software development methods, which incorporate project management within them. In isolation that can work, but when combined in a wider project with the development of other required outputs, the approach can fall apart.
Robert Buttrick is an independent advisor on portfolio, programme and project management, specialising in business-driven methods, processes and standards. Recent clients include the UK’s Cabinet Office and Infrastructure and Project Authority. He is a member of the British Standards Institute’s committee MS2 for project management and is a UK Principal Expert on the equivalent ISO technical committee, TC258 (dealing with international standards on portfolio, programme and project management.).
Publications include:
- Lead author, GovS 002 Project Delivery Functional Standard (HM Government); mandatory standard for all government portfolios, programmes and projects
- Contributing author, The Teal Book (HM Government. This replaces PRNCE2, MSP and MoP for government projects.
- Contributing author, PRINCE2, 6th edition, AXELOS
- The Programme and Portfolio Workout 1st edition, Routledge
- The Project Workout, 5th edition, Routledge
For a more comprehensive list see: https://www.projectworkout.com/publications/
For a list of articles, see: https://www.projectworkout.com/articles/
