Project Management 2.0 – a fool with a tool is still a fool
Many years ago I worked with an Information Engineering guru who specialised, amongst other things, in the delivery of high quality data models. Those familiar with the art of data modelling will recall that they can become quite large and complex, and as the technology evolved, software solutions, called CASE tools (where CASE stands for Computer Aided Software Engineering) were progressively used to ease the pain of recording and maintaining these models. As often happens, the introduction of these software solutions made it easier for Information Engineering practitioners to claim analytical capabilities they did not really poses, until one day my guru friend made the following profound comment: A fool with a tool is still a fool. What my friend was trying so successfully to articulate was that just being able to operate a piece of software does not turn you into a subject matter expert. To be able to use the software effectively and efficiently require experience and this experience does not come packaged in the box.
Why am I mentioning this?
Over the past few years, commencing probably with Chris Lynch’s article from September 2007, there have been constant discussions regarding the merits and content of this new wave methodology. Driven further by consultants eager to exploit any new buzz word that comes their way, this now seems to have grown into a reality that, in my mind, should never have existed, as I will detail below.
Before explaining why I believe this concept should be put to rest, let me quickly summarise what PM 2.0 is meant to be and what its key principles are:
At the core of PM 2.0, as formalised by Chris Lynch, lies the claim that project work is now undergoing cultural changes and that rather than projects being managed by a single all powerful project manager, they in fact become a collaborative effort where multiple players take control over the destiny of the project using new web based collaboration tools. So in a nutshell, PM 2.0 is about collaboration, whereas the old traditional Project Management 1.0 is really just about control.
Once the idea became a public domain, various authors and professional thinkers have further expanded the concept and have injected new and more extreme views, whereby turning away from the collaboration vs. control argument and have used it as an evangelical tool in their Agile vs. Traditional software development debate. A good example is Andrew Filev’s “the Agile Origins of Project Management 2.0″. Andrew’s main argument is that one of the basic principles behind agility is the “constant interaction and collaboration between managers, team members and stakeholders…” and this concept has become later “the background for Project Management 2.0″.
You get the point? The move from PM1.0 to PM2.0 is no longer described in terms of progression from a centralised control to a collaborative effort; it is rather described as a progression from waterfall based software development methodology to an Agile based software development methodology. In summary, according to the above, PM 2.0 = Agile.
Let me summarise my main difficulties with the PM 2.0 campaign:
|
PM 2.0 claims that: |
But the reality is: |
| Project Managers view PM as a way to control and manage a project using task lists and Gantt charts. | Using tasks lists and Gantt charts are just few of the many tools and techniques Project Managers use to manage their projects. Just look at the Project Management Body of Knowledge. There’s much more to managing projects than having some task lists and Gantt charts. |
| At the heart of the PM 2.0 is collaboration with the view to defining projects as the work undertaken to achieve a business objectives. | Project Management has always been about the work undertaken to achieve business objectives. Otherwise, why would you do it? |
| Traditional PM is all about control. | Traditional PM is mainly about Control, Co-ordination and Communication. Do I really need to mention the fact that a large proportion of the PM’s time is spent on communication? |
| Using collaboration tools teams can achieve business objectives without the need to employ a traditional PMP. | Before using the collaboration tools someone would have had to document the scope of work, agree what the deliverables are, describe what Done looks like, agree timeframes, obtain budget, etc. Does anyone really believe that teams can just jump in and use the collaboration technology without knowing upfront which way they’re going and how they’re going to get there? |
| PM 2.0 = Agile | This one really annoys me, for a number of reasons:
|
This takes me back to my opening statements. You could use Web 2.0, Office 2.0, Enterprise 2.0 tools and applications to your heart’s content. At the end of the day, though, if you don’t know what you are using these tools for and have got no point of reference of why you are doing what you’re doing, what your target destination is and how you intend to get there, then all you’ve got is just a set of tools. And, as we’ve learned earlier, a fool with a tool is still a fool.
I value your opinon, if you have any thoughts on the above please join in and share with others!
Related posts:
What a wonderful post. I never could have said this myself.
Here’s my added thoughts…
http://herdingcats.typepad.com/my_weblog/2009/09/no-fool-with-a-tool-is-still-a-fool.html
Thanks for the great words
Cheers mate, thanks.
Shim,
I have to disagree with you. Although you do have some valuable points in your post, I think you missed one important thought: agile software development is taken as an example of a bottom-up management approach. We all know that project management is not only about software development. There are lots of other industries that run projects that have to be managed. I’ve read Andrew’s posts and also checked out his slideshare presentation and I got the idea that when he says “agile” he means “agile organization” and “enterprise agility” and not agile software development. There’s a huge difference here.
Matthew,
Andrew mixed project management, business management, and software development all in one post.
Aside from the unsubstaniated claims in the graphic, it’s not clear what Andrew was trying to say about PM 2.0 other than forms using the bottom-up approach are somehow better off.
But he failed to state that all those firms using bottom-up operate within a business and proejct governanace model that is top-down. By skipping over that “little detail,” the suggestion is PM 2.0 is the “next big thing” in management theory – implemented by his tool of course.
PM 2.0 has many issues, not the least of which it is not connected to the core principles of project management. At least not in Andrew’s mind.
In the end I see Andrew’s approach as a common one – confusing software development methods using agile with project management methods using “some” agile.
In the absence of a framework for governing projects and the business processes they enable, the bottom up approach – while apealing – has limited traction in a real corporation.
Thanks Matthew.
I’ve gone back to Andrew’s to double check my understanding of his stated points. Andrew is quite explicit in his view that “The idea of constant interaction and collaboration between managers, team members and stakeholders is not new, however. Here I want to write a few words about the origins of this idea, which later became the background for Project Management 2.0.” He then, in the very next paragraph, goes on to say that “The idea of constant dialogue in project management surfaced in 2001 as one of the principles of so-called agile software development and is described in the Agile Manifesto. According to evangelists of agile methods, cooperation is crucial for the success of a project.” This is clearly saying that the underlying foundation of the PM 2.0 concept has already been conceived as part of the Agile Manifeso.
Cheers, Shim
Glen, not sure why, but there seems to be some sensitivity amongst Agile proponents for anything that might sound as criticizing the Agile concept. What we are saying here, however, has got nothing to do with Agile and is rather a statement of concern regarding a possible confusion between the what project management is, compared with tool and techniques that project managers might use as part of their job. Agile is a great methodology, and using it in the right environment and under the correct circumstances can bring in the expected benefits.
My opinion some new to the agile message are on the “early adopter” part of the Moore curve. As such any criticism or assessment is seen as a challenge. Those agileist who have moved further to the right (Jefferies and Sutherland) have also moved beyond the gut reaction to criticism response and into the “let me tell you how you can improve your lot in life.”
Folks like Andrew still use extremist words – “no moral motivation,” and “our product is the nest in the world” type phrases. This was the approach in the early days of XP. I used to travel in those circles, speaking at XP and Agile conferences. I took another path for my work, but I remember completely over the top claims of how XP would save the world and put organized IT departments out of business – uh probably not.
But there remains a deep confusion about writing software for someone elses money inside a corporation that is subject to governance – both corporate and IT. And essentially writing software for your own project.
Add to that the confusion between software development and project management processes. Then add the misunderstanding about how corporation actually work. Independent of all claims that IBM has adopted agile and is a bottom up shop. I can assure you that this is not true in the way Andrew wants us to believe. I say this from direct hands on talk with my next door neighbor, the neighbors (3) up the street and former neighbors who have been transferred (IBM means I’ve Been Moved). All work for or manage large chuncks of IBM Global Services here in Boulder, Colorado.
Agile processes are certainly used as a software development process – IF you consider RUP agile. Bottom Up management has ALWAYS been a large corporation engineering development process for the simple reason there are too many people – they have to have small groups bottom up management.
But the customers of IBM GS are billion dollar firms, mega-cities, and the federal government. Strong Top Down, hierarchical, command and control management still resides at the top for governance, business development, and large scale decision making.
It would be complete nonsense to have a firm the size of IBM GS “managed” bottom up in the way Adrew wants us to accept. It just ain’t so, and he’s welcome to come to Boulder and meet the managers and take a tour to see how they run their many multi-million dollar business units.
[...] see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. [...]
RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR
RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This applies to test automation as well!
RT: @agilenature: RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR Me ecntanta la frase!
RT @agilenature: RT @shim_marom: Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR
RT @lanettecream RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This applies to test
RT @shim_marom: RT @lanettecream RT Project Management 2.0 – a fool with a tool is still a fool http://bit.ly/1l5kZR I love it! This a …
Shim,
I have to disagree with you. Although you do have some valuable points in your post, I think you missed one important thought: agile software development is taken as an example of a bottom-up management approach. We all know that project management is not only about software development. There are lots of other industries that run projects that have to be managed. I've read Andrew's posts and also checked out his slideshare presentation and I got the idea that when he says “agile” he means “agile organization” and “enterprise agility” and not agile software development. There's a huge difference here.
Great point, especially “A fool with a tool is still a fool.” But regarding tools, such as collaboration, they are both an opportunity and a necessity. For example, not long ago, multi-national teams employing a lot of offshoring did not exist. However, with the internet infrastructure and the collaboration tools that have evolved with it, new opportunities have arisen to become more effective. Maintaining competitiveness has also made such tools a necessity in many situtions. But the basics of project management still remain the same, and “A fool with a tool is still a fool.” remains a valid statement.
Thanks John.
Yes, latest Web 2.0 collaboration technology has provided a plethora of tools all aimed at making our lives easier. I hope (although not entirely convinced) that organizations will use common sense in determining which tools they allow / encourage and which ones that stir away from as some of these tools are good and some are time wasters. I’ve seen a number of blog posts promoting so-called social networking tools as project management enablers. I use social networking personally but would not encourage allowing these tools in the workplace as they add no value what-so-ever to the well being or productivity of the organization. Technology should be used when appropriate and not just for the sake of using it as it is only the means to an end and not an end in itself.
Leave your response!
You must be logged in to post a comment.
My Recommendations
Recent Posts
Recent Comments
My Latest Tweets
Blogroll
Categories
Copyright © 2010 quantmleap ® All Rights Reserved | Powered by WordPress | Infinity Remix theme by Tips and Tricks HQ
Log in | Comments (RSS) | Entries (RSS)