1. Project Management

2. Project Management
 To provide an overview of Project Management
 To review some of the various methods and
knowledge bases available to Project Managers
 Who am I?

3. Project Management
Worldwide, infrastructure spending will grow from
$4 trillion per year in 2012 to more than $9 trillion
per year by 2025. Overall, close to $78 trillion is
expected to be spent globally between 2014 and
2025.
Source: PWC and Oxford economics Capital project and infrastructure spending:
Outlook to 2025

4. Project Management
 What is it?
 Which Project Method?
 Waterfall?
 Agile?

5. Project Management
 The 3P’s:
 Project
 Programme
 Portfolio

6. What is a Project?
A project is a temporary endeavour designed to produce a
unique product, service or result with a defined beginning
and end, undertaken to meet unique goals and objectives,
typically to bring about beneficial change or added value.
The temporary nature of projects stands in contrast with
business as usual, which are repetitive, permanent, or
semi-permanent functional activities to produce products
or services.

7. What is a Programme?
Programme management is the co- ordinated
management of related projects, which may
include business as usual activities that together
achieve a beneficial change of a strategic nature
for an organisation.
Source: APM BOK

8. What is a Portfolio?
Portfolio management is the selection and
management of all an organisations projects,
programmes and related business as usual
activities taking into account resource constraints.
A portfolio is a group of projects and programmes
carried out under the sponsorship of an
organisation. Portfolios can be managed at an
organisational , programme or functional level.
Source: APM BoK

9. Project Management
Project Management is the process and activity of
planning, organising, motivating, and controlling
resources, procedures and protocols to achieve
specific goals in scientific or daily problems.

10. Characteristics of a Project
 Change
 Temporary
 Cross – functional
 Unique
 Uncertain

11. Project Management
A project is usually deemed to be a success if it achieves
the objectives according to their acceptance criteria, within
an agreed timescale and budget.

12. Project Management
 The core components of project management are:
 defining the reason why a project is necessary;
 capturing project requirements, specifying quality of the
deliverables, estimating resources and timescales;
 preparing a business case to justify the investment;
 securing corporate agreement and funding;
 developing and implementing a management plan for the
project;
 leading and motivating the project delivery team;
 managing the risks, issues and changes on the project;

13. Project Management
 monitoring progress against the plan;
 managing the project budget;
 maintaining communications with stakeholders and the
project organisation;
 provider management;
 closing the project in a controlled fashion when appropriate.

14. Why Use a Metodology?
 Better control of financial, physical, and human
resources.
 Improved customer relations.
 Shorter development times.
 Lower costs.
 Higher quality and increased reliability.
 Higher profit margins.
 Improved productivity.
 Better internal coordination.
 Higher worker morale (less stress).

15. Project Management
 Prince2
 PMI – PMBOK
 APM – Body of Knowledge
 Praxis Framework
 Agile
 ISO 21500

16. Prince2
Prince2 addresses four integrated elements:
The Principles
The Themes
The Processes
Tailoring

17. Prince2
What’s excluded?
Specialist Aspects
Detailed Techniques
Leadership Capability

18. Prince2
Benefits of Prince2?
Proven best practice and governance
Applicable to any type of project
Widely recognised and understood
Recognises project responsibility
Clear project delivery
Designed to meet varying needs
Manages by exception

19. Prince2
 Focus on viability vs Business case
 Structured reporting
 Ensures stakeholder involvement in planning
and decision making
 Promotes learning and continuous improvement
 Consistent
 Diagnostic tool

20. Prince2 – The Principles
 Continued Business Justification
 Learn from Experience
 Defined Roles and Responsibilities
 Manages by Stages
 Manages by Exception
 Focus on Products
 Tailor to suit the Project Environment

21. Prince2 – The Themes
 Business Case
 Organisation
 Quality
 Plans
 Risk
 Change
 Progress

22. Prince2 – The Processes
 Start – up
 Directing
 Initiation
 Controlling
 Managing Product Delivery
 Stage Boundaries
 Closing

