It’s great; unless you screw it up
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?
Nov 9th, 2009 at 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.
Reply
Josh Nankivel Reply:
November 10th, 2009 at 1: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?
Reply
Glen B. Alleman Reply:
November 11th, 2009 at 12:03 am
No XP, Scrum and Crystal are software development methods. Applicable to sofwtare development activities.
Ask yourself, where in XP, Scrum and Crystal are the Knowledge Areas of PMBOK?
If by a lot of people you mean sofwtare developers, yes they associate those software development process with project management. But that doesn’t make it so.
Those people are “developers,” in the same way a thermal engineer on our program equates the processes of thermanl engineering with the management of his Work Package.
This is pretty much a “never ending” discussion with from the developers point of view. But look at a large organizaiton – like our local TeleCo – and see what activities are performed “outside” of the development of code for the billing system. They use some Scrum, lots of RUP and a little but of XP. But in that environment there is little confusion about what is the difference between PM and Development.
Another client in town – a large helth insurnance provider – uses Scrum on about 1/2 the work stream for a several 100 million dollar claims processing system. But we (they) have several dozen project managers. The “team” is not confused betwenn PM and development methods. XP, Scrum, and most of Crystal are what SEI-CMMI Dev 2.1 calls Engieering Processes:
• Requirements Development
• Requirements Management
• Technical Solution
• Product Integration
• Verification
• Validation
CMMI Dev 2.1 populates the Project Management Area with:
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Integrated Project Management +IPPD
• Risk Management
• Quantitative Project Management
This leaves Process Management and Support to cover oof the remaining Process Areas.
If look at the processes of say Scrum, you’ll see they are mostly Engineering. Good processes for engineering, but little coverage of Project Management. XP is nearly all Engineering. Crystal more so than Scrum.
Now if you’re not a SEI CMMI-Dev 2.1 fan, then you’ll probably be redefining the meaning of the Process Areas and disavowing CMMI all together. But then those folsk are defining lost of other thinsg as well – PM 2.0, Risk Management (agile is riks management is one of my favorite redefinitions) and other semantic bending processes.
Reply
Nov 9th, 2009 at 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”.
Reply
Josh Nankivel Reply:
November 10th, 2009 at 1: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”.
Reply
Tuyen Truong Reply:
November 10th, 2009 at 2:47 pm
Agreed. Figuring out what is necessary and what you can get away with doing less of seems to be one of the difficulties of effective project management. I would be interested in hearing your thoughts on the criteria that aid in determining the optimum balance of efficiency and effectiveness in project management.
It seems a lot of PM tools out there are trying to find that optimum mix. The large number of tools available seems to indicate that the efficiency/effectiveness spectrum is large or that the optimum mix isn’t easily determinable.
Reply
Nov 10th, 2009 at 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.
Reply
Tuyen Truong Reply:
November 10th, 2009 at 4: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.
Reply
Glen B. Alleman Reply:
November 11th, 2009 at 12:17 am
Tuyen,
That is exactly what we use on our defense and space programs. A layered set of processes, each with diffeent fidelity and rhythms.
Reply
Nov 10th, 2009 at 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.
Reply
Josh Nankivel Reply:
November 10th, 2009 at 5: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?
Reply
Bas Reply:
November 10th, 2009 at 5:50 pm
Of course I cannot speak for most people, but it’s all related. Once you open up the info flow to everyone, you get closer to the principles of the agile manifesto in more complex scenario’s (read “traditional”).
Once you liberated the communication flow, you reduce some risks associated to non-deterministic situations.
The problem here is, that, yes it is “just a tool”, but it is also a risk mitigation measurement that reduces some of the human risks, eliminates bottlenecks and opens doors for processes that traditionally were to risky to be considered.
People enable what you can do in a project. If tools enhance the abilities of people, those tools become more than “just tools”.
Does that make sense?
Reply
Glen B. Alleman Reply:
November 11th, 2009 at 9:44 am
Bas,
And what in the agile world is the best communication channel – a 128 character text message or a several hour face-to-face white board walk through of today’s problems with the system?
Reply
Glen B. Alleman Reply:
November 11th, 2009 at 12: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.
Reply
Matt Cogley Reply:
November 11th, 2009 at 2:02 am
“So communication flow is pretty much independent of any tools – other than the core tools of any large business.”
Glen,
With all due respect to your experience and knowledge, I think that this is where you miss the whole “new tools” point, as I see it. The PM2.0 tools allow you to integrate communications into project management. So it’s IM, twitter, wiki, or even email threads inside of a pm system, so that all the members of the team be aware that some guy “dropped something on the thermal modeling server” and that it messes up everything. As if some of them doesn’t notice the messed up thing and continues working as if nothing happened, it may ruin the whole project. Or even better, they can prevent a guy from messing up stuff on the server, cause a pm system notifies them about the changes being made on a project right away. This is the way I see it. Does it make sense?
I’ve never worked for NASA and I understand that there’re lots of factors that I may not be taking into consideration. I’m just sharing my own experience with the Web2.0 pm apps.
Reply
Glen B. Alleman Reply:
November 11th, 2009 at 9:42 am
Matt,
So what happened the agile face-to-face communication is the best paradigm. Maybe reading the agile manifesto will put some light on replacing human touch with IM and Web 2.0 tools.
For any credible project management process, sitting in a room with the stakeholders, waving our arms and arguing at the white board.
It’s nearly impossible to do that with a Web based tool.
I might surmise from your response about the thermal guys you don’t work in the spacecraft design and development business. Designing any part of the spacecraft, aircraft, subsystems or large construction project using IM, twitter, or a wiki as our communication channel is well – nonsense.
Let me take a minute to describe a day cycle on a typical project. We have mechanical, propulsion, software, and electroncis engineers all working on the station holding system. The mechanical guys have their 3D CAD system Catia, the electrical guys have their CAD system, prop the same, and the software (firmware) guys have there Handel-C emulator. The “package” for the station holding system has a weight, thermal, cycle time performance and a couple dozen other constraints. Concurrent engineer is used in a IPPD (Integrated Product and Process Development) world with the best of CMMI (oh joy).
Someone in the mechanical side (thermal blankets) releases to today version of the attachment fasteners. They now move the center of gravity of the system away from the null point, so the stability algorithm needs to be retested tonight on the simulator.
There is a TIM (Technical Interchange Meeting) prior to the start of the test run every one looks each other in the eye – in a face-to-face room – and walks the things needed to be verified and validated before we turn this thing loose in the high bay.
That does happen over IM and Twitter. Saying where we’re going for lunch – Applebee’s since we’re all veterans and eat free today – is a great MSFT Messenger task.
Think about the Agile Manifest – face to face communication is not only preferred – that’s not string enough – it’s mandatory for project success.
So it may turn out Web 2.0 apps for pm have a specific sweet spot in IT projects. But even then, I’d conjecture there is a limit. I’ve stood up several large ERP systems and face-to-face is preferred every time.
Reply
Matt Cogley Reply:
November 11th, 2009 at 11:31 am
Glen,
I couldn’t agree more. Face-to-face is king and will always remain king. No doubt about that. But what if team members are separated by oceans and face-to-face is simply not possible? Besides, will it not be helpful to have all the stuff that you discussed at the meeting right there in your project management system? So that you don’t have to search for this knowledge across numerous files with meeting records and all your team members can dig into it anytime?
Reply
Glen B. Alleman Reply:
November 12th, 2009 at 3:53 pm
Matt,
What we have learned in the aerospace business is to reduce coupling and increase cohesion for the programmatic architecture.
This means the “management of interfaces” is King. This is a Systems Engineering discipline. The interfaces are always defined in an ICD (Interface Control Document). This significantly reduces the need to have responsive communications. Manily because high levels of communications slows down progress. Invest in a sufficinet level of detail so the individual teams can run 100% for some period of time – say a month. Within the co-located teams face-to-face is of course maximized.
We work at the Programmatic Architecture (the program equivalent to system architecture) to maximize the decoupling of the communication processes. A periodic (monthly sometimes) TIM (Technical Interchange Meeting) is done for DoD and NASA programs.
Regarding “having all the stuff available from the meeting” – maybe. All the stuff needs to be more formal on our programs, in the form of documents – specs, models. All under change control, all access through the network, but all formally classified and sorted. This is the “performance management” paradigm, not often found in commercial IT, which seems more “fling it out on the share drive.”
The actual number of meetings – while it feels high on our large flight software programs – is very low compared to the “cluster style” meetings on our IT programs. The culture of “engineering the solution” has a different rhythm than we see in the code development for commercial IT systems world.
So my personal take on Web 2.0/PM 2.0 is it is a solution to the problem of undisciplined project and engineering management. Become more disciplined and you don’t need constant chatter to keep the project going in the right direction.
Careful, thoughtful analysis before any work or change to work is done. We hold cost and schedule as king, while high compliance to technical specification.
There is a large banner in the second lobby of one of our buildings (after security)
100% MISSION SUCCESS – that focuses the mind.
Reply
Nov 10th, 2009 at 5:58 pm
Twitter Comment
Talking about Project Management 2.0 at PM student [link to post] Makes sense? I hope
– Posted using Chat Catcher
Nov 10th, 2009 at 6:36 pm
Twitter Comment
Josh makes a really good point here: everything is great…until we screw it up. [link to post] #pmot
– Posted using Chat Catcher
Nov 12th, 2009 at 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
Reply