Home / Management / Project Management / Methods Compared

Methods Compared

There are quite a few methods for managing a project (approaches, working methods). the most commonly used methods are PMBok (and the closely related ISO 21500), Prince2 and Project-based Creation (PMC).

Similarities

Many project management approaches have the same characteristics and use the same principles.

As a result, they're also very similar. They share the following characteristics to a large extent:

- thinking and acting from a result (deliverable or product)
- separation of responsibility for purpose and result
- balance between man and method
- think first (from coarse to fine) then act
- focused on cooperation instead of negotiation
- systematically initiating, executing, controlling and transferring a project
- the central role of the client (customer, customer)
- early involvement of users and administrators in the project
- predetermine and record the (substantive) work to be performed
- Prepare management plans with margins for risks (uncertainties) in advance
- choose to stop or continue in the meantime
- assessment of the progress of the project on a starting document (business case)
- clear delegation of tasks, responsibilities and powers
- controls change management by adjusting for (imminent) deviations
- stakeholder involvement at the right time and on the right topics
- communication between the project organization, the rest of the organization (s) and the environment.

Most approaches pursue the same goals

The providers of all the approaches mentioned see their approach as an aid and not an end in itself. Using a thorough and proven project management approach, experienced users can strive to:

- coordinated execution of activities, which together yield a one-off and unique result
- constantly focus all efforts and energy on the result to be achieved
- actually achieving the result
- making a clear division of tasks, responsibilities and powers
- anticipating risks from the start
- consciously choose to stop or continue in the meantime
- flexible and controlled response to changed circumstances, goals and insights.

There are also differences!

The differences can mainly be explained by the origin of the approaches. For example, PMW and PMC have roots. The PMBok is an American method that later conquered the world. PRINCE2 is of English origin. PMW and PMC are more people-oriented, organizational and conceptual. This requires customization from the users in their own interpretation. While the PMBok and PRINCE2 provide very extensive 'manuals' with formats and checklists. This requires situational deviation and a selective application.

PRINCE2

PRINCE2 is very similar to the PMW. There are many similarities. But there are also substantial differences.

Similarities

Both approaches:

- are results-oriented and require prior justification
- provide a conceptual framework that can be introduced and used by an organization. This makes it possible to talk about projects in an unambiguous way within an organization
- attach great importance to change management, quality control, time and money control and organizational control
- emphasize careful decision-making during phase transitions.

Differences

But there are also some differences, namely:

- PMW is primarily an approach. PRINCE2 is a common in government organizations and large bureaucracies
- PMW gives a project management approach in outline and essentials. This approach must be made concrete for each project
- PRINCE2 provides a very detailed and detailed approach that can be deviated from per project
- PRINCE2 has its origins in the UK. PMW originated in the USA. Partly because of this, there are differences in accent in the implicit human approach
- PMW, for example, is less hierarchical than PRINCE2.

PRINCE2 in a nutshell

PRINCE2 is a project management methodology that stands for PRojects In Controlled Environments. PRINCE2 is an elaborated method that's the de facto standard for government ICT projects in the United Kingdom. According to the makers, the method is also applicable to other types of projects.

PRINCE2 in a nutshell

PRINCE2 entered the country from the United Kingdom in 1997 through the channel. The acronym PRINCE stands for PRojects IN Controlled Environments. It's an elaborated method that's de facto standard in the UK for government ICT projects, but which, according to the makers, is also applicable to other types of projects. The last improvement was carried out in 2009. The most important improvement is that the underlying principles of PRINCE2 now explicitly guide the content of the themes and processes as currently defined within the method.

PRINCE2 central features:

- the focus on a business justification through the business case of a project. This business case contains the efforts (costs, time, capacity) during the project as well as the efforts (costs, time, capacity) for the use, management and maintenance of the project result
- the use of a defined organizational structure for project management
- working with a process-based approach to planning
- the emphasis placed on the subdivision of the manageable and controllable management phases (to be determined per project).

The structure of PRINCE2

