About a year ago, I had a conversation with the product team for a major vendor of project and work management solutions. They wanted to talk to a project manager about how projects actually get managed in organizations and to discuss the user behaviour data that they were getting out of their systems.
All business domains are prone to religious schisms where adherents of one method will fight pitches battles with their ideological foes colleagues. Project management is particularly prone to this. There are the disputes between followers of PMBOK (from the US-based Project Management Institute) and PRINCE2 (originally developed within the UK government and now owned by Greek certification provider PeopleCert). Both of these were formally released in 1996 (drawing on older methods). While there are doctrinal disputes between PMBOK and Prince2, the primary differences are geographic.
In 2001, a group of software engineers nailed their Manifesto for Agile Software Development (with its 4 values and 12 principles) to the door of a Wittenberg church. Followers of Agile refer to legacy project management methods as “Waterfall” (although the term goes back to the 70s). No PRINCE2 or PMBOK practitioner would refer to their approach as such, just as no Catholic would refer to themselves as a “Papist”. There is really no single Agile methodology - rather a group of techniques such as XP, Kanban, and Scrum that focus on iterative product development. Recently, methods for “scaling” agile such as SAFe have been promoted, loved, and hated. Due to its associations with technology development, agile has become something of a fad. Businesses are exhorted to go 100% agile - with mixed results.
It’s all very emotional and exhausting.
All this kerfuffle misses one critical fact. The vast majority of projects are run by people with no knowledge of any of this stuff whatsoever. Never mind a product backlog or project schedule, for most projects you will be lucky to get a task list. Indeed, the verbal feedback from the vendor mentioned earlier was that about 10% of the task lists created in their system had names and dates put against them.
Most people do not know how to write meaningful objectives, do not know how to identify stakeholders, do not know how to gather requirements, and do not know how to make things actionable. And not all of these projects fail. But we might guess that fewer might fail if people knew how to do the basics.
While all the methods mentioned in this article have useful elements that work in certain contexts, we need to get back to basics. To twist a phrase from tech, we need an MVP - Minimal Viable Project (Management). We need to ditch the tedious arguments within the project practitioner communities about who is right and spread the good news that projects (or initiatives or campaigns or whatever) can be delivered better than they are now. And that this can all be achieved relatively easily.
This reminds me (as so many things do) of The Clash. In much the same way that punk boiled music down to three chords and THE TRUTH after the excesses of prog, so MVP(M) needs to make project management as simple as possible.
There is somewhere we need to get to that is not here. What direction is it in and how do we know when we are there?
What do we need to do?
Who needs to do it?
When do they need to do it?
Damn, I wanted there to be three (like the chords). Never mind, four it is. Onward!