Words that are often thrown around in conversations about project management are the two in the phrase “best practice".
They are not uniquely used in project management, but we seem to like them a lot. There are a couple of typical examples of when people use these words. During project reviews, to justify an approach, the sort of: why are you doing it that way - well its best practice conversations. The other time is when consultants and service providers are trying to sell their products and they all claim they use best practice.
We should applaud anyone who knows the best way to do anything. If it really is the best way, then we should all be doing it.
There are, unfortunately, problems with this thinking. Firstly, many of the proponents of best practice present it as some almost scientifically researched, unchallengeable, infallible wisdom. But most of these proponents are self- pronounced experts. Whilst they generally are trying to be helpful, the truth is that most often so called best practice is nothing more than what they have found works well on the projects they have worked on. Nothing wrong with that, as we can all learn from experience. But what I’ve found works in the past is not really the same as proven best practice.
So, is the answer then to do more and more research to find the best way of doing anything? That is an appealing answer, but frankly I am little sceptical of that too. Underlying the very words best practice is an implied assumption that there actually can be such a thing as best practice. Maybe you think - surely, there must be a best way of doing something and isn’t this best practice? My scepticism comes from my belief that every project is unique, it works in a unique context, has unique goals and so on.
I’m not saying we can’t re-use tools, techniques and processes. Of course we can. There is sufficient similarity between many projects that common approaches can be used. If I did not believe this then the whole discipline of project management would evaporate! But I do mean that we should be cautious in really thinking of anything labelled as best practice as truly best practice.
This leads into my other worry I have with best practice. If something really is best, then it can’t be improved. I mean, if it could it was never best practice in the first place. Sadly, nothing really is perfect. (Well if you do know some perfect Project Management approaches let us all know!) Am I completely against things called best practice? No, not really. I certainly would prefer an inexperienced team using weak project management disciplines to adopt “best practice”, whatever the real truth of its status as best! For experienced senior project teams I prefer people to consciously review the practices available, and select what is best for that specific situation. By all means adopt something called best practice, but don’t fool yourself that it really is the best or you cannot improve on it.
What is the alternative to everyone accepting best practice as a given? I think the answer lies in the adoption of a continuous improvement mentality to our project management practices. Start with whatever is best practice in your specific project management domain, and then build on it.
The words “continuous improvement” are easy to say, but I find few people put them into active practice. We all learn from each and every project we do, but how any of us truly go back to our tools, techniques, processes, templates and so on during every project and consider what can be improved and developed? Few of us, and whatever the hype and promise few organisations I have dealt with are really good at continuous improvement. (I might, slightly ironically, say I have not yet come across best practice in continuous improvement!)
But even with continuous improvement I want to raise a word of caution. Whilst I believe in continuous improvement, I do occasionally come across the other extreme, where continuous improvement is itself a fixed mantra. What on earth could possibly be wrong with too much continuous improvement? There are two problems I come across with the over-zealous application of the concept of continuous improvement:
- It becomes an excuse to do things half heartedly, as don’t worry, we can always improve on it
- It can become confusing for team members. The truth is we all like a bit of stability and we all take some time to learn new things. If all our processes are being adapted all the time, no-one knows if what they are doing is the right way or if they are following the latest standard. This then points to some sort of change control or release management over our tools, processes and so on. But unfortunately, the words “change control” often seem an anathema to many of the staunchest advocates of continuous improvement.
New methods and tools
Out of improvement activities come refined and enhanced approaches to project management. But whilst the discipline moves on, becoming more sophisticated all the time, there are an amazing number of project managers applying exactly the same approaches that they applied a decade or even decades ago. It is as if we were working in a completely static discipline.
Sometimes this is because there is a tendency once we know something that works not to want to fiddle with it. Perhaps it is because we are conservative deep down!
To be fair, there is an inevitable lag between new ideas being developed. Let me tell you my own story, with regard to one of the hot topics of project management over the last few years – Agile.
Coming from a pretty traditional waterfall style project background, albeit with odd forays into various iterative projects and accepting the premise of progressive elaboration, I was frankly sceptical of Agile.
I heard all the myths: there’s no process, it’s no good for big projects and so on. Sadly I believed this nonsense. Fortunately, I got the chance to work with a set of agile teams. There is no better teacher than experience, and I was quickly convinced.
But what is really interesting, and somewhat ironic, about new techniques is how quickly the revolutionaries become the reactionaries. Agile was developed in the software industry to overcome challenges with traditional project approaches. It was developed by seeing there had to be a better way. It builds in ongoing improvement. It’s therefore funny that some of the most rigid project people I now meet are the agile zealots. This is a shame as they risk taking a brilliant set of insights and simply making the next bit of yesterday’s news.
There seems something very human about this. We all seem at times to need a push to accept that whatever we hold close to our hearts may not actually be the best! At most it is just the best we have for the time being.
What’s my conclusion? Be open minded, adopt what seems best, but always be willing to go further. Project management, by itself, is not the answer to anything. It is a tool, a really powerful tool. Like the best of tools it needs to be applied in the right way to the right situation. And we, like the best toolmakers, should always be looking to improve on that toolset.