Purpose of this article:
The purpose of this new article is to share some of our thoughts and philosophy towards the much debated topic of what works best in project management (PM). It focuses on principles and practices (things we believe are highly important), rather than a single method. Methods come in all sorts of shapes and sizes, like Prince2, Agile etc. In truth, they vary a great deal, and being even more truthful, none is the only way to deliver a project successfully. However in our view some are definitely superior to others.
So, is there a Project Management method we would recommend? Yes:
For certain types of projects, if we had to pick one ‘method’ that most closely matches our PM philosophy it would be Agile (even though it is not a method as such). For example, we prefer and promote a light touch to elements that are often bureaucratic (to put it mildly) in some methods, together with daily (not monthly or even weekly) communication within teams at all stages of projects. This does not mean chaos or micro-management; it means shortening lines of communication and improving the probability of delivering successful outcomes to happy customers.
Over the years, we have witnessed many practices, that come from a variety of environments which elevate the prospects of project success. Align those key practices to a project management framework for your business, and real project management capability can be developed and deployed. To start then, let’s take a look at the first question below:
Which matters most: method or people?
This is definitely an interesting question. Consider this: find a group of very experienced project people, give them no method, but give them a project. How do you think they might do with their project? Conversely, find a group of people who have never been involved in projects – train them (for a handful of days) in a method and let them loose – how do you think this group will do? If it was my money, I know where it would go !
Our views on PM methods in general – and methodologies in particular
All Projects definitely benefit from following a logical life-cycle to bring order and discipline to its work. Does that mean that you need a specific ‘methodology‘. We are less sure on this question, because of what we see in organisations. You can write all the methodologies you want – but getting people to follow or use them is a different story. So, if this is so, what is key. What are the ingredients that successful project typically have?
Over the years, we have witnessed many examples where projects have been very successful, when the business had very light or close to nil procedures or processes to follow. This baffles some people – they clearly must have had something – so what was it? In short, their project teams had oodles of understanding of the ‘nature’ and challenges of projects, together with a thorough understanding of their project’s life-cycle. Most import of all, they worked as teams, to define, understand, plan, manage and deliver their project. Constantly.
From the 1990’s onward, many businesses tried to develop an ‘end-to-end’ methodology for delivering all their projects. While thousands of people have been trained in some methodologies, very few (if any at all) use the full intent and content of those methodologies. We believe the reasons are twofold: 1) project type work by definition carries a great deal of variation and 2) people don’t like being told exactly what to do and will simply do things their own way. We have always believed that trying to define an end-to-end PM methodology is doomed to fail. Most have become shelf-ware. There is however, significant merit in developing a common framework for delivering projects, maybe by project type in your business. Something we are very pleased to see is catching on today.
Are some Project Management Methods better than others?
Of course – that’s like asking if some athletes at the Olympics are better than others. Rhetorical question. Is there one that guarantees successful projects? Definitely not. In addition, different people interpret and implement methods in sometimes vastly different ways. Six Sigma tries to limit variation – great idea in principle – very hard (we would say impossible) to achieve across multiple projects. In addition, the behaviours of individuals (and even organisations) responsible for delivering projects will always far outweigh the methods employed. There is a also great deal of complete miss-information ( to use a euphemism ) banded about by some when they extol the virtues of one method over another. Here’s an example: Agile. Nothing at all wrong with Agile – it contains some excellent ideas. However, there’s much written by fans of the approach about Agile and other methods that is totally untrue.
For example, does Agile mean you never have to plan (as is some people’s interpretation). Of course not – it still expects you to set out vision, goals, objectives, communicate priorities, consult with stakeholders and move on. That’s precisely what planning has always been about. Not necessarily the way it is practiced by a lot of teams though, and that’s the difference. Agile never stated: ‘thou shall never plan‘ – it promotes simple and effective ways of doing this – so do we .
So lets look at some of the good things in Agile:
Agile started out as a philosophy for developing software (see below), not a method. Agile project management contains some excellent ideas and concepts but it is not unique or even new; it mirrors practices employed for some time by some industries and organisations very successfully, but under other names. A small example would be something like daily stand-ups, often used in an Agile environment. An excellent practice, but not invented by Agile – many other organisations employ the practice because it works. Let’s explore this more and look at the foundations of an Agile environment.
- Individuals and interactions over processes and tools: to us this is all about regular and effective communication – real time, inter – personal (i.e. not remote or passive). All are excellent practices and a key example of something commonly found in well managed projects today.
- Working software over comprehensive documentation: all good development environments should always lead to working software
- Customer collaboration over contract negotiation: contracts are there primarily for when things go badly wrong. Collaboration and ideas such as collocation are and have always been excellent practices to ensure productivity and that things never go that badly wrong.
- Responding to change over following a plan: plans and anything that needs to should always respond to required change – of course.
So what are examples of key things in Project Management?
Let’s just use the following example – it may look to some people like ‘motherhood and apple pie’ type statements, until you think of it this way: how often do you actually see the following routinely in evidence on real projects?
Successful projects usually:
- Have clear business objectives and goals: understood by all
- Limited in time and cost: firm but realistic budgets and schedule
- Involvement of several people: a well coordinated and motivated organisation
- Presupposes the need for information sharing: effective communication (open information)
- Use the Plan to communicate and manage: active management and control
Even in businesses that have been doing projects for decades, it can highlight the difference between what we say we do (in our glossy brochures perhaps) and what people really do in practice. It may also highlight whether the behaviours being exhibited around our project teams are contributing positively or otherwise.
On the positive side, there are many crystal clear parallels between the above set of statements, and what methods like Agile are trying to encourage. That’s an example of where there’s a clear opportunity to draw on practices that are really good for projects.
Seeking out practices that are clearly successful and transferable is the primary goal of PMIS, so that we can share them with others – and that’s exactly what all of our training courses include and are based upon.