At the PMI Global Congress that I attended in October, I met many project management practitioners. Some of them asked me about my views on Project Management 2.0. One of the questions was “How is Project Management 2.0 different from what many organizations have today?” I decided to summarize my answers and came up with a short list of key factors that distinguish Project Management 2.0 from traditional project management.
They are:
Environment. Manuel Castells, the author of "The Information Age: Economy, Society and Culture (v. 1-3)
" and a visiting professor in 15 universities around the world, states that we are currently experiencing an IT revolution, just like our predecessors lived through an agricultural revolution and an industrial revolution. According to Castells, there is a shift from industrialism (mass production) to informationalism (flexible production), and this new type of economy is empowered by the development of technologies— first of all, the Internet. As the world shifts from an industrial economy to an information economy and big part of the workforce becomes information workers, the importance of innovation, creativity and productivity rises. In traditional project management, people are often managed like any other resource, just like bricks and machines. In the present economy, people cannot be managed the same way, as it will simply be counterproductive. In Project Management 2.0, people are encouraged to participate in project planning, to introduce their ideas on project development and to give their feedback on other team members’ jobs. Environment as the main differentiator drives the other distinctions listed below:
Collaboration and collective intelligence. In an information economy, only organizations that are flexible enough, so that people and capacity can be rearranged and recombined quickly without major structural change, will be able to thrive. Quick access to information and rapid data-sharing become critically important in this environment, as they help companies minimize expenses, innovate, make better decisions and make them faster. Project Management 2.0 emphasizes the importance of leveraging the collective intelligence of the whole team, no matter where the team members are located, at the same office or on different continents.
At the same time, Project Management 2.0 stimulates collaboration and catalyzes the change in processes. Here I’d like to paraphrase Andrew MacAfee’s quote about Enterprise 2.0 and apply it to the new trend in project management: Project Management 2.0 technologies are “trying hard not to impose on users any preconceived notions about how work should proceed or how output should be categorized or structured. Instead, they’re building tools that let these aspects of knowledge work emerge.” Emergent structures, one of the basic principles of Project Management 2.0, empowers people on the team level to easily share information and make changes to their part of the project plan. This way, bottom-up field knowledge makes its way into a project schedule, and the schedule becomes more realistic. Comparing this approach with the one represented by most current project management platforms, wiki inventor Ward Cunningham highlights an important shortcoming of the traditional way. He says: “For questions like ‘What’s going on in the project?’ we could design a database. But whatever fields we put in the database would turn out to be what’s not important about what’s going on in the project. What’s important about the project is the stuff you don’t anticipate.”
The Project Management 2.0 focus on collective intelligence stipulates the next differentiator.
Shift in the project manager’s role. Traditionally, the project management role is focused a lot on tight control of the budget and schedule. This part of the project management job becomes more subtle in a talent economy. Organizational agility requires a more flexible approach to budgeting and deadlines. At the same time, the importance of leveraging the human talent becomes more prominent. Therefore, other parts of a project manager’s job, such as leadership skills, become more important. It's no longer enough for project managers to possess good people skills and to be fluent in project management best practices, tools and methodologies. To succeed today, project managers need enhanced leadership skills. They need to be flexible and focused on business value, writes Forrester Analyst Mary Gerush in “Define, Hire and Develop Your Next Generation Project Managers.”
Productivity. Web 2.0 tools allow an unprecedented productivity increase when it comes to information-sharing and communications. There are many examples spanning from the consumer arena to the enterprise space, from Wikipedia and Facebook to GE’s corporate collaboration system. Project Management 2.0 focuses on taking advantage of this productivity to achieve better results in shorter periods of time.
Have I enumerated all the distinguishing traits of Project Management 2.0? What’s your take on the main differentiators of Project Management 2.0? Please share your thoughts in the comments.
GE's collaborative network was started in the mid 80's when we installed the engineering document management system at GE Aircraft engines in Cincinnati. I was the PM on that contract. GE had an internal "meeting place" on the then crude web. GE "work-out" was the basis of collaborative improvement of process on the product development side.
Many of the attributes you connect to PM 2.0 have been in place and operation at major defense contractors for a decade or so. The Lockheed's and Northrup's of the world have lived on IM, SharePoint servers, virtual teams, and high collaboration (mandated by the IPT process of NASA and DoD) for some time.
Wiki's have been used on our space system programs since Ward released the code base.
Announcing PM 2.0 as "new" in 2009, missed the previous announcement of these processes in defense and space in the mid 90's. We were running virtual teams at the Department of Energy at Rocky Flats in 1996. Using crude tools no doubt, but the processes are nearly identical to those you describe.
I state again for clarity - any PM that doesn';t posses social networking skills - the red herring of "olde PM" is not a project manager. All those folks pushing PM 2.0 at PMI global need to come to IPM 2009 (PMI College of Performance Management) and see what the defense contractors have been doing for 10 years, that they are re-discovering in the IT world as "new."
"What has been will be again, what has been done will be done again; there is nothing new under the sun." - Ecclesiastes 1:9-14.
The PM 2.0'ers need to get out more, travel in the international construction and oil&gas world, visit Lockheed down the road in Sunnyvale, come to Denver and Colorado Springs and visit Space Command at the USAF and see what 2.0 things have been happening since the mid to late 90's.
IT is moving to PM 2.0. Good stuff. But you're coming late to the party. We're on to the next thing already.
"All has been invented before" comment does not bring much value into discussion. When you pick a call from your customer 1,000 miles away or share digital photos with your children in Facebook, think about the fact that there's nothing new under this sun. Maybe you should have just walked across the country to them instead. Walking was "invented" millions years ago.
I don't argue with the fact that internet, for example, walked out of DARPA. There's no surprise many innovations come out of government sponsored research, otherwise all those billions would simply be wasted. Defense industry was one of the most funded and had resources and people to innovate. If you personally participated in inventing some of that tech that improved the way we collaborate and communicate, kudos to you and big thanks to your teammates!
But the topic of this discussion is different. What we see around us is democratization of collaboration and communication technologies, when much more people suddenly have affordable and convenient access to something that was very complex and expensive just few years ago. Businesses need to know how to leverage these new opportunities in their day to day work to become more competitive. There's a shift in management practices happening across many industries now. Glen, if you are truly interested in the topic, I recommend you to visit Enterprise 2.0 conference or read some of the works referenced in this blog.
If DARPA or NASA is onto inventing something new that will walk into business environment 10 years from now and change the way we work one more time, we're all for it (unless it's a T-1:-). That's what they're supposed to do with their research funding, right?
Contrary to what you say, it's not all invented and it's not all old. We're yet to see further advancement of information access technology, and we're yet to see a whole new world of robotics and artificial intelligence. But that will be PM3.0, I guess;-)
Regards,
Andrew
The tone of the site and posts seems to be "look what I just discovered"
My point is you keep presenting things as new - possibly discovered by you in terms of usefulness. Looking around the PM space, most everything you speak of has been around for awhile, possibly a long time in dog years.
That's all. Maybe it's just the tone of the current generation, but there ain't much new looking back for age 62.
I see now PM 2.0 = New Tools for Managing projects.
Got it.
What you're proclaiming as the new version of PM is really just enhanced communication. Just as the PC thirty years ago was an aid to PM, not a revolution or version X.0.
http://www.wrike.com/projectmanagement/10/06/2009/What-Project-Management-2-0-IS-and-what-it-IS-NOT-Part-1
http://www.wrike.com/projectmanagement/10/07/2009/What-Project-Management-2-0-IS-and-What-it-IS-NOT-Part-2
Trevor,
The changes referenced in this post's original text are significant enough to be on the radar of many organizations. Businesses are created by people, and people communicate with each other to create value. So changes of this magnitude in the way we communicate do affect many businesses significantly. This is especially related in creative industries and information workers.
Now, this might not necessarily mean a lot to you. There might be different reasons for that: your business might not need it, or you might have been using PM2.0 practices under a different name already, or you might simply miss an important point here. Without knowing details of what you do and how you approach your job it's hard to judge.
Your claim of "something that works primarily in IT ..." is completely groundless. I try to avoid referencing our customers, so analysis blog doesn't turn into a sales pitch, but IT customers are not our biggest adopters. We have IT customers, but IT typically uses complex and expensive enterprise PPM solutions to manage their projects. IT infrastructure projects are quite different from software development projects, by the way, but that's another story.
Our customers and most of the readers of this blog are business managers and owners, without IT or PM titles. We also have many non profits and churches amongst our customers. They benefit significantly from the democratization of PM and collaboration tools, and find new and exciting ways to improve their personal and business productivity. They are far away from Glen's world of defense contracts, and judging by your comment might also be far away from yours.
Contrary to your point, it's not all minor and insignificant. There are plenty of organizations around us that may become much more productive with the use of PM2.0 tools and practices.
Regards,
Andrew
Add to that the missing context and domain of an IT project. Can $100M SAP roll outs use this approach? How about $200M health insurance claims processing system replacements, or maybe $100M worth of provisioning and billing systems for a RBOC? These are 3 examples I've worked in the past 5 years on the commercial side.
Also Andrew seems to be restating as new things that happened a few years ago. The information economy is started to get long in the tooth - going on 15 years now.
My real heart burn here is the suggestion that PM 2.0 replaces PM 1.0, when in fact the descriptions of PM 1.0 are simply BAD project management. This is a very common approach for product vendors or non-PM's when they try to convince people they have a better alternative to their BAD managers of the past.
All noble goals - but confusion BAD Project Management, with PM 1.0 is a critical mistake when trying to sell us on "new is better."
All you've done in the two reference links is point to PRODUCTS. Products are not project management. You're missing the fundamental processes of project management, replacing them with your version of PM 2.0 in the form of your own product pitch and calling it project management.
Your sales approach, while possibly catchy is not convincing to a Project Manager. Possibly a developer of software.
I see now it's not productive, since you're trying to convince the readers that your product is a replacement of good project management processes.
So the title of the Blog is a guise to sell the product not have a conversation about the needs of project managers - not developers - project managers.
I said IT projects because:
1) I have yet to see your approach used in any other (non-technology) field, and it sounds a lot like Agile
2) the IT/tech world is very fond of labeling every improvement "version 2.0"
"PM 2.0" has improved the communication and information availability, but it's also blurring/blending the roles of responsibility and distributing the accountability. This may work in some instances, but in most this approach would prove disastrous. As a friend of mine of fond of saying "shared responsibility is NO responsibility."
What you're describing is no different than PMBoK vs Prince2 vs Agile. Each has it's particular processes and focus, as does PM 2.0. Each has it's particular application. None should be mistaken as replacing 'traditional' project management. They're variations, not revolutionary ideas.
In you PM 2.0 world how do you maintain the integrity of the Responsibility Assignment Matrix (RAM), describing who is accountable for what deliverable on the project?
With the continuous rearrangement and recombining of the project personnel how can the project management know who is accountable?
I now that the business unit level does this all the time. But that is at the macro level of the business function. You seem to be suggesting here that the project needs to behave like the higher level business unit.
I'd aso suggest that from our experience in commerical and government enterprise level projects that the rearranging and recombining of relationships and personnel create chaos.
A classic scenario we encounter...
"Who's accountable for getting the monthly budget report for this project out the door 10 days after month end close," "Oh I don't know that team rearranged themselves last week."
The fluidity you mention is possibly useful at the lowest level of the organization. But any publically traded or regulated firm requires stability in the processes, procedures, deliverables and staff assignments.
To follow up Trevor's questions, could you describe the kinds of projects you've had success applying the theory:
Domain (banking, insurance, phrama, petro-chem, utilities, discrete manufacturing, government)
Context (NPD, Enterprise IT, construction, process improvement),
Size - staff size, span of control (personal, department, business unit, enterprise)
Budget - 1000's, 100's of 1,000's, millions, billions of dollars
With this approach have you been able to reduce variances in budget and time?
Here's a possible repositioning of the PM 2.0 topic.
Project Managers need to know a few core items:
1. How much will this cost and is that cost inside the budget?
2. When are the deliverables due and is the current forecast on or before that date?
3. What are the impediments to meeting the deliverable date and the forecast cost, and what are the activities to retire, reduce, or mitigate those impediments?
4. What resources are needed to produce the deliverables of the project?
Without these question being answered to the affirmative every period of measurement (weekly is best), no amount of 2.0-anything is going to help the project.
PM 2.0 at best is a mechanism to improve the operational processes once these questions have been answered.
Inverting the approach of having PM 2.0 and Web 2.0 be the starting point is a formula for failure on all but the most trivial of projects. By trivial in mean if the project fails no one looses their job.
For all projects where someone looses their job if success is not reached, the tools are 2nd order at best and likely 3rd order impact on success. Firms have 100's of millions of $'s of tools - even 2.0 tools - and still fail to deliver.
It ain't the tools...
Practioners of teams using Agile approaches can sometimes come across as saying that anyone who runs projects differently is doing it wrong.
And oddly enough, the same thing happens with just about all project managers who have seen some level of success, including myself.
When I look around I know there are programs and projects that have been doing many of the "PM 2.0" things for a long time. There are also a lot of them who have not been.
At any rate, I think we can all agree that in whatever domain you're in, we should all be striving for improvement across the board. It's one thing to look at the thought leaders and great practicioners and make judgements about progress there; quite another to look at the AVERAGE state of knowledge and execution across the board.
The great thing is that organizations are trying new things, adjusting and improving their existing methods, and adoption of best practices seems to be picking up in the mainstream. I like the push towards Agile and Lean, elimination of bad multitasking, and efforts going on with complex adaptive systems. I really like that lots of companies who's business is suited are trying it out, and many are succeeding.
I think we all have a long way to go before the AVERAGE becomes excellent, regardless of what methodologies or tools people may be using.
Josh Nankivel
http://pmStudent.com
Here's a direct quote from http://www.wrike.com/projectmanagement/10/07/2009/What-Project-Management-2-0-IS-and-What-it-IS-NOT-Part-2:
"Project Management 2.0 is NOT ... Replacement ...". So I'm not sure why you got an idea that I position PM2.0 as an equal replacement of traditional project management in traditional project management domains.
Glen,
Last time you argued against PM2.0 with comments on this blog and your own posts, you ended pitching your firm's "Deliverables Based Planning" process as a panacea. One could think that you try to generate publicity by trashing PM2.0 while pushing your own agenda. Please try to be more self-critical when you accuse people. I try to keep this blog very analytical and not product centric. Of course, for both of us work gives a lot of inspiration, experience and data, so it's impossible for two (work and blog) to have no connection. But as much as I can, I try to keep a good distance. For example, when it comes to cases which I reference in this blog, I first and foremost try to find ones from an industry and not from our portfolio.
Glen, I would respectfully ask you not to comment on my posts any further, as:
1) From time to time you get too personal. I don't want to reply at that level, but I don't appreciate just reading your comments and staying silent. The best way is just to stop the flame.
2) Deliberately or not, you try to reframe my writing quite often and I see that as very dangerous. I try to convey one thing, and it turns into another thing in your comment. I'd rather have people make impressions of my ideas from my writing, and not from your version of it.
That said, Glen, I appreciate your perspective and agree with some of your points. Thanks for that!
Josh,
Thank your for a thoughtful and respectful comment, I agree on all points.
My objection lies in the positioning as "Project Management" 2.0.
Not Software Project Management 2.0, not Project Communication 2.0, not Web-based PM 2.0...
You (or whoever named it) have applied it to the entire field of Project Management as if it's a next generation improvement or revolutionary idea, when in fact it applies to only a vary small fraction of projects, or, as Glen pointed out, parts have been in use for years already.
I also watched your interview with Bas de Baar at PMI Congress and noticed that you made no distinctions or clarifications when explaining it.
It's the, for lack of a better term, hubris, of taking something that works for you, and proclaiming it the next big thing.
And it confuses the issue. In a time when Project Management is needing to find ways to improve competency in the established methods and improve results, in my opinion, branding something as 2.0 that doesn't even acknowledge the existing processes only takes us in the wrong direction. We need Project Managers focusing on improving existing methods, not looking at the tools as a the solution.
My personal issue is simple. Your OP states there is no Moral Motivation for those using PM 1.0.
Your position - knowing or unknowingly - insults the 10’s of 1,000’s of PP&C leaders, program / project managers, and coordinators in every of industry who successfully deliver on their promises every day.
This statement is deeply uninformed, either from lack of experience or intentional misinformation. You owe an applogy to those of us who earned our living serving stakeholders of our programs.
I have unsubscribed from your feed.
Though I don't agree with you on some points, I think you're going the right way. From this comment thread I see that preaching innovations can sometimes be very challenging. :) Good luck!
Thanks for your point of view. It helps to see my own writing from another angle. I realize that the term (PM 2.0) may be a bit confusing, especially for successful traditional project management practitioners, like you and Glen. So I want to underline that I’m not calling to changing your ways, if traditional project management methods work perfectly for you. I do respect the body of knowledge gathered through years, as it helps many projects improve their completion rate and other metrics. In fact, I started my own career with drilling the PMBOK.
But as I gained more experience in managing projects, I started to realize that there are cases when a more disciplined approach would help, but the traditional way of managing projects wouldn't be that helpful. I mean you can alway try to fit one thing into another. For example, in software world, when "agile" term become trendy, everybody suddenly become "agile" overnight and you had an agile rational unified process, which was kind of oxymoron (at least those days). Anyways the point here is that while you can sometimes stretch processes and terms, sometimes another angle is a better approach.
This is where Project Management 2.0 can be helpful. It’s about embracing the innovation when the traditional methods don’t work well. By the way, I absolutely agree with your point that we should be focusing on improving existing methods.
As of offensive nature of "2.0"... A lot of my friends, who ran successful (and sustainable) dot coms didn't find "web 2.0" term offensive or targeting them. "Enterprise 2.0" term coined by Harvard Business School (now MIT) professor doesn't try to offend and doesn't offend execs of all enterprises around us. So I never thought of the fact that applying the same pattern to the term "project management" would be offensive. That said, it looks I've been wrong. Don't take it offensively. 2.0 just means the use of principles behind Enterprise 2.0 and applying them in the project management context.
Once again thanks for commenting. Your ideas gave me inspiration for my future post, where I’ll try to analyze the role of tech in Project Management 2.0.
Glen,
See my comment to Trevor above and take it easy. I never had an intention to insult you or anybody else with the term.
Everybody,
There's been a nice discussion on the topic at http://pmstudent.com/its-great-unless-you-screw-it-up/ post's comment feed.
Thanks for clarifying. While I still see some differences between how you're positioning PM 2.0 and the "2.0" examples you've cited I can see what you're trying to do.
Yes, improved communication flow is a plus, as is information exchange. As long as it's done in a responsible, thought out manner. Otherwise, after a certain point, the signal changes to noise. And the more you 'democratize' project management and distribute decision-making, the more you remove the 'management' from project management.
"the more you 'democratize' project management and distribute decision-making, the more you remove the 'management' from project management."
Distributed decision-making is not a bad thing, and it's not necessarily a PM 2.0 thing either although new technologies may help enable some of it, especially with remote teams.
I also don't equate decision-making power to management. It's part of it, and I would say a rather small part of it....at least the way I manage teams and projects.
Having worked as the lead PM and also the planning & controls manager at different times as a federal contractor in the aerospace industry (satellite remote sensing) I can tell you it was very effective for my team to make many of the decisions on our project, and have input into the larger decisions as well.
I make decisions by myself and/or without consulting my team only as a last resort. For most decisions on the project I trust my team and delegate responsibility to them. When I step in on one of their decisions it's to be a part of the discussion, not to dictate.
Perhaps there needs to be a discussion on what 'management' means, but to me it's mostly about supporting, facilitating, guiding, removing obstacles, etc. You also have to hold people's feet to the fire when it comes down to it but in my experience there's little need to do that if you're doing all the other things right.
Josh Nankivel
http://pmStudent.com
I'm not suggesting that distributed decision-making is a bad thing, within reason. Nor am I equating the 'power' to make decisions with management. I'm talking about the 'responsibility' to make those decisions.
But as always, context is king.
I work in the construction industry, with multiple projects in multiple cities (and sometimes states.) I can't be at all of these places all the time. Do I trust and allow my Superintendents to make the right decisions about how to build the project? Absolutely. Do I allow them to make decisions regarding contracts, change orders, scope changes or schedule changes? No. That's my job. I work with them regarding any requests and get their input, but ultimately the decision to proceed (or not) is mine. I'm the one financially accountable for the success or failure of the project. If we're late, over-budget, or have poor quality, no one is going to talk to my Superintendent or team/crew about it. It's my fault.
My point was, the more you distribute 'project' level decisions (which is how I read Andrew's comments), the more you're diluting the responsibility for those decisions.
And you're absolutely correct, management is about delegation. It's also about making decisions and taking responsibility for those decisions.
That's a very insightful comment, which is 100% aligned with my thinking.
Also, here is some thinking related more to overall discussion, not specifically to the comment by Josh:
Just to be clear - I don't care whether it's called PM2.0 (my term, I guess), Leadership Level 5 (Collin's term), "good project management" (Glen's preferred term, I guess), "collective intelligence", "wikinomics", "proper delegation" or anything else. I call it PM2.0, but I don't claim a royalty over this stuff. All good management practices are common sense and should be that way. What I care about is seeing more of that common sense in real-life organizations around us, and that's the primary driver of this blog.
While Glen thinks that we're already at that nirvana stage and everybody is already far beyond this knowledge, I've seen too many cases when it's not the case, for one reason or another (people/processes/tools). At the end of the day, not all companies and organizations are performing equally well. Some are leading their space, and some are failing miserably. I see it as a goal of every single manager to analyze other organizations' successes and thoughtfully apply successful management patterns to their organizations. And although good management practices are common sense, I don't feel like it's all been said, done and invented. Management discipline is a tricky beast. There have been many times when I thought that a particular idea is boring, or obvious, or that I've been following the same principle for a long time. Then years down the road, after I acquired a certain experience which gave me certain lenses, I started to greatly appreciate things which I previously deemed as obvious.
A typical example: You discuss the importance of focused strategy with your board, or read a book about strategy, etc. And you think "Yeah, that's me, and, man, it's obvious. Why are they even spending time on talking/writing about that?". Then time goes by and you get that "Aha" moment and you think "Oh, man, now I get it. I though I was having a very focused strategy, but in reality I was distracted and spent too much time on pursuing irrelevant stuff. I should have been focusing more and pursuing that focused strategy harder with much more ambitious goals". I don't know about you, but I had that not only for focus, but for delegation, for differentiation, for repeatable sales process, and many other things. I believe, it's a never ending journey or learning management, the art part of management at least.
Besides, there's always space to improve productivity, and sometimes when we're about to think that we're at the edge where improvements are only marginally better, the next innovation wave is coming and shaking our beliefs. We've all seen those boring mp3 players with sloppy sales figures which we didn't care much about. Then Apple's iPod came to market and transformed the whole industry.
It's a job of every manager to at least try to deliver Google/Apple/P&G/Toyota type performance to their companies and to get fun along the way.
So rounding things up, while I see a lot of common sense in the PM2.0 area, it doesn't make it less exciting for me, quite the opposite.
"While Glen thinks that we're already at that nirvana stage."
Nor would I ever say that.
That would be foolish, please don't be one as well.
"Common Sense is neither common nor sensical. Much of what passes for common sense is not based on any underlying principle it’s just anecdotes that have worked for the current situation." - Benjamin Franklin
This may be the basis of my disagreements with the notion of PM 2.0.
Thanks for revealing that understanding for my Andrew. It's a visceral response on my part based on the approach you are taking to this topic.
It looks like now we're quits with putting words in each other's mouth;-) Kidding aside, I'm glad we're on the same page. Hopefully, we won't misinterpret each other going forward, as it never feels good on the receiving side.
On the "common sense" comment, I'm not sure if I understood your notion of disagreement with PM2.0, and I'm not sure why there's any disagreement at all. As I said, I don't care how you name it, so there should be no reason for disagreement there. If we go beyond the name (see the comment by Josh above, for example), I'm not sure what would you disagree with in there as an experienced project manager.
I get the sense when you describe how PM 1.0 projects work you mat not have experienced projects where the core principles have been applied successfully.
I say this from your description of "red tape," bureaucracy, "command and control," and other attributes deemed undesirable.
While there are many examples of troubled project improperly applying the core principles of project management - http://herdingcats.typepad.com/my_weblog/2009/11/pm-20-link.html - lists a sample of the questions that must be answered by any project method.
At the same time I've seen and worked several project in the past 2 years where agile and the supporting tools have led to failure, and we've had to rescue the product development - "getting to green" using the very methods you suggest are undesirable.
This leads me to the "common sense" quote. Developing processes based on anecdotal evidence has been - in our domain - unsuccessful.
As a process development leader (Michael Hammer trained), it is problematic to use anecdotes to drive process development in the absence of executable principles. The principles of what you might refer to as PM 1.0 have been shown to be highly effective in a wide variety of domains when applied corrected by trained and experienced project managers.
I'm not sure we're on the same page. I consider tools to be the least important part of project management by a wide margin. I say this from nearly 30 years of product development (HW and SW), project, program, and systems management. All of that experience is anecdotal in the absence of you personally witnessing those projects and their "close out" reports.
Each of these projects used the core principles of project management - in the absence of tools. Many recent ones used agile software development for the engineering portions, embedded in a formal project management method.
http://www.niwotridge.com/PDFs/AgileMethodsforERP.PDF
http://www.niwotridge.com/PDFs/ADC%20Final.pdf
are 2 of many examples.
To review, my primary issue is the approach of declaring the past as undesirable in the absence of recognizing the poor application of the proper principles, while proclaiming "the king is dead, long live the king," - PM 1.0 is dead, PM 2.0 is the "new" way.
Without the principles based approach, I have trouble connecting the dots, when new ideas are presented. It's personal. But in the world I and my colleagues work - enterprise IT, large construction, defense, space, energy, petrochem - these principles have served us well. Agile and tools have their place in specific domains and context, but without defining those boundaries of applicability, the benefits in units of measure meaningful to the buyer.
I know you may see this has a less than desirable position for those in the small project IT world. (Large IT for us is SAP/PeopleSoft/Siebel class applications).
But in the absence of an "applicable" domain, the PM 2.0 discussion is difficult for me to see the benefit.
When you say...
"It's a job of every manager to at least try to deliver Google/Apple/P&G/Toyota type performance to their companies and to get fun along the way."
Would you expect managers at CH2M Hill, Lockheed Martin, Arizona Public Services (Nuke services), Yucca Mountain (DOE), Newmont Mining and the like?
I'm curious if there are any bounds to the statement above?
Yes and no.
Yes, because any statement can be stretched. For example, one can say that heavy processes fit any organizations, even the tiniest ones, it's just a question of fidelity or artifacts (your argument PM2 discussion at PMstudent). Same here, one can argue that every manager should strive for high performance, quality and productivity in any environment, and that its manager's job to adapt those goals to his environment.
No, because one can argue that the cause of mistake in Google and nuclear factory are dramatically different, which changes many dynamics.
In this case it's more "yes" than "no", because the statement that manager should strive for his organization to be the best in his field is not implying any particular process or the lack of one. We don't want subpar nuclear factories, do we?
On the PM2.0 applicable context.... What's the failure stats for Siebel and other heavy ERP implementation?:-) Was it something like 50% several years ago? Taunting aside, even if there is no small project context around you, there are tons of small projects in the world that I live. I'm not sure why you keep saying that all that exists are mega projects like ERP and nuclear factories. I've already cited you some stats before, like the fact that half of employees in US work for small business. And even in large businesses there are tons of projects like preparing for a trade-show, or launching a new small sales branch, etc., at least in my world. We've got thousands of clients ranging from marketing departments in large corporations to churches. They aren't working for defense or NASA, but that doesn't make their work less exciting or important.
I see your arguments for large industrial projects, but I don't and won't agree with your point that there are no other projects or that the rules of the game are same for building the power factory and for creating a marketing brochure.
Traditional PM was built for and works best on the left side of the scale. PM2.0 works best in the middle, where traditionally you would see no formal project management and oftentimes not even a formal process. GTD and other personal productivity methods works best at the right end. All of three overlap seriously, so it's not black and white, but rather a gradient.
This also goes back to Trevor's question of "replacing" traditional PM. It's not replacing, it's extending.
Glen, Trevor, thanks for helping me crystallize this through your critique. It's a typical "curse of knowledge" ((c) "Made to stick") case when something was obvious to me, and I didn't dive deep enough into it, potentially causing a confusion. I've tried to (see my "what PM2.0 is not" post), but I think this is a much more clear description. I'll follow-up with a post.
When you draft your picture it might increase it’s credibility if the data came from actual projects in your area, with a sampling technical to assures separation of the distribution value – this is a cumulates assessments to decouple the sample space from autocorrelation errors. Otherwise the “anecdotal” error enters in the outcome analysis.
I participated in a research project for PMI (local chapter) about the distribution of project "size." Size has several meanings. Dollar value; staff size; number of partners; locale in the Denver metro area; business domain – commercial IT, building, infrastructure, government IT (civil), embedded, social, Telecom (we have Qwest, Time Warner Telecom, ComCast Cable; commercial product development; government product development (weapons, aircraft, launch vehicles); and a few I’ve forgotten.
A pretty good distribution of domain (business) and context (organic, external products, IT, service or product delivery support). A distribution test (Kolmogorov Smirnov test) showed acceptable sample space and reasonable sample density (no outliners and under sampled populations)
Some distributions varied in unexpected ways. There were no "normal" distributions in the sense of Gaussian symmetric forms with the expected 1st and 2nd standard deviations. There are many asymmetric distributions. And a couple of bimodal distributions.
What was surprising in the bimodal distribution was the peak on the left of the mean (small dollar) and the peak right of the mean (moderate sized). Moderate sized in dollars was > $100K but
Because of the locale and the timing there was a skew to large projects – I–25 rebuild took 5 years, the DIA airport and the entire infrastructure, the local launch vehicle and satellite business, the expansion of Buckley AF Base. At the end of the survey period there was a boom in building in Denver LoDo (Lower Downtown). Add to this, waste water plants for expanding cities and of course we counted the residential building at the “contractor” level not each house.
If you focus only on IT the distributions are inverted. Many smaller projects with the mode to the far left and a long tail. This is what would be expected if only IT is your view is IT. But there was a sub distribution between large corporations – we have many head quarters in insurance and finance. When you look at retail, and the general business environment, the skew is much larger – very long tail.
The survey did not collect projects without a “project manager.” No assessment of the method. That would be interesting to try and connect things like project success to project method.
Glen B. Alleman
VP, Program Planning and Controls
Region 6 Co–Director PMI A&D SIG
So in response to the Siebel and ERP failure rates, it depends on the domain and context. The poster child for Seibel deployment here in Denver has a nearly 100% success rate - that's why they're the poster child.
Keen has nearly the same success rate with SAP rollouts in the defense business.
You need to have a context and a domain to respond in any meanigful way.
My question to the statement "It's a job of every manager to at least try to deliver Google/Apple/P&G/Toyota type performance to their companies and to get fun along the way."
didn't seem to get a definitive answer, so I take it there may not be a definitive answer?
I'd conjecture that managers at the firms I mentioned (since I've be present as a manager and worked with managers there) wouodl say NO. That is not their goal to deliver in a Google manner.
I'm coming to understand your "world view" is IT. Where possibly the activties experienced in IT are applicable to domains outside IT. I'd stringly suggest - as Trevor has - that this is not the case. The behaviours of commerical IT project teams would be considered unacceptable on defense IT systems deployment. For example rolling our an ERP systems for the Missile Defense Agency (a program we're on) in the same way the ERP system is being rolled out at a health insurance firm we also work is night and day.
Context and Domain are critical to any discussion beased on evidence rather than ancedote.
On the ERP failure rates, a quick Google search returns http://www.it-cortex.com/Stat_Failure_Rate.htm
On the "job of every manager" thing, last time I checked, P&G and Toyota didn't count as IT businesses.
On the definite answer - the world isn't black and white.
Cheers.
A Blog post would a start, but not sure how "actionable" once the concept is understood. That's the purpose of the Franklin quote. Understanding a concept is necessary but not sufficient for the business value to be delivered.
There are several similar examples in places like Cross Talk, DAU AT&L (Defense acquisition University). Since the government is the largest consumer of IT projects of all sizes - very small ($10K) to large ($billions). The www.fbo.gov (with all released government contracts) is a good source of the statistics for projects.
The provided link is getting a bit "long in the tooth," and doesn't have any context of domain. There are certaintly many examples of ERP failures. Just as many or more examples of success. The core problem with that site and the Standish-style reporting is they are statistically sound since they don't model the population statistics from which the samples were taken and don't have credible questions - any off cost, off schedule or change in requirements counts as a failure.
But other than that, notional (Blog examples) discussions certaintly establish the concept of asymetric distirbutions. No PhD required to move to the next level though - just good engineering practices.
a. Team participation in project planning is a new innovation, not previously encouraged or practiced;
b. Collaboration is not encouraged under traditional project management;
c. Prior to PM 2.0 there was no focus on delivering business value; and
d. PM 2.0 is about achieving productivity gains.
The above claims are so absurd that only repetitively hammering them into public consciousness can explain why they need to be discussed at all.
Let me say is very simple and explicit words. There is nothing new in PM 2.0 that has not already been practiced before. The only thing PM 2.0 can take some credit for (albeit in a very limited way) is the fact that web 2.0 technologies now enable the type of collaboration and communication that were simply not available before. Otherwise, there is nothing in PM 2.0 that suggests a different way of managing key aspects of projects. Not a single thing. I am yet to see any shred of evidence to demonstrate any of the claims made by PM 2.0 promoters, but don’t hold your breath for too long, as it will not and cannot come through.
Cheers,
Shim Marom
Those holding the concepts 1,2, and 3 needed to be in Building 06, One Space Park, Redondo Beach, 1978 when TDRSS Inertial Upper Stage flight controls were being coded.
Thanks for the reality check
It's strange though that some people take it to heart and continue posting even after they've unsubscribed from the feed ;)
Graham's applied network analysis techniques to both individuals (a la trad SNA) who could be project managers and also dependencies between projects (which is more innovative).
Meanwhile Laurie Lock Lee & Cai Kjaer have combined value network analysis with their own partnership scorecard - which is a way of looking at the exchange of intangibles between different roles. Lots of applications to complex project environments: http://www.optimice.com.au/services.php
While at IBM, I was part of an abortive attempt to apply SNA to large-scale "business transformation projects" - to ameliorate some of the more brutal organizational slice n dice efforts. It didn't work - seen as too 'fluffy' by the engineers...
This would be a powerful tool for our energy, aerospace and defense programs, where Integrated Product Teams (IPT) are the norm. Thanks for the link.
Interesting reading, thanks. I wonder if social capital maps are more reflective of existing links, of if they are used to promote weak links which many E2.0 proponents are fond of.
Cheers,
A.
www.onlineuniversalwork
www.onlineuniversalwork.com"
www.onlineuniversalwork.com