I hate the term “project management” with a passion.
That might come as a surprise to those who know that I am currently “managing” a large and commercially important web project at work. And not as a surprise to those who know how much I hate bureaucracy and admin as a general rule.
But allow me to explain what I mean when I say “project management”. I’ve been reading my friend Jason’s blog over the past couple of weeks and nodding in total agreement with him. Particularly his posting about project plans and gantt charts.
For me, the problem with the term is that it has most people, especially those starting off in it, firing up their MS Project apps, reaching for their PRINCE2 / Waterfall / Agile books and creating loads of highly detailed or weighty reports, documents and spreadsheets as that’s what they think project management is. The stuff they can easily learn out of books. It almost becomes their comfort blanket, their “evidence” for when things go wrong – “its not my fault boss, it clearly says in the functional spec or the plan ……….. ” and so on.
Yuk yuk yuk.
So I’d rather be called a “project delivery manager” – not responsible for managing the project as such (producing a hefty report each week to explain why the project is late, exactly which line in the 1000 line project plan we are up to and how we are 67.56% complete against plan) – but responsible for ensuring the project gets delivered on time, on budget and to the appropriate level of quality for the customer, given those two constraints.
Which means doing the bare minimum process and admin needed to get the project delivered and the compliance monkeys off my back – not to create a historic record of why the project failed.
And I must be doing something right because my project at work is one of the few that has been green since it started – and will hopefully still be green when it goes live next Friday. And any projects I’ve delivered in the past have usually also been green.
So what’s the secret?
Well, I mentioned to someone a few weeks ago that for me, successful project management is primarily about managing people and relationships, not about managing detailed processes or creating loads of paperwork.
Relationships
Build healthy relationships with both stakeholders and suppliers and ensure open, transparent and regular discussions from day one.
Build an atmosphere of trust – to the point where they both trust you and each other to do the right thing even when they aren’t clear themselves what it might be. Remember, all 3 have an interest in the project being delivered – work together, not against each other.
Be prepared for conflict, as it will happen – but deal with it quickly and effectively and don’t let tensions build up across this important senior team.
Teamwork and empowerment
Have a clear vision and scope for the project, supported by a high level plan showing only the milestones and deliverables, and ensure the entire project team buys into both. The whole team has to understand the project vision and scope, and feel the project is achievable (“our project”). If anyone doesn’t, encourage discussion around it and work to gain their support.
Give team members responsibility for appropriate deliverables and milestones (or entire workstreams) and leave them to get on with doing it. Don’t micromanage – instead, empower these smart people to get the job done and get short, regular status updates from them on progress.
If things start to look like they are going off track or risks and issues start appearing, that’s the time to step in. If things are ticking along fine, leave them alone to get on with it.
If a milestone looks tight, suggest they produce a detailed plan to build up to it, and keep an eye on progress against it.
Encourage a team atmosphere where collaboration replaces directives from “above”, where trust replaces the need for arse covering and where flexibility and teamwork replaces jobsworth behaviours.
Risk and Issue Management
As project delivery manager, this is the area I tend to focus on most. I am always looking ahead across the high level plan, checking for any potential bottlenecks or problems that may be looming and then working in advance to remove them. At a previous employer, some of the team used to call me “the plumber” for this reason – I was forever removing blockages so that projects could maintain momentum.
If issues come up, bring the relevant people together quickly to sort them out. And don’t stop until you have an agreed way forward to resolve them. Time is critical where an issue is concerned or a decision needs to be made – otherwise, things quickly grind to a halt and team morale dives.
If risks are identified, quickly discuss and agree actions to mitigate. Never have an open risk on the risk register without an owner or mitigating actions for it.
And don’t just look for project risks and issues, also watch for dependencies with other projects or wider things going on (holidays, mandatory departmental meetings) that could affect the delivery of your project.
The key is speed – don’t sit back while time ticks on, identify issues and risks and deal with them quickly.
Communication
Like many, I hate email. There is way too much of it. And I particularly hate emailing / being emailed by people in the same office as me. If it can’t wait and you think you might forget the point you wish to make, send it. Otherwise, wait until a time when you can have a face to face conversation about it. Or even a phone call. Face to face / phone helps build relationships – misinterpreted emails often help destroy them.
Have weekly meetings with the team – what have you done since the last meeting, what are you planning to do before the next one, and what issues do you need to table. Add any new risks and issues to the risk and issues register.
Minimal project management documentation
The only ones I happily use and feel are beneficial to project delivery are as follows:
- project charter – in my view, the most important one for the project, as it sets out the vision, scope, milestones, deliverables, key risks, approaches, roles and responsibilities. It is the one I tend to put the most time into producing and discussing with the team, the first thing I do at the start of the project and about the only one I refer to afterwards. If you can’t get agreement to the points in this document, don’t go any further until its resolved.
- high level project plan, showing deliverables, milestones and key tasks only. It doesn’t go into too much detail – if you need it, create separate detailed plans for the team to work against. The purpose of the high level plan is to provide a general guide on project progress and an indication of upcoming activities, not to specify in detail what tasks need doing and by when. ie. it’s not a workplan.
- project budget – keep it simple, summarised and up to date. But don’t overanalyse it.
- status reports – again, keep them short, simple and to the point. If you truly know the status of your project, if your high level plan is up to date and if everyone is in agreement on status, risks and issues, producing this should take less than half hour each time.
- risk and issue register – the things on here are those that can really derail your project so keep on top of them and follow through to resolution.
The most important thing is to focus on delivery, not management. Don’t manage a failing project, deliver it effectively and hopefully it will never become one.
Recent comments