I've specialised in a particular area of project management called "Turnaround". Where other project managers specialise in different aspects of project delivery I specialise in clearing up the mess that some of them leave behind. If project management was a hospital I'm more the Paramedic or A&E specialist than the long term cardiologist or pediatrician. You don't ask me to manage your long term care - just breath life back into the patient.
When my kids needed to know what I actually did when I left home for the day I found it a bit difficult to explain what a project manager actually does. I tried lots of things but finally hit on the explanation that "Daddy's job is to stop the s**t hitting the fan - but when it does he has to clear it up afterwards". As the years have passed I've realised that I've built my reputation up on the latter.
When my kids needed to know what I actually did when I left home for the day I found it a bit difficult to explain what a project manager actually does. I tried lots of things but finally hit on the explanation that "Daddy's job is to stop the s**t hitting the fan - but when it does he has to clear it up afterwards". As the years have passed I've realised that I've built my reputation up on the latter.
I'm often asked "... so how do you turn projects around?" normally followed by "... so what extra controls do you put in place to get it back on track?" or "...I bet you have to be tough with people?"
I've thought about it a lot this week, not least because I'm helping a new client deal with a failing critical project, and I've come to the following conclusions from my experience:
- Projects don't fail because of a lack of controls in fact the truth is the opposite. There are so many controls in place that everyone is wasting time managing the control system and forgetting to actually do something
- Projects don't fail because stakeholders aren't managed properly. Most people in my experience go to work to do a good job not destroy things. The problem is that we spend so much time "managing" stakeholders & teams that we forget that they need time to actually get on with what they're good at
- Projects don't fail because people don't know what they want. They struggle because people just don't take the time to think about the best ways to communicate something and make sure that everyone has the same ideas. No - we'd much rather have controls and detailed documentation that we read, review and comment on. Wouldn't it be so much better if we simply chatted, agreed the best solution and then got on with it? So much more effective & efficient
- Projects don't fail because we don't have enough resources, money or time. They fail because we allow expectations to get away from us or become so intransigent that we oppose change even if the new solution would make what we do more useful and relevant
- Projects don't fail because we don't follow a "proper" process, don't have "proper governance", don't have "rapid action teams" or don't have "change control". They fail because all of these things, if improperly applied, strangle the innovation out of the best of teams
For me projects have two type of influences - Gains & Strains. The higher the Gain to Strain ratio the more likely you are to keep it on track. So when I'm faced with a failing project I aim to reduce the strains as quickly as possible.
Typically this includes:
- Reducing command & control mechnisms to the absolute minimum
- Changing from "Project Review" meetings to more informal get togethers once a day to synchonise activity
- Stopping the "management" activity and emphasising the "leader/support" role
- Distracting company control freaks with "plans" and lots of activities that I need them to go away and deal with (that won't impact on the team or the project in any way)
- Taking on the role of dealing with the blockers rather than allocating the tasks
People over process, Deliver over Control Documentation, Cooperation over Contracts and Change over Detailed PlansHaven't I heard that before somewhere?
So it looks like my "secret" is that I make projects more agile. I liked that in the past I was a maverick and did projects differently to everyone else. Now agile's becoming mainstream does that mean I'm going to have to become a Waterfall evangelist now just to be different. Now that's a scary thought!
Mike :-)
No comments:
Post a Comment