by Josh
PM 2.0?
A lot of discussions have been going on about “PM 2.0″ recently. It can get a
Butting Heads by Jeff Pang via Flickr
bit polarized, especially when well-intentioned proponents of new ways to run projects sell it like a panacea, and sometimes it comes across as if nothing at all was good about “traditional” project management”.
In response, some practitioners of “traditional” project management can get a little defensive. Like me, for instance although I love the new an innovative developments that are going on. I just want some balance in the discussions.
One True Way?
Today I want to take a step back from the “conflict” and try to talk about what’s really important. It isn’t a dogmatic assertion of the “one true way” to do projects, and at the same time it’s not a completely relative approach either. I think the real question is “what is good project management?”
There are objective ways to judge a particular implementation of project management. Sometimes it tends to get framed in a black or white manner….either it’s good or it’s bad. Reality isn’t like that, it’s more of a continuum for various capabilities.
The shades of gray mean that you can have a great process (to some degree) poorly executed (in specific ways). It also means you can have a great methodology and decent execution but never get better because you’ve done a poor job at working continuous improvement into your process.
screwed up by OiD-W via Flickr
I mean, Scrum is great unless you screw it up. Then it sucks!
EVM is wonderful unless you act like you know how to implement it when you don’t. Then it’s a pain in the a$$ for everyone involved!
General management and great new tools get screwed up every day by well-intentioned project managers.
This week I’ll be writing about capabilities that are universal and something that can be used to judge your own implementation of “getting things done” with projects.
I invite you to leave a comment with your own ideas. What capabilities or attributes do you use to judge project management?
Don't Screw This Up
21 Comments
Josh Nankivel November 10 2009 13:53 pm
Let me be clear Glen. You're saying that XP, Scrum, and Crystal are NOT "PM2.0"
I was talking to Bas De Baar yesterday and I made the comment that "I don't even know what PM 2.0 is supposed to be."
Don't a lot of people who talk about PM 2.0 associate it with Scrum, XP, etc?
Tuyen TruongNovember 9, 2009 10:19 pm
To follow up on your point, I think a lot of people forget that the “traditional” project management methodologies are really effective at managing the longer, more complex projects that they are designed for. I think the problem occurs when people try to apply the same methodology to the smaller, more ad hoc projects that are more prevalent today (due in no small part to the Internet). To them, the new agile methodologies seem much more effective than the traditional methods, which seem heavyweight and cumbersome in comparison. But I think the same people would discover the opposite is true if they had to start managing a larger multi-year project that involved many people. They might start appreciating the additional structure provided by the traditional methodologies.
The appropriate methodology really depends on the projects. There is no “one true way”.
Josh Nankivel November 10 2009 13:57 pm
In part I think that's true. There are objective ways to judge a project management implementation that cross all project sizes and types. It's just that on some projects you have to do more or less of something to achieve the goal or attribute of "good project management".
Glen B. AllemanNovember 10, 2009 12:57 pm
Tuyen,
Our firm provides cost and schedule controls (Program Planning and Controls) to a large (multiple billion) manned space flight program. The customer (NASA two levels up) answers the question “how long are we willing to wait before we find out we’re late?” with the answer of TWO WEEKS.
So what seems like a “mega” project, has many of the attributes of an agile project. We produce assessments of “physical percent complete” every Thursday. This means items like you would find on a Scrum project – working code, bent metal, produced drawings, passed tests.
Once you start down the slippery slope of “large projects should use one process and small projects another,” you enter into the world of relativist project management processes.
The scale is not in the principles – those are immutable. The scale is in the fidelity of the artifacts.
Tuyen Truong November 10 2009 16:03 pm
I think I generally agree. Your comment on scaling the fidelity of the artifacts touches on my follow-up comment asking about the criteria that can be changed to suit the size and scope of different projects. Different fidelities seems to work better with different processes.
A large project can have many levels of artifact fidelities, which would imply that it can also have different processes in place. As a result, you could have a waterfall-style methodology at a higher level and a Scrum-like methodology at a lower level.
BasNovember 10, 2009 4:14 pm
“The scale is not in the principles – those are immutable. The scale is in the fidelity of the artifacts.” — That sentence just made me rethink my position on this matter. Doesn’t happen to often so… that’s a compliment 
About the PM 2.0 thing, let me try to clarify my opinion on this. It’s not about what used to be done was always bad, and this is perfect. If what you do works, stick with it. Always learn new tricks just in case But if it doesn’t provide value, don’t do it. That’s always the case for everything.
Generically speaking the 2.0 suffix refers to the capabilities web 2.0 technology brings us. They introduce a different way of communication and involvement to a mass audience. Yes, there were some isolated tools before that allowed this, but they didn’t have a mass adoption like web 2.0 does. They have “cut out the middleman” is some cases. They have improved virtual communication and have lowered threshold for communicating at all. And I can fill an entire blog about other reasons (wait… I did )
So where in some cases hierarchy was needed to facilitate communication, 2.0 made the hierarchy for that purpose unnecessary. It allows people that were not part of the primary information flow to be active in that flow.
This doesn’t mean the primary principles of good PM have changed. It does mean that bad management that survived because of information monopoly is taking a hit. And I applaud every one that hasn’t have operated in a “bad management environment”, but the people that have are happy to have found “a way out”. So basically 2.0 has provided a new tool to turn “bad” into “good” again. And yes, you can also try to change bad practice head on (which you should), but you are not always in a position to do just that.
Great discussion. I love to stretch ones own thinking… makes us all better PMs.
Glen B. Alleman November 11 2009 00:16 am
Bas,
Here's where it is important to look at other domains. Many of the programs we work have 100's if not sometimes 1000's of engineers and support staff. They all commonicate through some rudimentary tools compared to the "gee wiz" Web 2.0 stuff. They work in dozens of diffeent locations. Use mostly web based interfaces to large server side tools - SAP, CostView, CAD systems, Risk Management Systems, etc.
But they highly collaborate, interact everyday, every hour with each other - mostly on the phone, email, and live on IM for the short "hey what's this thing you just dropped on the thermal modeling server, it's all messed up from yesterday's run."
So communication flow is pretty much independent of any tools - other than the core tools of any large business. There is a theory in some circles that too much communication is ineffective. Engieering is a process, with a rhythm, the communication processes need to support that rhythm. If your coming to me every 30 minutes and asking "what's up with the thermal analsis?" I'll close my door or hide out soemwhere. If you come every 2 weeks I'll have to hunt you down to have a conversation.
These are control system paradigms - over control or under control and the system oscillates in undesirable ways. The feedback loop, its gain, and damping must be tuned to the business rhythm. Just having the ability to rapidly communicate does not by default make that good.
Josh Nankivel November 10 2009 17:35 pm
Thanks Bas. So here, methodology doesn't really have much to do with PM 2.0...it's really the changes that are enabled by the new technology.
Do most people have that view of it? Or is it a deterministic vs non-deterministic approach that most people have in mind?
projectshrink (Bas de Baar)November 10, 2009 5:58 pm
Talking about Project Management 2.0 at PM student [link to post] Makes sense? I hope #pmot
AceProjectNow (AceProject)November 10, 2009 6:36 pm
Josh makes a really good point here: everything is great…until we screw it up. [link to post] #pmot
Andrew FilevNovember 12, 2009 2:14 am
As one of the person’s who’s been writing for quite a while about the ways Enterprise 2.0 and PM entangle, I’d love to add more, but it’s all well said by Bas, Matt, Tuyen and others.
Cheers,
Andrew
Leave A Comment
Posting your comment...
Glen B. AllemanNovember 9, 2009 10:16 pm
Josh,
There is only one true way to do projects. The project manager must be capable of telling the interested parties:
1. When is the project forecast to be complete and what is the confidence on that date.
2. What will project cost in the end and what is the confidence on that value.
3. Do we know what the impediments are to reaching the end of the project on or near the planned time, and on or near the planned cost, and more or less with the capabilities needed by the “customer.”
4. What resources do we needed to get to all three of those “ends.”
5. What are the units of measure that can be used to describe the progress to plan that is being made and if that progress will result in “happiness” on or near the end of the project.
Get the answers to these and you’ve got a chance for success – at least for the things the PM is accountable for.
None of the PM 2.0 “sellers” speak about project in these terms, they only speak in features and functions of their products and what wonderful outcomes will result. No units of measure for those outcomes BTW. You know confidence intervals on cost and schedule improvements.
All TRUE project management methods from XP to Scrum to Crystal for software development – to full DoD 5000.02 IMP/IMS with full weekly earned value – all speak in those 5 (and more) terms.
Successful project management has very little to do with the tools. If those 5 (and possibly) more processes are not there, no PM X.0 process is gonna save you.
So in the end there is only one TRUE way – it called Project Management, not PM 2.0. The Greeks managed project this way, the Egyptians did, all the way to our manned space flight program.
The tools have changed of course, the principles have not.