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.