Thursday, October 11, 2012

When Projects Go Bad..... part I

Why do projects "go bad"? If we take the classic triangle of managing projects then ask the following questions with "the best made plans" in mind :

1) Why do costs escalate ?

2) Why do delays occur?

3) How do quality deviations happen ?

This blogg comes about from an off hand comment from a senior defence project manager, talking about the number of managers on a project.  I know to which I replied " Fannagers". Too many cheifs and not enough indians.

A top heavy project team on both client and supplier side is a recipie for disaster because it emplies that there are more MBA qualified non technical experts and of those technical experts on the team with authority, the majority have actually lost the currency in their skills being out of date.

Teams may not appear top heavy though! Top heavyness comes with the idea of being a manager often associated to having an MBA. The divine right to rule, to plan over for to execute, and to avoid detail at all costs. ( From most curriculums I have read and units I have undergone in MBA and eMBA, I do not see that the qualification engenders people with so much authority as they presume. The same with PHd.  They can in many cases be a license to be arrogant and manage accordingly with aggression and defensive poltical tactics. If you are a technical manager or operative confronted with such an idiot, and there are many who pop up in new, significant projects and take overs in particular, then start to ask what they actually specialised in or took as case studies in their MBA or PHd. This often cracks them down and takes away the smoke-and-mirrors act. This is an important aside probably undeserving of italics)

The last point , before I digressed into how to tackle the blue shirt and slacks crowd, is the crux of the matter. Attention to detail and unresponsive execution.

I have actually now about 10 years experience in managing pretty small projects on a "space programme" scale of things, but still it has the gravity of just what is lacking on many project management line ups. It is not that PM's and their over lords and MBA lackeys are inexperienced. No,  it is the double edged hara-kiri sword they weild unkowingly in not being RIGHT-EXPERIENCED or as mentioned, current enough, and on the other edge being PRESUMPTIVE and having a REMOTE management style.

Basically there can be a lot of managers who are blind to detail and will just not roll up their sleeves and delve into detail and work on the shop floor in solving problems and gathering information. I am sure somewhere, at some time, a multi million dollar/pound/ € project was significantly delayed because a single bolt could not be purchased due to clumsy and obstructive administration and lines of communications.

( I must also say that at the moment I work with some very good PMs who do roll their sleeves up by actually being able to pose pertinent questions at more or less the right time, and by listening to information and warnings they get and acting upon them towards internal resources and the customer of course!)

So this is a key thing in my experience: management don't know what they are actually doing apart from making plans and asking pushy questions or if they do know what should be going on, they get sucked into the whole plan and project reporting whirl pool and ignore what is going on.

Another key BAD in what companies do now is as follows and quite blunt: while they pay the world for the PM's and for the top technical people, they scrimp on employing engineers and key functional administrators. They get good people, but under experienced. These keen newbies  often ride the wave, sometimes plunge under it but then very often when companies admit they need more competance, they employ over their heads and the now experienced folk leave thus the company loose institutional memory and continuity.

Another big problem in organisational structure for new projects or for demanding delivery times is that Project has Sales as internal customer. The customer should be the customer. Sales promise the world. Project raise an eye brow and breath in deep. Engineering and purchasing are then set in motion with a one way military order: hope is not a strategy nor a detailed list of tactics to achieve delivery date.

tbc part II

No comments:

Post a Comment