As I near the completion of the Community Voices programme I have found it helpful to reflect on my performance over that period, in particular what I’ve learnt about programme and project management. My view of project management methodologies has changed during the course of the past 18 months and it is this story that I want to share with you today, having been encouraged to tell it following a conversation with a friend over a drink.
I first encountered the mysterious world of PRINCE2 ten years ago whilst working at Vodafone as a Graduate Engineer, delivering software projects and hardware solutions to help the mobile network cope with the ever increasing demands for greater capacity and sophistication from its users. Vodafone UK’s Technology arm had just embraced PRINCE2 with open arms, seeing it as a way through this challenge. I confess that I too had become consumed by this new initiative, and the mantra that seemed to circulate around it’s rollout – from now on all our projects would run to time, to budget, they’d never slip because risks were managed, issues logged and project boards updated – well perhaps that is a slight exaggeration but it shows how much I’ve learnt since then. It was during this time of great change at Vodafone that I forged my first impressions of project management and PRINCE2 in particular, how it can help and hinder an organisation to deliver new ideas and solutions.
Fast forward to 2009. My first weeks as Community Voices Project Coordinator started well, I introduced a project plan, risk log, issue log and PID to the programme, next came the communications plan and then the detailed work began, but what I’ve come to learn is that my experiences at Vodafone had left a distinct nervousness in me that altered my approach to developing the project management structure for Community Voices. There had been a very strong negative reaction to the introduction of PRINCE2 at Vodafone because there was a lack of understanding as to what a project is. PRINCE2 was applied to all business changes, including operational work, which merely created additional paperwork and processes around the operational change and added extensive delays to everything. It became a time of power shift, the once unheard of role of Project Manager seemingly overnight had become all powerful. No-one understood this weird world of PRINCE2 except the PM, no-one could generate new project codes except the PM, business cases were delayed because officious PMs could insist on further details being added before they could be viewed by the project steering group. And so with this experience very much at the front of my mind I tried to look objectively at what management products, to use the PRINCE2 terminology, I needed for Community Voices. I was nervous about introducing unnecessary documents or processes, I was nervous of a backlash from my team mates because I was delaying the development of the programme, so I aimed for what I thought would be the minimum – a PID including the project plan, a risk and issue log and a comms plan.
But actually, looking back I realise that I missed the point, my nervousness was missed placed and had distracted me from concentrating on what a project is fundamentally about – communication. Without effective communication the paperwork and processes become redundant, they get in the way instead of supporting and facilitating communication. What is a project plan if not a communication tool? With a project plan you as the PM can communicate not only the extent of your project, the resources required, but also show the impact of change, monitor risks as well as report progress. But so too can your project team, they can see visually what’s happening, what’s not happening, they can sense where the risks are and be active in controlling and mitigating them. The project plan can be not only a reason to communicate but also a means of communication. Don’t get me wrong I’m not advocating that the project plan can substitute the need for clear, face-to-face conversation, it can’t, far from it but I have learnt not to see all these management products as barriers but to think of them as opportunities to communicate. Not all of them are required or useful, it depends on what’s needed on the ground, but I think in future I will approach any new project or programme with a different view on the paperwork and processes that I want to introduce by asking myself ‘for this project how do I want to communicate?’