Trevor K. Nelson

Note: The following is my opinion only. As always, feedback is welcome.

 

I’ve been thinking about the definition of project management for a while now.

I think for many it’s been incorrectly defined, explained, or misunderstood, which has led to many of the challenges and ‘religious wars’ between Project Managemnt and Agile.

For many, ‘project management’ means a specific method or approach – waterfall. For others it signifies a leadership approach – command and control. For yet others, it’s a broader approach, or a concept.

Unfortunately, the larger or more visible/active project management associations haven’t helped in this area.

PMI defines it as: The use of specific knowledge, skills, tools, and techniques to deliver something of value to people. 

IPMA defines it as: Concerned with the application of methods, tools, techniques and competences to a project to achieve goals.

APM defines it as: The application of processes, methods, knowledge, skills, and experience to achieve specific objectives for change.

Now, while none of these are technically ‘wrong’, I think they’re only part of the definition. They only focus on the verb aspect of project management, the ‘managing’ of projects. But what about the ‘noun’ aspect?

I think of project management much the same as I do ‘medicine’. It’s an umbrella term for a large ‘body of knowledge and practice’. When I talk about project management, I’m talking about ‘all’ of project management – the tools, the processes, the theories, the leadership traits, the problem-solving aspects, the ‘aha’ moments, the different delivery approaches, the people aspects, etc.

In a business context, project management runs the gamut, from ‘strategy development’ to ‘product on the shelf’, from ‘culture change’ to ‘decommissioning the site’. What is strategy execution if not ‘managing the projects to deliver the strategy’? Change management is ‘managing the project of the change initiative’. Product development, digital (or even Agile) transformations, innovation…., all of it falls under the umbrella of project management- the getting from ‘here’ to ’there’. 

Merriam-Webster has several definitions for ‘medicine’, but there’s one that captures both the verb and noun uses – 

The science and art dealing with the maintenance of health and the prevention, alleviation, or cure of disease. 

I think we need a similar definition for project management – 

The science and art dealing with the development and delivery of desired outcomes or outputs.

And like medicine, this definition doesn’t mean there’s only one way of doing it. Medical Doctors don’t always agree with Chiropractic, or Naturopathy. Just look at the medical community’s response to the COVID-19 pandemic – while there existed a majority view, ‘medicine’ did not see it all the same, or have the same processes or treatments. 

The similarity doesn’t end with the discrepancies or disagreements. Medical professionals exist in a wide range of contexts – surgery, general practice, pediatrics, research, pharmacy, etc. There are specialties, which each knowing that they don’t ‘know it all’, and that the field and science is always growing. But it’s all still ‘medicine’. And as ‘medicine’ includes everything from ’take 2 aspirin’ or getting a Band-Aid to brain surgery, ‘project management’ spans everything from building a dog house or planning a vacation to building a nuclear submarine.

I think if we have a better definition, one that addresses the ‘science and art’ more than the ‘tools and processes’, we can be done with the religious wars of project management vs Agile, and focus on ‘what’s the best way to deliver the particular outcome/output’, and how can we keep evolving the practice, and professionals.  

Recently I posed a question on LinkedIn – 

Could anyone explain what Agile is, without explaining what it isn’t?

I asked this for a few reasons, primary being that there didn’t seem to be any real consensus on it.

For some it’s the Agile Manifesto and restricted to software development. Others claim it transcends software and is applicable to all business functions (Agile PM, Agile HR, Agile Marketing, Agile Hairdressing, Agile Dog Walking, etc.). Agile has in some ways become the ‘go to’ term for anything ‘good’ or ‘desirable’. But it’s also become nebulous in some ways. If I like it the process, then it’s Agile (yay, good), and if I don’t, then it’s not Agile (boo, bad). This seems to be regardless of whether the process itself works or not. 

It’s also retroactive. Henry Ford was practicing or being ‘Agile’ when he created the assembly line, as was Thomas Edison when he invented the light bulb. And Agile is the goal. Organizations (and practitioners) all want to be ‘Agile’. 

But what is it?

How do you explain it to an executive or team  that’s curious and wondering if ‘adopting Agile’ is the right direction? What does it mean for an organization, or its leaders? Or a team? 

What has to change? Who has to change? (always a concern for leaders). Change to what?

The rules were simple:

