It’s just as important to use a project management methodology when you’re embarking on a project that your organisation considers small, as it is when you’re starting a major, business-critical project. There really is no such thing as a routine project.
Small projects that are out of control, have a nasty habit of becoming big projects. They may they have spent far more than was budgeted; they could have overrun and are holding up other work; or they have failed to manage risk appropriately and now have major issues to deal with.
For project managers trying to keep a handle on what can seem like a hundred disparate elements of a project, there are a number of project methodologies available, each of which has its strengths. Organisations need to review the methods available and make a decision as to which will be the corporate project standard. What doesn’t work is a “mix and match” approach where project managers use their favourite method. To be able to compare project progress and output, projects need to use the same method.
Standards, principles, processes and themes are often the organising structure of project methods (although probably the most recognised methodology in the world, PRINCE2, doesn’t use standards in this way). So let’s look at some of the available methods.
1. PMI and PMBOK
PMI is the Project Management Institute, a global organisation that is not-for-profit and maintains the standards and qualifications framework for the methodology. This is explained in the Project Management Book of Knowledge (PMBOK). The method uses five key processes to define and run the project.
The processes will come as no surprise to project managers since all projects require them – they are initiation, planning, execution, control and closure. There are also ten key knowledge areas which cover management of integration, time, cost, quality, scope, human resources, risk and communications. However, this is not a very prescriptive method and the processes and knowledge areas are more of a common framework than a set of requirements.
Historically, this is how projects were managed. The tasks involved were put into sequence, so that one cascaded on to the next, resulting in a deliverable when the final task was completed. This method works well where there is a clear sequence of actions, with defined dependencies. It can be applied readily to stages in constructing a new building, for example.
However, where a project involves methods such as prototyping, in which a “repeat and improve” loop may be needed, the waterfall methodology can struggle to capture the degree of progress that is being made. In addition, carefully structured plans can be disrupted if there are changes to the requirement during the project.
Waterfall doesn’t have a set of themes, principles and processes for projects. Any that are used tend to be specific to the organisation which may make it harder to have discussions with users, or to run joint projects with business partners.
Agile can include various methods and approaches, such as Scrum. Agile came about through a manifesto which mainly described IT projects. Many of its methods work well when it comes to engaging teams of IT people. However, there can be a gulf between an IT team holding scrum meetings and talking in terms of sprints and stories versus a business user paying for the project who wants to know how much progress has been made for the amount of money and time that has been spent.
In general, an Agile strategy for projects prioritises working software over endless documentation. It stresses that interactions and individuals are more important than processes and tools. It veers away from formal contracts and towards collaborative working with the customer. And rather than rigidly follow a plan, Agile emphasises the ability to respond to change.
This works well when things are going well and if the project is in a small, informal environment. But when the project manager has to answer to strict governance requirements and make formal reports, it can be hard to justify facts and figures about team performance.
Although Prince2 doesn’t specifically implement a set of standards, it is still a much more structured method than the project management methodologies we’ve looked at so far.
It has defined stages and processes, defined roles and documents, a set governance structure and agreed triggers for managing risks, exceptions and other events. The advantage of this is that once Prince2 is adopted in an organisation, project teams and managers and indeed users and suppliers, have a common framework of concepts and understanding. This allows them to have meaningful conversations about projects, assisting transparency and engagement.
Furthermore, people can qualify in PRINCE2 at foundation or practitioner level, affording both new and more experienced project managers a professional standing in the organisation when they are interacting with subject matter experts.
About the Author: David Baker is marketing manager at PRINCE2 Training, who provide courses and certification in PRINCE2, Agile, Lean Six Sigma, ITIL, PMP, and Scrum project management methodologies. You can connect with David and PRINCE2 Training on Twitter, Facebook and LinkedIn.