23. Prince2 - Tailoring
 The appropriate use of Prince2 on any given
project, ensuring that there is the correct
amount of planning, control, governance and
use of the processes and themes.
 Done by the project team to adapt the methods
to the specific project

24. Prince2 – Tailoring
 Adapt the Themes
 Apply the organisations terms and language
 Revise the product descriptions
 Revise the role descriptions
 Adjust the processes to match the above

25. PMBoK
 The Project Management Institute is a professional PM
membership organisation that provide standards and
qualifications for project professionals.
 The PMBOK Guide contains the processes that project
management experts agree are necessary for most
projects in most environments. It reflects the evolving
knowledge within the profession. Processes are
presented by Process Group and Knowledge Area.
 Processes overlap and interact throughout a project or
its various phases.

26. PMBoK
 Processes are described in terms of:
 Inputs (documents, plans, designs, etc.)
 Tools and Techniques (mechanisms applied to
inputs)
 Outputs (documents, plans, designs, etc.)
 There are 47processes that fall into five basic
process groups and ten knowledge areas.

27. PMBoK – Process Groups
 Initiating : Those processes performed to define a
new project or a new phase of an existing project by
obtaining authorisation to start the project or phase.
 Planning : Those processes required to establish the
scope of the project, refine the objectives, and define
the course of action required to attain the objectives that
the project was undertaken to achieve.
 Executing : Those processes performed to complete
the work defined in the project management plan to
satisfy the project specifications

28. PMBoK – Process Groups
 Monitoring and Controlling : Those processes
required to track, review, and regulate the progress and
performance of the project; identify any areas in which
changes to the plan are required; and initiate the
corresponding changes.
 Closing : Those processes performed to finalise all
activities across all Process Groups to formally close
the project or phase.

29. PMBoK – Knowledge Areas
 Project Integration Management includes the
processes and activities needed to identify, define,
combine, unify, and coordinate the various processes
and project management activities within the Project
Management Process Groups.
 Project Scope Management includes the processes
required to ensure that the project includes all the work
required, and only the work required, to complete the
project successfully.

30. PMBoK – Knowledge Areas
 Project Cost Management includes the processes
involved in planning, estimating, budgeting, financing,
funding, managing, and controlling costs so that the
project can be completed within the approved budget.
 Project Time Management includes the processes
required to manage the timely completion of the project.

31. PMBoK – Knowledge Areas
 Project Quality Management includes the processes
and activities of the performing organisation that
determine quality policies, objectives, and
responsibilities so that the project will satisfy the needs
for which it was undertaken.
 Project Human Resource Management includes the
processes that organise, manage, and lead the project
team.

32. PMBoK – Knowledge Areas
 Project Communications Management includes the
processes that are required to ensure timely and
appropriate planning, collection, creation, distribution,
storage, retrieval, management, control, monitoring, and
the ultimate disposition of project information.
 Project Risk Management includes the processes of
conducting risk management planning, identification,
analysis, response planning, and controlling risk on a
project.

33. PMBoK – Knowledge Areas
 Project Procurement Management includes the
processes necessary to purchase or acquire products,
services, or results needed from outside the project
team
 Project Stakeholder Management includes the
processes required to identify all people or
organisations impacted by the project, analysing
stakeholder expectations and impact on the project, and
developing appropriate management strategies for
effectively engaging stakeholders in project decisions
and execution

