Anyone who has read much of my project management writings will soon realise that whilst I welcome standards, best practice and accreditation – it is sometimes a slightly cautious welcome that I give to them. (For example see my articles “Best Practice, Continuous Improvement and Progress in Project Management” and “Predictable futures: a management myth”).
In this article I want to talk a little more about methodologies. I don’t want to get too bogged down in defining “methodology” – as I think we all have an intuitive grasp of what I mean. What I write is generally applicable to methodologies, frameworks, lifecycles and delivery processes. I include any standardised approach for getting things done – accepting that this covers a broad range of items.
I am going to follow this up with at least one other article on this subject, as it is something I am very interested in. As always I hope to generate responses, as whilst I think I have some useful experience in this area, I’m sure there is lots I can learn from you as well. In this article there are three things I want to talk about:
- The source of methodologies
- The danger of a “one size fits all” mentality
- The application of methods as rules
Developing new methodologies
The most common way to develop methodologies that I have come across is as follows. Find some experts, get them in a room to work together, and for them to design the methodology. I have been directly involved in several developments like this, but it is not the ideal approach in my mind.
The philosopher Wittgenstein was famous for saying “Don't think but look”. What he was referring to was armchair speculation about the world. Certain things are best dealt with by abstract speculation. But when it comes to what works and what does not work in the practical realms of real life, including project management, we are better off understanding by looking rather than by abstract thinking. I feel this way about methodologies.
The best methods are not developed by getting a set of experts into a room who then have a deep and profound discussion about best practice and from this design a method. The best methods are developed by observing the actual working life of successful project teams and adopting those elements that make them successful.
The one size fits all mentality
Another problem I find with the development of many methodologies is the forced implementation of a single approach to delivering every single project.
There are many benefits to standardisation. I am particularly keen on two. One is that it encourages the development of a common vocabulary within an organisation – everyone understands and uses the same concepts in the same way. This is very powerful. Secondly, standardisation tends to push everyone to a minimum level of performance.
This is great if your projects are actually all standard and that common minimum level of performance is higher than your current level of performance. But all too often in the push for standardisation, standardisation becomes the goal and not a way for achieving the more important goal of high project performance. Project outcomes can get lost in debates about whether a standard has been adhered to or not.
Effective methodologies must enable flexible approaches. Not every project is the same. There is obviously enough similarity to have the discipline of project management, but projects vary in terms of scale, risk, content and context. Each of these factors should be enough to drive the development of flexible methodologies which enable the project team to select the most appropriate approach for the specific project they are running.
Rules instead of guidance
One of the advantages of standard approaches is that it facilities easier management and quality management of projects. But there is a tendency for those with oversight of projects, and for many less skilled project managers, to focus on adherence to the methodology. Of course the methodology is there for a reason: it should aid the project team to more reliably successful delivery. But the measure of success for a project should not be in terms of process adherence. It must be in terms of successful outcome as perceived by the project’s customers.
The best approach to methodologies is to treat them as helpful guidelines, and as access to the wisdom and ideas of those who have run projects before you. But any methodology is a simplification of every possible activity that can be done or has been done by those who have successfully delivered projects before – and every project has some unique characteristics. (If it does not, then you could turn the project into a repeated process – and if you can do this, you probably should). As a project manager, you are responsible for delivery – the methodology is responsible for nothing. So you should adopt whatever approach will work best in your situation. The methodology must not become a straightjacket – but should be a friendly and useful set of guidance.
That is not to say I am suggesting you abandon your methodologies for the sake of it. In most cases you will find existing project management tools and approaches which are perfectly adequate for your situation and which you would be foolhardy not to adopt. However, you should not think that a specific and individual approach or project management process will be ideal for every situation. The best results always come from the approach which is most appropriate to the situation.