Methods, methodologies, frameworks and Bodies of Knowledge (BoKs)

Difference between Project Management frameworks, methodologies, methods and Bodies of Knowledge (BoKs):

In many online project management forums, discussions often incorrectly classify Project Management artefacts.  For example, calling Agile a methodology when it is not a methodology at all. Agile is literally a set of values and principles – these alone do not make a methodology or even a method.

Lifecycles:

In general, a lifecycle is the major stages that something goes through as it evolves or grows.  Projects evolve so it is natural to look to find and define lifecycles for projects of different types.  There is never going to be a single lifecycle that applies to all projects unless it is so high level it has little practical purpose (e.g. Prince2).

There are many lifecycles covering several domains, e.g. software development, systems engineering and construction. It would be very unsuccessful to try to use one in a domain it was not intended for.

When working in a single domain or industry, project lifecycles are a great way to ensure consistency of approach, to reduce risk and bring order and discipline to projects.

Methodologies in general:

A methodology is a defined repeatable series of specific steps to produce an answer to a question (e.g. research) or a business problem.  They can include rules, procedures and practices to be employed when undertaking specific elements of a task of significant scale.  For example, there could be clear rules relating to and to be applied to analysis.  A methodology should be repeatable and provide consistency when answering complex questions or addressing multiple business problems of a similar kind.

Project Management Methodologies:

Are specific in nature and typically contain steps and activities within each phase of the whole project lifecycle. In some organisations, there is an expectation that most if not all projects will follow a specific methodology, as far as possible. This can be a very unrealistic expectation for many reasons.

Project Management Methods:

Are specific individual methods that can be used for part of the project or for a specific purpose, e.g.

1. Critical Path Method is used to analyse schedules and dates in a plan and is commonly used in some industries.
2. Scrum is a method most commonly used in software development and is aimed at supporting Agile values. Scrum in truth is more of a product development method than a project management method but could easily be a key part of delivering certain projects.
3. Earned Value Management is a method to measure and present quantitative data on performance relative to budget and schedule throughout the delivery phases of projects.

PM and Product Development Frameworks

The Waterfall “V” Model – is a framework for software development – it is not a PM framework.

This category is perhaps the most difficult to define, as it contains a wide variety of examples.  PM Frameworks usually cover the end-to-end phases that projects go through and the entire scope of work of a project, not just product development. They can be very useful and make real sense as they can be more flexible than methodologies but could contain some steps that might be compulsory for all projects, e.g. a business case etc.   Allowing projects of different types to determine how best to manage and deliver them can sometimes be a good thing, as there is never going to be a one-size-fits-all for delivering all projects (even inside a single business). Some flexibility is realistic as long as all projects can demonstrate they are being managed well.

The Waterfall (V) software development model above is no more than a model that has inherent principles, which reflect the phases and sequence of major activities for product development using this model.  On its own, it is not a framework, but could be used as the basis of developing one, by a single business.

A framework can refer to methods that are appropriate to the types of projects it is intended for. 

They may focus on the governance of projects (regardless of project type), being something you want to do on all projects above a given size or level of importance. They may also contain processes that define how control is to be applied, being something you want to do on all projects regardless of size.

Project Management Body of Knowledge – e.g. PMBoK ® or BoK by the APM.

A body of knowledge is a structured set of information on a collection of topics that relate to an overarching subject, e.g. delivering projects.  The most established are the UK APM’s BoK and the USA’s PMBoK ®.  A BoK will usually describe methods but is not a methodology.  A BoK could be used as the basis for developing a PM framework for a single organisation (or a methodology). In terms of their origins, they started out as predictive (as opposed to iterative) ways of delivering projects, although they are adapting to reflect new approaches and trends such as Agile.

Where has the confusion come in?  A few years ago some Project Management BoKs were little more than a collection of references for a specific list of project management topics.  Then along came certification processes and the large revenues these generate.  Professional associations quickly recognised it was very difficult to create credible exam processes on little more than a collection of references (which by their very nature would contain many different, even conflicting views on the same topic).  Hence over the last decade, some BoKs have moved a long way from simply being references to being much more specific – to the point they can provide the basis of a series of exams. We leave it to you to decide if that is a good thing or not.

Biggest difference between a Framework and a ‘Body of Knowledge’ is this:

A PM framework will tell you what to do. A body of knowledge will tell you (or point you in the direction of guidance in) how to do something.

Do we need methodologies or just BoKs and frameworks?

The evidence we see (across hundreds of projects) is that very very few organisations actually use methodologies on real projects. Partly this is a behavioural question but you have to also ask whether projects can ever follow prescriptive methodologies.  Far too many of them become shelfware.  However, project teams often develop a plan that represents how a specific project will be delivered within a framework that a business commonly uses. The framework will always represent their industry (e.g. construction/software development) and could be waterfall based or any other approach that you chose.

So what are Waterfall and Agile?

Waterfall and Agile are very different. Waterfall (on its own) is at best a model for delivering software projects, being the high-level life-cycle that projects go through.  You may also go further and define the major steps to be done that could be the basis of a Waterfall based framework.  Agile is not even a framework – it is a set of values and principles (e.g. delivering working software regularly). Agile principles are combined with methods (e.g. Scrum) to produce a framework for managing projects. However, Agile and Waterfall (on their own) are not project management.  They are product development methods. (N.B. many Agile methods do not cover many of the other elements that will also have to be done and managed in large-scale projects).