The PRINCE2 method deals with project management from four integrated angles:

- Processes: PRINCE2 describes seven processes. Each project comes into contact to a greater or lesser extent with the activities described within these processes. In addition, there are all kinds of events and decisions that 'trigger' other processes to carry out activities
- Themes: The minimum management aspects that must be controlled by the project manager during the entire project. Each theme describes the specific application and its necessity
- Principles: the foundations that any project must meet if it's to be a PRINCE2 project
- Tailoring the method: PRINCE2 can only be successful if it's applied 'sensibly'. Adapting the method to the type of project and the project environment is therefore crucial.

The PRINCE2 manual contains:

- seven principles
- seven themes
- seven main processes.

Each main process is further divided into sub-processes. The manual also contains product descriptions of all management products.

User manual PRINCE2

PRINCE2 recommends dividing a project into internships or phases. This creates assessment moments at which senior management can assess the progress of the project. But can also make adjustments if necessary. This "management by exception" is an essential part of the PRINCE2 philosophy. The end of each phase is an important decision and commitment moment (Go-NoGo). The number of phases is entirely project dependent (size, risks and critical moments).

7 principles of PRINCE2

The principles stem from years of experience and are universally applicable for any project. They offer users the opportunity to design and shape the project, tailored to the specific characteristics and context of the project. To manage a project according to PRINCE2, applying the principles is a requirement

1. Ongoing business justification

The Business Case describes the reasons and justification for the project and is approved by those involved. The validity of the Business Case is continuously tested and guides the decision-making process in a project so that the project products generate benefits that meet the organizational objectives. If not, the direction of the project will be adjusted or in extreme cases the project will be stopped.

2. Learning from experience

PRINCE2 project team members learn from experiences. Learning points aren't only sought, but also recorded and applied during projects.

3. Defined roles and responsibilities

A PRINCE2 project has clearly defined roles and responsibilities, which are organized to represent the interests of the Business, User and Supplier.

4. Management per phase

A PRINCE2 project is divided into phases. This allows the project to be planned, monitored and controlled per phase.

5. Management 'by exeption'

PRINCE2 uses three management levels within the project for managing the project, managing a phase and delivering the products, respectively. Specific agreements are made for each level about the freedom to act (tolerances) in the various management aspects of time, money, quality, scope, benefits and risks.

6. Product-oriented approach

A PRINCE2 project is aimed at delivering products, including meeting the agreed quality criteria. It's important to establish quality criteria and who assesses the quality of the individual products.

7. PRINCE2 is tailor-made for every project

Goal: tailoring the method in such a way that it 'fits' the specific project in its environment. The way in which the method is tailored to the specific circumstances must be explicitly described in the Project Initiation Documentation, so that everyone is aware of how the basic processes and procedures have been adapted for this project.

4 management levels in PRINCE2

It's important that the various management levels communicate well with each other in order to successfully set up, implement and close the project.

The process management according to PRINCE2 is based on:

- Governance: the responsibility of corporate or program management. This itself isn't part of the project, but it does define the project objectives and the products to be delivered
- Steering: the responsibility of the Steering Committee, chaired by the Client. The Project Board takes all important decisions in the project and gives direction and direction to the project in total
- Management: the responsibility of the project manager. He's responsible for the day-to-day management of the project, for steering the team managers and for preparing the decision-making of the Steering Committee. The Project Manager is responsible for the project within the framework set by the Steering Committee
- Delivery: the responsibility of Team Manager. The team members are responsible for the ultimate realization of the products to be delivered. The team manager directs the team members.

It's important that the various management levels communicate well with each other in order to successfully set up, implement and close the project.

7 processes of PRINCE2

The process approach used in PRINCE2 distinguishes seven main processes. These run from starting a project to closing it. An overview of the seven processes.

1. Starting a Project (SU)

This process starts after an idea or question, in the form of the project mandate, to start a project. Then the project manager and the client (Executive) are appointed. Experiences with such projects are sought and the project manager draws up the Project Brief containing a brief description and justification of the project. The Project Brief provides the Steering Committee with insight into the usefulness of the project for the organization.

