Traditional Project Management
Characteristics of traditional project management
- The term “Traditional Project Management” is typically reserved for project management methodologies which contain following characteristics:
- A rather strict implementation of the project life cycle (Initiate - Plan - Execute - Close) or a variant of this life cycle. These methodologies follow a waterfall approach to some extent where the project is divided in clear stages, each with their own tasks and deliverables. Furthermore, the implicit assumption is that once one moves from one stage to the next, the decisions made in the previous stage are more or less fixed.
- Traditional project management approaches put a lot of emphasis on the process aspect of project management. The aim of project management is to ensure that the project follows the predefined process (process compliance).
- A key element of traditional project management is context stability. Typically, these approaches assume that not only the environment remains stable once the project starts, but also the requirements, analysis and designs once they have been set.
- Within this context of stability, these methodologies focus heavily on predictability of the project. If enough efforts are made such that one can precisely predict the outcomes and risks of a project, in becomes possible to keep the project in control (compliant to the process).
- Given this emphasis on predictability, these methodologies also share their reliance on task breakdown. By breaking down the end deliverable into tasks of increasing detail (and narrowed scope), it becomes increasingly easier to make correct predictions.
- Two well-known traditional project management methodologies are PMBoK and PRINCE2.
PMBoK
Background
- PMBoK has been developed by the Project Management Institute (PMI) which was founded in 1969 as a non-profit organization to foster recognition of and provide support to the project management community worldwide.
- The PMI published a first version of the Project Management Body of Knowledge Guide (PMBoK Guide) in 1996, which to some extent was based on a white paper published in 1983.
- The PMBoK Guide was approved as an American National Standard in 1999 by the American National Standards Institute (ANSI).
- The most recent version of the PMBoK Guide (6th edition) was published in 2017.
PMBoK Guide
- The PMBoK Guide is a “subset of the project management body of knowledge that is generally recognized as a good practice. ‘Generally recognized’ means the knowledge and practices described are applicable to most projects most of the time and there is a consensus about their value and usefulness. ‘Good practice’ means there is a general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chance of success over many projects.” (source: Project Management Institute, A Guide to the Project Management Body of Knowledge – Fifth Edition, Project Management Institute Inc., 2013, Page 2.)
- PMBoK is process-based. It defines a set of processes which describes the work that is typically executed to manage projects.
- Each process is defined by the inputs it requires, the outputs it produces and the tools and techniques that can be applied to turn inputs into outputs.
- Processes are linked to each other as the outputs of certain processes serve as inputs for other processes.
- PMBoK is descriptive in nature. It does not prescribe how one must manage a project. It merely describes a set of processes that can be used to manage a project.
- Each of these processes must be tailored to the specific needs of the project. Decisions such as which processes should be executed, by whom and how rigorously, need to be made by the project management team on a project by project basis.
PMBoK Processes
- PMBoK (6th edition) describes 49 processes in total, which can be organized along two dimensions: process groups and knowledge areas.
- PMBoK identifies 5 process groups which corresponds to different stages in the project management lifestyle:
- Initiating
- Planning
- Executing
- Monitoring and Controlling
- Closing
- PMBoK (6th edition) also identifies 10 knowledge areas which refer to specific disciplines/aspects of project management:
- Project Integration Management
- Project Scope Management
- Project Schedule Management
- Project Cost Management
- Project Quality Management
- Project Resource Management
- Project Communications Management
- Project Risk Management
- Project Procurement Management
- Project Stakeholder Management
PRINCE2
Background
- In 1975, a private organization Simpact Systems developed a project management framework for the development and support of IT systems. This framework was called Project Resource Organisation Management Planning Technique or PROMPT. It contained a specific system development module called PROMPT II.
- In 1989, the UK government licensed the use of PROMPT from Simpact. The Central Computer and Telecommunications Agency (CCTA) only fully implemented the PROMPT II module and adjusted it to create a new standard for IT Project Management. This new standard was called “PROMPT II IN the CCTA Environment” or PRINCE in April 1989. Later, the acronym was changed to “PRojects IN Controlled Environments”.
- PRINCE was released to the public domain in 1990 and the UK government used it for different projects, both IT and non-IT. Over time it became also well adopted by industry, again both in an IT and non-IT context.
- In 1996 PRINCE2 was developed in consultation with about 150 European organisations. In contrast to PRINCE, PRINCE2 is a generic project management framework designed to be industry-agnostic (not with IT industry in mind as PRINCE did). Over time, PRINCE2 became a project management standard in Europe.
- Over time, PRINCE2 went through various revisions, with the latest update in 2017.
PRINCE2 Fundamentals
- PRINCE2 is not only process-focused, but also very much product-focused. This is reflected in its definition of a project: “a management environment created for the purpose of delivering one or more business products according to a specified business case”.
- This product-focus is also reflected by the emphasis put by PRINCE2 on the project’s business case which is considered the main driver behind the project.
- In contrast to PMBoK, PRINCE2 is much more prescriptive than descriptive. PRINCE gives specific guidelines how project management should be organized, structured and implemented.
- Nevertheless, PRINCE2 also clearly states that the PRINCE2 framework must be tailored to the needs of the project at hand.
- This can result in project management implementations that started from PRINCE2 but tailored away almost everything specific to PRINCE2. Such project are sometimes called PINO projects (PRINCE2 in name only).
PRINCE2 Principles
- PRINCE2 is based on 7 principles which cannot be tailored. They should be reflected throughout the actual project management implementation (source: Wikipedia):
- Continued Business Justification: The business case is the most important document, and is updated at every stage of the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case.
- Learn From Experience: Each project maintains a lessons log and projects should continually refer to their own and to previous and concurrent projects’ lesson logs to avoid reinventing wheels. Unless lessons provoke change, they are only lessons identified (not learned).
- Defined Roles and Responsibilities: Roles are separated from individuals, who may take on multiple roles or share a role. Roles in PRINCE2 are structured in four levels (corporate or programme management, project board, project manager level and team level). Project Management Team contains the last three, where all primary stakeholders (business, user, supplier) need to be presented.
- Manage by Stages: the project is planned and controlled on a stage by stage basis. Moving between stages includes updating the business case, risks, overall plan, and detailed next-stage plan in the light of new evidence.
- Manage by Exception: A PRINCE2 project has defined tolerances (6 aspects above) for each project objective, to establish limits of delegated authority. If a management level forecasts that these tolerances are exceeded (e.g. time of a management stage will be longer than the estimated time in the current management stage). it is escalated to the next management level for a decision how to proceed.
- Focus on Products: A PRINCE2 project focuses on the definition and delivery of the products, in particular their quality requirements.
- Tailor to Suit Project Environment: PRINCE2 is tailored to suit the project environment, size, complexity, importance, time capability and risk. Tailoring is the first activity in the process ‘Initiating A Project’ and reviewed for each stage.
PRINCE2 Themes
- PRINCE2 identifies 7 themes which are parts of the project that need to be continually addressed throughout the project life cycle. In some sense, these correspond to the Knowledge Areas in PMBoK. The 7 themes imply activities at the start of the project to set up the project as well as activities throughout the project life cycle to monitor these themes. The seven themes are:
- Business case
- Change
- Organization
- Plans
- Progress
- Quality
- Risk
PRINCE2 Processes and Activities
- PRINCE2 is process-based and defines 7 processes that consist of a structured set of activities designed to accomplish a specific objective. Note that processes in PRINCE2 are defined at a higher level than in PMBoK. What PMBoK calls processes are defined as activities in PRINCE2.
- The Processes in PRINCE2 have a strong resemblance to the different phases of the project life cycle, with the addition that it assumes that a project is defined into separate stages (i.e. one of the core principles).
- The 7 PRINCE2 Processes are:
- Starting up a Project
- Initiating a Project
- Directing a Project
- Managing a Stage Boundary
- Controlling a Stage
- Managing Product Delivery
- Closing a Project
- PRINCE2 identifies 40 different activities across the 7 processes for which it clearly states what needs to be done and by whom.