As a Learning & Development Consultant at =mc I have supported many organisations – from MS Society to the University of Reading to WWF UK – in developing their project management. Probably like many of you reading this, I also juggle several projects in the office. And like some of you, I have the advantage of using =mc’s tried and tested Systems model. Hindsight is a wonderful thing. In my previous life in HR, despite being responsible for a number of projects formal project management training was sparse. Reflecting on this, I’ve boiled my learning down to three key elements in managing projects that I know now and wish I’d known then:
Firstly, and most importantly, I wish I’d known to stop and ask myself (and I mean really ask myself – several times and then several times again) “What is the problem that my project is aiming to solve?” In other words, what is the driver?
If you’re thinking “really, duh” have you ever started a project because it seemed like a ‘good idea’ at the time, or because someone ‘told’ you that you should do it? Maybe it felt like something that you ‘ought’ to do? And did you then finish the project with more questions than you started with? Or have you ever run a project that ended with no tangible difference, insight or knowledge gained? Yep, I’ve been there.
What I didn’t know then was that I needed to spend more time on scoping. If I couldn’t identify a driver was it really a project – or just something that needed to get done? And If it was indeed a project, did the proposed outcome warrant the investment – i.e. was the organisational gain going to be greater than the organisational input? Or could my valuable – and limited – resources be better used elsewhere? Because I didn’t know to push myself at the start rather than getting stuck into the ‘doing’ as quickly as possible, I ended up managing too many projects in which the effort outweighed the results.
On the flip side, I also wish I’d know how to demonstrate more effectively the impact or outcomes that I did achieve. So I could go to the leadership team (and Board) and show them how my project added value to our overall mission and strategy. Sadly, my ‘proof’ tended to rely more on gut instinct than objective evidence. What I should have done was to spend time at the beginning of the project (see a theme emerging here?) on identifying the success criteria.
I really wish I had been better placed to understand and anticipate what might go wrong. It sounds like a bit of negative approach doesn’t it – especially if your natural inclination is to look on the bright side? The trouble, as I discovered, is that if you don’t think about what could go wrong, you can end up blind-sided by challenges that apparently came out of nowhere.
And back in my HR days, even if I had anticipated at least some of the risks, truth is I had no idea how to categorise their impact or likelihood of them happening. Oh how many sleepless nights and anxiety-filled days it would have saved me if I’d had been able to close the circle and to come up with a plan of how to deal with these hazards? Do you hear what I’m saying? What I needed to do differently was to plan for risks.
Last, but by no means least, it would also have been really useful to have the tools or techniques to stop what appeared at times like every Tam, Raj and Emma jumping on to my project with their ‘great’ ideas, turning it in to a huge unwieldy beast. Because HR projects affect the whole organisation everyone, apparently, has something to say. Have you ever brought a project almost to completion only for a senior manager to swoop in at the last minute with something along the lines of, “About this project of yours. I wonder if we should consider…?” – putting a fundamentally different spin on the whole thing? Are you a victim of this scope creep too? Too often my projects ended up looking nothing like I had intended them to.
What I needed was something to help me identify much earlier on who might be interested in my project – my stakeholders – and just who should be able to have a say in its execution. When it feels like you’re being pulled from pillar to post by lots of different interests, it’s important to know whose opinion you have to take into account and who it’s safe to say thanks but no thanks to. It would also have been terrifically useful to have the skills to influence my stakeholders (especially the disruptive ones) to bring them on board with what I was doing. I really needed to manage my stakeholders much more effectively.
If only I’d have known back then what I know now. If only I had been introduced to the Systems model before I started managing projects – so much frustration and wasted energy could have been avoided. With bags of tools to help me avoid my key pitfalls – and more –it’s been a life saver. I’m now out of the trenches battling my way through a myriad of problems and in project management heaven, if you’ll excuse the mixed metaphor.
To find out more about the Systems model, how flexible and adaptable it is, and what it can do to help you revolutionise your project management approach, read this article on Project Planning Tools.
And if you’re interested in our practical approach, visit the Project Management training programme webpage.
