The Old Way vs. the New Way in Project Management: An Observation
In my previous incarnation as a corporate climber, I was exposed to two entirely different project management methodologies and got rather caught up in the middle of this. The “old way” in which I had been tutored was replaced by the “new way” mid-project and whilst both methods had merit, it left the project reeling and caused much tension and silly office politics.
The “old way” was to assemble a dedicated project team, put together a plan, and deliver it as close to the business customer as technical requirements would allow. Thus, one project I managed was delivered on site just outside New York and distant from UK HQ and technical backup.
The “new way” was based on PRINCE2, which was more bureaucratic but consequently much more organized and theoretically more reliable and predictable. It was all the rage and was seen as the great new hope for sorting out haphazard project delivery.
Both had pros and cons. The former was fine in terms of building strong relationships with the business community, and tended to deliver something which was closer to user requirements (due to closer relationship and more emotionally involved and committed team members), however it was less good at getting the technical tasks delivered from those outside the project clique.
The latter was more organized and had more structure to fall back on and therefore could better know the state of progress and signal problems and delays in a more consistent fashion. However, due to its colder hands-off approach it failed to build strong business relationships, and delivered a product, whilst perhaps more technically suitable, was less business ready. Also, its perceived strength of being more predictable in delivery was not entirely true – so although it demanded detailed specifications of each and every task up front, at the end of the day it was a person who then estimated delivery times and costs, and this was a fallible as any other human intervention. Indeed, a supposed five-day job to migrate data from the old to the new took nearly four months due to bad estimates, unforeseen complexity and staff illness. PRINCE2 didn’t ride to the rescue.
Also, the method of demanding and delivering to exact specification fails on two counts. First in relies on perfect and complete analysis of the task required (very rare), and second it is inflexible to unforeseen events, which always occur during any even slightly complex project delivery.
Additionally PRINCE2´s standard forms for reporting progress to business managers were unsuitable and caused managers to switch off and miss key points. All they want to know is “how´s it going?” “any problems?” and “do you need me to do anything?”
Generally speaking, as technical delivery becomes increasingly remote from project delivery – literally geographically, but also emotionally as those doing the typing are entirely divorced from the end product, the temptation is to ensure ever more cast iron specifications to ensure a “right first time” approach. Of course this makes sense, but then it fails to take into account the two issues raised above (fallible analysts and the unforeseen). The answer is not to hand over the analysis to the same technical team as this is equally flawed in my experience. The motivations of the technical delivery company (or department) are entirely different (sometimes at odds with) the motivations of the business team receiving the project – somehow linking the techie´s performance with overall project success would be ideal. The simpler, though admittedly probably less good option, is to allow greater flexibility in the relationship which sounds like more time taken and more error prone, but when one debunks the myth of “right first time”, it actually doesn’t take longer and isn’t less good.
The problem with PRINCE2 type methodologies, and specification-led relationships between companies and outsource partners (or other internal departments), is that they attempt to push human performance closer to machine performance, assuming that if a human project delivery chain can become as reliable and as predictable as a mechanized plant assembly line, then project delivery will be far better off. I suppose this is true, but I see it as trying to squeeze square pegs into round holes, implementing any kind of change in business (technical or not) is not the same as making a car or a meat pie, and trying to make it so doesn’t make it so.
The author, zhisou, has chosen to remain anonymous. You can contact him and read more of his writings on his blog, http://zhisou.wordpress.com/.