What is the value of ISO 21500? This new globally accepted project management standard is recognized as a foundational reference for the application of project management knowledge and good practices. Research has confirmed that, when managing projects, the structured application of this fundamental knowledge and good practices clearly enhances successful delivery. Project environments that consistently apply this fundamental project management good practice approach not only show better project performance in terms of lower costs and shorter delivery times, but they also demonstrate higher levels of customer satisfaction. The application of the project management good practices, as described in ISO 21500, will support you in realizing these benefits.
In addition to the above, when working in a project management environment, for which the organization is far more dynamic than ‘normal’ operations, there is an increased need for good communication. To achieve this, it is important to use ‘one common language’ within your project management environment, which is understood by everyone involved, particularly the key stakeholders of the project. This pocket guide aims to quickly establish a shared vocabulary and terminology on the project management fundamentals and create a common understanding about the basic project management processes together with the key roles and responsibilities. Moreover the guide provides a high level description of how the ISO 21500 guideline can be applied in practice, using a ‘generic’ project life cycle as a reference.
What it’s not? It is definitely not ‘the’ solution for all challenges when managing projects. The project manager and the team remain ultimately responsible for deciding what good practices shall be applied to the specific project at hand, in close cooperation with the project sponsor and the management of the line organization or sponsoring entity.
In a nutshell, this pocket guide is intended as a key contributor and tangible asset when introducing and reinforcing concepts of project management in your organization for improved communication and cooperation. It supports an organization-wide implementation of a project management culture, bringing you the benefits of ‘your projects executed right the first time’! At the organizational level this can be enhanced by implementing a project management approach, based on these good practices.
Every organization has its unique culture and faces diverse challenges. Also, organizations start with a different situation and set of problems to be resolved. In order to define the value of project management, we firstly need to define exactly what is meant by project management, as this is a broad concept. Then we can look at the various aspects of project management and show the value associated with each aspect.
Project management – ISO 21500 definition:
Project management is the application of methods, tools, techniques and competences to a project. Project management includes the integration of the various phases of the project life cycle. Project management is accomplished through processes.
Research shows that, with the increasing complexity and faster changing environments that businesses are faced with, projects managed by the structured application of good practice-based processes show consistently better performance in areas such as, but not limited to:
'Deliver as promised' by realistic expectation-setting through up-front project definition, planning, and estimation.
Faster delivery through the reuse of common and known project management processes.
Less ‘surprises’ during project execution, utilizing proactive project management processes.
Improved customer satisfaction and less rework by delivering the right product or service, right, the first time.
These opportunities together with the savings offered by organizational project management excellence are all tangible. But the value proposition for project management is much greater and also includes less tangible benefits like:
- A highly committed and motivated team that can work together through effective communication and goal setting.
- An inspiring project environment with a ‘can-do’ mentality through ambitious yet realistic commitments.
- Transparent and improved decision-making at all organizational levels through more effective communication.
These qualitative benefits will even reinforce the quantitative advantages, which will guarantee that an organization is able to excel.
Many organizations have built a good reputation for being able to consistently deliver top quality projects. However, a majority of organizations are still struggling with this. Do you recognize the following characteristics?
- Projects mostly deliver late, over-budget, or without meeting the functionality requirements of the project sponsor and end-users.
- Project managers do it ‘their way’ as there are no, or poor, standards for project management processes and techniques. - Project management is regarded as an overhead instead of being recognized as providing business value; - The project work undertaken by resources from within the line organization is not carefully planned for as part of the operations planning, but is typically regarded as ‘next to your primary function’.
- Project budgets do not include the cost of the internal workforce as they are ‘already paid for’.
- There is no overall insight available on all the projects being undertaken in the organization, nor their cost versus the added value.
- The required work for managing projects proactively is not included in the project plan.
- Projects may be somehow ‘successful’ in the end but only through heavy stress and overtime work.
We have identified some typical questions that one could ask when first confronted with project management or the ISO 21500 guideline.
Project – ISO 21500 definition:
A project is a unique set of processes consisting of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective. Achievement of the project objective requires deliverables conforming to specific requirements, including multiple constraints such as time, cost and resources.
- This means: It has a defined start and finish, therefore a project is temporary.
- ‘Something’ is finished when the project is finished; it creates an end deliverable, the project objective.
- It is not business as usual, and as a consequence does not follow normal procedures, because there is something unique to it.
- Given the above, it needs a specific organization for the coordination and control of this unique set of processes.
Although within an organization some projects may be similar, each project is actually unique as differences may occur e.g. in the deliverables provided by the project, the stakeholders influencing the project, the resources used, the way processes are adapted to create the deliverables, etc.. Because there are projects of all types and levels of complexity, the project management activities and the underlying processes should be geared to the project at hand. But it’s the organization’s responsibility to firstly decide if the desired objective should be realized through undertaking a project. If that is the case, then the project should be organized accordingly.
While there is no agreed definition of a ‘profession’, you could describe it as: ‘A disciplined group of individuals who adhere to defined ethical standards and uphold themselves to the public as having specific knowledge and skills in a generally recognized, organized body of learning, derived from education and training, and who apply this knowledge and these skills in the interest of others.’
With projects getting more and more complex, the demands on a project manager’s competence are also increasing. For example, everyone can apply a bandage to a wound but that does not make everyone a doctor. The need to obtain specific skills, knowledge and education, in order to successfully fulfill the role of project manager, is generally recognized. This is even confirmed in the academic world where Masters degrees in project management are now available.
Characteristics of a professional discipline also include the use of a common vocabulary. The ISO 21500 terms and definitions provide a foundational professional vocabulary of specific project management terms, in addition to commonly used terminology, which is already defined in the Oxford Dictionary.
Given the fact that, due to the ISO processes being followed for the creation and global acceptance of the content of ISO 21500, apparently there is consensus about what can be regarded as a set of foundational:
Terms and definitions.
Concepts, including competences.
Processes.
ISO 21500 also states that successful management of projects requires people who are competent in project management principles and processes. ISO 21500 defines, but does not limit, at least three categories of project management competences which are needed in order to apply project management:
Technical competences, for delivering projects through applying the project management processes in a structured way.
B ehavioral competences which refer to the capabilities required to build and reinforce relationships, beneficial to the project, within the organizational environmen.
Contextual competences, which relate to adjusting the project management processes to the organizational environment.
One can, therefore, safely conclude that ‘project management’ has matured into a profession.
Line organizations are typically function-centric and, in general, focus on ongoing day-to-day operations, while ‘doing their thing better’. Operations can therefore become resistant to (major) changes, particularly when the driver for such a change lies outside their own functional responsibilities and needs.
Projects and project management, on the other hand, are all about implementing necessary changes in operations, in order to stay in business. The realization of the project’s objective and its application in operations might even threaten the effectiveness and efficiency of specific operational entities (e.g. departments, business units), but is nevertheless executed to enable whole organization to perform more effectively.
And the reality is that hardly any organization can survive in today’s environment without having projects. At times they are not formally recognized but organizations undertake them anyway. The increasing number of ‘reorganizations’ reflect this, with a constant drive for ensuring that the line organization keeps up with the increasingly complex and ever-faster changes in the environment. The increasing number and scope of changes, as well as the risks associated with these, are demanding greater focus and attention on projects, together with the need for a more professional approach towards project management. This is because this type of professional approach ensures that the changes are delivered and managed in an appropriate way. It will support line organizations in continuing to ‘do the right thing, the best way’ and getting ahead.
ISO 21500 describes a professional approach towards project management, which is applicable to most projects, most of the time. It is, therefore, very likely that your projects can benefit from it. This approach is based on its proven value and benefits in practice, through the contribution of hundreds of experts in the project management profession, from all over the world, who base their expertise on the experiences of thousands of project practitioners worldwide in conjunction with in-depth studies. Making this knowledge available to a wider audience, in a well structured and easy to understand way has been the key-driver for developing this standard; for the aim is improved communication and cooperation in projects environments, thus increasing project success.
ISO 21500 is referred to as an informative standard; a guideline. A guideline can be defined as a basic conceptual structure to allow homogeneous handling of different business processes grouped together. It also increases management discipline. It pre-defines common deliverables to and from each business process. A guideline provides a model with a well-defined tactic to master the complex environment of an organization in a simple fashion. It acts as a taxonomy or map of the entire body of project management knowledge.
A method is defined as a particular procedure for accomplishing or approaching something, especially a systematic or established one3. A method not only mentions the process, but also describes how a task is completed; a more detailed prescribed way to execute the processes.
A methodology is defined as a system of methods used in a particular area of study or activity4.
Being a basic reference ISO 21500 is a guideline rather than a method or methodology. Although the common project management processes are described (the ‘what’), they do not prescribe the exact way of doing (the ‘how’). In practice, for the implementation of this guideline, several project management methods and methodologies can be defined and applied, and then fine-tuned towards the application area and specific subject of the projects. But before one can select, define, or apply any project management method or methodology, there should first be a thorough and common understanding of the project management terms and definitions, concepts and processes.
Certification, also known as third party conformity assessment, is the provision by an independent body of written assurance (a certificate) that the product, service or system in question meets specific requirements. Many companies and organizations decide to get certified to one of ISO’s management system standards, such as ISO 9001 as a way of showing outsiders that the organization has an effective quality management system in place.
As ISO 21500 is an organizational standard, with currently the status of a guideline or ‘informative standard’ one cannot obtain an ISO certification (like with ISO 9001). It is expected that over time, when the market shows an interest, the guideline can be upgraded to a ‘normative standard’. In that case organizations can be certified by nationally acknowledged accreditation bodies. In the meantime, however, organizations can perform a ‘self-assessment’.
Because ISO 21500 as ‘informative standard’ now, or ‘normative standard’ in the future, is aiming at organizations and not at individuals, individual certification is not possible.
However there is a globally recognized individual certification track, organized by PMI, using A Guide to the Project Management Body of Knowledge (PMBOK® Guide) as a reference. There is huge similarity in the structure and content of ISO 21500 and the PMBOK Guide:
PMI uses the PMBOK Guide (and therefore essentially ISO 21500) as a basis for its globally recognized individual Project Management certifications for the typical project manager roles: Certified Associate in Project Management (CAPM) and the Project Management Professional (PMP). Based on the above, one can safely conclude that a PMI certified project manager (PMP) not only understands the ISO 21500 concepts, but is able to apply these in practice as well. PMI does not issue organizational certifications in the same way as ISO or ANSI, however PMI does offer Organization Project Management Maturity Model (OPM3) as an assessment method for organizations.
Also IPMA maintains an individual certification track, which uses the three competence areas as a reference. Within these three areas more detailed competences are defined, including possible process steps. Most of these competences clearly relate to the ten Subject groups as defined in ISO 21500. Other competences are more related to methodologies which are not part of ISO 21500. IPMA also does not issue organizational certifications in the same way as ISO or ANSI. However IPMA is developing IPMA Delta as a project management assessment for the entire organization, due Autumn 2013.
As ISO 21500 is based on globally recognized and accepted good practices, it can effectively act as a ‘foundational worldwide lessons learned database’ for project management. Based on its structure and well defined processes, it will definitely turn the mind-set in organizations from an ‘ad-hoc’ and fire-fighting mode (reactive management), which is still too often experienced in projects, towards a more proactively oriented and well organized approach (project management). It enables you, your project team and project stakeholders, when faced with challenging project situations, to proactively refer to the appropriate project management processes and fine-tune these to your project. It directly enhances project communications by creating a common understanding of ‘projects’, ‘a shared vision on how to best manage these’, resulting in a shared project management approach for successful team work.
ISO 21500 provides a guideline that is generally accepted as global good practice for project management. Therefore it is a perfect guideline for creating and understanding your organizational project management approach, which needs to fit with your specific projects in your specific environment. This is typically where the project management processes and the content creation processes should be integrated.
‘Drowning’ people in several different approaches, with different backgrounds and definitions and having each individual doing their own ‘integration exercise’, is likely to cause confusion, errors and miscommunication, as well as being inefficient. A well-organized comparison of the processes, terms and definitions of ISO 21500 with the processes, terms and definitions of other methods, practices and models applied in your organization, will enable a quick identification of any potential overlap, and enable effective integration in an appropriate way. In Chapter 7 we provide additional insights into how ISO 21500 compares to other commonly used project management methods, practices and models.
Organizations develop procedures for delivering results in a predictable way that allow them to manage expectations. However, as most projects are cross-functional, several organizational entities typically come together in projects and are required to deal with situations not encountered before, and for which no procedures are defined (as yet). When projects result in changes in organizations, different stakeholders are involved at different organizational levels, i.e. operations level, tactical level, and even strategic level. Therefore the understanding and application of a common organization-wide reference for managing projects, such as ISO 21500, is of particular value in such situations. In separate sections of the concepts in Clause 3, ISO 21500 addresses ‘Organizational strategy and projects’, ‘the Project environment’, ‘Project governance’ and ‘Projects’ and ‘Operations’ as well as how these can interact.
Organizationally developed project management methods and practices typically stem from a recognized need for improvement in the application of project management, based on organizational experiences and good practices. As ISO 21500 is also quite often based on the same, practices, the majority of your own project management method will not drastically change. However, maintaining your own developed good practices, as well as ensuring continuous alignment with the latest developments in the project management profession and possible changes in your environment, or internal processes can become very costly and time consuming. This could be a key driver for organizations to switch to ISO 21500 as their basic reference for a project management method or practice and only adjust this where necessary for their specific projects and environments, and document these changes or additions transparently. Following the Pareto rule; around 80% of the guideline is likely to be generally applicable to your type of projects. This allows a focus on the specific 20% of the project management processes that form the uniqueness of your specific organization and project environment. This then becomes the heart of your own project management method or practice.
The generic publicly available project management methods, practices and models are now starting to point to ISO 21500 as a basic reference (PMI’s PMBOK Guide – Fifth Edition, January 2013; IPMA’s ICB version 4.0, due Autumn 2014; IPMA Delta - project management assessment for the entire organization -, due Autumn 2013; The GPM Reference Guide to Sustainability in Project Management5, January 2013). In such cases the knowledge contained in ISO 21500 substantially supports the better understanding and positioning of these project management methods, practices and models, thus reinforcing the correct application.
As this is a pocket guide, it should be viewed as an introduction to and summary of ISO 21500. Many more details and explanations on certain topics can be found on the ISO website, or more specifically in the document ISO 21500:2012 Guidance on project management, or the national version of this.
This chapter describes the ISO organization, the development process of its standards and the background, benefits, structure and future of the ISO 21500 document.
ISO (International Organization for Standardization) is the world’s largest developer of voluntary international standards. It was founded in 1947 and since then has published over 19,000 international standards, which give state of the art specifications for products, services and good practice, helping to make industry more efficient and effective. ISO is a network of national standards bodies in 164 countries, which make up the ISO membership and represent ISO in their country.
ISO mission:
ISO objectives:
‘Conformity assessment’: checking that products, materials, services, systems, processes or people measure up to the specifications of a relevant standard or specification. Today, many products require testing for conformity with specifications or compliance with safety, or other regulations before they can be put on many markets. ISO guides and standards for conformity assessment represent an international consensus on best practice. Their use contributes to the consistency of conformity assessment worldwide and so facilitates trade.
‘Certification’: ISO does not carry out accreditation or certification to any of its standards; there exist many testing laboratories and certification bodies which offer independent conformity assessment services.
Via the national standards bodies, subject matter experts from all over the world participate in the standards development through a global, open and transparent process aimed at achieving consensus. The forming of a shared view on the contents of a standard is a long process, but this means in the end that the ISO standards are widely supported.
The development process is organized via:
Project or technical committees, which formulate the scope of the standards and organize meetings with international experts to discuss and write the contents of the standards and process the received comments;
National mirror committees, which appoint subject matter experts to take part in the development and comment on the draft standards.
On average, developing an international standard takes approximately four years.
ISO develops international standards. A standard is a voluntary agreement between stakeholders on a product, service, result or process. The agreements contain terms and definitions, functional and performance related requirements, processes, measuring methods and good practices.
Two kinds of standards exist:
If one talks about a standard one normally means the prescriptive standard. A descriptive standard is often called a guideline. A guideline presents the course of action with regard to the demands of goods, services and people. A guideline does not specifically describe what to do, that is the goal of a prescriptive standard. Prescriptive standards are often the next logical step, after descriptive standards have been implemented in organizations and have globally been accepted as a good practice.
This section discusses the economic driver for developing ISO 21500, along with the process and the sources which have been used for its creation.
One-fifth of the world’s GDP, or more than $12 trillion, will be spent on projects each year in the next decade1. This is an enormous investment, which calls for prudent spending and proper management control.
Since the industrial revolution, standardization has been an important prerequisite for growth. Recent research indicates that today’s businesses face economic pressure from clients and other stakeholders to meet their needs faster and more cheaply than ever6.
In today’s world, investments and organizational changes are realized via projects and programs of related projects. For many of these projects a variety of disciplines and a mix of internal and external workers are involved. All these people need to cooperate in a proper way, everyone has to carry out his/her tasks effectively and, at the same time, all this work must be aligned and executed in a process-driven way. A great number of project management methods and practices exist. Who can apply these properly? Which method should be chosen in a multidisciplinary project? How does one communicate with the stakeholders? These questions do not have easy answers.
In the past there have been a number of initiatives aimed at developing global project management standards, like Global Project Management Forum (from 1994), PMBOK Guide (ANSI standard, First Edition in 1996), Operational Level Coordination Initiative (OLCI, from 1999), Global Alliance for Project Performance Standards (GAPPS, from 2002) and ISO 10006 – Quality management systems – Guidelines for quality management in projects, 2003). They all failed to produce one body of project management knowledge that was accepted globally. ISO 21500 – Guidance for project management is the step towards the true world standard for project management.
In 2006 the United Kingdom submitted a proposal to develop a new international standard for project management, which later became known as ISO 21500. With the forthcoming 2012 Olympic Games in London they realized that their current standard developed by the BSI (British Standards Institution) needed a revision. The United States supported this proposal and it went for ballot to the 164 countries that have an ISO representation. A majority of ISO members voted positively and the ISO/PC (Project Committee) 236 was established at a meeting in October 2007 in London with the charter to develop the standard.
Hundreds of project management experts and their mirror committees from more than 30 countries have co-operated during the five years of its completion. The participants have discussed the contents, wrote the body text and processed more than 1,000 comments that came up per draft version. An international project team that worked very well together came into being, because the same 80 – 100 delegates participated in the various international meetings.
The large project management associations were involved in various ways. PMI (Project Management Institute) was the secretary of ISO/PC 236. IPMA (International Project Management Association) formally took part in the development in a liaison role. There was no noticeable representation of UK’s Cabinet Office (owner of PRINCE2). Of course, a number of experts in the working group were also members of these associations or holders of their professional certifications and have represented the associations’ views via their involvements.
ISO 21500 has a broad target audience that uses various sources for project management. Therefore, the support for the guideline – first by its developers and later by its users – had to be the core of project management that is relevant for everybody. All country mirror committees had the opportunity to bring in relevant sources of project management as input for the guideline at the start of its development in 2007. They proposed the following national standards:
1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Third Edition, Chapter 3 and Glossary, PMI Inc., 2004 – the American ANSI standard.
2. DIN 69901 Project Management: Project Management Systems, DIN, 2007 – the German DIN standard.
3. BS 6079 and BS ISO 15188:2001 – Project management, BSI, 2001 – the English BSI standard.
In the course of the ISO 21500 development other market standards and existing ISO standards have been used as reference materials:
2. PRINCE2 (PRojects IN Controlled Environments) – by Cabinet Office, previously OGC.
ISO 9001 – Quality management systems.
ISO 10006 – Quality management systems – Guidelines for quality management in projects.
ISO 31000 – Risk management – Principles and guidelines.
The ISO 21500 guideline is not a new project management standard, but a reference for other project management standards, methods and best practices, such as PMBOK, PRINCE2, Agile and ICB. It does not compare one against the other, but brings the best project management practices together.
The importance of ISO 21500 is that it introduces one global standard and language for the project management practice. It is overarching and a reference point for all projects in all organizations.
One can use the ISO 21500 guideline as follows:
As a reference in an audit. If an organization’s project management practice complies with the requirements and criteria of ISO 21500, it has a good foundation for competent project managers to achieve proper project results. At the same time, the organization can prove both internally and externally that it delivers quality projects, because they have based it on the independent standard. Indeed, this guideline does have direct influence on the project execution, but not on the project result as such.
As a link between different project management and business processes. ISO 21500 can supplement the ISO 9001 for quality management, especially in the area of continuous improvement: realizing the necessary and wanted improvement processes in operations with minimal disturbance of the production and service processes.
As a checklist to prove the knowledge and skills of project managers and project workers in executing projects. The guideline looks at one project at a time. It does not refer to more complex situations, like multi-project management or sub-projects. This makes the guideline accessible for a broad target group, who can simply relate their own role to the guideline. ISO 21500 strongly emphasizes the role that the environment plays during the execution of the project in order to maximize the added value of the deliverables of the project.
As a common reference (bridge function) between different methods, practices and models Existing project management methods like PRINCE2, collections of good practices like the PMBOK Guide, and competence models like ICB 3.0, provide an anchor to the project manager when running a project. A concise and clear guideline will attract parties that are not familiar with these existing methods, practices and models;
As a common language in project management. ISO 21500 bridges the differences and reinforces the similarities between the many parties that often work together in a project: sponsor, project manager and his colleagues, project organization, project workers, customers, users and/or the internal organization. ISO 21500 supports the communication between the related parties by offering a common language. A common language is also essential with international and/or multi-disciplinary projects, where different teams work with different methods, and where cooperation is necessary. The guideline can then be a binding factor by relating the processes and deliverables of the different methods to those of ISO 21500.
This section highlights the scope and the structure of the ISO 21500 contents.
The scope of ISO 21500 is to provide guidance for project management and may be used by any type of organization and for any type of project.
The guideline provides a high-level description of concepts and processes that are considered to form good practice in project management.
Projects are defined in the context of programs and project portfolios. Guidance on their management will be the subject of separate ISO standards.
The structure of ISO 21500 The guideline is structured as follows:
Clause 1 covers the scope of ISO 21500, i.e. the management of projects in ‘most organizations most of the time’.
Clause 2 contains 16 project management terms and their definitions. It contains only those specific terms that from a project management practice viewpoint are not properly defined in the standard lists of ISO definitions or in the Oxford English Dictionary. The glossary in Annex B of this pocket guide presents this list of terms and definitions.
Clause 3 describes the concepts which play an important role during the execution of most projects:
Project.
Project management.
Organizational strategy and projects.
Project environment.
Project governance.
Projects and operations.
Stakeholders and project organization.
Competences of project personnel.
Project life cycle.
Project constraints.
Relationship between project management concepts and processes.
In fact these concepts are centered around value creation in an organization (e.g. an internal investment in a business or a (non-) governmental organization) or a sponsor entity (e.g. a railway owned by a governmental entity). The organizational or entity strategy creates opportunities which are evaluated and selected, for example in a portfolio management process. Business cases for selected opportunities may result in one of more projects with deliverables. These deliverables are normally used by operations to realize benefits and thus create value for the organization. The benefits can be input to realize and further develop the strategy. In commercial projects the benefits are realized without passing deliverables to operations.
Clause 4 identifies the recommended project management processes that should be applied to the whole project and/or to project phases. These processes are generic and can be used by any project in any organization or entity. Normally, the project manager and the sponsor select the applicable processes and the sequence in which they are dealt with, depending on the project at hand and the needs of the organization or entity.
The project management processes are viewed from two different perspectives: as process groups from the management perspective of a project, or as subject groups from the perspective of a specific theme (refer to the knowledge areas in PMI’s PMBOK Guide) of the project management practice.
There are five process groups:
Initiating.
Planning.
Implementing.
Controlling.
Closing.
These process groups are based on the well known Deming Circle (Plan-Do-Check-Act) for continuous improvement.
There are 39 processes, divided into ten project management themes, called subject groups:
2. Stakeholders.
3. Scope.
4. Resource.
5. Time.
6. Cost.
7. Risk.
8. Quality.
9. Procurement.
Within the processes all activities are performed that are relevant for managing a certain aspect in a project. All of the processes transfer inputs into useful outputs, which can, in turn, be inputs to other processes. Typical inputs/outputs here are project management documents, such as a project plan, a schedule, a contract, or a progress report. Only the most relevant inputs/ outputs are listed in ISO 21500.
In Annex A of the original ISO 21500 an example of a possible logical sequence of the processes is included for a particular project.
ISO 21500 has been written as a guideline and because it does not contain requirements, it is in principle not meant for certification purposes. This differs from, for instance, the normative standard ISO 9001 ‘Quality management systems’, which describes management systems for an organization to manage and improve its processes or a certain aspect of its operations. An organization can make the effort to become ISO 9001 certified to improve its quality and service to customers and clearly display its performance to the business environment.
As for every ISO standard and guideline, it is likely that ISO 21500:2012 will be updated in the next four to five years to integrate new developments and new best practices for project management. This next version could have a normative nature and then certification of organizations might be possible.
As an intermediate step towards organizational certification, a so called ‘self-assessment’ could be developed. To this extend, the developments which happened for the ISO 21600:2010 may serve as an example. To support and promote the interest for ISO 26000:2010 – Guidance on social responsibility a ‘Self-assessment ISO 26000’ has been developed
This self-assessment is not a certification but is a declaration of how an organization applies the principles and guidelines of ISO 26000. By publishing these self-assessments in a central database, organizations can prove that they operate sustainably and in a socially responsible way.
A similar self-assessment could be beneficial to organizations that run projects. Nowadays tenders for project work often prescribe that the supplier uses a specific project management method. One can foresee that in the near future project sponsors will require their suppliers to show that their project management practice conforms to ISO 21500.
Annex A of this pocket guide presents an example of what a ‘ISO 21500 self-assessment’ could look like. At the time of writing this book, there is an initiative in the Netherlands to develop such a self-assessment for the Dutch market.
This chapter provides a definition of the roles and responsibilities and categorizes the stakeholders who can be identified in a project. It then describes typical roles of people working in the project organization, the PMO and the project management consultancy organization. Finally it describes some specific roles in very large (complex) projects and when projects face governmental constraints.
Role and responsibilities of each stakeholder should be clearly defined and communicated during the course of the project. From this it should be evident which tasks they have to perform in the project.
A role is the function assumed or part played by a person or thing in a particular situation11. The project role is the function/title of a person in the project, e.g. project manager, project sponsor, customer.
A responsibility is a thing which one is required to do as part of a job, role, or legal obligation12. The project responsibilities are the clear description of what each person working in his/her project role should do, including the person’s authorities and accountabilities.
A task is a piece of work to be done or undertaken. Project tasks include activities to actually create (part of) the project objective (also often called product components or product deliverables) and/or to produce a project document for managing the project, e.g. project charter, project plan, schedule, action list (often called project management products or project management deliverables).
An activity is a thing that a person or group does or has done. Project activities are being used to describe the work to be done in a project management process and may include one or more tasks.
The project stakeholders who are in any way affected by the project are described in ISO 21500 and shown in figure.
The project stakeholders are divided in two groups: those within the project organization and within project governance are called the internal stakeholders (grey) and the others are called the external stakeholders (blue).
Project manager – the manager of the project and responsible for the successful completion of the project.
Project management team – the people assisting the project manager in managing the project.
Project team – the people who perform project work.
Typically higher management, the sponsor, the project steering committee and the PMO (project management office) belong to the project governance group:
Project sponsor – the representative of the organization that owns and funds the project;
Project steering committee – the senior managers and the project manager who together direct the project from the perspective of the organizational strategy and the Business case (benefits realization).
PMO – the group that supports the practice of project management and execution. Note: In ISO 21500 the PMO is included with the ‘other stakeholders’, but depending on its role it might also fit in the ‘project governance’ group
Customers or customer representatives – the people that define the requirements and receive the deliverables of the project.
Suppliers (vendors, contractors, third parties) – those that supply human resources, facilities or materials to the project.
Employees, shareholders, business partners, special interest groups, finance providers, regulatory bodies, etc.
In the following paragraphs we describe examples of some specific roles for which knowledge of ISO 21500 can be useful in supporting the application of project management.
In ISO 21500 the PMO (project management office) is one of the stakeholders, see above. The PMO, sometimes called PSO (project support office), can take many shapes in the organization and may perform diverse activities, such as:
Governance, ensuring how projects are directed and controlled.
Deciding on project management methods, tools and techniques.
Training of project management staff.
Planning and control of one or more projects, or of a collection of projects in a program or portfolio.
Project audits and reviews.
It could act at a corporate level, as an ‘independent’ corporate department reporting to the executive management team, or at a lower departmental level e.g. as a team in the section where projects are executed, or it could even be part of the project organization, as is often seen in large projects.
The following roles can be recognized in a PMO:
- Project advisor – the person who (in)directly supports the projects that are being executed, in some way.
- Project controller – the project advisor with the main role to support the project and financial planning and control of projects or collections of projects.
To properly perform these roles some form of standardization of project work is needed; the advisor can use the definitions, concepts and processes of ISO 21500 to shape the project management practice in their own organization. By adopting ISO 21500 the PMO ensures that the organization adheres to a worldwide accepted project management practice, which makes working in or for projects, where many organizations have to work together, more easy.
Nowadays there are many organizations that provide project management consultancy, ranging from training in project management methods, tools and techniques, through to advising on projects or sourcing project staff. Such staff can work as either an internal or external contractor on (part of) a project.
The following roles can appear in a project management services organization:
CEO – the chief executive officer/director of the consultancy organization.
Account manager – the interface between (new) customers and the project staff on (new) work.
Project consultant – the person providing consultancy and advice on a specific project.
Project manager – the manager of a single project.
Project team member – the person working on a project.
Trainer – the person providing PM training and individual coaching for their project roles.
ISO 21500 does not focus on this type of organization specifically, but it is very important for them because it is the globally accepted and independent project management practice. The PM consultancy organization can generate new business by developing training for ISO 21500, gaining expertise in ISO 21500 in order to assist other businesses in applying the new guideline and aligning the execution of their projects to ISO 21500.
In general, a complex project will be large in size and duration, require huge funding, carry high risk and deal with many (external) stakeholders, because it often affects the general public. Examples are: the building of a refinery, the construction of a railway, or the organization of the Olympic Games.
For such a complex project the project organization and the personnel aspects normally require special attention, as it is the essential foundation for its future success. It is essential that sufficient human resources, including other critical resources, are available to carry out all the work to complete the project. It must be ensured that the different project team roles and the responsibilities are described properly, based upon which resources with the right skill sets are assigned to the project. For complex projects, it is also essential to identify the key (external) stakeholders and manage their expectations properly, as these external stakeholders can sometimes ‘make or break’ the project.
And for complex projects it is critical to establish the project governance correctly. Inadequate governance is one of the main reasons that complex projects often do not run satisfactorily. The temporary project organization runs almost autonomously. There should be a strong alignment to corporate governance in order to ensure and maintain proper support from the project environment. This aspect is difficult and therefore needs specific attention.
To function properly the definition and assignment of the governance roles need special attention and ISO 21500 gives a good indication of what roles are required here. The complex project should have:
An active sponsor – who has a direct link to the project manager to express commitment for project success from both sides and to promptly deal with issues of any kind.
A project steering committee – of senior managers from both the client and the contractor organization sides to monitor and control the project.
Its own PMO (project management office) – to support the project directly.
Because complex projects are often public (infrastructure) projects, the whole project organization should demonstrate ethical and responsible conduct for the benefit of the society and the environment.
So, the bottom line challenge here is that, in practice, many different parties will have to communicate effectively in order to work together successfully, whilst recognizing that all stakeholders have their specific interests and roles, as well as using their own cultures (national as well as organizational), procedures and project management practices as a basic reference. To improve the communication between all stakeholders ISO 21500 can act as an effective common reference for managing a complex project.
Projects with governmental constraints require special attention. These constraints could be procurement-related (e.g. using an international tendering process), fixed yearly budgets (e.g. for large infrastructure projects requiring public funds), legal obligations (e.g. the implementation of the Sarbanes-Oxley Act of 2002 – new or enhanced standards for all U.S. public company boards, management and public accounting firms – or the implementation of Basel III – a global, voluntary regulatory standard on bank capital adequacy, stress testing and market liquidity risk in response to the deficiencies in financial regulations revealed by the late-2000s financial crisis), public/private projects (e.g. a new highway), and so on.
ISO 21500 can well be applied to projects in governmental settings which have to deal with these special constraints. The focus here will be on managing the interests of their specific stakeholders, relating to:
Public responsibility.
Sensitivity for fraud.
Broad internal and external support.
Risk management, focusing on security and reliability.
Proper use of public resources.
A number of specific roles, beyond those mentioned in ISO 21500, are required to properly deal with governmental constraints in a project:
Sponsor – representative of the government that launches the project, provides the funds and becomes the ‘owner’ of the deliverables at the end to ensure that the benefits are achieved, which makes the government spending defendable.
Contractors – firms that actually carry out the work and realize the project objective.
Project steering committee – consisting of senior managers of both government and contractor, ensuring that the project is delivered successfully within the given constraints.
Project manager – needs to have experience with these governmental assignments, given the special constraints which need to be managed.
Governmental experts – individuals with the appropriate knowledge of confederational or federal regulations (European Union, United States), national, or local government.
Internal and external auditors – ensuring compliance with organizational and legal constraints.
General public – often the user of the end product of an infrastructure project (e.g. a new train line).
For projects which have to deal with governmental constraints as described above, paying sufficient attention to managing specific stakeholders by attracting specialist roles such as those above to the project will significantly increase their chance of success. For specialists, given their different backgrounds and experience, ISO 21500 can act as a common reference for managing such projects.
The Oxford English Dictionary defines a constraint as: a limitation or restriction15.
In the Theory of Constraints16, developed by Eliyahu Goldratt, a constraint is defined as anything that limits a system (which can be project) in reaching its goal. This is a very broad definition, because it encompasses a wide variety of possible constraining elements. Constraints could be physical (equipment, facilities, material, people), or they could be policies (laws, regulations, or the way we choose to do business—or choose not to do business). Frequently, policies cause physical constraints to appear.
While the project manager and the team try to realize the project’s objective, based on the requirements for the project, the project will be faced with different constraints. Constraints can, therefore, be regarded as a specific subset of requirements, with a limiting or restricting character. It is important for a project manager to balance these constraints, as constraints are often interrelated such that a change in one may affect one or more of the others. Hence, the constraints may have an impact on the decisions made within the project management processes. If the constraints are too limiting and impossible to balance, it may become impossible for the project to realize its objectives within the stated requirements.
A well reasoned and maintained agreement on the constraints between the key project stakeholders forms a strong foundation for project success.
There are many different constraints that may be imposed on a project. The typical constraints often mentioned in project management concepts are: Scope, Time and Cost (also referred to as the Triple Constraint, Project Management Triangle or the Iron Triangle) where each side represents a constraint.
The constraint of Time refers to the amount of time available to complete the project (the ‘deadline’).
The constraint of Cost refers to the financial limitations based on the funding available for the project.
The constraint of Scope refers to ‘all the work’ that must be done to produce the project’s end result for meeting their requirements.
A further refinement of the constraints integrates Quality and Scope in ‘Performance’ (= scope at a certain quality) or turns Quality into a fourth constraint. Other project management methods, practices and models go even further by adding, for example, Risks or Resources as additional constraints. The basis nevertheless always goes back to the Triple Constraint.
With a dilemma (choice between two options) already being difficult to deal with, a ‘trilemma’ is an even more difficult choice given the three options, each of which appears unfavorable. There are two logically equivalent ways in which to express a trilemma: it can be expressed as a choice among three unfavorable options, one of which must be chosen, or as a choice among three favorable options, only two of which are possible at the same time. A third approach, and in projects the realistic way of dealing with this trilemma, is to carefully balance all of the constraints in such a way that the outcome is acceptable to all stakeholders.
This balancing of constraints starts when defining the project, in order to create a realistic and feasible plan that is acceptable to all key stakeholders:
Increased scope mostly leads to increased time and increased cost. Although end-users of course would like to get the ‘perfect’ solution, it’s still the sponsor who has to provide the funding for that.
A very tight deadline, which could be demanded by the sponsor, but could lead to increased costs and reduced scope, which may not be acceptable to end-users as it might create unfavorable working conditions since the end solution is far from perfect.
A very tight budget which could lead to reduced scope, and once again may not always be acceptable to end-users or other stakeholders.
So, one side of the triangle cannot be changed without affecting the others. And speaking of change: when executing the project, changes will definitely happen. The project manager then has to constantly manage and rebalance the constraints in order to respect all stakeholder requirements sufficiently. Frequent communication with key stakeholders about their constraints is therefore essential. It’s the discipline of project management that enables the project team (not just the project manager) to organize their work in such a way that it will meet all constraints, thus satisfying the stakeholders’ requirements, including any limiting requirements.
On top of the previously mentioned ‘Triple Constraint’, ISO 21500 also mentions other constraints like:
Limited availability of project resources such as people, facilities, equipment, materials, tools and others required.
Safety constraints.
Risk limiting factors.
Ecological impact.
Laws, rules and other legislative requirements.
But other constraints to take into account might be:
It’s the project management team’s job to define and document the constraints and manage these during the project life cycle. Given the ‘source’ of most constraints there is a strong relationship between:
The impacting constraints and their relative importance (which constraint takes priority when faced with a dilemma?).
And the project environment and the key-stakeholders (what is their level of ‘power’).
The chances of success for the project management team significantly increase if this relationship is managed properly.
Identifying and managing constraints becomes a little easier if there is an orderly way of classifying them. A suggested way of categorizing constraints is using the following seven basic types15):
Market: limited demand for a product or service. In most project environments this typically relates to the project Business case and therefore it’s the main responsibility of the project sponsor. Increased collaboration between project manager and sponsor can significantly improve the Business case and therefore can reduce the limiting effects of constraints e.g. funding limitations.
Resources: not enough people, equipment, or facilities to satisfy the demand for products or services in time.
In most project environments resources are obtained from the line organization. A stronger and more compelling Business case, and clear communication about the effects of decisions in the line organization for ensuring sufficient resource availability may change the willingness of the organization to actually provide the right resources in time.
Material: inability to obtain required materials in the quantity or quality needed to satisfy the demand for products or services. In most project environments materials are either acquired from the line organization or via suppliers/vendors (see below). For internally acquired materials, as with resources, a stronger and more compelling Business case, or clear communication about the expected effects of decisions ensuring materials availability may change the willingness of the organization to provide the right materials (sufficient and of the right quality) in time.
Supplier/vendor: unreliability (inconsistency) of a supplier or vendor, or excessive lead time in responding to orders. In most project environments materials are either acquired from the line organization (see above) or via suppliers/ vendors. For externally acquired materials, a more strict selection of procurement parties may prevent supplier/vendor constraints, or a different type of contract (incentives) may lead to a different way of cooperation between the buyer and the vendor (partnership), thus limiting the effects, or even removing these constraints completely.
Financial: insufficient cash flow to finance the project. For externally funded projects, payment could be planned and aligned to the cost plan (budget) or to the work items completed. For internally funded projects, the scope of the first project could be reduced to the lowest level of objective, which is confidently expected to achieve the initial benefits (savings, revenues, other financial benefits). Optimization of benefits realization (program management) enables the program to become financially self-sustainable.
Knowledge/competence: necessary information or knowledge is not available within the project team or people don’t have the skills (or skill levels) necessary to deliver the required project objective. Typically a team composition issue which can be resolved by either sourcing the critical knowledge or competences (usually with cost consequences) or training the available team members (usually with a time consequence).
Policy: laws, regulations, internal policies and procedures or business practices that inhibit progress toward the project’s objective. Laws and regulations require interpretation. By thoroughly studying the laws and regulations, this often leads to identifying opportunities that were previously unknown.
Internal policies and procedures, next to being very supportive and preventing that the project has to ‘invent everything’, may also act as major constraints. These policies and procedures are typically created for the optimal functioning of a line organization. At some level, these processes can become quite large and complex, such as a production process, a purchasing process, or a marketing and sales process. One way of dealing with complexity is to compartmentalize it, by creating functional departments. Each department is responsible for some function that constitutes a part of the whole system. Procedures and policies are then created in an orderly way to deal with the issue of complexity in a predictable, cost efficient manner. Efficiency and effectiveness are key – but focused on their ‘own’ departmental objective!
Projects are typically cross-departmental, and for good reasons! A project is defined and a project manager assigned, because the line organization is not capable (as it doesn’t have the appropriate structure for it) of creating that specific and unique objective, as required by the project sponsor. Projects therefore quite often need to have some own policies and procedures, which are defined to optimally facilitate the creation of the project’s objective.
In cases where a project has to comply with all of the policies and procedures defined by each department involved in the project, it may be just as well not to create a project with a project manager with some level of authority. For such an initiative, it could be better to assign an ‘expediter’ instead, who has no authority but simply follows and ‘facilitates where possible’ every cross-departmental step of the objective’s components in the complete chain of production and implementation. In reality the key-driving constraint simply remains the efficiency and effectiveness of the individual departments. The creation of the specific objective is automatically treated as of secondary importance, which of course needs to be recognized and accepted by the sponsor of the initiative (expectation management) since organizational constraints ‘always’ take priority over project constraints.
Competence is the ability to do something successfully or efficiently; also competency17. While ISO 21500 mentions both competence and competencies, in this book we use competence only.
ISO 21500 is rather limited on the competences, but nevertheless, in the context section 3.9 of ISO 21500, the competences of the members of the project team are mentioned as a prerequisite to successfully deliver projects. ISO 21500 categorizes these competences in three areas as follows:
It is clear that by mentioning these competences, reference is made to the IPMA Competence Baseline (ICB) version 3.0, where these competence areas are described in much more detail.
In the ICB version 3.0 project management is broken down into 46 competence elements, covering three competence areas in the ‘eye of competence, which represents the integration of all the elements of project management as seen by the project manager, when managing the project:
Technical competences (20) – the hard skills of project management, including the project management terminology, concepts and processes as they are also described in ISO 21500.
1. Project management success
2. Interested parties
3. Project requirements and objectives
4. Risk & opportuntity
5. Quality
6. Project organisation
7. Teamwork
8. Problem resolution
9. Project structures
Scope & deliverables
Time & project phases
Resources
Cost & finance
Procurement & contract
Changes
Control & reports
Information & documentation
Communication
Start-up
Close-out
Behavioral competences (15) – the soft skills of the project personnel, their professional behavior within the boundaries of the project; essential to bring projects to a successful conclusion.
1. Leadership
2. Engagement & motivation
3. Self control
4. Assertiveness
5. Relaxation
6. Openness
7. Creativity
8. Results orientation
9. Efficiency
Consultation
Negotiation
Conflict & crisis
Reliability
Values appreciation
Ethics
Contextual competences (11) – the skills related to properly understanding the project environment, including project governance and the way programs and portfolios are managed. Understanding and properly applying these skills is an important aspect for everyone working on a project.
1. Project orientation 2. Programme orientation 3. Portfolio orientation 4. Project, programme & portfolio implementation 5. Permanent Organisation 6. Business 7. Systems, products & technology 8. Personnel management 9. Health, security, safety & environment 10. Finance 11. Lega
The project management competences of all project personnel should be known and, if necessary, they should develop these via training, coaching and mentoring for their individual development, or for the needs of a particular project.
Also see section 7.3 for a comparison between ISO 21500 and ICB 3.0
ISO 21500 recognizes two perspectives for structuring the project management processes, either by Process group (Initiating, Planning, Implementing, Controlling and Closing) or Subject group. A Subject group is a project management theme. This chapter describes the Subject group perspective in order to provide a better understanding of the contents of ISO 21500.
ISO 21500 contains ten Subject groups in total. Every Subject group collects the processes by subject and each process is shown in the Subject group in which most of its related activities are performed.
The Integration Subject group is about planning the work and working the plan. It covers the start and finish of the project and everything in between. It is about finding balances between competing constraints and requirements, finding alternatives and handling the dependencies between the various project management Subject groups.
Like the spider in the web, the Integration Subject group coordinates and integrates the processes from all the other Subject groups.
There are seven Integration Subject group processes in total:
1. Develop project charter: the process to document the high level requirements and project boundaries – the charter will authorize the project manager to start the project or phase.
Develop project plans: ‘plan the work’; compiling the overall plan by capturing the subsidiary plans that originate from the other nine Subject groups. Typically two plans are mentioned: the Project management plan (describing how the project will be organized and controlled) and the Project plan (an outputs-based description, starting high-level and progressively elaborated throughout the life cycle of the project, defining the baselines for scope, cost, time, etc., which will be updated throughout the project).
Direct project work: ‘work the plan’; direct the team members’ activities required to create the project deliverables.
Control project work: this is managing the project’s progress and performance compared to the plan and the initiation of process changes in order to improve performance.
5. Control changes: a process for structuring the way in which the project deals with change requests and how changes are managed to the plan (formal acceptance or rejection) and to the deliverables;
Close project phase or project: completing all activities to close a phase or the project including the formal verification and acceptance of completed project deliverables;
Collect lessons learned: generating and documenting key positive and negative performances during the project to act as useful references for planning future project phases or other projects, thus increasing the organization’s project management maturity (increasing effectiveness and efficiency in project performances).
This subject group includes all of the steps necessary to identify the people, groups, or organizations that could impact, or be impacted by, the project. We try to analyze stakeholder expectations and their impact on the project. We try to analyze stakeholder impact on the project and their associated needs. We try to develop appropriate management strategies for effectively engaging and communicating with stakeholders during the project duration.
Stakeholder satisfaction should be managed as a key project management objective.
Stakeholders are part of every project and they can be impacted by, or can impact, the project in a favorable or less favorable way. Some have a limited ability to influence the course of the project, while others have more influence on the project and its outputs The Stakeholder Subject group has two processes:
Identify stakeholders: understanding the stakeholder environment is a key input for scope definition. By overlooking a key-stakeholder you may well miss 100% of their requirements. If you’ve ever had the experience of being forced to ‘squeeze’ requirements into a project which was perceived as ‘nearly finished’, you will not be surprised by the fact that you may have to rework a significant part of the project scope, with devastating consequences for both time and cost (triple constraint!), quite apart from the expected level of acceptance and support by that stakeholder, whose ‘existence’ you have forgotten....
Manage stakeholders: making sure that stakeholders with a positive interest are behaving positively towards your project (don’t lose your friends; you might need them ...!) and that stakeholders with a negative interest are unable to destroy ISO 21500 – A Pocket Guide your project (keep your friends close, watch your enemies even closer). By taking a proactive look at your project from their perspective you may be able to predict 80% of their expected behavior, and organize accordingly in advance. If you don’t manage your stakeholders they will manage you, resulting in reactive management, instead of project management!
The Project Scope is the answer to the ‘what’ question: what ‘product’ will the project deliver and what intermediate results need to be produced to get the ‘end product’. This includes the product scope, the features and functions characterizing the project end-result, as well as the project scope, all the work required to deliver the aforementioned product scope.
The Scope Subject group covers all processes required to define and control the work that is needed (in scope) and not needed (out of scope) to deliver the project result.
The processes in the Scope Subject group are:
Define scope: creating a Scope statement including the link to the organizational strategy, defining and documenting stakeholders’ needs to meet the project objectives and creating a description of the project boundaries and its product (project end state).
Create work breakdown structure (WBS): breaking down project deliverables and project work into smaller and more manageable components.
Define activities: defining an overview of the tasks required to create the detailed or ‘operational’ project plan for implementing, controlling and closing components of the WBS.
Control scope: monitoring the status of the project scope and controlling changes (maximizing positive and minimizing negative) to the Scope baseline.
The Scope baseline consists of the Scope statement and the WBS and its dictionary. This Scope baseline is then monitored, verified, and controlled throughout the life cycle of the project
The Resource Subject group is about getting people on board the project and retaining, leading and managing them, together with obtaining the materials, facilities, infrastructure, etc. The people are called ‘project staff’ or ‘the project team’. It is considered quite beneficial to have the project team assigned and available as early as possible – as their expertise will be used during the planning process and the overall commitment of the team towards the project will be strengthened.
The number of team members might change throughout the course of the project; it depends on the tasks and the work to be done. While the staff are needed for their particular content-related expertise within the project, the project manager’s expertise lies in orchestrating their roles and responsibilities, and influencing the project team in terms of communication, politics and organizational issues. In addition, staff may be added to the team for specific project management support, such as scheduling expertise, risk management expertise, or administrative support.
It is necessary to distinguish between the project team and the project management team. The latter is usually a subset of the project team, being concerned with typical project management activities. The project team is the sum of all people working for the project. There might be a programmer assigned 100% to a strategic IT project. If he or she is not involved in project management leadership activities, the programmer is not considered to be part of the project management team but is part of the project team.
The Resource Subject group contains six processes:
Establish project team: obtaining the resources necessary to establish the project team.
Estimate resources: determine the resources needed for the project, including human resources, materials, facilities, equipment, infrastructure and tools.
Define project organization: identifying all team members and other persons directly involved in the project work and obtaining their commitment. Also the definition of roles, responsibilities and authorities that are relevant to the project, aligned with the project’s nature and complexity and respecting the performing organization’s existing policies.
Develop project team: establishing the project’s ground rules of preferred and acceptable behavior and continuously improving the team performance, interaction and motivation, while respecting and growing the available competences in the project team.
Control resources: ensuring that the resources required to undertake the project work are available and assigned to the project, as well as establishing procedures to identify resource shortages, and dealing with conflicts in availability of resources and facilitating their reallocation if needed.
Manage project team: optimizing team performance, providing feedback, resolving resource issues, encouraging communication, and coordinating changes to realize the project objective.
The Time Subject group is concerned with all of the necessary steps to manage the timely completion of the project. Time management seeks to determine feasible delivery dates, milestones or end dates, taking all known constraints into account. Time management is sometimes seen as the core discipline of project management and various popular software tools are available which primarily focus on the time management aspects. The printouts of these software packages are often called the ‘project plan’. According to the Time Subject group this is a ‘project schedule’ and not a ‘project plan’.
The Time Subject group covers four processes:
1. Sequence activities: identifying and documenting the logical relationships between project activities, providing a network diagram and identifying the critical path.
2. Estimate activity durations: estimating the elapsed time to complete each activity in the project, including the time needed for administrative processing and approval, as well as making periodic re-estimates and updated forecasting against the baseline.
3. Develop schedule: establishing the overall project schedule baseline and subsequent schedule updates, based on calculating the start and end times of project activities, enabling objective measurement of progress.
4. Control schedule: monitoring schedule variances by determining the current status of the project schedule and comparing it to the approved baseline schedule, and taking appropriate actions to avoid adverse schedule impacts.
Particularly on projects of a smaller size, the different processes are so tightly linked that they are often viewed as a single process that can be performed by one person.
Money is typically one of the key constraints of any project. The Cost Subject group is therefore all about defining the budget and managing the actual project cost within the approved budget. But if the project’s primary driver is financial, i.e. approved investment based on much higher expected savings after project delivery, it also about safeguarding and possibly improving the financial Business case of the project.
In supplier-customer environments it is necessary to distinguish between the project budget and the potential price of a project (i.e. by selling the result of the project to the marketplace). Project management and especially the Cost subject group are only concerned with the project budget – the price and the respective positive or negative margin of the project deliverables is a management decision outside of the project.
The Cost Subject group contains three processes:
A project manager needs to be aware of which costs are assigned to the project, how they are assigned and the concept of controlling these costs. In a case where, for example, a project needs a dedicated facility or supporting tool, it is crucial to have a clear view on the mechanics of how costs for this are budgeted. It is also very important to keep an eye on any stakeholder requirements for capturing costs. Different stakeholders may have different views and different requirements on how costs are assigned and reported.
Another aspect of project cost management covers the consequences of project decisions in respect to product maintenance or the cost of product support. E.g. think about the following question: should we keep the project costs low in order to meet the budget, even if the consequence is an expected increase in maintenance costs after the project delivery?
Projects are by definition ‘risky’ endeavors. It means dealing with unknown situations and as a consequence often resulting in project changes. In order to prevent each project becoming a ‘game of chance’, the Risk Subject group can support us in controlling the project risks. Project risks are future uncertainties that may affect project results – in both directions, i.e. for the better or worse. Project risks are not business risks, or risks that are related to the performing organization. A project might create such risks, but they are handled from a different perspective.
Risks are uncertainties that matter. It is the job of the project management team to take care of those uncertainties, to identify them, to analyze their impact, to develop responses if applicable, and to monitor and control their effect.
If the project management team neglects risk management, it will be constantly faced with problems on the one hand and missed opportunities on the other. Risk management is about trying to minimize the impact of potential threats on project results, which is usually everything that could cause a project to be delayed, be more expensive, or be delivered with less quality. Risk management on the other hand is also about trying to maximize the impact of potential opportunities; factors which could help to achieve the project results faster, cheaper and with better quality. These need to be actively promoted and supported.
The Risk Subject group has four processes:
2. Assess risks: measuring and prioritizing the risks for further action, based on estimating the probability of occurrence of each risk and the corresponding impact on the project objective.
3. Treat risks: developing options and determining actions for enhancing opportunities and reducing threats to project objectives.
Risk management processes have little value if they are performed only once, say at the beginning of the project. Constant evaluation is necessary to really harvest the full benefits of risk management.
The Quality Subject group supports the project in achieving its quality objectives.
ISO 21500 recognizes the following three processes in the Quality Subject group:
Plan quality: gathering all the quality requirements and describing how the project team will demonstrate its quality compliance.
Perform quality assurance: the process of auditing the quality requirements and application of the quality standards by reviewing the quality control measurements.
Perform quality control: executing the quality control activities to measure performance and recommend changes if needed.
Failure to meet the project’s quality requirements will have a strong negative impact on project performance and the delivery of its expected result. This underlines the importance of quality management. Quality management therefore looks at the quality of the project product as well as the project management processes.
Quality can be defined as the level to which a product or service meets its specification or meets the expectations of its users. Quality is not synonymous to grade. Grade is an expression of a product’s technical features. Two products or services can have the same functional use but can have a different number of features. Where low quality (many defects or not meeting expectations) is always a problem, a lower grade (less features and limited functionality) may not be an issue.
Project management and quality management both acknowledge the importance of customer satisfaction, prevention over inspection, continuous improvement and management responsibility for quality. Moreover the Cost of Quality approach looks even further than simply the project life cycle. The level of desired quality usually comes with a cost first, because of the effort needed to achieve it. This is a trade-off that project management and the sponsoring organization or entity need to manage carefully because the cost of quality relates to the total product life cycle and is not limited to the project life cycle only. Increasing quality as early as possible in the total life cycle will generally lower the cost. Therefore we emphasize the statement: Quality is for free!
As most projects need products, services or resources from outside the project team, there will be a need to purchase them. Given the trends of outsourcing to ensure more competitive cost rates, as well as increasing project complexity which results in external input being frequently needed by specialists ‘not available in-house’, there is an increasing role for suppliers and partners. One can quickly conclude that a straightforward fixed price contract is not the best option for every project. When the contract scope is developed as the project progresses and the supplier’s creativity is needed to get the best result within a given timeframe, budget or other constraint, more specific arrangements may be needed.
To deal with these situations effectively, one should apply project procurement management.
The Procurement Subject group consists of three processes:
2. Select suppliers: evaluating the supplier responses, selecting a supplier and signing the contract.
3. Administer procurements: managing the relationship with the supplier, monitoring the supplier’s contract performance and making adjustments if needed including the completion of the contract life cycle for each procured item.
Since purchasing a product or a service always implies a legally binding agreement between buyer and supplier, you are advised to cover this in a formal contract.
Most organizations will have procurement policies and procedures that will define the rules to follow if you need to buy a third party product or service. In many cases you will need to involve the buying professionals of the organization to make sure the procurement is done in a professional way consistent with organizational policies and processes.
The procurement processes actually determine the contract life cycle. Deciding to buy (a part of) the project result instead of having it made by the project team could be triggered by a risk assessment, or a budgetary or time constraint. If, for example, achieving a part of the project result is considered to be risky, buying that particular piece of work might mitigate the risk.
Every item to be purchased is subject to the three processes outlined previously and to process 4.3.7 Close project phase or project, where the item is actually completed.
Suppliers are also known as contractors, subcontractors, vendors, or service providers. A buyer can be called a client, customer, prime contractor, contractor, acquiring organization, governmental agency, service requestor, or purchaser. The supplier’s position during the contract life cycle can change from bidder, via selected source, to contracted supplier.
For the purposes of this chapter we have assumed that the buyer is positioned in the project team and needs to buy items for the project; the supplier is external to the project team. And we have assumed that both buyer and supplier develop a contractual relationship that needs to be managed.
Effective communication enhances the project’s chance of success by building stakeholder relationships that can be leveraged to create coalitions and partnerships. It creates bridges between diverse stakeholders involved in a project, and connects various cultural and organizational backgrounds, different levels of expertise, and various perspectives and interests in the project execution or outcome. Project managers spend most of their time communicating or facilitating, and ensuring communication between stakeholders. This starts from day one of the project!
The Communication Subject group defines the key processes required to ensure timely and appropriate exchange of project information.
The Communication Subject group has three processes:
Plan communications: determining the information and communication needs of the stakeholders in a communication plan.
Distribute information: making the required information available to project stakeholders as defined by the communications plan and responding to unexpected, ad-hoc requests for information.
Manage communications: ensuring that the communication needs of the project stakeholders are satisfied and resolving communication issues if applicable.
This chapter compares ISO 21500 with other well known project management methods, practices and models and explains the differences in approach together with the differences and similarities in the project management processes.
ISO 21500 has been mapped to the PMI’s PMBOK Guide-Fifth Edition, issued at the beginning of 2013. The Annex A1 “The standard of project management for a project” of the PMBOK Guide is an ANSI standard. The ISO 21500 processes have been compared with the PMBOK Guide processes. The result is shown in figure 7.1.
The overall conclusion is that:
ISO 21500 processes have an almost perfect match with PMBOK Guide processes; this is not surprising, because PMBOK Guide was one of the input documents for ISO 21500 and the development process for both documents was the same, i.e. a compilation of globally used good practices of project management.
90% of the process names are the same.
ISO 21500 has been mapped to the PRINCE2 2009 Edition project management method19, the version issued by UK’s Cabinet Office in 2009. The ISO 21500 processes have been compared with the PRINCE2 themes, processes and some special items (i.e. tailoring, product and role). As part of the comparison the activities of the PRINCE2 processes have been reviewed to determine matches with ISO 21500 processes.
The overall conclusion is that:
ISO 21500 processes have a very good match with PRINCE2 processes and/or themes.
The name of the processes/themes may differ, but when undertaking a match they (partly) cover the same activities.
Only one ISO 21500 process (4.3.36 Select suppliers) is not covered by PRINCE2.
Procurement is barely dealt with in PRINCE2.
Some of the PRINCE2 themes (i.e. items starting with a number between 4 - 10, being the chapter number in the PRINCE2 document) match with the ISO 21500 subject groups.
As seen in chapter 5, IPMA’s ICB version 3.0 consists of competence elements, grouped into three competence areas: technical, behavioral and contextual competences. In ISO 21500 the competences of the project members are based on the ICB version 3.0, and these are mentioned briefly.
In Figure ISO 21500 has been mapped to ICB version 3.0, where the ISO 21500 processes have been compared with the ICB ‘possible process steps’ that are listed with every competence. All ICB competencies are shown in chapter 5 of this book.
The overall conclusion is that:
All technical competences are covered in ISO 21500.
Half of the behavioral competences are mentioned in ISO 21500.
Most of the contextual competences are dealt with in ISO 21500 in relation to developing the project plans and more extensively in clause 3 (Concepts).
All 39 processes in ISO 21500 can broadly be linked to all possible process steps as listed in the technical competences (‘hard skills’).
Only six out of 15 of the behavioral competences (‘soft skills’) are mentioned in two processes of ISO 21500 (process 4.3.18 Develop project team and process 4.3.20 Manage project team).
One ISO 21500 process (4.3.3 Develop project plans) deals with eight out of eleven contextual competences (‘environmental knowledge’) and 13 other ISO 21500 processes deal with only a single contextual competence. Three competences (Program orientation, Portfolio orientation and Project, Program & portfolio implementation) do not link with a ISO 21500 process, but they are dealt with in the concepts clause of ISO 21500.
Although ISO 21500 doesn’t explicitly refer to iterative development methods, it also doesn’t state that the project life cycle should typically adopt the ‘waterfall’ development approach. Given the huge overlap of ISO 21500 with the PMBOK Guide processes, the comparison between Agile and PMBOK Guide may be used as a valid reference for the comparison between Agile and ISO 21500.
Agile project management is based on the following principles: embrace change, focus on customer value, deliver part of the required functionality incrementally, collaborate, reflect and learn continuously. Applying these principles results in:
Only plan what you realistically expect to happen, with a level of detail which is appropriate to the planning horizon (relatively short – the Agile manifesto talks of a two to four weeks cycle and delivery at the end of each iteration).
Don’t go for delivery of the project objective (Scope with a defined quality) in one go, but plan for several iterations instead.
‘Control’ is through inspection and adaptation using reviews and retrospectives by a self organizing team.
This approach allows higher flexibility in Scope (embrace change!).
Agile practices which are used to manage change are:
Continuous feedback loops.
Iterative and incremental development.
Prioritized backlogs.
The result is that Agile project management methods cannot be considered completely, from the traditional project management point of view, since a number of processes are either missing or not described explicitly. But then again, because of the reduced level of complexity there is less need to perform the planning and controlling processes to that level of detail.
Nevertheless, a detailed Scope is still defined (What ‘features’ are in the scope of this iteration?) for which the processes in the Scope subject group can be applied and a Schedule needs to be created, though only a detailed plan as we only plan to a certain planning horizon, for which we can use the processes from the Time subject group and the Budget per iteration (limited) needs to be planned based on the Resources planned for the iteration. Given the above, Agile project management is more of a method (how) than a project management guideline (what). In this respect, Agile and ISO 21500 are complementary.
One could even consider that through the application of program management as an overarching layer for a group of projects, Agile principles are introduced as well; instead of one big project, a well balanced set of smaller projects is delivered, maybe sequentially or in parallel, with each sub-project delivering benefits (and thus customer value).
Finally one should also respect that the Agile project management method is not suitable for every project. Imagine using an Agile approach for realizing a project with the objective of ‘switching all traffic from left hand driving to right hand driving’ as follows:
Lorries, busses and trucks change in week one.
Passenger cars in week two.
All the remaining traffic (cyclists, motorists, etc.) in the third week ....
PRiSM™ (PRojects integrating Sustainable Methods)20 is a methodology for green project management, that was developed between 2008 and 2011 by GPM (Green Project Management). It integrates sustainability with well known project management practices from PMI, (UK based Association for Project Management) and IPMA, and knowledge from a number of ISO standards: 21500!! (Project management), 14001 (Environmental management), 26000 (Social responsibility), 50001 (Energy management), and 9001 (Quality management). Green project management focuses not only on the deliverables themselves but also how they are created. The ‘green’ project manager places an emphasis on P5: People, Planet, Profit, Product, and Process. He has to become an innovation agent as much as a team leader and process driver, considering what the long-term impacts are of the project deliverables during planning and creation, and focusing on sustainability before the delivery life cycle starts.
In figure ISO 21500 has been mapped to the GPM PRiSM Flowchart V 2.1. The ISO 21500 processes have been compared with the PRiSM’s processes/activities (per phase).
The overall conclusion is that:
PRiSM has a number of processes/activities focusing on sustainability, while ISO 21500 does not specifically mention it. However sustainability is covered by ISO 21500 process 4.3.3 Develop project plans, where it is stated that the project management plan defines the procedures for the environment, amongst other subjects.
PRiSM has special processes/activities to sign off next phases or stages, ISO 21500 does not.
The PRiSM flowchart is weak on showing ‘control’ processes in the themes stakeholders, resources, time, cost, quality and communication, whilst procurement is not covered at all.
While the GPM website states that the new GPM Reference Guide To Sustainability in Project Management covers ‘... key aspects of sustainability related International Standards, the new ISO 21500 Guidance on Project Management ...’, its published flowchart is not (yet) aligned sufficiently with ISO 21500.
Critical Chain Project Management (CCPM)21 is a method of planning and managing projects that focuses primarily on the resources required to execute the project work. It was developed by Eliyahu M. Goldratt. A critical chain is used as an alternative to critical path analysis. The main features that distinguish the critical chain from the critical path are:
Taking into account resource dependencies and their availability.
The identification and insertion of three types of buffers:
3. Reviewing project progress and health by monitoring the consumption rate of the buffers rather than individual task performance to schedule.
In the CCPM planning approach the careful use of buffers prevents large amounts of safety time being added to all tasks within a project. By doing so, typical bad planning behavior like multitasking, student syndrome, Parkinson’s Law and poorly synchronized integration are avoided18.
ISO 21500 defines project management as the application of methods, tools, techniques and competences to a project, but does not mention any methods, such as Critical Chain Project Management. The project staff select particular methods to be used for the project at hand.
Related processes to Critical Chain Project Management in ISO 21500 are:
The Resource-related processes 4.3.15 Establish project team and 4.3.19 Control resources, for which the resource availability is one of the key inputs.
The Time-related processes 4.3.21 Sequence activities and 4.3.23 Develop schedule and Control schedule, where a schedule can be created and managed using the CPPM technique.
The Risk-related processes 4.3.30 Treat risks and 4.3.31 Control Risks, where buffers can be assigned as a response to dealing with schedule risks and managed accordingly.
The Critical Chain Project Management method could be utilized in these processes as a technique.
Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology is the next advance beyond Critical Path Method and Critical Chain Project Management. Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project.
ISO 21500 defines project management as the application of methods, tools, techniques and competences to a project, but does not mention any methods, tools and techniques, such as the Event chain methodology. The project staff select particular techniques to be used for the project at hand.
ISO 21500 deals with events in the planning processes 4.3.23 Develop schedule and 4.3.28 Identify risks and the Event chain methodology could be utilized as a technique here.
Process based management is a holistic management approach that guides the actions and mindset of an organization. Process based management has a wider scope than the management of individual processes. A process based organization explicitly recognizes that it designs, manages and improves all processes to optimize the delivery of customer value. Process based organizations use this as a guiding philosophy and as a strategy to differentiate themselves and outperform their competitors23.
In essence, Process based management is a method to improve organizational efficiency and effectiveness. To realize these improvements quality standards, like ISO 9000, Lean and Six Sigma are often adopted. It would be relatively easy for a process based organization to adopt ISO 21500, being process based itself, as a reference for managing its own projects and so increase the chance that its projects are completed successfully. In that respect Process based management and ISO 21500 are complementary.
Lean project management is the comprehensive adoption of other Lean concepts like Lean construction, Lean manufacturing and Lean thinking into a project management context. Lean project management has many ideas in common with other Lean concepts; however, the main principle of Lean project management is delivering more value with less waste in a project context. Lean project management has many techniques that can be applied to projects and one of main techniques is standardization. Key techniques are those ‘inherited’ from Agile software development like: blame-free employee involvement, the need for a strong facilitator, pipelining, etc.
The five Lean principles are:
Specify value from the standpoint of the end customer.
Identify all the steps in the value stream.
Make the value-creating steps flow towards the customer.
Let customers pull value from the next upstream activity.
Pursue perfection.
Applying Lean to project management leads to the following Lean project management principles26:
Eliminate waste.
Instill empowerment, respect, integrity.
Decide later, deliver fast.
Amplify learning.
See the whole.
Manage risk.
ISO 21500 defines project management as the application of methods, tools, techniques and competences to a project, but does not mention any techniques, such as Lean. The project staff select particular techniques to be used for the project at hand. Using ISO 21500 as a reference for managing a project is not a guarantee for success, but it certainly increases the chance of the project becoming a success.
As Lean strives to deliver more value with less waste, combining Lean concepts and principles with project management would lead to more successful projects. So when combining Lean with ISO 21500 the chance for even more successful projects would increase – projects run faster, have fewer deviations, deal with less uncertainty and use less resources than without Lean. In this respect, Lean project management and ISO 21500 are complementary.
Six Sigma is a set of tools and strategies for process improvement. Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes. It uses a set of quality management methods.
Six Sigma consists of three basic parts (‘strategies’):
Process Investment.
Process Design/Redesign.
Process Management.
‘Process Improvement’ tries to identify and eliminate the causes of undesired process outcomes or defects, produced by the process. The five steps of the ‘Process Improvement’-strategy are (DMAIC) :
2. Measure the defects and how the process operates.
3. Analyze the data and discover the root causes of the defects.
4. Improve the process by removing the causes of the defects.
5. Control the process to ensure defects don’t occur again.
‘Process Design/Redesign’ is applied when introducing a new product, or if one or more key processes are replaced instead of repaired or improved. In this strategy the steps are adapted to focus on the (re)design, and are as follows (DMADV) :
2. Measure and match performance to customer requirements.
3. Analyze and assess process/product/service design.
4. Design and implement new processes/products/services.
5. Verify results and maintain performance.
‘Process Management’ is defined as a fundamental makeover in the way an organization is structured and managed. For this, ‘Process Management’ focuses on the entire process and not only on a specific defect or a redesign, with the steps as follows (DMAC) :
1. Define processes, key customer requirements and process ‘owners’.
2. Measure performance to customer requirements and key process indicators.
3. Analyze data to enhance measures and refine the process management mechanisms.
4. Control performance through on-going monitoring of inputs/ operations/outputs and responding quickly to problems and process variations.
ISO 21500 defines project management as the application of methods, tools, techniques and competences to a project, but does not mention any methods and techniques. The project staff select particular methods and techniques to be used for the project at hand.
When combining Six Sigma Process improvement with ISO 21500 project management practices, it is expected that the organization will deliver more successful projects in terms of increased customer satisfaction and less costs. In this respect, Six Sigma and ISO 21500 are complementary.
Six Sigma, Lean and Process based management are in essence all organizational improvement methods. Sometimes Lean an dSix Sigma are used together to optimize the performance in the organization and increase its success even more.
So combining both Six Sigma and Lean with ISO 21500 will increase the chance of project success.
As a project focuses on the realization of the project objective, achieving the benefits (customer value) through proper application of the project deliverables is outside the scope of project management. It is the sponsor’s responsibility to ensure the benefits are realized. Sometimes benefits realization becomes so complex that a separate role is needed to direct multiple projects in order to optimize the expected benefits and ensure that the benefits are realized when projects are delivered. This role can be fulfilled by a program manager. The program manager is of course working within, or closely with, the line organization or the sponsor entity that has accepted the deliverables to actually realize the benefits.
ISO 21500 refers to benefits realization (value creation) in the concepts, where in the organization based on the organizational strategy, opportunities (and threats) are defined, which subsequently lead to an approved project, via Business case approval in the project environment, through the application of project governance. The project delivers the project objective to the organization, which via its Operations ultimately realizes the benefits that were planned-for in the Business case.
ISO 21500 describes this in the value creation framework in section 3.4.1 Organizational Strategy, 3.4.2 Opportunity identification and project initiation, and 3.4.3 Benefits realization. During the project life cycle the project manager, when making decisions, should consider the impact thereof on the planned benefits and their opportunities for realization.
Note: The term ‘organization’ should be interpreted here in the widest sense to cater for the differences in the environments in which projects are executed.