2. Initiate a project

This process involves preparing the project initiation document (PID) based on the approved project proposal. The PID is an agreement between the project manager and the Steering Committee. It describes, among other things:

- the business case
- the products that are delivered
- the quality requirements that these products must meet
- the way in which (how) the project is managed (communication, risk, quality and configuration management).

3. Managing a project

Within this process, a Steering Committee grants authorization for the start of the project. But also for starting and closing each phase and for closing the project. The steering group:

- establishes tolerance limits
- provides advice
- provides guidelines to the project manager.

4. Controlling a phase

Controlling a phase is the daily work of the project manager. This includes:

- determining the work to be performed
- monitoring progress
- taking corrective measures
- handling change requests.

5. Managing product delivery

This process consists of the execution of the work by team leaders / project employees.

6. Managing phase transitions

Information emerges from decision-making processes from this main process; at the end of each phase or if the agreed tolerances are exceeded. The Steering Committee decides whether the project will continue or whether it'll be stopped.

7. Closing a project

This main process consists of:

- a structured project end
- the acceptance of the project result by the users
- the transfer of the project result to the organization.

During this process, the project manager produces for the Steering Committee:

- the final project report
- and the learning points report.

Finally, the project manager makes recommendations to the steering committee for follow-up actions in this process.

3 techniques of PRINCE2

In addition to the seven principles and the seven processes, PRINCE2 also contains three specific techniques. This concerns product-oriented planning, control of changes and quality review.

Product-oriented planning

The project result to be delivered can be identified using this technique.

Control of changes

Changes are tracked through a change control procedure. The same applies to issues or open questions / themes. Before deciding on a proposed change, its priority, consequences, costs and importance must be known.

Quality review

This technique is suitable for determining whether a project (interim) result meets the set quality requirements. The use of this method also strengthens the support base and the sense of ownership.

Multi Project Management (MPM)

MultiProjectManagement (MPM) is managing a (large) number of projects at the same time. This concerns matters such as prioritizing, accepting and allocating these projects. But also about learning from these projects. Collecting the lessons learned.

What's MPM?

MPM is a form of management for controlling many projects at the same time. These projects have no relevant - and as such to be managed - substantive coherence. They must all be performed by one capacity source (the contracting organization) for third parties.

MPM arranges things across projects, not every project individually. MPM thereby fulfills a bridge function between the permanent organization and the temporary project organizations.

What does MPM do?

MPM includes two main tasks:

- the 'daily' control of the prospects and project portfolio
- setting up and maintaining a project infrastructure within the parent organization.

A project infrastructure is complex

MPM has an interest in an adequate project infrastructure. All heterogeneous design variables are addressed in a balanced and coherent way:

- strategy
- structure
- systems
- staff
- management style
- culture.

MPM variants

Many operational variants of MPM exist. Variants that mainly differ in the way in which the MPM function is accommodated in a parent organization. Important basic choices are often:

- central or decentralized
- low or highly automated
- in whole or in part
- im- or explicit

Assess the projects (MPM)

Assessment is the assessment of the result and project implementation of current projects. Projects can be stopped or reconsidered based on this assessment. It also makes it easier to distribute scarce resources.

Why Asses projects?

The scarce capacity requires a critical attitude towards projects and their added value. Most assessment instruments mainly focus on the result. Project implementation is an aspect that's discussed less often. But a full judgment consists of an opinion on both the project result and the project implementation.

How projects assess?

The results and implementation of the project projects are assessed using checklists.

The results are then displayed in a matrix. The following conclusions can then be drawn from the completed matrix:

- projects with a low score on both axes are better stopped
- projects should be reconsidered for a low result score and a high performance score; are there alternatives available that can achieve a better result with greater certainty?
- projects with a high result score and a low implementation score must be better managed: for example by additional measures to improve project implementation.

Prioritize the projects (MPM)