34. PMBOK Processes Map
Initiating Planning Executing Monitoring & Controlling Closing
Integration Develop Project
Charter
Develop Project Management Plan Direct and
Manage Project
Work
Monitor and Control Project Work
Perform Integrated Change
Control
Close Project or
Phase
Scope Plan Scope Management
Collect Requirements
Define Scope
Create WBS
Validate Scope
Control Scope
Cost Plan Cost Management
Estimate Costs
Determine Budget
Control Costs
Time Plan Schedule Management
Define Activities
Sequence Activities
Estimate Activity Resources
Estimate Activity Durations
Develop Schedule
Control Schedule
Quality Plan Quality Management Perform Quality
Assurance
Control Quality
Human
Resources
Plan Human Resource
Management
Acquire Project
Team
Develop Project
Team
Manage Project
Team
Communications Plan Communications Management Manage
Communications
Control Communications
Risk Plan Risk Management
Identify Risks
Perform Qualitative Risk Analysis
Perform Quantitative Risk Analysis
Plan Risk Responses
Control Risks
Procurement Plan Procurement Management Conduct
Procurements
Control Procurements Close
Procurements
Stakeholder Identify Stakeholders Plan Stakeholder Management Manage
Stakeholder
Engagement
Control Stakeholder Engagement

35. APM - BoK
 The Association for Project Managers is a professional
PM membership organisation that provide standards
and qualifications for project professionals
 Their objectives are “to advance the science, theory and
practice of project and programme management for the
public benefit.”
 The APM BoK has 7 chapters, each broken down into
its component parts and amounting to 52 topics in all.

36. APM - BoK
 APM BoK is not a set of rules or practices, it’s aim is to
convey knowledge on the discipline of managing
projects rather than the processes.
 The APM BoK is not in reality a method for project
management, but provides a solid foundation of project
knowledge.
 Derived and published through APM - Praxis is a free
framework for the management of projects,
programmes and portfolios.

37. APM - BoK
Project
Management in
Context
Project
Management
Programme
Management
Portfolio
Management
Project Context Project
Sponsorship
Project Office
Planning the
Strategy
Project success &
benefits
management
Stakeholder
Management
Value
Management
Project
Management Plan
Project Risk
Management
Project Quality
Management
Health, Safety &
Environmental
Management
Executing the
Strategy
Scope
Management
Scheduling Resource
Management
Budgeting & Cost
Management
Change Control Earned Value
Management
Information
Management &
Reporting
Issue
Management
Techniques Requirements
Management
Development Estimating Technology
Management
Value
Engineering
Modelling &
Testing
Configuration
Management
Business &
Commercial
Business Case Marketing &
Sales
Project Financing
& Funding
Procurement Legal
Awareness
Organisation &
Governance
Project Life
Cycles
Concept Definition Implementation Handover &
Closeout
Project Reviews Organisation
structure
Organisational
Roles
Methods &
Procedures
Governance of
Project
Management
People &the
Profession
Communication Teamwork Leadership Conflict
Management
Negotiation HRManagement Behavioural
Characteristics
Learning &
Development
Professionalism
& Ethics

38. Praxis
 Praxis is a free framework for the management of
projects, programmes and portfolios. It includes a body
of knowledge, methodology, competency framework
and capability maturity model.
 Praxis Framework provides a single, integrated
framework for the management of projects,
programmes and portfolios.
 Praxis takes the principles of existing, proven guides
and adapts them so that they have a common
terminology, structure and approach.
Source: Praxis Framework Limited

39. Praxis Overview
 Contextual functions are not directly responsible
for achieving project, programme or portfolio
objectives but are part of the context which
supports that endeavour.
 Management functions are the ones that are
applied in the completion of projects,
programmes and portfolios.
 The knowledge section integrates with all the
other sections of Praxis.

40. Praxis Framework
 The four core sections of the Praxis Framework
are:
 Knowledge
 Method
 Competence
 Capability Maturity

41. Praxis Framework

42. Knowledge

43. Method

44. Competence

45. Maturity

46. Agile
What is Agile Project Management?
Agile project management is an iterative and
incremental method of managing change, that
provides a new product or service in a very
flexible and interactive manner.

47. Agile
Agile project management focuses on continuous
improvement, scope flexibility, team input, and
delivering essential quality products. Agile project
management methodologies include scrum,
extreme programming (XP), lean and kanban,
among others.

48. Agile Iterative Model

49. General Agile Principles
 The highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
 Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive advantage.
 Deliver working products frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

50. General Agile Principles
 Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.

51. General Agile Principles
 A working product is the primary measure of
