How PM disserves IT

 

Back in August of 2008 I wrote and presented a webinar for PMI®’s Information Technology Special Interest Group on the topic of integrating Earned Value techniques in Agile/Scrum environments (“Stop Those Divorce Proceedings!”). A few years prior to that, one of my PMNetwork columns, “Poor Man’s Project Controls,” made similar points about the unnecessary baggage that has been added to what is considered valid Earned Value Management Systems. And, years prior to that, I presented a paper at PMI®’s annual conference in Boston, entitled “The Bottoms-Up Myth,” about the absurd business practice of mandating a re-estimation of a project’s remaining budget, adding that figure to its cumulative actual costs, and then pretending the resulting Estimate at Completion had intrinsic value.

While the first work (obviously) was aimed at IT projects specifically, the latter two were not. What they all have in common is that they addressed parts of legacy project management that many so-called experts insist must be part of any valid PM information system or approach, but which, in fact, detract from the overall business models of the project where they’re applied, as well as their owning organizations in general. And those are just three examples – there are many, many more of instances of techniques and practices that are considered by the PM intelligentsia to be absolutely vital to “doing” project management correctly that are singularly counter-productive, and have no place in general PM approaches, but are even less appropriate in IT projects.

Consider the standard approach to configuration management. The stodginess of the whole process of identifying the needed change, capturing its scope, estimating the new budget and schedule, writing it up in a Baseline Change Proposal, and getting that BCP approved by the appropriate stakeholders is the probably the single strongest reason that Agile/Scrum was developed in the first place. Think about that – the traditional approach to a major aspect of project management was so moribund that an entire adjunct specialty line of project management was developed, just so IT projects could get around it.

Okay, so how did it become so stodgy? Well, in the construction industry, a favorite tactic of sneaky contractors bidding on cost-plus type contracts is to place a bid that is known to be lower than what they think they need to complete the project. Then, once they win as the lowest bidder, they begin to process change notices and proposals in an attempt to fool the customer into raising the budget ceiling. That’s why the change control process became so highly scrutinized, and why the layers of review and approval were put in place, all appropriate for that industry. Apparently, the experts did not hail from the software industry, where the inability to process rapid changes in input and output functions, not to mention overall processing, often proves fatal to the organization’s ability to meet customer expectations.  Add in the fact that cost-plus contracts are not quite as common in IT projects as they are in construction, and the possibility that some basic precepts of project management being introduced and codified that have little or nothing to do with best business practices in disparate industries becomes near-certainty.

Configuration management isn’t even the most egregious example of standard PM practices having a poor fit in the IT industry. Try performing a risk analysis based on a Monte Carlo simulation on an IT project to see what I mean.

What’s the remedy? I think IT project managers need to be fearless in their readiness to modify, or even abandon, many of the techniques associated with traditional project management, and to completely ignore PM experts from other fields who maintain that they are not “doing” PM properly. In this regard, I may be making PM writer history – I’m actually advocating not adopting aspects of traditional project management!