Projects often have to 'compete' for scarce resources such as money, time and knowledge. Prioritizing is then an issue and prioritizing also helps to use scarce resources as profitably as possible.

Investment priority

Investment decisions about projects are about finances; the costs and benefits. Obviously, there are also other (commercial, political, organizational) considerations about whether or not to do a project. External factors (new legislation, monetary changes) also play a role in determining the right investment projects for an organization.

Connecting points

There are three starting points for investment decisions in which all kinds of factors can be classified:

- business relevance: for example customer relationships, operational processes, innovation, learning and growth
- urgency: the factors that make a project necessary. Notable examples are the introduction of the euro and the new tax system. Market opportunities or systems that no longer function properly also score on urgency
- feasibility and risk: identifying technical and organizational risks in advance. This makes it possible to estimate the (in) certainty with which project results can be realized.

In a scoring model, all these factors can be clearly related to each other.

Application levels

This scoring model can be used at various levels in an organization. Namely at the level of:

individual projects. For each project, it can be determined whether the expected returns / benefits outweigh the project costs (including matters such as use, management and maintenance). At the end of the initiation phase of a project, the project assignment is available as a decision document. This decision document contains a description of:

- the goals
- the intended project result
- the demarcation
- the substantive activities
- the management plans for time, money, quality, information and organization with margins for any risks

division / department. A department of an organization can align various projects with a given task. Based on this, she can make optimal use of a given budget space. If specific opportunities arise to generate additional revenues (market opportunities) or to engage in other valuable activities, the budget can be accounted for separately to the client.

managing board. At a strategic level, the scorecard can provide guidance in determining priorities between projects. In this way, top management can determine the right balance between matters such as:

- short and long-term returns
- urgency and relevance
- risks and feasibility
- opportunities for different departments.

Prioritize benefits

Prioritizing based on investment calculations for the entire organization has many advantages. In addition to better financial control, there are also advantages in terms of better pro-active planning in various parts of the organization. It's then possible:

- establish a substantiated and result-oriented project budget
- prioritize projects in a more substantiated manner
- anticipate personnel and organizational changes
- better anticipate the required qualitative and quantitative staffing.

In this way, profitable projects and organizational objectives can be directly linked.

Process management vs Project management

The book 'Management of Processes' by Titus Bekkering and Jaap Walter provides a clear counterbalance to the manufacturability thinking that's so characteristic of project management.

Closed system

Projects are primarily about controlling a closed system. A project manager has the assignment to deliver the agreed result. Sometimes (or often) a manager has to deal with a mobile, unpredictable environment, where unpredictable processes take place. These are issues that have characteristics such as unstructuredness, connectedness with many parties and dynamic (problem definitions and perceptions of solutions shift over time).

Layering, ambiguity

While the project-based approach lends itself well to controlling the 'inside' of the closed system, the project, the process-based approach is more applicable for understanding the context and controlling the environment. The process manager operates in situations characterized by stratification, ambiguity and interaction or as the authors say: things are often not what they seem. Due to the interaction, there's constant movement and perspective change. Often there's an unclear or shifting center of power.

The process manager

The central idea in process management is that a process starts with an idea and then gets going when there's an exchange of facts and figures (factors) on the one hand and opinions or insights (from actors) on the other.

Management with seven control variables

The project manager manages his project with the five management aspects of time-money-quality-information-organization, the process manager manages (Bekkering and Walter call it 'directing') the process with seven 'control variables', the 7-T's:

- Theme: Determine the subject and frame it
- Timing: Choose the right moments
- Tempo: Determine the speed
- Access: Select the participating parties
- Theater: Create the right environment
- Tone: Communicate appropriately
- Tol: Are you aware of everyone's contribution

Process management for unstructured problems

Project management is a smart working method for issues where it's possible to draw up a clear problem definition, to formulate a common goal, to draw up an unambiguous result description and to make realistic plans. Process management helps manage unstructured problems.

Problem definition clear? Project management!

