Darren Crozier (Black Belter and esteemed Chairman of the CIB in Scotland) e-mailed us yesterday on the subject of IC managers acting as project managers and business planners. I'm afraid it prompted a mini rant (sorry Darren) back from me about the trials and tribulations of working with project teams. Taken aback by the steam coming out of my ears, Liam helpfully suggested it could be an interesting topic for the blog ...
My issue with projects is when the necessary process and discipline involved goes into overdrive. I turn from a mild-mannered smiley person into a stroppy and irritable hag when I'm asked to produce back-up templates for my templates (I was, on one occasion, asked to produce a contingency plan for the contingency plan), fill in RAG reports every 2 days and get quizzed about whether the red triangle on my gantt chart shouldn't ideally be a yellow circle.
There's also the scenario when you're constantly told you're on 'red' because you haven't produced a comms plan. "I can't produce a comms plan," you helpfully explain (several times and increasingly through clenched teeth), " because you haven't worked out the project plan yet." Producing a neat matrix showing weekly updates for the next six months with a couple of conferences thrown in (just to make them leave you alone for 5 minutes) appears to get a tick in the box, even when you point out that actually it's not related to anything at all and will get re-written when the project plan finally turns up.
(Takes deep breath and climbs down from soap box.) So, given that we do want to be treated as workstream leaders, steering group members and valuable contributors to projects, how do we add value, and what are the secrets of success? Here are three suggestions as a starter. Please add yours to the list ...
1. Provide constructive feedback and challenge about the project plan itself. As someone who doesn't hasn't been totally immersed in the new system/product/whatever it may be, you're well-placed to challenge assumptions, give a realistic view about potential reactions, question timescales and spot holes in plans.
2. Understand where project managers are coming from. Speak their language and give them the milestones, progress updates and risks and issues logs that show you're in control of your brief. And where you feel there really are risks or issues from a comms perspective, make sure they get heard. Sometimes they can feel tiny to a project team that's focused on the fact that they're 20% over budget or the new system's developed a major bug.
3. Be clear about roles, responsibilities and boundaries. Set out what you will and won't do, and where you can and can't add value. Some times templates and tracking charts are eminently necessary, but sometimes it can go OTT. On those occasions it's worth pointing out what's NOT going to get done that they really need your communication expertise for, because you have to fill in another round of templates. It may well turn out that there's someone else on the project team that can look after some of the process piece for you.
Seriously, I do enjoy getting involved in a good, meaty change project that you can get your teeth into, and I've worked with some great project managers, some of whom are now good friends. But it's quite likely that we've had a few 'spirited' conversations in the course of our work together, and they would probably tell you with a wry smile that 'Sue doesn't do gantt charts'...!
Anyone else want to share any project working horrors or suggest some tips?
Sue
Recent Comments