Why the current focus on methodologies is totally wrong:

There are large numbers of online discussions and posts promoting one project management or product development “method” over another.  As a career-long project management practitioner who has seen everything from excellent practice to very poor attempts at managing projects, I feel this is very wrong, damaging and totally the wrong debate.

Where does all this ‘methodology’ discussion come from?

Firstly let’s deal honestly with why we have reached this point. It is largely down to vested interest by those who benefit commercially from the existence of such methodologies (and that includes so-called ‘professional’ bodies).  It has also become fashionable to adorn personal CVs with certifications, based on ‘methodologies’.  The truth is that these certifications demonstrate little if anything about competence. In addition, some firms see it as part of their marketing appeal, that sections of their staff are certificated.  This may seem logical.  However, in the real world of delivering complex projects, the logic starts to fall apart quickly as:

1. gaining certification does not make you a competent project manager by itself;
2. having a random selection of people certified (in any ‘method’) gives you very little if anything in terms of organisational competence relating to the delivery of projects.

It also gets worse, as some organisations feel that as their PMs are trained and certificated, there is little else to do but let them loose in the real world of doing projects.

One other place it comes from (indirectly):

Some organisations (sadly far too many) are very poorly led by their executive / leadership when it comes to projects.  They have no time for discussions about the realities (and real-world challenges) of delivering complex projects well.  In those organisations, there is often very poor recognition and focus on the elements around projects that have the most impact.  They are far more likely to focus their efforts (and resources) on items that on their own, have little if any impact, e.g. certification.

It is very common for those organisations to only want to hear about very simple solutions to what are in fact complex problems and issues. It is also common for discussions on ‘methods’ to thrive and be discussed as if they are the solution to all their (project) woes.

There is a really critical point to all this:

A methodology implies a consistent set of steps to be followed to complete a task (in this case a project) which you can use repeatedly (i.e. across many projects). However, projects are just not like that.  It is folly to believe that such ‘methodologies’ can ever really exist or work for projects.   There can be product development methods (e.g. Scrum, which only deals with a subset of the elements of the project), but that is all they are – product development methods.  They do not address a large part of the management of the project as a whole, i.e. all those things that have to be done before, during, after and outside of the core product development.

And there is another point.  People are not robots.  They do not execute ‘methods’ the way a machine or a computer would follow coded instructions.  One team’s application of a ‘method’ can be light years from another’s.  There can be huge variations in the way different projects are carried out in the same organisation – sometimes for valid reasons and other times just out of choice, for better or worse.

Having a consistent framework (e.g. lifecycle) for delivering projects is fine, and needed in some industries – but ‘methodology’ – is the wrong way to think about projects.

Here is something no methodology could ever cope with:

Projects, by their very nature often contain unique elements (and inputs).  Having a team, that understands that they have to identify, understand and work through key questions at the start of the project, logically and in a disciplined fashion, and then develop for themselves and the customer/sponsor a strategy for delivering that project, can often be absolutely crucial.  How is any methodology going to achieve that or express how you do that?

So what always trumps ‘methodology’?

In a single word – people!  The attitude and approach they take; for example:

1. the way people do or don’t engage with the project, the team and all other key parties (especially stakeholders outside of the core team);
2. the way people communicate around critical aspects of the project;
3. the way key people take responsibility for the project as a whole, not just their own contribution;
4. the way all other people take responsibility not just for delivering quality outputs, but also for recognising and meeting the broader needs of the project while doing so.

All of the above are far more important than methods (assuming a basic competence within the team).  It is also useful to consider, how often do we really see the above happening on real projects.

Methodologies never have and never will deliver projects; people do.

And the sticky subject of dates !!

There are large sections of communities involved in product development of a certain kind, who despise the fact that in business you sometimes have to work to dates.  Many even believe that is it impossible to predict or manage to dates in a development environment.  It would be very interesting to know if that same group of people, would allow the same attitude towards dates (being fixed etc.) when it comes to scheduling their own monthly pay packet.  Somehow, I think not.

In business, dates matter.  In projects, dates can be managed too, if you want to.

Lastly, evidence of the lack of need for methodologies in projects:

In the early part of my career, I worked on complex large-scale engineering projects.  There was no phase II on these projects – de-scoping of the projects was never possible and dates were sacrosanct.   The organisation consistently delivered projects successfully one after another.  In that firm, there was not a single line of PM process, methodology or even procedure.  What always existed, however, was a thoroughly thought-through, respected and comprehensive single plan covering every aspect of the project.  That ‘plan’ was used on a daily basis by all involved in the project. Issues were highlighted as they happened, and the management function of the project dealt with them immediately, regardless of their cause.  That is called, people taking responsibility for delivering a successful project.  That principle will always outweigh any ‘methodology’ on the planet.