I have recently read a blog contribution by Craig Brown from BetterProjects, titled “On Project Management Blogging“. Craig was discussing the recent explosion of Project Management related blogs and the value of continuing blogging in  this, seemingly, over crowded environment.

Excellent question.

Having been wandering about this very question myself, and further looking for a value proposition justifying the time and effort in maintaining a viable, constructive and (hopefully) interesting blog I’ve reached the following conclusion. The purpose of publishing a blog is to advance the cause of project management by increasing or contributing to the advancement of the knowledge area of this domain. This cause can only be achieved by communication and discussion. I therefore made the following personal blogging resolutions:

  1. I will become actively involved in discussions taking place in other blogs, elaborate on my opinions and respond in detail to other comments and questions.
  2. I will keep on using Twitter to promote other blog posts on the strict condition that any recommendation I make to other posts will be done after I have read the post and decided that this post is worth my RT recommendation.

Over the past week I contributed to and commented on a number of blog discussions:

The PM 2.0 debate

Geoff Crane of Papercut Edge published a post regarding a Twitterview he was involved with, alongside two other project managers. This post grabbed the attention of Glen Alleman who went on to question to logic behind conducting an interview using this medium. His conclusion was that “Serious adult communication seems to require a wider channel.” What really turned the heat up was the apparent connection between this interview, limited in scope as it was, and the PM 2.0 debate. From the discussion in Glen’s site, and a subsequent one carried on in Papercut’s site it became obvious that the issue wasn’t quite the twitterview event in itself as much as the conceptual implications that could arise from it.

My view is that the use of a limiting tool like Twitter to conduct an interview is an indication to a generational philosophy according to which the tool makes up the end (as opposed to being the means to an end). From the point of view of ‘let’s have some fun and explore another technology for conducting an interview’ perspective (as highlighted in a number of comments to Geoff’s post), it seems like a non-issue, as these comments were taken from the narrower perspective of the issue.

From my perspective (which I believe was also shared by Glen Alleman) there is a bigger fish to fry here, as it is sympathetic on a bigger issue, namely the propagation of the PM 2.0 idea, based on a desire to make use of social tools, irrespective of whether or not these tools are fit for purpose. This discussion is far from over and I expect more will be written about it in the months to come.

PMP Certification

Eric Brown discussed the value in having a PMP certification and more specifically the importance of having a PMP certification when looking for a Project Manager candidate. My two cents, when looking at PM candidates, my selection criteria (amongst other things) will be:

1. Relevant experience and PMP
2. Relevant experience and no PMP
3. Just having a PMP – mmm…not good enough.

The Chaos Report

Richard Patrick (The Hard-Nosed Project Manager), based on data collected from recent Standish Chaos reports, concluded that projects’ success rate has flat lined over the years. In my comment on his article I made the point that “I’ve been struggling to understand the Standish Chaos report for quite some time now. It seems to me that something fundamental is wrong with this report, even without taking the scientific approach used by Glen to explain why this report is lacking from the statistical analysis point of view. From my simplistic perspective things are much clearer. In any human endeavor there will always be a line over which further improvements will require infinite levels of resources to attain.

The Standish report (at least as far as I understand the psyche behind it) assumes that we as human being, given our limited resources, can achieve much higher success rates than currently obtained. Given your observation (which I tend to agree with) that the success rate has flat lined over the years, I conclude that we have reached that level beyond which far greater resources will be required in order to get that line any higher. Having said that, the problem with the Standish report is not that it is statistically or methodologically incorrect, the problem with it is that it assumes that we are lacking in our project delivery, whereas the truth is that in the main our delivery methods are valid given our limited capacity to do any better.”

In all honesty, Richard thought that my approach, as stated in the last sentence in the previous paragraph, was somewhat defeatist, as we can do better, as demonstrated in space exploration projects. My response (to this justified query) was that “in the main most projects are not run as space exploration projects, the reason being that in most traditional projects the cost of failure will not necessarily translate to massive explosions or costly loss of human lives. In that respect the point I was trying to make is that in most projects there is an acceptance of potential failure by the virtue of limiting budgets. So its not that we can’t do better (as I stated earlier), it is just that in the main we look at our opportunity costs and make a decision to take the risk of failing. Had our level of tolerance been adjusted to that applied to space exploration projects we would not have nearly as many ‘failed projects’ as we seem to experience now.”

Project Failures

Steve Romero from the CA Community wrote an interesting article about Common IT Project Management Mistakes. One point in his article that really caught my eyes is where he argues that when it comes to determining the project’s success factor then out of the Schedule, Cost and Performance factors, it is OK to determine the success based on two of these factors only. That’s a bold and brave statement (one I haven’t quite seen before). This requires a serious mind shift as for most project managers (and this is also reflected in the Standish Chaos Report) a success means meeting all three factors; Schedule, Cost and Performance. Clearly, this is unattainable as nothing is life is achievable 100%, and projects (despite all other claims) are just part of life! So thumbs up to Steve on his article.

More comments…next week.

I value your comments, if you have any thoughts on the above please join in and share with others!

One of my biggest issues with the ‘Project Management 2.0′ concept is that it is conceptualized around other ’2.0′ concepts like ‘Web 2.0′ and ‘Enterprise 2.0′; both of which are terms that emphasis and denote a technological dimension relating to human interactions. In that context, and following the same logic, PM 2.0 is meant to be denote the application of ’2.0′ technologies to enhance project management capabilities.

A recent article in the Harvard Business Review analyzed the reasons behind the failure of western Intelligence Services to prevent the recent terror attack on an American Airline. The article states that the whole episode represents a “massive failure of collaboration among intelligence and governmental officials”. The facts known about this terror attack are sufficient to conclude that although there was sufficient information to enable an effective prevention of this incident, it lacked nevertheless the final  touch of connecting all the dots and consolidating the known data into effective management information.

The author of the HBR article concludes that despite the US (and other countries) investing in IT systems aimed at supporting the above detection and alert systems, it lacked nevertheless the investment in cultural change necessary to ensure that information is not only collected but is also shared. This, the author says, is a matter of cultural change, one that will encourage and foster not just collaboration but effective collaboration.

An interesting case study is cited by Professor Morten Hansen from the INSEAD institute, where SONY failed to launch an effective competition against the Apple iPod and, despite having a collective know-how and expertise in all aspects of designing and manufacturing an iTunes-iPod hybrid, “it turned out to be a failure because the individual departments did not work in unison”.

In an earlier post I have stated that ‘a fool with a tool is still a tool‘. The premise of that post was that a tool in the hands of an inexperienced user, will not generate the desired results. The observations cited above add another dimension to this claim. they highlight the point that even when used by experienced users, desired results are still dependent on other organizational factors, primarily based around cultural adaptation.

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:

  1. Agile is NOT a PM methodology.
  2. Agile does NOT imply collaboration tools more than any other development methodology.
  3. Agile is, primarily, a software development approach. PM 2.0, when taken literally, is a neutral approach that can be applied to all types of projects.

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!

%d bloggers like this: