Welcome to the IPM. Podcast, OPM is the childhood
body for the project profession. My name is Emma DeVito and I'm
the editor of project apm's quarterly journal, and your
host. And this podcast, I'm speaking
with Adrienne Duty, a long time project, professional, whose
views, and all things are Darlin much in demand from the project
community in his 45 years, in project management.
Judgment. He tells me that he is seeing
many fads rise to prominence and then become integrated into the
background of good practice. He believes our Joel will follow
that same path. Just to give you a little bit of
background and Adrian he started out his career.
As a construction project manager, eventually becoming
involved in developing software applications for construction
in. 1984, he set up the projects group as a training and
consultancy Company and all things related to project
management. Adrian was one of the Founders
of project manager today magazine and also served as an
executive council member of a p.m. he was lastly the lead
author of the sixth edition of opm's body of knowledge, Adrian
remains a non-executive director of a PN group and is also the
founder and Lead author of the Praxis framework a free online
methodology body of knowledge and much more for project
program and portfolio management.
Welcome agent. Thanks for finding the time to
speak to us. Thank you, Emma.
You've been in the world of project management since the
1970s a long time and no doubt have seen many Trends come and
go, could you give us a bit of background and context and to
how agile might fit into this post?
40 years? Yeah.
Well, I've been I think about this a lot and I've been
pondering the various fads and Fashions.
I've seen come and go. And perhaps the one that is, is
foremost in my mind, is the one that I sort of found myself in,
when I, when I first joined the profession and in some respects,
it feels as if that particular fashion led to the one, we have
at the moment with agile, it was the very late 70s, and desktop
computers came along for the first time.
And those of us who were in planning and project,
Management. Saw this is a great opportunity
and lots of people around the UK started developing software for
project scheduling so that they didn't have to send sheets off
to the bureau Mainframe. And wait for schedules to come
back usually with a typo in them, which made them completely
wrong. So, we started developing this
localized software so you could sit in the site office and do
your scheduling there and then it was real time, and Grew and
grew and the use of desktop computers, grew, and grew.
And, and just to give one illustration of how that became
such a thing. I remember an advert which was
for something called super project and it was a box
because, you know, those days software came in boxes, on
floppy disks and a manual. And it was a box sitting on the
Mastermind chair, and the caption was the best project
manager you'll ever meet. Now, we'd laugh at that.
Now, you know, the idea that a boxer, so, Software can manage a
project although maybe with a i it's getting there.
But in those days that was the hype around.
That particular tsunami of enthusiasm about the ability to
schedule projects locally on your desktop.
And I remember at the time, there was an enormous demand for
those of us who had experience in scheduling mainly from
construction, from the IT industry and the it.
The street adopted this with gusto, I remember being called
into various organizations and they said, right?
This is this is what we're doing and I'd say well, doesn't really
apply to what you're doing, you know, I know it's a big thing
but this is not for you. This is this is not what you
should be or how you should be scheduling your projects and it
struck me on reflection that maybe that it's in some way.
It's the reaction against all that.
Hi type of project schedules which in some way led to the
opposite. Hype of.
No we don't need plans. We shouldn't have plans.
Everything has to be very, very flexible.
So in some ways you know the pendulum swings and one fashion
leads to an opposite fashion further down the line.
So agile came about at the turn of the Millennium and sauce that
the agile Manifesto from a very specific part.
Of wild and if you know specific sector industry, how has the
concept of agile changed since then since the agile Manifesto
came out and how has that morphed into something for the
world of project management? To use what we have to do is to
challenge some of the assumptions here.
So you're absolutely right was it 2001 its 17 software Ella
purrs got together in in a ski resort and said why we're going
to write this Manifesto and it was all about software
development and there's a perception that agile started
with the manifesto. If we drop the word agile from
moment and talk about agility, the ability to flex and be
adaptable on your projects, there are numerous examples and
case studies going back to the pantheon in Rome.
In the first century through Christopher wren's, Paul's
Cathedral where people have had to stop rethink.
Look again at the scope and head off in a slightly different
direction that that's nothing new.
So I think agility has all always been there and never
another example, would be in the 80s.
I think. Probably late, 70s and 80s.
Concurrent engineering was very popular and concurrent
engineering is about. Self-managed multidisciplinary
teams. So to think that agile started
in 2001, the only thing that started in 2001 was the hype.
The agility was already there the agile Manifesto crystallized
that perhaps as I suggested as a reaction to how the software
industry had somewhat unthinkingly.
It's so much stuff from construction which wasn't
necessarily relevant, but it was that Manifesto that started in
2001 and rapidly became something that I believe it
wasn't intended to be because of the hype.
What did it become then? Almost like a cult, I'd agree
with you and I'm probably would drop the word.
Almost I think. Yes, it's It has become a cult.
One example of that, is that agile has become binary.
You know, when I talked about agility and flexibility, you're
talking about something which is a Continuum.
There are different degrees of agility, different degrees of
flexibility. Whereas agile has become binary,
sadly something I I do quite a bit.
He's monitor all the conversations on social media
about this and you keep getting these debates among People who
are in the agile Community saying, well that's agile.
That's not agile. Particularly when it comes to
trying to scale agile across an organization.
If you look at this stuff on social media, for example on
LinkedIn, you will find there is quite a battle between the camps
that say safe, the scale. Agile framework.
Safe is not agile and other people will say, well, yes it
is. It's scaled added agile.
You'll get People debating whether scrum is agile or not,
that's a slightly different kind of argument.
But there are these quite heated debates about.
What is agile? What is not agile?
It's become binary. And one of my observations is
that because people can't quite pin down.
What agile? Is they resort to the easier
thing of defining what it isn't? And that's where waterfall comes
from because if we can't agree, what agile is?
So let's talk about what it isn't.
We don't have a name for what it isn't in the way that we have a
name for agile. So we need to create something
an antonym for agile. And that's where the term
waterfall comes from. And you will see some quite
prominent and respected. People will quote things about
waterfall or the other term that they commonly uses traditional
project management. So there's this idea that there
is this traditional project management.
IE every project previous to 2001 followed this traditional
approach and typically that is Is colloquially called waterfall
and I read or I read a transcript to a presentation of
a professor at a university giving a talk about a case that
the case study was the Empire State Building and the comment
was you develop all these plans? And if one resource goes sick or
it starts to rain or your plans go out the window, Now that's
just crazy that's not the way it works but the rigid rigid
waterfall approach which is you sit down.
You define everything. You produce an immutable plan
which can't change. And then you start delivering
according to that, plan is a say, a creation of people who
want to promote what they perceive as the opposite to
that. So you you you Can't have a
saint that doesn't have a dragon to slay and we're agile, is the
saint waterfall and traditional are the dragons that it seeks to
slay. So yes you're right.
It becomes very coltish out in the real world of projects.
It seems to me that people aren't so hung up on the
definition of a job. But just using what works and
there's two separate things here really, there's the mindset of
agility, the approach of agility which is what I'm understanding.
Ending from this. And then this is whole host of
agile tools that have been described as a child known as
that. Other that in reality, I think
people adapt experiment with whatever makes things work.
And when I've interviewed project leaders, often they go
for what's now been turned a hybrid approach.
Which actually is to have a toolbox that filled with all the
processes and techniques and everything you need from the way
projects have been done to incorporate new tools and ways
of thinking, would you agree with that out in the real world
of projects? Is it about this idea of having
a hybrid approach? I think again there's two ways
I'd like to approach that question, firstly, the
difference between what I've seen referred to as the agile
Just real complex. There is this interlocking
system of Consultants trainers tool providers in the agile
space who are slightly detached from the people who are actually
out there doing it and their interrelation their
interdependence on each other, just amplifies and amplifies the
message. And it's interesting when I post
on social media, about my views on on agile, I Will get.
I will get a lot of truly agile people saying, no, you're wrong.
That's not the way it works. And even say, blocking me on
LinkedIn, because they don't agree with the points.
I'm making. All the good conversations I
have are with people who are actually out there doing it and
saying, well, it's not that black and white.
We as you quite rightly point out, we adapt to the context of
our project will use tools and techniques which some will call
our Joel, some will call waterfall Locker somewhere in
between and we will use those as our project needs and those are
people are actually out there doing it.
So this is Act between the layer which depend on the hype, and
the layer that are just trying to do a job.
Now, when we then what that leads to and I think again, this
comes from the, if you like the agile Elite to the agile cult,
The Druids of agile, observing the people who are actually out
there doing it and say, ah, they're not totally agile,
they're not totally waterfall. So we'll call This hybrid.
Now my view on that is that if you look up the dictionary
definition of hybrid, which I haven't memorized, it is a
combination of two things by definition, the two things have
to exist in order to have a hybrid.
Now, my argument is that waterfall stroke traditional,
definitely doesn't exist and never did.
And agile is just one extreme if the Continuum of agility.
So if you don't have Waterfall and agile is just a view, a
superficial view of the underlying practice.
Then how can you have a hybrid of those two things for me,
hybrid is the acceptable face of the mistake that was made.
To make agile and waterfall these two polarizing positions.
What advice have you got for project professionals, who are
aware of all of this going on and aware of our child.
And perhaps thinking that that means a specific thing that they
need to be doing practically and with your longer view.
What advice would you give to them about agile to promote the
right way of thinking, my advice would be stop thinking in terms
of agile. And waterfall think in terms of
the Continuum of agility. It's going to sound very nerdy
when I say that a Giles and adjectives and Agility as a
noun. But yeah, Joel originally was a
was an adjective to describe to qualify something you're doing
so agile. Project management would have
been I'm managing my project with agility.
When it became a noun, when it became a thin, that's when it
became binary, you're either agile, you're not.
So we've got to get rid of that. We somehow got to get away from
that kind of thinking, and I believe strongly.
Foot when we talking about how we want to manage our projects
and our programs, we should be talking about agility because
that gives us a whole spectrum of approaches that we can take
and not just on a project-by-project basis but on
different parts of the project actually lists talk about agile
projects and waterfall projects. Well for anybody out there who's
worked on an engineering project.
Yes, if you're going to build a bridge, you've got to have the
full requirements and specification done before you
start digging holes in the ground, otherwise you've got,
you're going to have problems. But that design work in the
design, in the early stages of the project will have been done
in a very agile way or to use my preferred way of saying it will
have been done with great agility.
There will have been multi-disciplinary teams going
through multiple iterations of the design working with the
client working with stakeholders to gradually come to the design,
which is going to be built, so you can have great agility in
the design phases. Phases of a project and very low
agility in the latter, phases of the project, because ultimately
the, the ability to be agile, The ability to to apply agility
is down to the cost of change. And that comes back to where
this all came from, which was software development in software
development. If you want to change a feature,
you rewrite the code. Clearly there's a cost to that.
If you're halfway through building a bridge and you want
to change the design, the cost of change is enormous.
So within any project there are there are elements of the
project. There are phases of the project
where the cost of change is low, and that's where you can apply
great agility and there are areas of the project where the
cost of change is very high and that's where it's very
difficult. Well by definition, very
expensive to apply changes. So my advice to people is think
in terms of agility, think in terms of how different projects,
different parts of your project can make use of agility and
flexibility and then apply the relevant.
Approaches to those different projects different parts of
those projects just please please please get away from this
mentality that there's red which is agile.
Indigo, which is waterfall and all the other colors of the
rainbow in between don't exist. All the idea that hybrid is not
the colors in between hybrid is just a mixture of red and
indigo. So as sort of a muddy gloopy
Bluey read, you know, it's just need to open our minds to this
spectrum of agility. Where are we now with agile?
We've got past the hype. It's not idea that's been
maturing in the world of business and projects and
Beyond. Where do you think it's heading?
Now own particularly from the world of project management, a
good Bridge just briefly going back to the manifesto.
I think what that did was to crystallize and formalize, some
of the good ideas that were out there or L, help the
formalization of the ideas. That are out there so you know,
I'm not trying to I don't want to come across as an antique.
Well, I suppose I am Auntie agile.
What I'm not is anti agility and I think the manifesto and some
of the stuff around that has done a lot to help boost and
understanding of agility in project management.
So I think that ultimately the profession is better for a lot
of this discussion about agility.
And I think the next phase that we have to work through, is a
lot of those ideas about agility, just being absorbed and
becoming part of the profession. So we don't talk about them as
being some separate way of managing projects.
We just see them as a natural component of managing projects.
They are part of the project managers tool kit.
When they come to deciding what tools are best for their
particular project. Now I think again to to to draw
another business analogy who talks about business process
engineering anymore. But what does it was that was it
Mike Hammer published an article in the.
I don't know, the Wall Street Journal or the Harvard Business
review or something. And all of a sudden everybody
was talking about business process re-engineering, And then
it disappeared. Did it disappear or did it just
get absorbed into the general mindset?
You know, I think when people talk about digital
transformation now, You think well, how much of digital
transformation is just business process?
Re-engineering? In a digital world.
And in a way, these labels are kind of a handy way of exactly
what he says or crystallizing the kind of zeitgeist or a shift
in the way we think about things often the way we think about
business or the way we think about projects which is going to
leave me to ask you another another question.
But already people are asking what is beyond agile?
What is after, what comes after our child?
Probably four months ago. I wouldn't have known how to
answer that question. Now I'm going to say a I you
know we're all every people talking about AI for years I
remembers when I first got involved in software development
I wish I still had it but I remember buying a book on
artificial intelligence. Most of it was sort of a bit
over-the-top and and primarily it was just about well I
remember an article in a magazine if I can get this.
This quote, quite right there was two two phrases.
It was time flies like an arrow fruit flies, like a banana, how
do you explain to artificial intelligence the difference
between those two sentences So the the thinking about
artificial intelligence has been around since Turing.
Proposed his famous test. What has happened in the last
four months is chat GPT all of a sudden.
Every other post in LinkedIn is about chat GPT.
And what I see happening again is loads and loads of hype and
I've Played with it in a very amateurish way and it does feel
like it brings back. Those feelings from 40 years
ago, when we first had desktop computers.
What do you mean? We're like, excitement or yes.
Yes excitement in that. This is life-changing.
Well this is this is world changing.
But at the moment, it's very clunky and the danger is that
people get to in You see a stick about the clunky version?
In terms of, it's finished its here.
Rather than saying, why, this is a great start.
Where can we take this in the future?
So the hype says, it's here, it's great, you've got to use it
now. The more balanced approach says,
okay, let's let's have a look at this.
This is good. This is bringing a lot of stuff
together. I can see this has opportunities
but it's got to improve a lot and I'm sure it will over the
next few years. So again, it's this danger of
hyping it up too soon already people are talking about as
possible application to the World of projects is that is
that something you're willing to put your you know gives a give
us some views on? I think it's early days my view
of that particular tool chat GPT is governed by the fact that if
I if I put a question in about something I'm not very familiar
with, I get a very convincing very eloquent answer.
That makes me too. Alright, that's how it works.
If I put a question in about something that I'm very, very
familiar with Did I get an answer back?
Particularly if you put in questions about agile and
waterfall, what we'll what you'll get back is very
eloquent. Very convincing answers based on
information. It's scraped from the web, which
I would say, is completely wrong.
So, one of the things that I think AI has to do is get to the
point where it can somehow make a judgment about what is good
information on what is bad information.
I don't think it could well I'm but I'm pretty sure it can't do
that at the moment. So when you start to see
statements like all project managers are going to be out of
a job in 3 years because we're just going to get AI to manage
the projects while. Yeah.
Come on, be serious. This is a this is another tool
which is going to help. We've got to work out how to use
it. We've got to work out how to
understand it and then we've got a build it in.
In to the way we manage our projects but let's be very very
careful about not getting too excited too soon because then
we're just repeating what happened with scheduling
software in the early 80s when people people's attitude was you
know the answer is your scheduling software.
What's the question? And 30 years later, it was all
the answers. Agile.
What's the question? Let's not start doing the
answers. AI, what's the question?
Any leaving? Thoughts for listeners about
agile and Agility? And I know it sounds like a very
pedantic grammatical point, but it is actually just the surface
presentation of a change in mindset, which is, we need to
think about agility. Which is a Continuum, a spectrum
of different degrees of agility and stop talking about binary
Concepts like agile. And definitely opposing binary
Concepts like agile and waterfall.
Take a more relaxed considered holistic view of these things
and don't get wrapped up in the hype and the jargon.
Okay, Asian great way to end this podcast.
So we've, we've covered a lot of ground there.
Thank you so much for your time again.
Thank you very much, Emma. It's been great fun.
Thanks again to Adrienne for joining us and to you for
listening to the OPM podcast. Don't forget to look out for
more episodes or to rate and review as wherever you get your
podcasts. We welcome you to get in touch
with your comments feedback and suggestions by e-mailing us at a
p.m. podcast at think publishing .co.uk.
This podcast has been brought to you by APM to chartered body for
the project profession for More information on a p.m. visit, a
PM. Org.uk.