progress.
 Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant
pace indefinitely.
 Continuous attention to technical excellence
and good design enhances agility.

52. General Agile Principles
 Simplicity — the art of maximizing the amount
of work not done — is essential.
 The best architectures, requirements, and
designs emerge from self-organizing teams.
 At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts
its behaviour accordingly.
©Agile Manifesto Copyright 2001

53. Agile Methodologies
 SCRUM
 A product owner creates a prioritised wish list called
a product backlog.
 During sprint planning, the team pulls a small chunk
from the top of that wish list, a sprint backlog, and
decides how to implement those pieces.
 The team has a certain amount of time — a sprint
(usually two to four weeks) — to complete its work,
but it meets each day to assess its progress (daily
Scrum).

54. SCRUM
 Along the way, the Scrum Master keeps the team
focused on its goal.
 At the end of the sprint, the work should be
potentially shippable: ready to hand to a customer,
put on a store shelf, or show to a stakeholder.
 The sprint ends with a sprint review and
retrospective analysis.
 As the next sprint begins, the team chooses another
chunk of the product backlog and begins working
again.
Source: Scrumalliance.org

55. SCRUM

56. SCRUM
Beyond the sprint the cycle repeats until enough
items in the product backlog have been
completed, the budget is depleted, or a deadline
arrives. Which of these milestones marks the end
of the work is entirely specific to the project. No
matter which impetus stops work, Scrum ensures
that the most valuable work has been completed
when the project ends.

57. Extreme Programming(XP)
Extreme programming is a software development
methodology, which is intended to improve
software quality and responsiveness to changing
customer requirements. It advocates frequent
releases in short development cycles, which are
intended to improve productivity and introduce
checkpoints at which new customer requirements
can be adopted.

58. Basic XP Values
 Communication - the XP practices are designed to keep
communication flowing within the development team and with
stakeholders.
 Simplicity - XP bets that doing the simplest thing that works today
and paying tomorrow if a change is needed, is cheaper than doing
a more complicated thing today that adds flexibility that may never
be needed.
 Feedback - concrete feedback based on production-quality,
working code enables better communication.
 Courage - the courage to make changes both supports and is
supported by the other three values.
 Respect; respect for other members and roles within the project
team and respect for all interested parties.

59. 12 XP Principles
The Planning Game:
Business and development cooperate to produce the maximum
business value as rapidly as possible. The planning game happens at
various scales, but the basic rules are always the same:
 Business comes up with a list of desired features for the system. Each
feature is written out as a User Story, which gives the feature a name,
and describes in broad strokes what is required.
 Development estimates how much effort each story will take, and how
much effort the team can produce in a given time interval (the
iteration).
 Business then decides which stories to implement in what order, as
well as when and how often to produce a production releases of the
system.

60. 12 XP Principles
Small Releases:
 Start with the smallest useful feature set. Release
early and often, adding a few features each time.
System Metaphor:
 Each project has an organising metaphor, which
provides an easy to remember naming convention.
Simple Design:
 Always use the simplest possible design that gets
the job done. The requirements will change
tomorrow, so only do what's needed to meet today's
requirements.

61. 12 XP Principles
Continuous Testing:
 Before programmers add a feature, they write a test
for it. When the suite runs, the job is done.
Refactoring:
 Refactor out any duplicate code generated in a
coding session.
Pair Programming:
 All production code is written by two programmers
sitting at one machine. Essentially, all code is
reviewed as it is written.

62. 12 XP Principles
Collective Code Ownership:
 No single person owns a module. Any developer is
expected to be able to work on any part of the
codebase at any time.
Continuous Integration:
 All changes are integrated into the codebase at least
daily. The tests have to run 100% both before and
after integration.

63. 12 XP Principles
40-Hour Work Week:
 Programmers go home on time. In crunch mode, up
to one week of overtime is allowed. But multiple
consecutive weeks of overtime are treated as a sign
that something is very wrong with the process
On-site Customer:
 Development team has continuous access to a real
