risks, issues and RAGs

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

Comments

[Timm]

As someone with a background in Project Management AND Internal Comms, I can sympathize with both sides here. Network diagrams, Gantt charts, work breakdown structures - if done correctly - are indispensible tools to understand dependencies, getting timelines right, and for managing risks and costs. The question is, if a communications plan runs as part of project plan, or in parallel to it.

Typically, a communications manager is involved in a project as a post-planning consultant, causing the plan to be developed on top and in parallel to the project itself. This makes little sense, since communication activities themselves should be counted as deliverables with clear dependencies in the plan (e.g. with regards to that all-important union vote).

Communications managers should be an integral member of the project, involved in the planning phase of the project in order to point out what important deliverables need to be achieved with audiences. That's what strategic involvement is about. And if we comms managers want that level of involvement, we need to be able to demonstrate to Project Managers that we have our part of the project under control.

To demonstrate that, we will need to measure success. And in some cases this might mean tracking our progress on a Gantt chart.

Hi Timm and thanks for the comment - you always add such a well-rounded perspective to things because you can see things equally well with an IC/HR/Project Management hat on, and incidentally that's why I think we're fortunate that so many people join our profession with a background in another discipline.

I guess the thing for me is that I absolutely see the value of these types of tools, I just have a sense of humour bypass where there are so many of them flying around that I don't have any time in the day left to do anything else. A friend called me the other day in a tizz because three different project managers had asked him for the same information, and each needed it providing on a different template.

As with all things, I think it's about understanding the other person's needs and knowing their world well enough to give them what they want (and earn yourself an early and influential seat at the table), whilst being able to push back in a reasonable and constructive way when you need to.

Sue

[Timm]

I completely agree, and your friend makes an excellent case for standardization of project data collection practices.

In the end, it comes down to the question of how you, as a project manager with data needs, collect this data. In IT terms: How do you design an "interface" to users which is gives the application enough info to run on, while limiting the effort to put it in the system.