Project management is a smart working method for issues where it's possible to draw up a clear problem definition, to formulate a common goal, to draw up an unambiguous result description and to make realistic plans. However, project management is unsuitable for unstructured problems that occur in a 'network of dependencies'.

This's the situation where, according to De Bruijn et al., Others don't accept the problem definition, goals and schedules of the initiator up to a change. In addition, it's often the case that the initiator is dependent on other parties for a change. Parties that are often not convinced by substantive arguments of the initiator.

Everything moves with unstructured problems

"Unstructured problems" are problems for which there's no clear and / or authoritative solution available. There are three reasons for this:

- no objectifiable information is available
- there's no consensus on the standards to be used in problem solving
- problems and solutions are dynamic.

In projects, people accept an authority relationship.

In a project, the decision-making process is initiated by the hierarchically superior. The other parties involved in this decision-making process behave cooperatively (partly as a result of their hierarchical subordination to the person who formulates the problem). When there's no subordination, project management isn't appropriate, but a process approach is desired.

Decisions in rounds

While the decision-making process for a project is regular and linear, in a process this takes place in 'rounds'. In a round, those involved make a decision or try to prevent it. A round ends at some point and yields a preliminary outcome, including winners and losers. The decision-making seems to have ended with this, but a new round may just present itself.

According to De Bruijn, a process approach to change means that:

- the emphasis in the change shifts from the content of the change to the way in which it'll come about
- agreements are made in advance between the parties involved about how the decision-making process will proceed
- these process agreements provide sufficient space for each of the parties involved to serve their own interests.

The process manager ensures that the change process runs smoothly. So: that the parties keep to the agreements, that the parties are heard, that there's good communication, that decisions are made in accordance with the rules of the game, and so on.

PMBoK

PMBoK stands for the Project Management Body of Knowledge. It's a registered trademark in the USA of the project Management Institute Inc. The PMBoK is a good, stable and well thought-out internationally recognized project management method.

This method is described in the PMBoK Guide 2000 edition. The PMBoK is based on years of best practices in the USA.

The PMBoK in an Organization

Within an organization, this method can be applied to all projects. Then it's important to carefully safeguard that use in the organization.

Three elements can be distinguished within the PMBoK:

- processes
- focus areas
- techniques.

Use of the PMBoK

The PMBoK can be made ready for any concrete project and the concrete project situation. Failure to do so could easily lead to frustration and project failure.

5 processes of PMBoK

The Project Management Body of Knowledge (PMBoK) consists of 5 processes, 9 focus areas and 39 techniques.

Each PMBoK project phase has five processes

Five processes emerge in each phase of a project. In other words, the five processes are repeated at every project phase. Information flows run between these processes. The output from one process is again input for the next process. The processes that can be distinguished within the PMBoK are:

- initiation
- planning
- implementation
- control
- closure.

9 knowledge areas of PMBoK

In addition to five processes, the PMBoK consists of nine areas of attention or knowledge. The PMBoK Guide lists the import and export of each area of ​​attention, as well as the associated supporting techniques.

These focus areas are linked to the sub-processes of the five main processes mentioned (initiation, planning, implementation, control and closure).

The nine focus areas of the PMBoK are:

- integration management
- scope management
- time management
- cost management
- quality management
- human resource Management
- communication management
- risk management
- purchasing management.

Program management

Project management, program management and process management are good tools for planning and executing assignments. Which tool is most adequate for which assignment depends on the assignment, the client and the setting in which the assignment must be carried out.

The difference between programs and projects is more than a question of quantity, lead time and size. Where a project focuses on the realization of one pre-agreed result, a program focuses on pursuing more, sometimes mutually conflicting goals. That makes project management something fundamentally different from managing programs. But there are also similarities: both projects and programs focus on focusing and bundling the energy of those involved to realize a unique assignment in a planned manner.

The core of both approaches is:

- consciously choose a specific approach to a problem
- working in a systematic manner helps with assignments where routines and improvisations fall short
- distinguish the responsibility for achieving goal from that for results
- pay close attention to the roles and cooperation between those involved
- planning, monitoring and conscious steering form an important basis
- consciously and carefully choose to stop, adjust or continue
- it's people who have to do it, so ensure a good balance between man and method