live customer, that is, someone who will actually be
using the system.

64. 12 XP Principles
Coding Standards:
 Everyone codes to the same standards. Ideally, you
shouldn't be able to tell by looking at it who on the
team has touched a specific piece of code.

66. ISO 21500
ISO 21500 is the first in a planned family of project
management standards. It is designed to align with related
International Standards such as
 ISO 10006:2003, Quality management systems −
Guidelines for quality management in projects,
 ISO 10007:2003, Quality management systems −
Guidelines for configuration management,
 ISO 31000:2009, Risk management – Principles and
guidelines,
 sector-specific standards in industries such as
aerospace and IT.

67. Purpose
 Provides a generic guidance on the concepts
and processes of project management &
referred to as “an informative standard”
 Recognised as a foundational reference for the
application of project management knowledge
and good practices
 One global standard for project management

68. ISO 21500 Content & Structure
 Clause 1 Scope
 Clause 2 Terms and definitions
 Clause 3 Project management concepts
 Clause 4 Project management processes
 Annex A (Informative) process group:
processes mapped to subject groups
Source: ISO 21500, Guidance on project management, A Pocket Guide: Anton
Zandhuis, Rommert Stellingwerf, (c) Van Haren Publishing 2013

69. ISO21500 Clause 1
 Clause 1 covers the scope of ISO 21500, which
is to provide guidance for project management
and may be used by any type of organisation
and for any type of project.
 The guideline provides a high level description
of concepts and process that are considered to
form good practice in project management.

70. ISO 21500 Clause 2
 Clause 2 contains 16 project management
terms and their definitions, those specific terms
that from a project management practice
viewpoint are not properly defined in the
standard lists of ISO or Oxford English
Dictionary

71. ISO 21500 Clause 3
 Clause 3 describes the concepts which play an
important role during the execution of most
projects:
 Project;
 Project management;
 Organizational strategy and projects;
 Project environment;
 Project governance;
 Projects and operations;

72. ISO 21500 Clause 3
 Stakeholders and project organisation;
 Competences of project personnel;
 Project life cycle;
 Project constraints;
 Relationship between project management concepts
and processes.

73. ISO 21500 Clause 4
 Clause 4 identifies the recommended project
management processes that should be applied,
consisting of:
 5 process groups
 39 processes divided into 10 project management
themes, called subject groups

74. ISO 21500 Clause 4
 The 5 process groups are:-
 Initiating
 Planning
 Implementing
 Controlling
 Closing

75. ISO 21500 Clause 4
 These process groups are based on the
Deming Circle (Plan-Do - Check – Act) for
continuous improvement.

76. ISO 21500 Clause 4
 There are 39 processes divided into 10 project
management themes, called subject groups:
 Integration
 Stakeholders
 Scope
 Resource
 Time
 Cost
 Risk
 Quality
 Procurement
 Communication

77. Annex A
SUBJECT GROUPS PROCESS GROUPS
INITIATING PLANNING IMPLEMENTING CONTROLLING CLOSING
TIME Sequence activities
Estimate activity
durations
Develop schedule
Control schedule
COST Estimate costs
Develop budget
Control costs
RISK Identify risks
Assess risks
Treat risks Control risks
QUALITY Plan quality Perform quality
assurance
Perform quality control
PROCUREMENT Plan procurement Select suppliers Administer
procurements
COMMUNICATION Plan communications Distribute information Manage
communications
INTEGRATION Develop project
charter
Develop project plans Direct project work Control project work
Control changes
Close project phase or
project
Collect lessons learned
STAKEHOLDER Identify stakeholders Manage stakeholders
SCOPE Define scope
Create work
breakdown structure
Define activities
Control scope
RESOURCE Establish project team Estimate resources
Define project
organisation
Develop project team Control Resources
Manage Project team

78. Which Method?
 Waterfall or Agile?
 Waterfall methods – Importance on the process
 Agile methods – Importance on the result
 Can one Method fit all purposes?

79. Variations on a Theme?