Project managers are among organisations’ biggest assets, because they provide flexibility and leadership – and they are increasingly being used to align specialist skills within software environments and general business abilities.
Indeed, Colin Bentley’s Adaptable Project Management – A combination of Agile and Project Management for All (PM4A) demonstrates that Agile needn’t only apply to software development.
In this blog, we take a look at an extract from Bentley’s book.
Who is this book aimed at?
Project managers and stakeholders trying to develop a project management approach suitable for their organisation. Many staff are expected to take on project manage mentor ‘client/product owner’ roles without any briefing or other support. This book will help to address this gap. It will also benefit any readers doing a project assurance review for the first time.
I don’t want to confuse readers. I understand that ‘Evo – Evolutionary Project Management’ is a term used by Tom Gilb and his partners. I was introduced to Tom Gilb’s ideas back in the 1960s and greatly admired his thinking, but this is not a book based on his ‘Evo’. It is a combination of the old ‘waterfall’ methods of project management, such as PRINCE2® and PM4A, and the Agile method of software development.
‘Waterfall’ project development
‘Waterfall’ is a name given to ‘traditional’ projects that follow the format of specify, design, develop, deliver. It is assumed that all the requirements can be defined at the outset and that nothing (or almost nothing) will be delivered to the client until the project finishes.
Project Management for All (PM4A) is a method I created with Andy Britton in the early 2000s. It is a simple but comprehensive method of project management based on the waterfall method. PM4A is aimed at smaller projects and is very strong in the areas of starting up a project and providing an in-depth view of how to handle quality, risk, version and change control.
Agile project management
Agile project management is an iterative approach to delivering useful parts of the product of a project throughout its life cycle.
Iterative or Agile life cycles are composed of several iterations or incremental steps towards the completion of a project. Iterative approaches are frequently used in software development projects to promote early delivery of key components and adaptability. The benefit of iteration is that you can adjust as you go along rather than having to follow a linear path. One of the aims of an Agile or iterative approach is to release benefits throughout the process rather than only at the end. Popular methods for Agile software development include Scrum, Lean, Dynamic System Development Method (DSDM) and Extreme Programming (XP).
Although Agile started out as a method purely for software development, it is now often used for non-software projects.
The ‘Agile Manifesto’ came out of a meeting of software developers in 2001 in Snowbird, Utah. It was based on work that had been going on since around 1994 around a growing need for a robust approach to software development that could deliver benefits as early as possible. I can remember working with Tom Gilb back in the 1960s when he was already working on ‘evolutionary development’, very much ahead of his time with this Agile concept.
I believe the first to call themselves ‘Agile’ were early Toyota teams who added frequent customer feedback to their work.
Although this manifesto is enticing for anyone looking to manage the development of a project, Agile has received criticism over the years:
- More suited to continuous development (i.e. there is a never-ending stream of changes, so where does the project stop?).
- Can get out of control (if you break the rules; e.g. Agile allows no time slippage to complete a piece of allocated work. If this rule is broken and work continues beyond its current time limit until the work is finished, the schedule is ruined and other packages that are meant to coincide with it are also affected. Agile is built around stopping work when the time runs out and returning anything unfinished to the work queue to be re-prioritised).
- Requires a ‘no blame’ culture.
- Can be difficult to give an early idea of total cost (how easy is it to estimate how many changes will be requested, compared to senior management wanting a clear idea of project cost at the outset?).
- Work is deferred from an iteration and never gets completed. This can be a common problem for security and control features.
- Requires users to fully engage and be disciplined.
However, for the all the criticism, Agile has some great features which can be adapted to projects in multiple industries:
- Delivers real business benefits, not unnecessary fluff.
- Deeply involves users in the development process.
- Users feel involved and empowered.
- Gives early visibility of working prototypes.
- Receive early user feedback.
- Reduces testing and defects.
- Reduces unnecessary processes and documentation.
- Lessens management overhead.
- Delivers on time!
Complement or clash?
As we have just read, one of the key concepts of Agile is the building of the end product in a series of iterations; build a bit, find out a bit more about what you’ve done and what is required next, add a bit more and so on round the building loop until the product is finished.
So, do we simply have two widely different approaches to projects? Do we choose one or the other? Or is there a middle road, where we can merge the two to make an even more powerful method of managing projects? I hope that’s where this book comes in.
Both see the business need/justification as important, so that’s a good start. Also, both have a strong emphasis on quality, though they have different approaches to it. No doubt these can be built into a very strong handle on quality.
There is some common ground between the Agile concept of build incrementally and develop iteratively and the PM4A ‘Plans’ principle. They address different aspects of planning, but we will see that these can be complementary, not adversarial. The basic approach to planning by focusing on products, rather than activities, supports the quality approach and gives a very solid base to any planning.
The Agile principles of collaboration and continuous communication fit in with traditional progress control, and make it much easier than taking the time to create formal progress reports.
There is also a lot of common ground between Agile’s acceptance of change and the ‘Change control’ principle of PM4A, but we need to be careful here. By continuing to accept changes and new requirements, many Agile projects move without interruption into what traditional project management would call maintenance and enhancement. This works fine where you have, for example, a software system looking after an aspect of hospital work. Work there is never-ending, with new requirements coming along in an endless stream. Where ‘waterfall’ methods would be looking for a finite end point, Agile copes with an open-ended requirement quite easily. We will be looking for a method that can handle a clear end point yet still provide a means to incorporate changes.
Although project roles are not part of the Agile principles, perhaps they should be, because Agile offers a very comprehensive role structure. Our method must produce an organisational structure from the Agile and the very simple PM4A offerings.
Three things stand out. There is no PM4A equivalent of the Agile ‘deliver on time’, and this is something that can be brought into a combination of the two methods. In PM4A, the risk subject is more comprehensively dealt with and product-based planning can be very helpful. Both are important and will add greatly to a combination of the two methods. Some Agile offerings touch on the need for version control, but I believe that the procedures for this need to be much more comprehensive. The PM4A approach to change must be more flexible to accommodate Agile principles, but we must recognise that some suggested changes may be so big that senior management need to be involved in any decision making.
In this book, I am going to adapt the PM4A method to create a method of flexible project management. I shall call this powerhouse, ‘Adaptable Project Management’ (APM).
The way ahead
Following the next chapter on terminology, the remainder of the book will present a method of project management that I believe incorporates the best of both methods. This is where APM starts.
Throughout this book, I will explain:
- This is what Agile says.
- This is what PM4A says.
- The difference (if there is one) matters because …
- Here is what I think (my) APM should do.
Here is what APM should do:
APM will be based on eight principles:
- Focus on the business need.
- Deliver on time.
- Never compromise on quality.
- Build incrementally from firm foundations.
- Develop iteratively.
- Communicate continuously and clearly.
- Demonstrate control.
Want to know more?
You can find out more about Adaptable Project Management: A combination of Agile and Project Management for All (PM4A) and purchase your copy on our website.
This book is ideal if you’re interested in:
- Understand how to approach projects where the full requirements are not known at the outset;
- Learning how to combine the benefits of Agile and waterfall project management methodologies for successful project implementation;
- Understand how to take thorough approach to risk management; and
- Discovering a universal approach to project management, making sure that it is accessible for multiple industries and not wedded to software development practices.