Agile project management

It's a misconception that Agile is a project management methodology such as PRINCE2 and PMW. Agile is a counter-current to the traditional software development methods, of which the waterfall method is the best known.

What's agile?

Agile project management is increasingly referred to in projects that aim to develop software. Below is a brief explanation of what agile is and why it receives so much attention.

It's a misconception that Agile is a project management methodology such as PRINCE2 and PMW. Agile is a counter-current to the traditional software development methods, of which the waterfall method is the best known.

New insights: a new project goal

With traditional methods, the result, the preconditions and other matters of the project are recorded in detail at the start of a project. These principles are then established during the implementation of the project. In practice, it appears that this doesn't work well enough, specially for projects with a long lead time. New insights regularly arise during the project. Insights that the user organization has adjusted the project goal in relation to the original goal.

Agile approaches accept these changing specifications as a 'fact of life' and try to integrate them into the development approach. This's done by an 'adaptive' approach. Development methods that lend themselves well to tackling a software agile development process are:

- SCRUM
- EXtreme Programming (XP)
- Dynamic Systems Development Method (DSDM).

Responding to changing needs

Agile approach to development processes also requires a different way of project management. The aim is that project teams deliver customer value quickly and recognizable. Project teams work on recognizable (partial) results for the end users. In this way, it can be determined whether the result actually meets the requirements. Then it's agreed what the result of the next iteration should be. Projects respond to changing needs and more complex environments. The focus is on the "troughput", teamwork and leadership.

Budget control a challenge

This presents a number of challenges for the client and project manager, because it isn't closed up in advance which result will be realized when and for what budget. An overall planning is made, but per iteration it's tested whether the functionality provided does indeed meet the customer's wishes. Does this not appear to be the case? Then a new exercise will follow, of course with the application of the acquired insights.

From a control perspective this's new for clients, it's difficult to fit into existing budgeting systems of organizations. It's good news for (ICT) projects to succeed, because in principle only meaningful functionality is developed.

Characteristics of agile

An agile project approach is characterized by development in defined periods (time-boxes; preferably a maximum of 6 weeks) with a fixed budget and result, the so-called iterations. At the start of each iteration, it's determined together with the user (s) which things are developed. After each iteration there's a functionality available that can actually be put into production.

This's in direct contrast to the traditional development approach; after all, 'something' is only delivered for the end user (s) at the end of the total project. It's clear that this places demands on ICT departments in the field of testing and production of new versions.

Tools

The following tools can be used in an agile approach:

- the planning game (the planning game: meeting in which it's determined which parts will be included in the next iteration)
- small releases (small versions: better a number of small versions that have direct customer value, than one large one for which the customer value is less certain)
- metaphor (metaphor: metaphors are often spoken to clarify something. Example is the "scrum" from American Football as a way of talking to each other)
- refactoring (reuse of components: not developing the same thing twice)
- coding standards (use of standard programming code instead of customization)
- pair programming (programming in pairs:
- 1 + 1 = 3 and important for transfer of work, appreciation by employees increases)
- 40-hour week (40-hour work week is sacred: no work to take home!)
- on-site customer (on location at the customer: programming between the customers)

Tackle conditions for agile

The agile approaches look for solutions that are realistic for large IT projects. For the approach to be successful, a number of conditions must be met, namely:

- large solution space
- senior developers / employees with a high task maturity
- very variable project requirements
- small number of developers
- culture that thrives in chaos
- mature ICT management organization
- good relationship between client and project manager.

Change management versus agile approach

For example, change management also works with the traditional project management methodologies to manage the changing user wishes. But showing results to end users within a short period of time and involving them in the definition of the result of a subsequent iteration is new and promising.

Share on Facebook Share on Twitter Share on LinkedIn
Back to top


Copyright 2011 - 2020 - All Rights Reserved