1.  No “Agile is an alternative to Waterfall” or similar.
• This focuses on what Agile isn’t. If Agile is a response or alternative to Waterfall, then doesn’t that mean improving Waterfall obviates the need for Agile?
2.  No “Agile is a mindset”. 
• This is too easy and a cop-out. You might as well say Agile is ‘positive thinking’, or ‘being resilient’ – two more ‘nothing’ phrases.
3.  If you referred to Agile ‘methods, tools, or techniques’, you had to explain what those were as well.
• Too often I see explanations that say ‘Agile is set of processes for developing software, or making decisions’. Okay, but that still doesn’t tell me what it is, what needs to be implemented, or why Agile is ‘better’. 

So what did we get? Well, for starters it turned out to be more difficult than I (and I think others) thought it would be, and to say the responses were varied would be an understatement. In some cases responses directly contradicted other responses. All leading to the inevitable conclusion that – no one really knows. 

It seems everyone has a view or opinion about what Agile is, or isn’t, and like fingerprints or snowflakes, no two are alike. 

A small sampling of the (paraphrased) responses – 

• It’s a software development approach per the Agile Manifesto
• It’s a problem solving approach
• It’s a set of rules or decision-making approach to address complex or chaotic situations
• It’s an approach to team enablement
• It’s an approach to enable quicker response time
• It’s doing work iteratively
• It’s an adjective

There were some humorous responses as well. One suggested I had actually posed a riddle. Another suggested that Agile is now an industrial complex (maybe not wrong there), and another that it’s really a ‘trigger word’.

As an example of the contrary views on this, one response was that Agile was about creating well-functioning teams. When pressed, it was agreed that if this indeed was the case, then a phased-approached project could in fact be Agile, as long as the phased-approach was A) the one best suited for the project type, and B) allowed for well functioning teams. At the same time another response suggested Agile was iterative, and if you weren’t delivering incrementally, then you weren’t using Agile practices. 

Unfortunately, the idea/challenge of defining what Agile is became even more problematic shortly after I posed my question. Under normal circumstances one might think that going back to the source material (the Agile Manifesto) would help solve or at least clarify things. As it turned out, while my question was being discussed there was another discussion going on over whether or not SAFe (Scaled Agile Framework) was in fact “Agile”. Sadly, when it was suggested by someone that all seventeen of the original authors of the Agile Manifesto had all, individually, stated that SAFe was in fact not Agile, many decided that they (the creators of the concept of Agile) were not the final arbiters of what is or isn’t Agile. 

Honestly, I’m still pondering how that works.

Regardless, in the face of this disregard for the opinions of the Manifesto’s authors, I decided to press on and take a deeper look for myself. The Manifesto itself is actually pretty short – 4 Values, 12 Principles, and 1 page (History) about how they got there (so it’s not like the research was hard). 

After reading the History page I thought I was getting somewhere – it’s pretty clear that the original group gathered to discuss ways to use ‘light weight methods’, to ‘deliver good products’, and wanted to actaully treat people as important and not just say they were. The only process/methods described were ones already in use (Scrum, DSDM, XP, Crystal, etc.). Nothing new or prescriptive at all.

The ‘self-organizing teams’, the ‘frequent delivery’, the ‘welcoming of change’ seem more like simply mechanisms the authors thought would help facilitate this than ‘requirements’ (that’s why it’s “we value” and not “we require”). They even go so far as to say they aren’t anti-plan or anti-methodology. They just wanted to find ways to remove, as they called it, the “Dilbertesque” approach to work. Oh, and it was written by 17 software development professionals, about software development methods, to develop software better. So do with that what you will. 

Alas, even this view was challenged and it was suggested that this described Agile 20 years ago, but it’s evolved since then. And maybe that’s true. Towards this end we’re now seeing suggested updated versions of Agile – Agile 2.0, Modern Agile, Amplio, etc. 

Reading the responses (both to my question and the SAFe discussion) I was often reminded of Justice Potter Stewart’s famous comment during the 1964 obscenity trial –

“I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description, and perhaps I could never succeed in intelligibly doing so. But I know it when I see it,…”

So after all this where did I end up? In the end I’ve come to the conclusion that Agile is an intent. It’s not a thing, not a set of practices, not a method or methodology, not a ‘mindset’, not responding to change faster, not delivering incrementally. It’s not Agile vs agile vs agility. The word Agile seems to simply be the agreed upon alternative to ‘light’ or ‘light weight’ and really appears to have little significance. It’s not anti-waterfall, or anti-plan, or anti-documentation. The only thing it’s “anti-” towards is cumbersome, pointless, painful bureaucracy.

It’s simply delivering a good product, with a light touch (and a plan), and treating people well. 

Now I realize that this isn’t good news for those selling Agile products, toys, t-shirts, gift certificates, etc. But there it is. 

 

Of course, I may be wrong.