The Old Way vs. the New Way in Project Management: An Observation

April 20, 2010 | Author: PM Hut | Filed under: PRINCE2, Project Management Musings

The Old Way vs. the New Way in Project Management: An Observation
By zhisou

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/.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

3 people have left comments

I’m not quite sure I understand. Are you advocating not supplying the customer with the exact requirements it asked of you?

Laura Bamberg wrote on April 21, 2010 - 9:33 am | Visit Link

Zhisou, I’ve gone through your article a number of times but am still puzzled as to what you see as the key difference between what you term the ‘old’ vs ‘new’. The example you bring is about a geographical seperation between the project and the customer, where, using the ‘old’ methodology you have co-located the team to be in close vicinity the customer. You then describe the ‘new’ as being a PRINCE2 based project, and this is where I got lost. Do you propose that PRINCE2 has anyhing to do about the geographical location of the team. Can PRICNE2 not support project teams co-located at the customer location?

I’m sorry but can you explain this point again?

Shim Marom wrote on April 26, 2010 - 10:13 pm | Visit Link

This article was written for my blog not a professional project management audience. It’s a rant about very specific circumstances when project methodology switched mid-project. Apologies that the point made, such as it is, is not clear.

When I began in IT project management, projects were made up of dedicated teams who got up close to the their business customers. The project was their day job and often their only job. The “new” method was the opposite, the tasks formed the project but they were delivered by people who had no connection with the project, they simply delivered one task after another, some on this project, some on another, some routine maintenance tasks.

That was the old/new distinction - the drive to move away from dedicated teams to something close to “business as usual” delivery.

zhiaou wrote on June 28, 2011 - 2:00 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories