Lecture Notes for Project Management

B. Depaire
2019-12-26

Contents

Contents 1

Preface 3

1 An Introduction to Project Management 5

1.1 The importance and rise of project management . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Projects vs ongoing operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 When is a project successful? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Projects and Product Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Project vs Product Development Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Project Management Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Project Initiation 11
2.1 The project initiation stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Stakeholder Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Project Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Project Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Project Planning 19
3.1 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Project Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Knowledge Discovery 25
4.1 Managing the unknowns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Challenged versus unchallenged demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Knowledge Discovery and project outcome value . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Knowledge Discovery is a process of incremental effort . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Common pitfals to be aware of during the discovery process . . . . . . . . . . . . . . . . . . . 26
4.6 Two types of learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7 Methods and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Traditional Project Management 31

5.1 Characteristics of traditional project management . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 PMBoK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1
2 CONTENTS

6 Agile Project Management 35

6.1 Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Impact of agility drivers on work efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Agile Project Management Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Preface

This document contains the lecture notes for the course Project Management (3897) taught at Hasselt
University. Each chapter of this document serves to support the lecture presentations and contains a summary
in bullet-point style. We advise students to go throught these lecture notes immediately after the lecture
and to add your own notes to this document.

3
Chapter 1

An Introduction to Project Management

1.1 The importance and rise of project management

• Projects are becoming increasingly important. One of the reasons is because innovation is driven by
projects and innovation is becoming increasingly important. Our economy has shifted from where
competition between firms focussed on operational excellence (becoming more efficient) to one where
competition is driven by disruptive innovation.

• To understand the link between innovation and projects, it is important to understand the two essential
characteristics of a project.

– Every project has a beginning and an end. While the start can be fuzzy as ideas evolve gradually
into projects, the end of a project should be clearly defined.
– Every project produces a unique outcome. Note that this outcome can be both tangible - e.g. a
piece of software - or intangible - e.g. a new set of guidelines.

• In sum, projects are unique and temporary, similar to innovation. After all, if innovation was not
unique, then it would not be innovative. At the same time, innovation is temporary because once an
innovation is introduced, it is picked up and becomes business as usual and is no longer considered
innovative.
• With the rise in importance of projects, the necessary skills to manage these projects have also increased.
On the one hand, this gave birth to the specific function of a project manager, but also other job
functions such as executives, functional managers and team members need to have project management
skills. It has become a must-have job skill that will only become more valuable.
• Project Management itself consists of methods, theories and techniques to manage the complexity
of project work. As a discipline it has evolved over the past 60 years under the umbrella of sev-
eral standards organizations, such as the Project Management Institute and the International Project
Management Association.

1.2 Projects vs ongoing operations

• Work within an organization can be broadly divided within two categories: projects and ongoing
operations.
• Ongoing operations represent the work an organization performs repeatedly and which is often the
primary purpose why the firm or department exists. Examples are the processing of invoices by the
accounting department or the production of cars at a car manufacturer’s plant.
• The characteristics of ongoing operations are very different from those of projects.

– Ongoing operations typically have no end and they consist of tackling similar problems, producing
likewise results, all by using a repeatable set of activities.

5
6 CHAPTER 1. AN INTRODUCTION TO PROJECT MANAGEMENT

– The focus of operations management, which entails the management of ongoing operations, typi-
cally focusses on operational excellence, i.e. the continuous improvement of achieving a constant
or increasing levels of high quality in ever more efficient ways.
– Another managerial domain that focusses on operational (repeatable) work is that of business pro-
cess management. In contrast to project management, process management deals with organizing
and managing repeatable work.

1.3 When is a project successful?

• The traditional view on project success consists of three parts and is also called the iron triangle or
triple-constraint:
– The project is executed on time.
– The project is executed within budget.
– The project produces an outcome of high quality. This consists of two dimensions:
∗ Product Scope: What is the product supposed to do?
∗ Performance: How well does the provided functionality work?
∗ Both product scope and performance should be defined at the start of the project and high
quality is achieved when the project delivers as specified.
• These three aspects of project success are not independent from each other. On the contrary, typically
improving one criteria implies delivering short on one of the other criteria - e.g. if one wants to execute
the same project in less time, one needs more resources (higher budget) or one has to lower the
specifications of the deliverable.
• Recently, it has been argued that these three success criteria are only a small part of a bigger pic-
ture. Delivering to specification, does not guarantee that the project actually produces value to the
stakeholders.
• A more general definition of a successful project is one that delivers business value.
• However, delivering value is not only a matter of delivering the product to specification, but also
delivering the right specification, i.e. delivering the right product.

1.4 Projects and Product Development

• Producing outcomes which deliver actual value is increasingly difficult in environments where:
– the specifications keep changing along the way due to changing stakeholder expectations,
– customer are often not capable of describing the actual problems they try to solve,
– the goal is often to introduce something that nobody is asking for, but many might actually need.
• The goals of ‘Building the right product’ and ‘building it correctly’ actually belong to yet another
discipline, that of product development.
– Product development entails processes and techniques for determining the right product or service
to build and methods to ensure it is developed correctly and efficiently.
• Product Development uses different criteria to measure success. Three common criteria are:
– Feasibility: Is the solution (technically) feasible?
– Desirability: Is there a market, do people want it?
– Viability: Can the solution be delivered in a sustainable way?
• The argument for product development as a separate discipline states that while the development of
a new product is a unique project, there are clearly similarities in the process to be followed to go
from identifying the right product to actually constructing the product correctly and efficiently. By
creating a standard development methodology, the development process can be made repeatable and
thus allows for quality improvement and cost reduction.
1.5. PROJECT VS PRODUCT DEVELOPMENT LIFE CYCLE 7

• There exists a strong relationship between project management and product development. The de-
velopment of a product is an innovative endeavour which requires a project-based approach. Both
disciplines also focus on producing outcome according to pre-defined specifications.
• At the same time there are also some clear differences between both disciplines.
– The product development process explains what the work is and how to do it correctly. It describes
the work required to create the product.
– Project management emphasizes communication and coordination so the work is performed effi-
ciently. It focuses on managing the work.

1.5 Project vs Product Development Life Cycle

• To better understand the similarities, relationships and differences between project management and
product development management, it helps to take a closer look at the life cycles of both processes.
• A very basic process life cycle consists of four sequential stages:
– Define: The project goals, rules, approach and cost-schedule-quality equilibrium are agreed upon
by the stakeholders.
– Plan: A plan is developed for the project. As each project is unique, this must be repeated
every time for each project. This stage implies that the work to be done is identified, split up
in workable pieces, the time required for each piece and the entire project is estimated, resources
are assigned to the work to be done, costs are budgeted, risks are identified and risk management
plans are set up, and many other activities.
– Execute: This is the stage where the actual work is being executed. During the execution stage,
the goal of project management is to keep the project on track and ensure that execution is done
efficiently.
– Close: This stage entails activities to make the transition to the next phase (operations or another
project), to establish formal closure in the eyes of the customer and to review project successes
and failures in order to learn for future projects.
• Many different product development life cycles exist, but in most cycles one can distinguish the follow-
ing four stages:
– Requirements: During this step the requirements for the product to develop are identified and
described.
– Design: During this step, a product will be designed which meets the requirements. The output
of this step are a set of design plans which allow the construction of the product.
– Construction: During this step, the product is built, documented and tested.
– Operate: In the final stage, the product will start to fulfill its purpose and requires many activities
such as training, support and maintenance.

1.6 Project Management Methodologies

• Over the past decades, different frameworks, standards and methodologies with respect to project man-
agement have been established. In this course, we will highlight three such methodologies: PMBOK,
Prince2 and Agile Project Management.

1.6.1 PMBOK
• The Project Management Body of Knowledge is a set of standard terminology and guidelines (a body
of knowledge) for project management. The PMBOK Guide is published by the Project Management
Institute (PMI) and recognized as a standard by the American National Standards Institute (ANSI)
and the Institute of Electrical and Electronics Engineers (IEEE). Its sixth edition was released in 2017.
• The PMBOK Guide defines 47 processes, which describe a set of tools and techniques to turn a set of
required inputs into a set of expected outputs, with the goal to achieve a pre-specified result.
8 CHAPTER 1. AN INTRODUCTION TO PROJECT MANAGEMENT

– Some example processes are ‘Estimate Activity Durations’ or ‘Plan Human Resource Management’
• These 47 processes are on the one hand grouped into 5 Process Groups, which define categories of
processes that show a strong resemblance with the different stages in the project life cycle. These five
process groups are:
– Initiating
– Planning
– Executing
– Monitoring and Controlling
– Closing
• Additionally, PMBOK also organizes these 47 processes into 10 Knowledge Areas. It defines a Knowl-
edge Area as representing a “complete set of concepts, terms and activities that make up a professional
field, project management field, or area of specialization”. These 10 Knowledge Areas are:
– Project Integration Management
– Project Scope management
– Project Schedule Management
– Project Cost Management
– Project Quality Management
– Project Resource Management
– Project Communications Management
– Project Risk Management
– Project Procurement Management
– Project Stakeholder Management
• Together, the Process Groups and Knowledge Areas form a matrix containing the 47 processes.
• PMBOK has a rather descriptive nature, i.e. extensively describing different aspects of project man-
agement.
• PMBOK is mainly popular in the USA.
• One of the main strengths of PMBOK is that it provides a comprehensive range of useful tools and
techniques (119 in total!). Many of these tools are not described in detail, but PMBOK does describe
when they might be useful.

1.6.2 Prince2
• Prince2 (PRojects IN Controlled Environments) is a structured project management method, originally
developed by the UK Government as a standard for information systems projects. It has become
increasingly popular and is now one of the de facto standards for project management. It’s mainly
popular in the UK, the EU and Australia.
• There have been two major revisions of PRINCE2 since its launch in 1996: “PRINCE2:2009 Refresh”
in 2009, and “PRINCE2 2017 Update” in 2017.
• Prince2 identifies 41 activities in total which closely resemble the processes in the PMBOK Guide.
• These 41 activities are grouped into 7 processes, which should not be confused with processes in the
PMBOK Guide. Processes in Prince2 are rather similar to the Process Groups in the PMBOK Guide.
These Prince2 processes are:
– Starting Up a Project
– Initiating a Project
– Directing a Project
– Controlling a Project
– Managing Product Delivery
– Managing a Stage Boundary
– Closing a Project
• These Prince2 processes also describe who is responsible and accountable for what, and when. This
makes Prince2 much more prescriptive, in contrast to the descriptive nature of PMBOK.
1.7. RESOURCES 9

• Additionally, Prince 2 identifies 7 themes, which are aspects of project management which must be
continuously addressed throughout the project lifetime, as well as 7 principles which act as the building
blocks upon which everything is based.
• One of the strengths of Prince2 is the central role the business case plays in the methodology. Prince2
requires that prior to the project a robust business case is developed which provides a clear understand-
ing of the benefits versus the costs and risks. This business case is further refined during the initiation
stage and is updated on a stage-by-stage basis throughout the project. This ensures that the project
is always seen as a means to an end, rather than an end in itself and should avoid that the product
is successful in terms of time, cost and resources, but fails to provide value. Furthermore, Prince2
prescribes explicit responsibilities for developing, maintaining and approving the business case.

1.6.3 Agile Project Management

• Agile Project Management is a significantly different approach to project management compared to
the more traditional approaches such as described in the PMBOK Guidelines or by Prince2. Whereas,
PMBOK and Prince2 follow a very structured approach, with predefined processes, roles and respon-
sibilities, Agile Project Management is fundamentally much less structured.
• Agile Project Management actually originates from Agile Software Development (and thus a product
development approach!), which was a reaction against traditional waterfall approaches that relied on
structure and documentation. The Agile Software Development movement was kick-started by the
Agile Manifesto which identified 4 core values and 12 fundamental agile principles.
• The core values are:
– Communication with parties is more important than standard procedures and tools.
– Focus on delivering a working application and less focus on providing thorough documentation.
– Collaborate more with clients.
– Be open to changes instead of freezing the scope of the work.
• The fundamental principles are:
– Satisfy the customer through early and continuous delivery of value.
– Welcome change, even when it arrives late.
– Deliver frequently.
– Work together (with different skills).
– Trust and support your people to get the job done.
– Face-to-face conversations.
– Produce results that get (part of) the job done (Working software).
– Sustainable development.
– Continuous attention to excellence and design.
– Simplicity is essential.
– Self-organizing teams.
– Reflect and adjust.
• In a sense, Agile is more of a belief system than a methodology. It has become an umbrella term for
different project management methodologies, such as Scrum.

1.7 Resources
• https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
• http://johnmuldoon.ie/wp-content/uploads/2014/08/PMBOK-Summarized.pdf
• https://www.cio.com.au/article/402347/pmbok_vs_prince2_vs_agile_project_management/
• https://en.wikipedia.org/wiki/PRINCE2
• https://www.knowledgetrain.co.uk/res/ebooks/prince2-process-model.pdf
• https://www.knowledgetrain.co.uk/res/ebooks/prince2-principles-ebook.pdf
• https://www.knowledgetrain.co.uk/res/ebooks/prince2-themes-ebook.pdf
• https://www.knowledgetrain.co.uk/res/ebooks/prince2-processes-ebook.pdf
10 CHAPTER 1. AN INTRODUCTION TO PROJECT MANAGEMENT

• https://www.knowledgetrain.co.uk/res/ebooks/prince2-time-triggers.pdf
• https://www.knowledgetrain.co.uk/resources/qualifications/prince2-and-pmbok-guide-comparison
• http://agilemanifesto.org/principles.html
• https://www.knowledgetrain.co.uk/res/ebooks/12-principles-download.pdf
Chapter 2

Project Initiation

2.1 The project initiation stage

• The project initiation stage is situated at the very start of the project management life cycle. This is
the stage that precedes the actual start of the project.
• The main goal of the initiation stage is to reduce the amount of uncertainty to an appropriate level to
make a final decision whether to approve the project or not. We need to consider two types of risk:
– Business Risk: Will the outcome of the project actually create the envisioned value? This kind
of risk does not really belong to the field of project management, but rather to the domain of
product development. Nevertheless, it is during the initiation stage that this risk needs to be
assessed and reduced to acceptable levels.
– Project Risk: Will the project deliver the promised outcome within budget and on time? Man-
agement of this risk is an essential part of project management. The goal of the initiation stage
is to provide a first estimated answer to this question. It is important to realize that this answer
is based on estimates with varying accuracy.
• How much of the uncertainty (in terms of risk and estimates) needs to be reduced during the initiation
stage is a trade-off between the minimum amount of certainty to make a project approval decision
required and the maximum amount of time and resources spent during this stage.
• As will become clear, this project management stage is closely related to the Ideation and Design stage
of the product development life cycle. The more uncertainty needs to be removed, the more detailed
the design needs to become and the more effort must be put into the project initiation stage. At a
certain point, this can become so extensive that the initiation stage (and thus the ideation and design
stage of the product development life cycle) becomes a project on its own.
– At the same time, there is an inherent risk of spending too much time on this stage. Particularly
in an environment that changes rapidly or where customer needs are not stable, spending too
much time and effort on the initiation stage can lead to a project with low project risk, but high
business risk (as by the time the project starts, what will be developed no longer matches what
the customer needs).
• The start of this stage can sometimes be very clear, but often it is not.
– In case of an urgent problem that needs attention, a clear precise directive can be given to initiate
a project which should solve the problem. In such a case, the start of the initiation stage is
well-defined.
– Often the idea for a project grows slowly inside the heads of a few people, who at a certain point
in time decide to follow a more structured approach and transition to a more formal initiation
stage.
• The project initiation stage consists of:
– Analysis of the problem/opportunity under consideration

11
12 CHAPTER 2. PROJECT INITIATION

– Development of a project proposal

– Stakeholder analysis
– Definition of the project rules
– Evaluation of the project proposal

2.2 Problem Analysis

• The project initiation stage typically starts off with a first informal analysis of the problem/opportunity
the project tries to tackle. Note that ideally the project initiation stage starts from a problem or
opportunity for which a solution or application is searched, rather than directly from a predefined
solution or application.
• It is important to realize that the purpose of a project is to solve a problem or exploit an opportunity.
Failing to clarify the problem/opportunity is therefore a common source of disappointment, particularly
because it is routinely discovered after the project is completed.
• Therefore, it is important to define the problem/opportunity in a clear way. One way to do this, is by
articulating the problem as the gap between the as-is state and the ideal state. This approach is also
known as gap-analysis.

– One should always try to define the to-be state in terms of what the customer is going to be able
to do as a result of the project (when successful).
– This should result in carefully written descriptions of what the deliverable must be able to do.
We call these descriptions the requirements.
– Note that requirements only define what the deliverable must do, not how it should be done!
Requirements are a first direct translation of the problem to the deliverable. Any deliverable
that doesn’t meet the requirements, are not capable of solving the problem or exploiting the
opportunity.
– Requirements should be written down in such a way that it is easy to recognize whether they are
met or not.
– To identify and define requirements, the most important perspective is that of the customer.
∗ Therefore it is important to understand who the customers are, which problems they experi-
ence and which needs they have.
∗ Remember that customers are often not very good at making their needs explicit. Do not
mistake what a customer wants with what they need. Specific methods to discover customer
needs are focus groups, surveys, site visits, usability studies and market research.
∗ This perspective is closely related to the desirability criterium of project value.
∗ Common ways to express these requirements are through use cases of user stories.
– As projects and their deliverables are not islands on their own, other requirements can relate to
the organizational structure, strategy and existing technological constraints. It makes sense that
the project outcome should fit within the organizational strategy and the existing technological
architecture.

• Once the problem/opportunity is clearly analysed and root causes are identified, creativity is needed
to design potential solutions.

– This is where the design of the solution starts and the requirements (what) are translated into
specifications (how).
– This typically consists of a divergent and subsequent convergent phase.
– The divergent phase is where you should invest in creativity and exploration. This is the stage
where the least amount of money has been spent and the greatest number of options exist. The
cost of exploring a new idea can be small and often only requires a limited amount of time.
– This creativity finds its inspiration in understanding the stakeholders and their needs. It is
important to realize that while searching for a solution that meets the requirements a substantial
set of constraints are defined (explicitly and implicitly). Creativity requires knowledge which
constraints can be ignored and when. Thus requires a strong understanding of the stakeholders.
2.3. STAKEHOLDER ANALYSIS 13

– During the convergent phase, one should try to quantify the costs and benefits of each proposed
solution. During this stage, you should expose the ideas to criticism and invite others to evaluate
the ideas honestly on the three main criteria: viability, desirability and feasibility.
– To be effective, there must be a interaction between defining requirements and creating specifica-
tions. If during the specification development stage it appears that certain requirements can’t be
met, the requirements should be re-evaluated. Therefore, it is often most efficient when the mem-
bers designing the solution also have the authority to change the requirements where necessary.

2.3 Stakeholder Analysis

• Involving stakeholders in the project initiation stage is very important but also relatively difficult.
– It is very important as this is the stage where the goals and direction of the project are determined.
– It is relatively difficult during this stage as the group of potential stakeholders is still very broad
which makes it more complex to correctly analyse the problem and propose a solution.
• Identifying stakeholders should be one of the first tasks (typically done by the project manager) because
all the important decisions during the definition and planning stage are made by these stakeholders.
– During the definition stage, it might not be necessary to actively communicate with all stakehold-
ers, but the more stakeholders you identify, the better the assumptions will be about how the
project will be perceived.
• Stakeholders can be involved in following activities:
– Establish agreements on the goals and constraints.
– Construct strategies and schedules.
– Approve the budget.
– Ultimately judge the success of the project.
• Stakeholders can be broadly split into two categories: those who are engaged in the project and those
who are only affected by the project. Each category can be further divided in stereotypical roles.

2.3.1 Typical roles of engaged stakeholders

• The project manager
– Obviously, this is the person who has to manage the project and make sure the project delivers
what is required on time and within budget.
– Once the project manager is identified, it is important to clearly define his or her authority, to
whom he/she has to report and their own expectations.
• The project team
– These are the people who are actually going to do the work and this should be considered in the
broadest sense.
– People who contribute time, skills and effort to the project.
– Please note that contractors, vendors and even customers can also be part of the project team.
Don’t limit yourself to people within the organization.
– Managing these stakeholders typically involves making sure all team members agree to their
responsibilities and roles in the project. Obviously, this requires that one first knows who is
involved and which work needs to be done by whom.
• Management
– By management, we refer to the typical functional management found within the organization.
– These managers can play two important roles for the project, i.e. as a project sponsor or resource
manager.
– The project sponsor is the person with real authority within the organization and provides this
authority to the project manager, who typically lacks real authority.
14 CHAPTER 2. PROJECT INITIATION

– Project sponsors typically:

∗ Publish the project charter announcing the existence, purpose and project manager of the
project.
∗ Approve the statement of work.
∗ Approve the project plan.
∗ advise the project manager.
∗ Assists in overcoming organizational hurdles.
– Management also serves the role of resource managers.
∗ As most members of the project team are often part of a functional department within the
organization, they need to be freed from their daily work in order to work on the project.
∗ Their functional managers act as resource managers to the project.
∗ These resource managers need to approve on the work that their people assigned to the project
will be doing.
• The customer
– The customer is the person who is typically paying for the project and therefore has final control
over the requirements, budget and time constraint.
– Therefore, one way to identify customers is by asking who should be involved in making the
necessary trade-offs within the iron triangle.
– Notice that it is not uncommon to divide customers into two separate roles: those who define the
requirements and those who provide the funding. It is not necessary that these two roles reside
with the same person.
• While the engaged stakeholders are often easy to identify and will always stay on the radar, it is not
uncommon to oversee or lose track of the stakeholders that are affected but not directly engaged.
• One tactic could be to make stakeholder identification a repeatable activity throughout the project.
• Another tactic could be to actively engage the people who will have to change their behaviour as a
result of the project by alerting them about the coming change to win their cooperation. These tactics
belong to the field of change management.

2.3.2 Stakeholder Management

• The general process of stakeholder management consist of three stages:
– Identification of stakeholders
∗ To identify engaged stakeholders you should ask the question: “Who will make a contribution
to the project?”
∗ To identify the affected stakeholders, ask “Who will (have to) change their behaviour by the
outcome of the project?”
– Prioritization of stakeholders
– Analysis of stakeholders

2.4 Project Proposal

• To determine if a project should get funded and started or not, the main question to be answered is:
“How will the project deliver value?”
• Therefore, one of the main deliverables of the initiation stage is a project proposal which tries to answer
this question and acts as the basis for evaluating the project.
• A project proposal articulates the benefits of the project in contrast to the costs that need be made.
The proposal must convince the reader of the project’s value, which can be judged on following 3
criteria:
– Desirability: The outcome of the project is something the stakeholders want. (Customer perspec-
tive)
2.4. PROJECT PROPOSAL 15

– Viability: The lifetime cost of the project and its outcome are outweighed by the benefits. (Busi-
ness perspective)
– Feasibility: The proposed solution by the project is (technically) feasible to realize. (Technological
perspective)
• Additionally, a good project proposal also identifies how one can determine during the project if the
project is going to achieve its goals or not. However this can be challenging, because the proposed
value of the project is often to a great extent realized only when the project has been completed.
– Waiting until the end of the project (and later) to determine if one is on the right track is clearly
not acceptable. Therefore, it is important to think about good leading metrics which give an
indication whether the project will produce the desired value.
– A leading metric is typically related to a root cause of the problem.
– A proposal should clearly identify what will be measured, when and how.

2.4.1 Project Proposal Template

• Project goal:
– Which are the specific desired results from the project over a specified time period.
– Focus on the value that should be experienced after the project.
• Problem/Opportunity definition.
– Describe the problem/opportunity without suggesting a solution.
– Provide factual evidence of the problem and try to avoid assumptions.
– Describe the problem/opportunity in its context and how it affects the context.
• Proposed solution.
– How will the project address the problem/opportunity.
– Be as specific as possible about the boundaries of the solution.
• Project selection and ranking criteria.
– Ideally, these are already defined as part of project portfolio management.
– Some criteria will focus on the benefits: compliance/regulatory criteria, efficiency/cost reduction
criteria, increased revenue criteria, …
– Some criteria will focus on the strategic fit with the organization and other projects.
– Some criteria will focus on the project’s urgency.
• Cost-benefit analysis.
– This part focusses on the financial reasons and represents the results of an quantitative analysis.
– It should focus on 4 elements: tangible benefits, intangible benefits, required resources (cost) and
financial return.
• Business requirements.
– Which are the requirements that must be fulfilled in order for the project to have a chance of
being successful.
• Scope.
– Describe the major accomplishments the project tries to realize.
• Obstacles and Risks.
• Schedule Overview.
– Describe at a high level the expected duration of the project, the significant milestones and the
major phases.
16 CHAPTER 2. PROJECT INITIATION

2.5 Project Rules

• Properly setting the project rules before the project starts is an important step to prevent difficult
discussions during the project execution stage.
• Clear project rules have a positive impact on three project success criteria: goal agreement, project
scope control, management support.
– Clear project rules make sure all stakeholders agree up front on the goals of the project and
expectations are properly managed.
– Clear project rules makes it explicit who, when and how the scope of the project can (be) changed.
– Clear project rules ensures that the project managers gets the appropriate authority from man-
agement to properly manage the project.
• The project rules are typically written down in three different documents:
– The project charter.
– The statement of work.
– The responsibility matrix.

2.5.1 The Project Charter

• The project charter contains:
– The name and purpose of the project.
– The name of the project manager.
– A statement of support from the project sponsor.
• The project charter announces that a new project begins and makes it clear to everybody involved
and affected by the project that the project and project manager are supported by the organization’s
management level.
• The project charter can be something as simple as a short email from the sponsor to the entire
organization.

2.5.2 Statement of Work

• The SOW lists the goals, constraints and success criteria for the project. It can consist of following
elements:
– Purpose Statement
∗ What will be done in the project and why?
∗ Having a clear purpose statement helps making decisions later on in the project.
∗ Note that it is not the purpose of the purpose statement (nor the SOW) to develop a business
case which justifies the funding of the project. The latter is typically part of the project
proposal.
– Scope Statement
∗ A description of the major activities of the project.
∗ The scope statement should make it clear at the end of the project which activities were
originally part of the project and which were added afterwards.
∗ It can also be helpful to also define which activities/results are out of scope.
∗ Be aware of the difference between the project and product scope!
· Product scope describes the features and performance levels of the product/service that
is to be created.
· Project scope describes the work and responsibilities of the project.
– Deliverables
∗ What is the project supposed to produce?
∗ When appropriate, make a distinction between intermediate and final deliverables.
2.6. PROJECT EVALUATION 17

∗ When appropriate, make a reference to more detailed product descriptions, typically found
in design documents.
– Cost and Schedule Estimates
∗ The budget and the deadline of the project should be mentioned.
∗ But also the rules if, how and when the budget and deadline can be changed.
– Measures of Success
∗ Make it clear how it will be decided whether the project is complete and successful.
∗ These measures should follow the SMART principles, otherwise it will be difficult to reach
agreement up front or, even worse, agreement at the end of the project.
– Stakeholders
∗ The SOW should clearly identify all stakeholders within the project.
• It is a good idea to write a first draft of the SOW and use this to manage expectations and create
agreement among all stakeholders. Based on all the input, one can then rewrite the draft into the final
‘original SOW’
• Note that the SOW can change throughout the project as long as there is agreement and consent
among all stakeholders.

2.5.3 Responsibility Matrix

• The responsibility matrix, is also known as a RACI (responsible, accountable, consulted, informed)
chart. It details who or which roles hold which responsibilities throughout the project.
• One dimension of this matrix defines the major activities in the project.
• The second dimension defines the different roles/stakeholder groups.
• The cells of the matrix hold any of four possible codes:
– R for ‘responsible’. This person/group is responsible that the work gets done. They have to report
to the person who is accountable for the activity.
– A for ‘accountable’. This person/group has the final word on decisions and has to give the final
approval whether the work is completed. There should only be 1 person/group responsible.
– C for ‘consulted’. This person/group must be consulted while the activity is done. They can
influence the direction and outcome of the activity.
– I for ‘informed’. This person/group must be informed about the decisions, progress and outcome
of the activity. They don’t influence the activity.

2.6 Project Evaluation

• Because resources are typically limited, launching a new project should be a well considered decision
which is made in the context of other running projects, other project opportunities and the overarching
organization’s strategy.
• Despite the informal start of the initiation, a more structural and rigorous approach is recommended
to determine whether the project should be launched or cancelled.
• A key element is the presence of clear and unambiguous criteria for approving a project.
• When the decision is not only whether a project is worth the effort or not, but rather which of the
worthy projects should get the limited budget, an even more structural approach is needed. This
approach is known by the term of ‘project portfolio management’ and operates at a higher level than
project management.
Chapter 3

Project Planning

• Once a project is selected for execution, the structural project planning approach prescribes that the
project get planned in detail prior to the actual start of the project.
• Project planning consists of two main stages: Risk Management and Project Scheduling.
– The goal of the risk management stage is to identify project risks and take the necessary precau-
tions.
– The goal of project scheduling is to make a detailed schedule of all the tasks that need to performed,
with specific time frames and resource allocations.

3.1 Risk Management

• In projects, there is always some uncertainty about the schedule, the costs and the quality of the end
product.
• Project management is to some extent risk management which tries to systematically manage this
uncertainty in order to increase the likelihood of meeting project objectives
• Risk management deals with uncertainty, which comes in two flavours:
– Known unknowns: Identified potential problems. One doesn’t know exactly what will happen,
but one is aware of the risks and their potential to damage the project. One can prepare for these
risks.
– Unknown unknowns: These relate to problems that arrive unexpectedly and cannot be anticipated.
However, good project managers still expect these to happen.
• All project management activities can be considered as managing risk, but the risk management process
is a specific set of activities performed consciously to identify and manage risks on the project.
• There is a difference between project risk and business risk.
– Business risk relates to creating the right project output. Business risk is seldom the responsibility
of the project manager, but rather of the project owner.
– Project risk relates to making sure the project produces the promised results within budget and
on time. This is the responsibility of the project manager.

3.1.1 Risk Management Framework

• A possible risk management framework consists of 5 main steps:
– Identify Risks: Find all the factors that threaten project objectives.
– Analyse and prioritize: Assess each risk in terms of its possible damage and likelihood of occur-
rence.
– Develop a response: Create strategies for reducing the possible damage and/or probability the
risk will occur.
– Establish reserves: Set aside additional funding for the project that will be used for known risks
and unknown risks.

19
20 CHAPTER 3. PROJECT PLANNING

– Continuous risk management: Implement strategies and monitor the effects of these changes on
the project.

3.1.1.1 Step one: Identify the risks

• Organize brainstorm sessions with stakeholders to gather potential risks. Generate a list as big as
possible with potential risks. Once you have a list of potential risks, organize them by combining
similar risks and order this list by magnitude and probability of the risk.
• Another approach to identify risks is by means of interviews, which is a more structured approach than
brainstorming.
• To support the identification of project risks, one could use a risk profile. This is a list of questions that
address traditional areas of uncertainty on projects. Creating such a risk profile should be an ongoing
process, such that the end of the project, what has been learned will incorporated into the profile.
• Another source of risk identification is the other main activity during project planning, i.e. the process
of estimating schedules and budgets. Activities and tasks which are hard to estimate often imply a
substantial amount of uncertainty. Identifying the cause of this uncertainty will most likely reveal
project risks.
• Note that the goal of this step is NOT (yet) to identify ways to minimize or eliminate risks. The goal
is only to identify risks.

3.1.1.2 Step two: Analyze and prioritize the risks

• To identify the importance of risks, one has to take two dimensions into account, i.e. the likelihood of
occurrence and the impact if the risks becomes reality.
• After creating an initial list of potential risks, a first step is to quickly eliminate risks from your list
which are not worth worrying. Next, one should sort the remaining risks in order of importance. This
step should be performed quickly and based on intuition.
• A next step could be to concisely describe and analyse the remaining risks by clearly formulating the
condition which causes the uncertainty as well as the consequence of this situation in terms of the
possible negative outcomes.
• Once the risks are defined, the consequences in terms of cost, schedule and damage to the project must
be described as well.
• Finally, each risk must also receive an estimate of the probability that the risk will actually occur.
• Providing an exact estimate of both the impact and the probability of occurrence is often difficult.
This should never be an excuse to skip this step. Instead, when exact estimates are difficult to obtain,
one could switch to an ordinal scale with e.g. three categories (from 1 to 3, representing respectively a
low, medium or high impact/probability).

3.1.1.3 Step three: Develop Response Plans

• A first step is to identify those risks that are within the control of the project team and those that are
not.
• There are five ways to deal with identified risks:
– Accept the risks. This implies that you understand the risk and decide to do nothing about it.
This is a common strategy when the impact or the probability are low.
– Avoid the risk. You can try to avoid a risk by choosing not do to specific parts of the project or
by selecting a lower-risk option for meeting the project goals.
– Contingency plans. When you cannot ignore, nor avoid the risk and have no impact on the
probability, you can try to reduce the negative impact and have a fall-back plan in place when the
risk becomes reality. Note that contingency plans require a continuous monitoring of the risks,
such that you can activate the continuous plans on time. This implies that this strategy can only
be efficient if there is a way to detect the risk on time.
– Transfer the risk. This strategy typically boils down to paying for insurance. Another approach
is setting up a fixed-price contract that will get the work done on time for a fixed price. Note
that this could however introduce new risks as more external parties get involved.
3.2. PROJECT SCHEDULING 21

– Mitigate the risk. This strategy tries to reduce the risk and more particularly the probability that
the risk occurs. This often implies taking extra actions.

3.1.1.4 Step four: Establish Contingency and Reserve Funds

• Once the strategies are determined, (financial) reserves must be set aside to allow the strategies to be
implemented. Such contingency and reserve funds serve the purpose to account for known un-knowns.
• Unknown unknowns are never accounted for by such reserves. Instead, management reserves must be
used for risks that cannot be anticipated. Risk management only deals with anticipated risks.

3.1.1.5 Step five: Continuous Risk Management

• The initial risk plan is based on all known information at the start of the project. However, as the
project progresses, more information is gained, also on potential risks. Therefore, risk management
should be a continuous effort. This includes:
– Monitoring known risks.
– Checking for new risks.
– Repeating the risk management framework for newly identified risks.

3.2 Project Scheduling

• A second element of the project planning stage is the development of a detailed project schedule.
• The classical approach of project management relies heavily on upfront planning. We first plan every-
thing prior to execution.
• Developing a project schedule can be broken down in following steps:
– Develop a work breakdown structure.
– Identify task relationships.
– Estimate work packages.
– Calculate initial schedule.
– Assign and level resources.

3.2.1 Work Breakdown Structure

• A first step is to break down the work into smaller pieces of work which make it easier to accurately
estimate the required time and resources. This is typically achieved by developing the Work Breakdown
Structure (WBS) of a project, which is a tool for breaking down a project into its component parts.
• The work breakdown structure identifies all the tasks/deliverables in a project and can be set up
graphically or as an textual outline. Traditionally, a WBS focussed on tasks, more recently there has
been a shift towards deliverables.
• Building a WBS helps to:
– Provide a detailed illustration of project scope.
– Monitor progress. The tasks on the WBS become the basis for monitoring progress, because each
is a measurable unit of work.
– Create accurate cost and schedule estimates.
– Build project teams as it provides clear work assignments to the team members and provides an
overview how his or her work fit into the overall effort.
• A WBS breaks all the work into separate tasks of which two types exist:
– Summary tasks. A summary tasks includes several subordinate tasks and is not actually executed.
Its purpose is to summarize more detailed tasks, called work packages.
– Work packages. These are the tasks that actually require execution.
– E.g. Creating manual can be the summary tasks which consists of the work packages writing
content, setting layout, proofreading and printing manual.
22 CHAPTER 3. PROJECT PLANNING

• Developing a WBS typically follows three steps:

– List the major deliverables or high-level tasks.
– Name all the tasks required to produce deliverables.
– Organize the WBS.

3.2.1.1 WBS Step One: Start from the top

• A WBS is typically developed in a top-down approach. You can start from the deliverables mentioned
in the statement-of-work and turn them into the major summary tasks.

3.2.1.2 WBS Step Two: Identify all tasks required to produce deliverables
• The next step is to break down each task into lower-level, more detailed tasks required to produce the
deliverable.
• This is often the most difficult step in the planning process and requires a good understanding of how
to produce the project outcome.
• Give each task (work package and summary task) a name that describes an activity which produces
some specific output. Therefore, the naming of activities typically follow the “verb-noun” format.
• Try to avoid open-ended tasks such as “read literature” as these could go on indefinitely.
• Try to avoid tasks that don’t clearly describe the action which is required, such as e.g. “literature”.
• To ensure that the work packages are the correct size, following rules can be applied as rule of thumb.
– No task should be smaller than 8 labour hours or larger than 80. (These limits might need
adjustment depending on the kind of project and availability of non-stop working time).
– No task should be longer than the time between two reporting meetings.
– Break work packages down to smaller tasks if:
∗ It makes the task easier to estimate.
∗ It makes the task easier to assign.
∗ It makes the task easier to track.

3.2.1.3 WBS Step Three: Organize the WBS

• Once all the work packages are identified, rearrange them in the most appropriate way.
• In this step, one often creates new summary tasks and put work packages in new/other summary
packages.
• Different ways of organizing work packages emphasizes different aspects of a project.
• Make sure that summary tasks are meaningful as their sole purpose is for communication or visibility.
These summary tasks communicate what your project is about.
• Also make sure that the work packages underneath the summary task add up to the summary task.
When one has completed all the work packages, the result automatically be that the summary task is
completed.

3.2.2 Identify task relationships

• The sequence in which detailed tasks - work packages - are performed is determined by the relationship
between the tasks.
• Any time a series of tasks is performed, there will be sequence constraints, i.e. some tasks need to be
performed before others.
• To visualize these constraints, tasks and sequential constraints can be visualized as a graph. When
doing so, two basic rules are important:
– Task relationships (arrows) should only be shown between work packages (and not summary
tasks).
– Task relationships should only reflect sequence constraints between work packages, not resource
constraints.
3.2. PROJECT SCHEDULING 23

• When visualizing task relationships in a graph, it can be useful to identify significant events in the
project, as known as milestones. Such milestones are events and have no duration. They serve following
purpose:
– Milestones are useful anchors. They provide a quick overview how the project progresses.
– Milestones can be used to mark input from one party to another. It illustrates when the project
delivers something to its stakeholders.
– Milestone allows visualization of events that aren’t represented by a work package or summary
task.
• The sequential constraints between tasks, visualized by graphs, can further be separated into different
categories:
– Finish-to-start relationship. The subsequent activity can only start when then preceding activity
finished.
– Start-to-start relationship. The subsequent activity can already/only start when the preceding
activity started.
– Finish-to-finish relationship. The subsequent activity can start independently of its predecessor,
but cannot finish before the predecessor finishes.

3.2.3 Estimate Work Packages

• Now that the project is broken down into smaller, estimable work packages, the goal is to estimate the
duration of each work package.
• Note that the duration is the time between initiation to completion.

3.2.4 Calculate an Initial Schedule

• Now that the work packages and their duration and interdependencies are identified, one can start
estimating the duration of the project.
• The first step is to perform a forward pass. This will allow you to determine the earliest starting point
(ES) and finish time (EF). The EF of a task equals the ES plus its duration. The ES of a task equals
the latest EF of all its direct predecessors. The forward pass starts with the first task, whose ES equals
the starting time of the project.
• The next step is to perform a backward pass. This allows one to determine the latest start time (LS)
and latest finish time (LF) of each task. The LS time equals the LF minus its duration. The LF of
a task equals the earliest LS of all its direct successors. The backward pass starts with the last task,
whose LF equals the project deadline.
• Next, it is important to calculate the float of each task. The float of an activity is the difference
between its ES and LS (or EF and LF) and represents to what extent the start of an activity can be
postponed in relation to its ES. Float provides flexibility in a schedule.
– The set of tasks which zero or negative float is the critical path. Any delay in the critical path
will automatically result in a delay in the project (unless corrective actions are taken).

3.2.5 Assign and level resources.

• Now that the schedule is made, it is time to assign resources to the schedule. It’s goal is to do so in
order to optimize the use of people and equipment to the project.
• It begins with the assumption that, whenever possible, it is most productive to have consistent, contin-
uous use of the fewest resources possible. In other words, try to avoid repeatedly adding and removing
resources time and again throughout the project.
• This goal is achieved by the act of resource levelling which focusses only on people and equipment, not
materials. The amount materials needed is dictated by the specifications.
• Resource levelling follows a four-step process:
– Forecast the resource requirements throughout the project for the initial schedule.
24 CHAPTER 3. PROJECT PLANNING

– Identify the resource peaks.

– At each peak, delay non-critical tasks within their float.
– Eliminate the remaining peaks by re-evaluating the work package estimates.
Chapter 4

Knowledge Discovery

4.1 Managing the unknowns

• A large part of project management is managing the unknowns. As the definition of a project implies
unique and temporary work, it also implies that many aspects related to the outcome of the project
and the work required to produce the outcome is unknown at the start.
• When talking about unknowns, one can distinguish between “known unknowns” and “unknown un-
knowns”. Dealing with “known unknowns” is the field or risk management.
• Once one is aware that each project contains “unknown unknowns”, it becomes clear that a process is
needed to reveal these “unknown unknowns” and turn them either into things we know or things of
which we now know that we don’t know. We call this process “knowledge discovery”.
• Knowledge discovery is an active process that aims to acquire new and additional knowledge with
respect to the project, either through experience or education.

4.2 Challenged versus unchallenged demand

• The difficulty of discovering “unknown unknowns” and acquiring new knowledge lies in the obvious fact
that we are unaware of these unknowns. Therefore, we need some structured approach for knowledge
discovery.
• It is important to be aware that the risk of “unknown unkonwns” already exists at the onset of a
project. Typically, when a project is initiatied, the sponsor (internal or external) comes with a specific
demand. However, there is a risk that this demand is not what is really needed in order to create value.
– Therefore, one could challenge the original demand from the start, to make sure the demand is
not based on false assumptions (as long as we don’t know whether the underlying assumptions
are true or false, there is the potential for unknown unknowns).
– At the same time, many project managers will tell you from experience that what a cus-
tomer/sponsor asks is often not what they need.
– However, they will also be able to tell your that at the start of a project, you as a project manager
will lack the necessary context and background knowledge to make such judgement calls (whether
the requested project outcome is also the required project outcome).
• When you assume that the requested project outcome is also the required project outcome, all that
remains is project risk - i.e. delivering according to requirements, on time and within budget - which
requires proper risk management.
• When you want to challenge whether the requested project outcome is also the required project outcome,
you are actually challenging whether the project delivers value - i.e. desirability, feasibility and viability.
Challenging the assumption that the project will produce value is an important focus during knowledge
discovery.
• Note that in practice you will not always challenge the demand. There are many occasions where
you simply accept the requested outcome as such and focus on delivering according to requirements.
External factors and experience typically guide a project manager to make such call.

25
26 CHAPTER 4. KNOWLEDGE DISCOVERY

4.3 Knowledge Discovery and project outcome value

• Product risk relates to the risk that while the outcome of a project meets the predefined requirements
and is delivered on time and within budget, it still fails to deliver the expected value.
• The value of a project deliverable is defined by three dimensions: desirability, viability and feasibility.
For each of these three dimensions a different approach exists to uncover hidden assumptions and
discover “unknown unknowns”.

– Desirability is related to the question whether the project deliverable meets an actual need of the
client. Each project addresses a ‘friction’ that exists between the current AS-IS situation and a
more desirable TO-BE situation. The more the project outcome helps the transition towards the
TO-BE situation, the more desirable it is. To challenge the desirability of a project, one tries to
discover the tension between the AS-IS and TO-BE situation.
– Viability relates to whether the project outcome can deliver value in a sustainable and user-friendly
way, such that it will be actually used by the end-user. A typical approach to challenge viability
is by means of designing prototypes of the project outcome and testing them.
– Feasibility relates to whether the project outcome can actually be built. Therefore, the typical
approach to discover hidden assumptions in relation to feasability is by means of building a
Minimum Viable Product.

• While the discussion above might suggest a predefined order between the three dimensions of value,
this is often not the case in reality. Typically, these three dimensions are tested simultaneously by
means of iterative and overlapping approaches.
• While knowledge discovery has a very important role during project initiation, it is certainly not limited
to the initial project lifecycle stage. Particularly in agile project methods (as we will discuss later), the
discovery of unknown unknowns is a continuous effort.

4.4 Knowledge Discovery is a process of incremental effort

• During project initiation, the request of a project sponsor is tyically a fragmented story (with important
information often missing) and at the same time contains (elements of) a solution that is based on
hidden and untested assumptions.
• At the same time, as the project manager, you often lack the necessary background knowledge and
context to identify these issues, which makes it difficult to efficiently discover the “unknown unkowns”.
• As identifying “unknown unknowns” becomes increasingly easier as the knowledge about a project
increases, the knowledge discovery proces should follow an approach of incremental effort:

– First, one should focus on collecting as much as information as possible. This information can
still be fragmented, ambiguous and conflicting at this stage, which is fine. This first “Capture”
step requires the least effort.
– Next, one can move towards the “Synthesis” step, which implies that one creates a coherent
and shared understanding of the problem at hand. By “shared” we refer to the fact that the
understanding of the client and the project team should be aligned. Therefore, this step should
be a story of co-creation with the client and already requires more effort.
– Thirdly, once we have reached a shared understanding of the situation, it is time to analyze the
context in search for assumptions and to test these assumptions against reality to see if they hold
true. If not, one has spotted an “unknown unknown” which either will be solved by changing
the project outcome or becomes a “known unknown” that can be dealt with by traditional risk
management.

4.5 Common pitfals to be aware of during the discovery process

• During the discovery process, one has to be aware of three common pitfalls: ambiguity, invisible gorillas
and ugly babies.
4.6. TWO TYPES OF LEARNING 27

• Ambiguity refers to the fact that two people can observe the same facts, but see a different story. This
is particularly problematic when your interpretation of the project context is not aligned with that of
the client. This does not imply that you should assimilate the interpretation of the client, but rather
that discovery should be a social activity where you interact as much as possible with your client to
develop a shared understanding. At the same time, you should always welcome such conflicts between
interpretation. Often we need conflicting ideas and interpretations of reality to actually learn and make
progress.
• Invisible gorillas are a metafor for assumptions that we make about reality in order to efficiently reason
about it. These assumptions are so ingrained in our thinking that we are often not aware of them
although they are present in full sight. The key take away is to develop a scientific attitude where you
question everything and make your assumptions explicit.
• Ugly babies is a a metafor for the fact that during the project initiation stage and during the discovery
process, the initial ideas don’t seem to be of high quality and often contain many hidden assumptions.
However, the key take away is to not quit an idea too early and to keep incrementally improving. Like
many ugly babies, over time these projects could deliver something of high value.

4.6 Two types of learning

• A central theme in Knowledge Discovery is ‘learning’. However, we should distinguish two types of
learning that can and will occur during knowledge discovery and of which one should be aware: intuitive
learning and rational learning.
• Intuitive learning typically occurs unconsciously and is a fast way of learning based on experiencing
reality. Four phases (OODA) can be distinguished in the intuitive learning cycle.
– It all starts by observing certain events which unfold themselves. These observations are the raw
information on which decisions and actions will be based. Be aware that because of how our brain
works, we filter our observations. Many events will unfold themselves without being noticed or
observed by an individual. At the same time they can be absolutely obvious to other individuals
(cfr. the invisible gorillas).
– Next, we move towards the Orient phase. This implies that we will put the observation in a
context that is mentally constructed. Because of genetic heritage, cultural traditions and past
experience, the same observation will be interpreted differently by different individuals (they orient
themselves differently).
– The third phase is where one decides what to do based on the observed event and the interpretation
given to it in the previous phase.
– Finally, the fourth phase (Act) refers to the actual action one takes in response to the observed
event, based on the decision made in the previous phase. Obviously, this action will trigger new
events which will result in a new iteration of intuitive learning.
• Rational learning is a very concious process which is much more deliberate and slower. This is the
type of learning that corresponds to the well-known PDCA cycle in management.
– During the Plan phase, the objectives of the learning are established as well as the processes are
designed to deliver the desired results.
– Next, the Do phase allows the plan from the previous step to be executed. Small changes are
usually tested against a baseline and data is gathered to evaluate how effective these changes
were.
– During the Check phase, the data and results from the previous phase are evaluated against the
expected outcomes. Based on this evaluation against the original assumptions, one discovers new
knowledge and can improve.
– These improvements are implemented during the Adjust phase, which is typically followed by a
new iteration of the plan phase, resulting in continuous improvement.
• These two types of learning are not independent from each other and can be connected to each other.
Typically one starts with the OODA cycle of intuitive learning which is action oriented, fast and
conservative. However, when during the orient phase, frictions arise between the observed events and
28 CHAPTER 4. KNOWLEDGE DISCOVERY

the observer’s expectation, one can decide to move over to the more thoughtful, slow and explorative
way of learning by developing new hypothesis and experiments in the Plan phase of the PDCA cycle.
After the necessary iterations of the PDCA cycle, when knowledge has been discovered and the friction
between event and expectations has been removed, one can switch back to the OODA cycle of intuitive
learning and act in line with the new knowledge.
• Being aware of these two types of learning is an essential step. Becoming mindful when to switch
between these types of learning is essential to master knowledge discovery.

4.7 Methods and Techniques

• Understanding the process of ‘knowledge discovery’ is a first step in order to unveil the ‘unknown
unknowns’, but is often insufficient to actually do so succesfully. To this end, there are various methods
and techniques which facilitate the action of knowledge discovery. By applying these methods, one
increases the probability of discovering new knowledge.

4.7.1 Effectuation
• To reach a goal, two broad strategies exist: causation and effectuation.
• Causation starts from the goal in mind and tries to figure out how to reach this goal effectively and
efficiently.
• With effectuation, the goal does exist but is rather a direction than an exact destination. With
effectuation as strategy, one starts from the available resources and takes a step in the direction of
the end goal. After each step, one evaluates again and takes a new step forward. However, because
one starts from the available resources and one re-evaluates after each step, it is not unlikely that one
discovers new information that will lead to another goal than originally set forth.
• 5 strategies to implement effectuation as a strategy are:
– “Bird in the hand” principle: Don’t wait for the ultimate idea, but just start with what you got
and what you know and try to take steps forward.
– “Affordable loss” principle: You should only invest what you ar ewilling to lose. Minimize the
risk of a project by only investing what you are willing to lose - rather than focusing on what
can be achieved if the project succeeds. By taking small steps in one direction instead of working
towards long-term goals with unpredictable outcomes (effectuation logic), it is possible to avoid
investing time or money that you are not actually willing to lose.
– “Crazy Quilt” principle: Entering into new partnerships can bring the project new funds and
new directions. It is often more valuable to collaborate with various types of partners who are
willing to commit, than to search for potential partners who might not be available or motivated.
However, it is important that in this case one is open to let the project change direction as the
new partners offer different and surprising perspectives.
– “Lemonade” principle: Mistakes and surprises are inevitable and can be used to look for new
opportunities.
– “Pilot in the plane” principle: Be aware and make sure that you are always in control of your
project. Create your future with the elements that you control and with the partners that you
choose.

4.7.2 Impact mapping

Following comes directly from https://www.impactmapping.org/)

• Impact mapping is a strategic planning technique that prevents organisations from getting lost while
building products and delivering projects, by clearly communicating assumptions, helping teams align
their activities with overall business objectives and make better roadmap decisions.
• An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior
technical and business people. It is a mind-map grown during a discussion facilitated by considering
the following four aspects: * Goal: The centre of an impact map answers the most important question.
4.8. RESOURCES 29

Why are we doing this? This is the goal we are trying to achieve. * Actors: The first branch of an
impact map provides answers to the following questions. Who can produce the desired effect? Who can
obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are
the actors who can influence the outcome. * Impacts: The second branch level of an impact map sets
the actors in the perspective of our business goal. It answers the following questions: How should our
actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent
us from succeeding? These are the impacts that we’re trying to create. * Deliverables: Once we have
the first three questions answered, we can talk about scope. The third branch level of an impact map
answers the following question: What can we do, as an organisation or a delivery team, to support the
required impacts? These are the deliverables, software features and organisational activities.

4.8 Resources
• Unknown Unknowns
• Jonathan Haidt, the righteous mind.
• Alan Page Fiske, Social structures
• Effectuation, Saras D. Sarasvathy
• Impact Mapping
Chapter 5

Traditional Project Management

5.1 Characteristics of traditional project management

• The term “Traditional Project Management” is typically reserved for project management methodolo-
gies which contain following characteristics:
– A rather strict implementation of the project life cycle (Initiate - Plan - Execute - Close) or a
variant of this life cycle. These methodologies follow a waterfall approach to some extent where
the project is divided in clear stages, each with their own tasks and deliverables. Furthermore,
the implicit assumption is that once one moves from one stage to the next, the decisions made in
the previous stage are more or less fixed.
– Traditional project management approaches put a lot of emphasis on the process aspect of project
management. The aim of project management is to ensure that the project follows the predefined
process (process compliance).
– A key element of traditional project management is context stability. Typically, these approaches
assume that not only the environment remains stable once the project starts, but also the require-
ments, analysis and designs once they have been set.
– Within this context of stability, these methodologies focus heavily on predictability of the project.
If enough efforts are made such that one can precisely predict the outcomes and risks of a project,
in becomes possible to keep the project in control (compliant to the process).
– Given this emphasis on predictability, these methodologies also share their reliance on task break-
down. By breaking down the end deliverable into tasks of increasing detail (and narrowed scope),
it becomes increasingly easier to make correct predictions.
– Two well-known traditional project management methodologies are PMBoK and PRINCE2.

5.2 PMBoK
5.2.1 Background
• PMBoK has been developed by the Project Management Institute (PMI) which was founded in 1969
as a non-profit organization to foster recognition of and provide support to the project management
community worldwide.
• The PMI published a first version of the Project Management Body of Knowledge Guide (PMBoK
Guide) in 1996, which to some extent was based on a white paper published in 1983.
• The PMBoK Guide was approved as an American National Standard in 1999 by the American National
Standards Institute (ANSI).
• The most recent version of the PMBoK Guide (6th edition) was published in 2017.

5.2.2 PMBoK Guide

• The PMBoK Guide is a “subset of the project management body of knowledge that is generally rec-
ognized as a good practice. ‘Generally recognized’ means the knowledge and practices described are

31
32 CHAPTER 5. TRADITIONAL PROJECT MANAGEMENT

applicable to most projects most of the time and there is a consensus about their value and usefulness.
‘Good practice’ means there is a general agreement that the application of the knowledge, skills, tools,
and techniques can enhance the chance of success over many projects.” (source: Project Manage-
ment Institute, A Guide to the Project Management Body of Knowledge – Fifth Edition,
Project Management Institute Inc., 2013, Page 2.)
• PMBoK is process-based. It defines a set of processes which describes the work that is typically
executed to manage projects.
• Each process is defined by the inputs it requires, the outputs it produces and the tools and techniques
that can be applied to turn inputs into outputs.
• Processes are linked to each other as the outputs of certain processes serve as inputs for other processes.
• PMBoK is descriptive in nature. It does not prescribe how one must manage a project. It merely
describes a set of processes that can be used to manage a project.
• Each of these processes must be tailored to the specific needs of the project. Decisions such as which
processes should be executed, by whom and how rigorously, need to be made by the project management
team on a project by project basis.

5.2.3 PMBoK Processes

• PMBoK (6th edition) describes 49 processes in total, which can be organized along two dimensions:
process groups and knowledge areas.
• PMBoK identifies 5 process groups which corresponds to different stages in the project management
lifestyle:
– Initiating
– Planning
– Executing
– Monitoring and Controlling
– Closing
• PMBoK (6th edition) also identifies 10 knowledge areas which refer to specific disciplines/aspects of
project management:
– Project Integration Management
– Project Scope Management
– Project Schedule Management
– Project Cost Management
– Project Quality Management
– Project Resource Management
– Project Communications Management
– Project Risk Management
– Project Procurement Management
– Project Stakeholder Management

5.3 PRINCE2
5.3.1 Background
• In 1975, a private organization Simpact Systems developed a project management framework for the
development and support of IT systems. This framework was called Project Resource Organisation
Management Planning Technique or PROMPT. It contained a specific system development module
called PROMPT II.
• In 1989, the UK government licensed the use of PROMPT from Simpact. The Central Computer and
Telecommunications Agency (CCTA) only fully implemented the PROMPT II module and adjusted it
to create a new standard for IT Project Management. This new standard was called “PROMPT II IN
the CCTA Environment” or PRINCE in April 1989. Later, the acronym was changed to “PRojects IN
Controlled Environments”.
5.3. PRINCE2 33

• PRINCE was released to the public domain in 1990 and the UK government used it for different
projects, both IT and non-IT. Over time it became also well adopted by industry, again both in an IT
and non-IT context.
• In 1996 PRINCE2 was developed in consultation with about 150 European organisations. In contrast
to PRINCE, PRINCE2 is a generic project management framework designed to be industry-agnostic
(not with IT industry in mind as PRINCE did). Over time, PRINCE2 became a project management
standard in Europe.
• Over time, PRINCE2 went through various revisions, with the latest update in 2017.

5.3.2 PRINCE2 Fundamentals

• PRINCE2 is not only process-focused, but also very much product-focused. This is reflected in its
definition of a project: “a management environment created for the purpose of delivering one or more
business products according to a specified business case”.
• This product-focus is also reflected by the emphasis put by PRINCE2 on the project’s business case
which is considered the main driver behind the project.
• In contrast to PMBoK, PRINCE2 is much more prescriptive than descriptive. PRINCE gives specific
guidelines how project management should be organized, structured and implemented.
• Nevertheless, PRINCE2 also clearly states that the PRINCE2 framework must be tailored to the needs
of the project at hand.
• This can result in project management implementations that started from PRINCE2 but tailored away
almost everything specific to PRINCE2. Such project are sometimes called PINO projects (PRINCE2
in name only).

5.3.3 PRINCE2 Principles

• PRINCE2 is based on 7 principles which cannot be tailored. They should be reflected throughout the
actual project management implementation (source: Wikipedia):

– Continued Business Justification: The business case is the most important document, and is
updated at every stage of the project to ensure that the project is still viable. Early termination
can occur if this ceases to be the case.
– Learn From Experience: Each project maintains a lessons log and projects should continually
refer to their own and to previous and concurrent projects’ lesson logs to avoid reinventing wheels.
Unless lessons provoke change, they are only lessons identified (not learned).
– Defined Roles and Responsibilities: Roles are separated from individuals, who may take on multi-
ple roles or share a role. Roles in PRINCE2 are structured in four levels (corporate or programme
management, project board, project manager level and team level). Project Management Team
contains the last three, where all primary stakeholders (business, user, supplier) need to be pre-
sented.
– Manage by Stages: the project is planned and controlled on a stage by stage basis. Moving
between stages includes updating the business case, risks, overall plan, and detailed next-stage
plan in the light of new evidence.
– Manage by Exception: A PRINCE2 project has defined tolerances (6 aspects above) for each
project objective, to establish limits of delegated authority. If a management level forecasts that
these tolerances are exceeded (e.g. time of a management stage will be longer than the estimated
time in the current management stage). it is escalated to the next management level for a decision
how to proceed.
– Focus on Products: A PRINCE2 project focuses on the definition and delivery of the products,
in particular their quality requirements.
– Tailor to Suit Project Environment: PRINCE2 is tailored to suit the project environment, size,
complexity, importance, time capability and risk. Tailoring is the first activity in the process
‘Initiating A Project’ and reviewed for each stage.
34 CHAPTER 5. TRADITIONAL PROJECT MANAGEMENT

5.3.4 PRINCE2 Themes

• PRINCE2 identifies 7 themes which are parts of the project that need to be continually addressed
throughout the project life cycle. In some sense, these correspond to the Knowledge Areas in PMBoK.
The 7 themes imply activities at the start of the project to set up the project as well as activities
throughout the project life cycle to monitor these themes. The seven themes are:
– Business case
– Change
– Organization
– Plans
– Progress
– Quality
– Risk

5.3.5 PRINCE2 Processes and Activities

• PRINCE2 is process-based and defines 7 processes that consist of a structured set of activities designed
to accomplish a specific objective. Note that processes in PRINCE2 are defined at a higher level than
in PMBoK. What PMBoK calls processes are defined as activities in PRINCE2.
• The Processes in PRINCE2 have a strong resemblance to the different phases of the project life cycle,
with the addition that it assumes that a project is defined into separate stages (i.e. one of the core
principles).
• The 7 PRINCE2 Processes are:
– Starting up a Project
– Initiating a Project
– Directing a Project
– Managing a Stage Boundary
– Controlling a Stage
– Managing Product Delivery
– Closing a Project
• PRINCE2 identifies 40 different activities across the 7 processes for which it clearly states what needs
to be done and by whom.

5.4 Resources
• PMI
• PMBoK
• PMBoK Processes organized according to Process Groups and Knowledge Area
• PRINCE2
• The history of PRINCE2
• PRINCE2 Wiki
• PRINCE2 Process Diagrams
• PRINCE2 or PMBoK - A question of choice
• Comparing PRINCE2 with PMBoK
Chapter 6

Agile Project Management

6.1 Agility
• Agility is the capability to efficiently and effectively adapt to an ever changing environment.
• Agility can be defined at different levels: personal, departmental or organizational.
• Note that it is not possible to implement agility directly. Agility is a property of a system that is
present to some varying extent, depending on how the system operates.
• One can identify three drivers which will cause a system to become more agile: flow, learning and
collaboration.

– Flow refers to the way work is processed by the system. If the processing of work occurs at a
steady and sustainable rate, the system has a high level of flow. Such state of high flow is often
accompanied by a feeling that work becomes easy and routine takes over. Some people refer to
this state as “being in the zone”.
– Learning refers to mechanisms in the system which allow the system to learn from past experiences,
mistakes or other people, but also to uncover unknown unknowns (knowledge discovery).
– Collaboration refers to various ways how people in the system can work together to achieve a
single goal. Different forms of collaboration can be distinguished:
∗ Helping. One person decides to help another person finish his or her job. This way of
collaboration is useful when you have nothing else to do. In this approach, the person who
helps takes the initiative to collaborate. Most likely this person will not be as productive as
the person he or she is helping due to lack of experience in the task at hand.
∗ Apprenticing. A specialist involves another person in his or her job, so this person can help
but also becomes more experienced. In this approach, the expert takes the initiative for
collaboration. This approach is useful to prevent specialists to become bottlenecks in the
process.
∗ Synchronizing. This is a form of pre-emptive collaboration. The idea is to never start a
task that one cannot complete without the help of another person unless we are certain that
this other person will be available. Synchronizing implies that one synchronizes with the key
resources to make sure they will be available when necessary.
∗ Swarming. When faced with a very critical or highly uncertain task, swarming could be a
useful collaboration approach. The idea is for the team to get together and discuss the task in
order to decide on a plan of action and then spread out for a limited amount of time (e.g. 30
minutes) to each work on a part of the task individually. Next, they come back together to
discuss the progress and synchronize with each other, before they scatter again to continue
working. They repeat this process until the work is done.
∗ Integrating. Often a task will require different people to do parts of it. If the task is moving a
lot from one person to another person, the integrating approach would imply to work together
on it. The idea behind this collaboration technique is that moving work from one person to
another implies a transaction cost (waiting time because both people need to be available,
time required to bring the other person up to speed, errors due to miscommunication, …). By

35
36 CHAPTER 6. AGILE PROJECT MANAGEMENT

integrating the work, these transaction costs can be eliminated.

∗ Pairing & Mobbing. Pairing and mobbing are two techniques where either two people (pairing)
or an entire team (mobbing) work together on a single task. While one person takes the lead
(e.g. controls the keyboard), the rest observes, asks questions, makes suggestions, … . Often
the role of leading the collaboration is passed around from team member to team member at
a fixed time interval.

6.2 Impact of agility drivers on work efficiency

6.2.1 How work works
• While agility refers to the capabilities of a system to adapt to a changing environment, it is important
to realize that the drivers behind agility also influence the work efficiency of a system.
• Efficiency of work can be expressed in two different ways:
– Resource Utilization. This is the perspective often used by management and refers to the percent-
age of available time that a resource is is actually working. A resource utilization rate of 0.8 implies
that a resource is only working 80 percent of the time that he/she is available. Sometimes this
is also called chargeability, which refers to the percentage of working time (or the corresponding
cost) of a resource that can be charged to the customer.
– Flow Efficiency. This is the reciprocal of the average lead time. Thus as the lead time (time
between arrival of a job and completion of the job) goes up, the flow efficiency goes down. The
more waiting time occurs during the execution of a job, the higher the lead time and thus the
lower the flow efficiency. This perspective is often taken by the customer and is strongly connected
to the concept of ‘flow’.
• To understand how work works, we must be aware of four reinforcing loops.
– Loop 1: Whenever we start work, we create work in progress. A certain percentage of this work
in progress will get blocked due to unforeseen circumstances, missing knowledge or waiting for
external input. When work gets blocked, it will make workers idle, which will lower resource
utilization. This is typically compensated by starting new work. However, as more work gets
started, the WIP will further increase, creating a reinforcing loop.
– Loop 2: As mentioned before, a certain amount of work in progress will result in blocked work.
To unblock this work, we need to perform unblocking work which is non value adding. The fact
that resources must spend their time on non-value adding work, decreases the time they have to
finish work. This results again in a reinforcing loop. The less work is finished, the more work
remains in progress, which increases the likelihood of blocked work, which increases the amount
of non value added work, which furthermore decreases the amount of finished work and thus the
loop continues.
– Loop 3: As the average work in progress increases, the average lead time will also increase assuming
a steady-state process where the average processing rate remains constant. This follows directly
from Little’s Law which states that the average lead time equals the average work in progress
divided by the average processing time. As the lead time increases, the flow efficiency will go
down. But at the same time, the amount of urgent work will go up. Urgent work is defined as
work that must be started immediately and should get priority in order to meet the deadline.
However, more urgent work thus implies more work that should get started and the work in
progress will again increase, resulting in a third reinforcing loop.
– Loop 4: Increasing lead times also imply that the time between the moment a client requests a
job to be done and the moment we can deliver the output to the client increases. The more time
passes between these two moments, the longer we must wait for feedback from our customer. In a
non-stable environment, such feedback delays increases the likelihood that the deliverable is not
completely as the customer desires, resulting in necessary non value adding work. As known from
loop 2, non value adding work decreases the rate at which we can finish work, which increases
the work in progress, which will have a detrimental effect on the lead time, further increasing the
feedback delay, resulting in a fourth reinforcing loop.
6.3. AGILE PROJECT MANAGEMENT METHODS 37

• Note that each of the four loops have the effect to increase the work in progress, which according
to Little’s Law has a negative effect on flow efficiency. However, unless an organization considers
flow efficiency important, this is not necessarily a problem. After all, we can always keep resource
utilization high by starting new work. The perverse effect however is that this approach will decrease
flow efficiency even further.

6.2.2 Agility drivers and work efficiency

• Flow as a driver implies that one keeps the rate at which work is processed steady at a sustainable
rate. One common way to implement this to set a limit on the work in progress. Thus, whenever a
worker becomes idle and the WIP has reached its limit, the worker can no longer start new work, thus
breaking the first reinforcing loop.
• Collaboration as a driver can be used as an alternative approach to keep the resource utilization rate
high whenever workers become idle due to blocked work. Instead of starting new work, they can decide
to help other colleagues complete their work or to unblock blocked work items. Helping colleagues to
complete their work will increase the rate at which work can be finished, which lowers the work in
progress. This approach lowers the negative effect of the second loop on work in progress.
• Learning as a driver should counteract potential feedback delay. If the system incorporates sufficient
points where we can learn (e.g. from the customer or environment), the delays in feedback will be
smaller again, which will result in less non value adding work, which again has a positive effect on the
work in progress by breaking the fourth reinforcing loop.
• Note that all three drivers ultimately have a positive effect on the work in progress, trying to break
the reinforcing loops. As a consequence, this approach allows one to both increase the flow efficiency
as well as the resource utilization.

6.3 Agile Project Management Methods

6.3.1 Origin
• Agile Project Management finds its origins mainly within the field of software development.
• Traditionally, software development methodologies followed a waterfall approach which resembles tra-
ditional project management methods in nature, with a strong focus on processes, predictability and
risk control, assuming a stable environment.
• In response to such heavyweight software development methods, various lightweight methods were
introduced in the 1990s, such as Scrum, Extreme Programming and Rapid Application Development.
• While such lightweight methods were introduced before the Agile Manifesto, the latter is often consid-
ered the start of the Agile movement.
• The Agile Manifesto was written in 2001 by 17 software developers who came together to discuss the
lightweight development methods. Together they published the Manifesto for Agile Software Develop-
ment.
• Fundamentally, agile approaches (of both project management and software development) differ from
traditional approaches in the sense that they are adaptive rather than predictive and integrative rather
than waterfall.
– Adaptive vs predictive. In a predictive approach the focus is on analysing and planning the future
in detail, preparing for potential risks. The idea is that if one can predict the future, one can
plan for it. In an adaptive approach it is assumed that the environment changes fast, often and
in unpredictable ways. The focus of adaptive approaches is not to plan everything ahead of time
but to leave flexibility to respond to a changing environment. Flexibility to address changes and
the ability to detect these changes are key elements in an adaptive approach.
– In a waterfall approach, planning, execution, testing and delivery are clearly separated in sequen-
tial steps. In an integrative (also called agile) approach, these steps are integrated in one phase,
which is typically iterated multiple times. These iterations are also incremental by nature, which
means that each iteration builds upon the output of the previous iteration enhancing it further
towards the end deliverable.
38 CHAPTER 6. AGILE PROJECT MANAGEMENT

6.3.2 The Agile Manifesto

• The agile manifesto identifies four core values:
– Individuals and interactions over processes and tools. While tools and processes are important, it
is even more important to have competent people working together effectively.
– Working software over comprehensive documentation. While good documentation is useful, the
main point of development is to create software not documentation.
– Customer collaboration over contract negotiation. While a contract is important, it is no substi-
tute for working closely with customers to discover what they need.
– Responding to change over following plan. While a project plan is important, it should not hinder
to accommodate to changes.
• The agile manifesto also identified twelve principles:
– Customer satisfaction by early and continuous delivery of valuable software.
– Welcome changing requirements, even in late development.
– Deliver working software frequently (weeks rather than months).
– Close, daily cooperation between business people and developers.
– Projects are built around motivated individuals, who should be trusted.
– Face-to-face conversation is the best form of communication (co-location).
– Working software is the primary measure of progress.
– Sustainable development, able to maintain a constant pace.
– Continuous attention to technical excellence and good design.
– Simplicity - the art of maximizing the amount of work not done - is essential.
– Best architectures, requirements, and designs emerge from self-organizing teams.
– Regularly, the team reflects on how to become more effective, and adjusts accordingly.
• While the agile manifesto was written with software development in mind, many of its ideas can be
transferred to projects in general, giving rise to idea of agile project management. Some core principles
that return in agile project management are:
– Iterative, incremental and evolutionary development.
– Efficient and face-to-face communication.
– Very short feedback loops and adaptation cycles.
– Focus on quality.

6.3.3 Scrum
• The origin of Scrum goes back to the work of Hirotaka Takeuchi and Ikujiro Nonaka, who developed
a new approach for product development based on cross-functional teams.
• The Scrum framework as agile software development approach was developed by Ken Schwaber and
Jeff Sutherland.
• For a good overview of Scrum as Agile Project Methodology, we refer to The Scrum Guide
• Some key takeaways are:
– Scrum defines three key roles: a product owner, a team member and a scrum master.
– Scrum assumes that the work is done by a single self-organizing cross-functional team which
contains a diverse set of skills required to perform the work.
– The role of a product owner emphasizes the need to continuously evaluate the needs of the
customers.
– Scrum defines five key events: a sprint, the sprint planning, the daily scrum, a sprint review and
a sprint retrospective
– The sprint represents a single iteration which is timeboxed (fixed amount of time). If one considers
the work assigned to a single sprint as 1 work-item, one could state that Scrum uses a WIP-limit
of 1.
– Scrum defines three main artefacts: a product backlog, a sprint backlog and an increment.
6.4. REFERENCES 39

– The increment is the potentially releasable output of the sprint. Scrum assumes an incremental
approach. Therefore, the increment refers to the work done in a specific sprint integrated with
the work of all previous sprints. At the end of each sprint, the end deliverable has received an
update which moves it closer to the end goal.
– Scrum mainly focusses on the collaboration and learning drivers of agility.

6.3.4 Kanban
• The Kanban method goes back to a lean manufacturing method which was inspired by the Toyata
Production System. Its key idea are to visualize work items to give participants a view of progress and
to allow work to be pulled rather than be pushed.
• Over time, Kanban and Kanban boards in particular found their way to software development projects.
• Today, Kanban is used in all different kind of contexts outside software development.
• For a good overview of Kanban, we refer to Essential Kanban Condensed
• Some key takeaways are:
– Kanban focusses on the visualization of work (by means of a Kanban board).
– Kanban limits work in progress (WIP). It does so by defining a commitment point and a delivery
point in the process. The commitment point is where the team and the customer commit to the
work being done, whereas the delivery point is where the customer commits to accept the output.
– Kanban advises to make work (and kanban) policies explicit.
– Kanban focusses on managing the flow at a steady and sustainable rate.
– Kanban implements feedback loops.
– Kanban assumes collaborative improvements.
• Kanban focusses mainly on the flow driver of agility.
• Typically, Kanban is not only applicable to projects, but also to operations. As a project method it is
often combined with other method to give sufficient guidance for project management.

6.4 References
• Pairing, swarming and mobbing
• Agile Software Development
• Manifesto for Agile Software Development
• Principles behind the agile manifesto
• Scrum
• The Scrum Guide
• Kanban
• Essential Kanban Condensed