Like many organisations CIPD has a number of project managers around the business, both in IT, focussed primarily on managing technology projects, as well as embedded within various teams, with a focus more on delivering operational initiatives. And like many organisations we have a project management community – bringing both groups together to swap war stories, celebrate successes and share good PM practice.
A few weeks ago the PM Community ran a session on the topic of Project Success. In preparation for that session I was approached for my perspective on the matter. What did I think a successful project looked like? Was it the delivery of a project within budget, time, and scope, or was it more subtle than that?
In a previous life (at John Wiley – my previous employer) I was a Project Manager for a number of years. And I was trained to see project success very much in terms of delivering working software within scope, on time and to budget.
Learning as we go along
But I’ve learned at my time at CIPD a more nuanced, more practical and perhaps also more forgiving definition of project success. Yes those other things are important, but more important still is that we learn as we go along. That we continuously ask ourselves what are we discovering and how do we embed those lessons (that come out of both positive and negative feedback) into the project going forward? And – where appropriate – how do we extend those lessons to the wider organisation?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
(Agile Manifesto principle no. 12)
If what we’ve learned by the end of the project doesn’t necessarily tie back all that precisely to what we believed we’d learn at the beginning of the project then that’s not a failure, but rather the very definition of success.
Most projects aim to introduce some element of organisational or operational change. And effecting change is never easy. Even the most skilful of PMs can’t always help toes being stepped on and noses being put out of joint. But a powerful technique to help manage the negative politics that swirl around any change initiative is to ask stakeholders for their feedback as the work progresses, and to be seen to include that feedback into the following iteration.
Obviously this isn’t rocket science, it’s good project management practice, but I think placing the emphasis more on the learnings gathered along the way rather than the outcomes leads to a more flexible, a more agile approach. Because desired outcomes may change as the project progresses, but the learnings – if they are acted upon – are always gold.