Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 1 of 117

Certification in IT Project Management

(CITPM)

Body of Knowledge
4th Edition

March 2015

All rights reserved. No part of this publication may be reproduced, stored in a

retrieval system, or transmitted in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise, without prior permission of the publisher.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 2 of 117

This book is made possible by:

Writers/Review Panel
Tan Kar Joo, SMSCS, COMIT (Senior) (Chairperson)
Vivian Tay, NEC Asia Pacific Pte. Ltd. (Vice Chairperson)
Tan Yan Noi, Inland Revenue Authority of Singapore
Daniel Boey, Institute of Systems Science
Lee Chee Yong, NCS Pte. Ltd.
Tiong Shu, Accenture Ltd.
Khin Myint Cho, CrimsonLogic Pte. Ltd.
Karen Wong, Infocomm Development Authority of Singapore
Tan Eng Pheng, Infocomm Development Authority of Singapore
Tan Shui-Min, Integrated Health Information Systems
Seow Keng Tain, Great Eastern Life Assurance Co. Ltd.

Writers/Reviewers
Daniel Boey Swee Kee, Institute of Systems Science
Felicitas Seah, Institute of Systems Science
Richard Tan, Institute of Systems Science
Lee Boon Kee, Institute of Systems Science
Tan Liong Choon, Institute of Systems Science
Howard Russon, Institute of Systems Science
Angela Huang, Institute of Systems Science
Tan Tzann Chang, Institute of System Science

First Edition Published May 2003

2nd Edition Published March 2004
3rd Edition Published October 2011
4th Edition Published March 2015
Singapore Computer Society
53/53 A Neil Road
Singapore 088891
Website: http://www.scs.org.sg

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 3 of 117

PREFACE to 4th Edition

By Ms Tan Kar Joo
SMSCS, COMIT (Senior), Chairperson Review Panel

Welcome to the 4th edition of the Book of Knowledge (BOK) for the Certification in IT
Project Management (CITPM). Since its first publication in May 2003, many
experienced IT project managers and veterans in the Singapore IT industry have
contributed towards improving this BOK to ensure that it continues to be useful and
relevant for all practitioners of IT project management. While every effort has been
made to ensure that this BOK documents the IT project management practices that
work based on past experience, it is by no means comprehensive as every project
has its unique characteristics and challenges. This is what makes project
management interesting, and differentiates one project manager from another,
making good project managers a rare and valuable asset to any organization.
In this latest edition, we put greater emphasis on the soft skills required of project
managers, especially in the areas of change management and stakeholder
management. In today’s environment, with stakeholders who are much more
exposed to what technology can and cannot do for them, it is no longer sufficient just
to get buy-in prior to the start of the project. More importantly, they need to be fully
engaged during the project in shaping the outcomes, be convinced of the value that
the system will bring, and be committed to maximize the returns in the way they use
the system when it is commissioned.
In terms of methodologies and practices, we have included an appendix on what it
takes to manage projects that use an agile development methodology, where
requirements evolve through close engagements and experimentations with the end
users.
Finally, since this is Singapore’s CITPM BOK, we have included local compliance
requirements and standards, e.g. data protection requirements and healthcare data
standards, so that IT project managers are aware of the local context and
requirements when practicing in this country.
The CITPM BOK review panel has also decided to tap on the wisdom of the crowd
by putting up a draft of this edition of the BOK for public consultation prior to its
publication. We want to make this BOK one that is useful and relevant for all!
Be challenged and enjoy the IT Project Management Journey!

Tan Kar Joo

Chairperson
CITPM BOK Review Panel

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 4 of 117

Contents
1.   INTRODUCTION 9  

1.1   Roles of Project Managers 9  

1.2   Body of Knowledge 10  

2.   ECOSYSTEM OF PROJECTS 11  

2.1   The Project/Programme/Portfolio Concept 11  

2.2   Project Governance 12  

Practical Tips 12  

3.   PROJECT LIFE CYCLE MANAGEMENT 13  

3.1   IT Project Phases 13  

3.2   Project Initiation 13  

3.3   Project Business Case and Benefits Management 13  

3.4   Project Management Planning 15  

3.5   IT System Development Life Cycles 15  

3.6   Life Cycle Processes of Typical IT Project Types 18  

3.7   Selecting the Life Cycle for a Project 19  

3.8   Project Change Control 19  

3.9   Project Closing, Lessons Learnt and Knowledge Management 19  

3.10   Post Implementation Review 20  

Practical Tips 20  

4.   SCOPE MANAGEMENT 21  

4.1   Project Management Planning Process 21  

4.2   Project Execution Process 23  

4.3   Project Monitoring and Controlling Process 24  

Practical Tips 25  

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 5 of 117

5.   TIME MANAGEMENT 26  

Practical Tips 28  

6.   COST MANAGEMENT 29  

6.1   Project Cost Estimation and Budgeting 29  

6.2   Project Cost Control 31  

6.3   Project Cash Flow Management 31  

Practical Tips 32  

7.   QUALITY MANAGEMENT 33  

7.1   Basic Quality Concepts and Considerations 33  

7.2   Quality Management Frameworks 34  

7.3   System Quality Control Techniques 35  

7.4   System Configuration Management (SCM) 40  

Practical Tips 41  

8.   HUMAN RESOURCE MANAGEMENT 42  

8.1   Qualities of an Effective Manager 42  

8.2   Planning for Project Team Resources 43  

8.3   Forming Project Teams 43  

8.4   Managing the Project Team 44  

8.5   The Project Manager’s Skills 48  

Practical Tips 53  

9.   COMMUNICATIONS MANAGEMENT 55  

9.1   Managing Team Communications 55  

9.2   Managing Customer Involvement 56  

9.3   Managing External Communications 58  

9.4   Reporting Project Performance 58  

9.5   Communicating Effectively 58  

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 6 of 117

Practical Tips 59  

10.   RISK MANAGEMENT 60  

10.1   Principles of Risk 60  

10.2   Risk Management Process 61  

10.3   Disaster Recovery and Business Continuity Planning 65  

10.4   Regulatory Compliance 66  

Practical Tips 67  

11.   PROCUREMENT MANAGEMENT 68  

11.1   IT Outsourcing and Subcontracting 68  

11.2   Software Licenses 72  

11.3   Packaged Solutions 73  

11.4   Turn-key Solutions 73  

11.5   IT Infrastructure Procurement 73  

Practical Tips 74  

12.   STAKEHOLDERS MANAGEMENT 75  

12.1   The Stakeholder 75  

12.2   Processes in Stakeholder Management 75  

12.3   Managing Stakeholder Relationships 76  

Practical Tips 78  

13.   MANAGING PROGRAMMES 79  

13.1   Managing a Programme with Multiple Projects 79  

13.2   Financing Complex Projects/Programmes 81  

Practical Tips 82  

14.   CHANGE ENABLEMENT 83  

14.1   Value Proposition for Change Enablement 83  

14.2   Objectives of Change Enablement 84  

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 7 of 117

14.3   Understanding the Stakeholders and the Impact of Change 84  

14.4   Change Enablement Plan 85  

14.5   Change Enablers 86  

14.6   Change Readiness Assessment 86  

Practical Tips 87  

15.   ABBREVIATIONS 88  

16.   BIBLIOGRAPHY 91  

APPENDIX A. AGILE PROJECT MANAGEMENT 94  

A.1   Introduction 94  

A.2   Agile Manifesto 94  

A.3   Principles behind the Agile Manifesto 95  

A.4   Differences between Waterfall and Agile 97  

A.5   Requirements Analysis 98  

A.6   Requirements Prioritization Techniques 100  

A.7   Lifecycle of an Agile Project 101  

A.8   Agile Project Progress Tracking 101  

A.9   Project Management Considerations for Agile Projects 102  

APPENDIX B. SAMPLE TEMPLATES 105  

B.1   Sample Project Management Plan (PMP) Table of Contents 106  

B.2   Sample Change Register Template 108  

B.3   Sample Issue Register Template 109  

B.4   Sample Defect Register Template 110  

B.5   Sample QA/Peer Review Memorandum Template 111  

B.6   Sample Risk Register Template Example 113  

APPENDIX C. PREFACE TO THE 3RD EDITION 114  

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 8 of 117

APPENDIX D. PREFACE TO THE 1ST AND 2ND EDITIONS 116  

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 9 of 117

1. Introduction
The Info-Communications Development Authority of Singapore (IDA) and the
Singapore Computer Society (SCS) jointly launched the National IT Skills
Certification Programme on 26 November 1998. Heeding the calls from Chief
Executive Officers (CEOs) and Chief Information Officers (CIOs) in Singapore for IT
project management (ITPM) to be the first IT skill to be certified, SCS initiated the
Certification in IT Project Management (CITPM) programme. In line with the evolving
changes and emerging best practices in ITPM, the SCS CITPM Body of Knowledge
(BOK) Resource Panel initiated the review and update of the BOK resulting in its 3rd
Edition in 2011 and its 4th Edition in 2015.
The CITPM is the most widely-recognised standard for ITPM competence and
professionalism. It is designed for those who are involved in ITPM and wish to have
their competencies assessed. The CITPM designation is recognized by IT managers
worldwide as a mark of quality.
The certification examines the candidate’s competence in thirteen knowledge areas
of ITPM. Candidates can be assessed through the submission of a dossier to
demonstrate their professional competence in the management of IT projects.
Alternatively, candidates who have yet to acquire sufficient years of project
management experience can be assessed by sitting the CITPM Examination
conducted by the Institute of Systems Science (ISS), the appointed examination
agent of SCS.
There are three levels of the CITPM Certification:
• CITPM (Senior).
• CITPM.
• CITPM (Associate).
As project managers have a professional obligation to themselves, to their
employers and to the profession to sustain their skills and knowledge by undertaking
appropriate professional development, certified IT project managers are required to
be recertified every five years. It is through recertification that both professionals and
employers can be assured that the knowledge and competency of certified IT project
managers remains formally assessed.
The purpose of the document is define the aspects of ITPM in which certification
candidates would need to demonstrate proficiency.
1.1 Roles of Project Managers
The CITPM BOK recognises that project managers could come from client
organizations that have outsourced their IT projects to a vendor. In such cases, the
client and vendor project managers would share in the management of the project.
Based on the contract, the responsibilities of the two project managers could differ,
but would be in general as follows:
a. Project Manager from Client: the overall project manager responsible for
planning, executing and monitoring/controlling all the project activities, liaising
with user project coordinator for the user activities (if any) and vendor’s
project manager for vendor activities (if any).

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 10 of 117

b. Project Manager from Vendor: responsible for planning, executing and

monitoring/controlling all vendor’s activities (e.g. solution delivery
specifications, solution integration testing, solution training) and liaising and
coordinating with the client project manager.
1.2 Body of Knowledge
The CITPM BOK structures the IT project management knowledge into the following
areas:
a. Ecosystem of Projects.
b. Project Life Cycle Management.
c. Scope Management.
d. Time Management.
e. Cost Management.
f. Quality Management.
g. Human Resource Management.
h. Communications Management.
i. Risk Management.
j. Procurement Management.
k. Stakeholders Management.
l. Managing Programmes.
m. Change Enablement.
These key knowledge areas are described in the following chapters.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 11 of 117

2. Ecosystem of Projects
IT project managers continuously strive to juggle the constraints of scope, time, cost,
quality, risk and resources to ensure project success. However, the work of a project
is not undertaken in isolation. To keep all these constraints under control, the project
manager needs to fully understand the ecosystem in which he is operating in; and
be able to influence/engage the stakeholders and the project environment to
minimize the risks and optimize the opportunities – thereby enabling project
success.
This chapter explains the key concepts surrounding IT project management. The
practitioner with sound understanding of these concepts will know how to leverage
on his project ecosystem to bring about a successful project delivery.
2.1 The Project/Programme/Portfolio Concept
The project is the fundamental basis for organising and managing new IT work. This
is achieved through the effective application of all the project management
knowledge areas to ensure that the objectives of the project are achieved. These are
described in the subsequent chapters of this document. The selection of projects to
initiate is often based on the business case and benefits. See section 3.3 for further
details.
A programme consists of two or more inter-related projects managed in a
coordinated manner to obtain benefits and business outcome not available from
managing the projects individually (e.g. a core processing replacement programme
may consist of a new application development project, an infrastructure
modernization project, a change management project and a business process
reengineering project). In addition, it is often more economical to group projects
together to help streamline management, staffing, purchasing and other functions.
A programme manager provides leadership and direction for the project managers
heading the projects within the programme. Programme managers also coordinate
the efforts of project teams, functional groups, suppliers and operations staff
supporting the projects to ensure that project products and processes are
implemented to maximize benefits. Programme managers are responsible for more
than the delivery of project results; they are change agents responsible for the
success of products and processes produced by those projects. Refer to chapter 13
for further details.
A portfolio refers to a collection of projects and programmes that are not
necessarily inter-related but are grouped together to facilitate effective management
and realization of strategic business objectives (e.g. a business portfolio may consist
of a revenue generation programme, a cost containment programme, a customer
service programme and a business process improvement programme).
Portfolio managers need to understand how projects fit into the bigger picture of
the organization, especially in terms of corporate strategy, finances and business
risks. They create portfolios based on meeting specific organizational goals, such as
maximizing the value of the portfolio or making effective use of limited resources.
Portfolio managers help their organizations to make wise investment decisions by
selecting and analysing projects from a strategic perspective.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 12 of 117

2.2 Project Governance

Organisations prioritise and initiate projects in order to achieve the desired business
outcome. As significant investments are made in IT projects, it is important that the
required governance model is properly constructed to allow for high-level monitoring
of projects, and to provide management support and direction in the face of
changes/issues. While the governance model may need to be adapted to each
organisation’s specific needs, the following areas would normally be considered:
a. Governing processes (approval, escalation, regular status review, etc).
b. Governing bodies (designated project manager, project director, project
steering committee/change control board, senior/top management, board of
directors, etc).
c. Project/programme/portfolio management office.
d. Project management information system (PMIS) to satisfy automated
tracking, monitoring and controlling of projects.
Deserving special mention here is the need for resolution of conflicting operational
work and project priorities through the proper constitution of the project steering
committee (PSC).
Practical Tips
1. The ecosystem surrounding a project makes or breaks the project. It is imperative for the project
manager to influence ecological factors that are within his control in the favour of project success.

2. Project, programme and portfolio management entails different skill sets and experience. It cannot
be assumed that a person who can do one of these roles, will be able to do all of the roles.

3. The construction of an effective project governance framework during the initiation phase of any
project is fundamental to ensuring project success and control.

4. Build the business case for IT projects jointly with the project sponsor and stakeholders. This will
secure buy-in and commitment from the business for the project.

5. One good approach to identifying benefits is “Think Faster, Better, Cheaper”. When things are
done “faster” (exploiting use of IT) or “better” (improved performance/outcome), it will then
translate to savings in manpower, materials or space that can be quantified more objectively. It
would also enhance customer satisfaction and experience resulting in improved service
performance or business revenue results. “Better” can also be in the form of quality which
translates to reduced cost of rework, return of goods, defects etc.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 13 of 117

3. Project Life Cycle Management

This knowledge area describes the phases of an IT system project life cycle and
typical life cycle models commonly used to manage IT projects.
3.1 IT Project Phases
IT projects are typically preceded by feasibility studies resulting in project
prioritisation and approval. After approval, the project is initiated and planned.
According to ISO/IEC/IEEE Standard 12207, the development of IT systems
includes the following processes:
a. Analyse: Requirements Analysis Process.
b. Architect: Architectural Design Process.
c. Design: Detail Design Process.
d. Develop (Construct): Construction and Coding Process.
e. Integrate: Integration Process.
f. Test: Qualification Testing.
g. Implement: Implementation Process - move the system to the production
environment and go-live.
h. Support/Maintain. Operations and Maintenance Process.
Due to the complexity and strategic importance of many IT projects and their
resulting IT systems, it is important to take time to review the status of the project at
the end of every phase. Each phase would typically be completed successfully
before proceeding to the next phase. Management review should be conducted at
important pre-determined milestones (usually at the end of some key phases) to
evaluate progress, potential success and to ensure continued alignment with
organizational goals. During these reviews, decisions could be made to continue or
terminate a project.
3.2 Project Initiation
For a project to be successful, it is important that its feasibility is assessed in terms
of economics/resources and technology at the earliest possible stage, and that
commitment is obtained from the organisation’s management. Formal project
initiation procedures facilitate this need to look-before-you-leap and manage
expectations.
In this case, project initiation typically involves receiving requests from the user
departments, analysing and assessing their feasibility (both technically and from a
business perspective), and achieving joint approval from the IT and user department
management to commence. This agreement is often documented in a project charter
document.
3.3 Project Business Case and Benefits Management
As there are normally limited resources in an organisation and competing priorities
for these resources, projects are typically approved after business prioritization
based on techniques such as Cost-Benefit Analysis (CBA) and Total Cost of
Ownership (TCO). The stated benefits and recurring costs are tracked and

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 14 of 117

monitored until the project is commissioned to ensure the anticipated business

outcome is achieved.
The business case (i.e. the project cost justification) is the process of comparing the
estimated development costs for a proposed system with the benefits that are
expected to be accrued as a result of implementing the system. It is an important
activity to be performed during project initiation, during the feasibility study phase to
justify the selection of a specific strategy or technology, and also as part of the
assessment of change requests that occur during the project life cycle. The typical
reasons for undertaking a cost justification exercise would include:
a. To compare the value of IT projects and prioritise them for implementation.
b. To evaluate alternative project strategies or technology options.
There are two basic approaches to IT project cost justification: quantitative and
qualitative approaches. These are described below.
3.3.1 Quantitative Cost-Benefit Analysis
This involves the following:
a. Estimating total project costs as described in section 6.1.
b. Identifying and quantifying the benefits. The following are typical sources of
benefits that need to be quantified:
• The reduction or avoidance of costs (i.e. cost savings) as a result of
implementing the project, such as reduction in staff costs, office space
rental, and hardware and software costs.
• The estimated benefits (in terms of cost savings or increased revenue)
from improved business/control performance as a result of implementing
the project.
• The estimated benefits (in terms of cost savings or increased revenue) of
improvements in quality of service as a result of implementing the project.
• The estimated benefits (in terms of increased revenue) due to business
expansion as a result of implementing the project.
c. Performing a cash flow analysis, where cash flow is calculated as the
difference between net revenue and net costs calculated at intervals over a
period of time. The following accounting concepts are applied when
performing this analysis:
• Present value.
• Payback period.
• Return on investment.
3.3.2 Qualitative Approaches
It is not always possible to quantify benefits in terms of cost savings or increases in
revenue, but such benefits are nevertheless real in some situations (known as
intangible benefits). Such benefits typically occur in:
a. Strategic IT investments – which aim to create competitive advantage in the
future but without any discernible short-term payback.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 15 of 117

b. IT infrastructure investments – which aim to improve the general

operational environment or security of the system but without appearing to
directly contribute to returns from specific products.
c. Long-term IT investments – which aim to facilitate business improvements
in the long-term but without any discernible short-term payback.
Approaches that can be used to assess and compare the intangible benefits of
several different IT investment options include the following:
a. Assessment using a ranking and scoring technique. This involves
selecting evaluation criteria for the options, identifying the factors that
influence those criteria, assigning weights to the factors, scoring each option
against the factors, and then selecting the option with the highest score.
b. Value chain analysis. This involves determining the activities on the value
chain that each option will enhance or replace, determining the costs
associated with each activity and then using quantitative cost benefit analysis
or ranking and scoring techniques to select the best option.
c. Strategic match analysis. This involves determining the overall strategic
goals of the organisation and how IT developments can support them, and
using these as the basis to score each investment option against the goals to
select the option that best supports the goals.
d. Porter’s generic strategy model. This involves understanding and
classifying the competitive strategy of the organisation and then using this as
the basis to select the option that best supports this strategy.
3.4 Project Management Planning
The project management plan normally makes an important contribution to the
success of an IT project. It usually comprises plans to manage the scope, time, cost,
quality, human resources, communications, risk and procurement aspects of the
project, which are described in the subsequent chapters. A sample plan outline is
provided in appendix B.
3.5 IT System Development Life Cycles
Systems development life cycles (SDLC) are frameworks for describing the phases
involved in developing IT systems, which can be categorised into the following
models:
3.5.1 Waterfall Development Lifecycle
The Waterfall Life cycle, sometimes also called the fully plan-driven or predictive
lifecycle, determines the project scope, time and cost as early as practically
possible. Each project phase is executed in sequence and only once, and any
changes to scope are carefully managed and controlled. This life cycle is often used
when the product to be produced by the project is well understood with substantial
industry practice and has to be delivered in full at a single milestone to have value.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 16 of 117

UR

SR

AD

DD

UR : User Requirements Definition

SR : Software Requirements Definition TR

AD : Architectural Design
DD : Detailed Design and Production
TR : Transfer OM
OM : Operations and Maintenance

3.5.2 Incremental Development Life Cycle

Incremental development Life cycles, are similar to the Waterfall development life
cycles except that some phases of the project are repeated to deliver the product as
a series of increments (or releases) which successively add functionality and
capability. These increments may be performed sequentially or overlapping, each
delivering a subset of the total requirements that are usable by users (ie: capable of
doing useful work).
UR : User Requirements Definition
UR
SR : Software Requirements Definition
SR
AD : Architectural Design
AD
DD : Detailed Design and Production
DD TR : Transfer
1 TR OM : Operations and Maintenance
1
R OM
1

DD
2
TR
2
OM
2

DD
3
TR
3
OM
3

3.5.3 Iterative\Evolutionary Development Life Cycle

In this life cycle, the product is developed through a series of releases. Each
release, often referred to as an iteration, requires all phases of development (from
analysis through to installation) to be executed. Each delivered release (iteration)
enhances or adds functionality and capability. The detailed scope of the product is
elaborated one iteration at a time and each new iteration incorporates the user
feedback and operational experience of earlier releases. Preferably, a high level

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 17 of 117

architecture design should be developed during the early iterations to ensure that
the software developed is adaptable (to accommodate later releases).
UR1
SR
1 AD
1
DD 1
TR
1 OM
1

UR2
SR
2 AD
2
DD 2
TR 2
UR : User Requirements Definition OM
2
SR : Software Requirements Definition

AD : Architectural Design UR3

DD : Detailed Design and Production SR
3 AD
TR : Transfer 3
DD 3
OM : Operations and Maintenance TR 3
OM
3

3.5.4 Agile Software Development

Recently, agile software development and agile project management have
become popular terms to describe some new approaches that focus on close
collaboration between the developers and business users. Details of these
approaches can be found in appendix A.
Agile and non-agile Waterfall style approaches each have their own advantages and
a high chance of success for projects with certain characteristics. Below are six
factors to consider when deciding on which approach to choose:

Factor Suited for Planning Driven Suited for Waterfall-Style

Agile Approaches Non-Iterative Approaches
Interactive Versus Backend Agile approach is suited for For backend data driven
Data Driven System interactive systems that system such as data migration
involves high degree of user tasks, enterprise application
interaction. Web site design integration, data warehousing
and mobile applications are system, waterfall approach has
example of such system. more established processes.
Product Team Size Low to Moderate complexity. High or Mega complexity.
Each agile team should be Methods have evolved to
capped at around 10 handle large products and
members. Bigger teams teams.
should break down to smaller
feature teams. Co-located in
one place.
Requirements Stability Suited for highly dynamic Systems are well understood
system where requirements and detailed stable
changes are expected. requirements are available for
highly stable environment.
Personnel Has critical mass of Experienced members needed
experienced team members in project definition stage. Can
throughout the project. work with fewer less
experienced members in later
stages.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 18 of 117

Factor Suited for Planning Driven Suited for Waterfall-Style

Agile Approaches Non-Iterative Approaches
Culture Committed people comfortable People comfortable with roles
with empowerment and having well defined by clear policies
many degrees of freedom. and procedures. Used to be
assigned with tasks.
Customer Involvement High and regular involvement Involvement is intense at
throughout the project. certain period such as
Customers willing to constantly requirements gathering and
provide feedback. Willing to acceptance testing stage, but
put priority on features. Willing less frequent in normal period.
to go on time and material Customers used to fixed price /
contract. fixed scope mindset, and
demands all scope to be
delivered.

3.6 Life Cycle Processes of Typical IT Project Types

The SDLCs may be adapted and modified based on specific project needs, such as
the use of specific technologies, hardware and software packages. The typical life
cycle processes for some frequently implemented types of IT projects are described
in the following subsections.
3.6.1 Packaged Software Life Cycle
In the interest of not reinventing the wheel, most organisations prefer to buy rather
than make so as to leverage on the in-built best practices (best-in-class
functionalities, embedded processes) in packaged solutions:
a. Package solutions typically require less IT personnel support, but for highly
parameterized solutions there may be a need to setup a product configuration
team. Such parameterized solutions usually require thorough testing
processes to be adopted with particular emphasis on regression testing.
b. Application built using commercial-off-the-shelf (COTS) components, such as
enterprise resource planning (ERP) and business process management
(BPM) applications. A gap analysis exercise is usually performed to
determine the degree of fit to the stated business requirements. An out-of-the-
box solution, if possible, allows the buyers to benefit from future releases by
leveraging seamlessly on new functionalities and process improvements.
Common gaps such as regulatory requirements and specific industry-based
reporting may result in the need for customization work for these COTS
components.
3.6.2 Systems Integration or Turnkey Life Cycle
Systems integration or turnkey projects usually involve both application and
hardware/infrastructure components. An example would be an end-to-end bus
tracking system involving the development of a tracking application and the
installation of various hardware/infrastructure components including LED displays at
bus stops, satellite-based trackers at multiple locations and individual tracking units
mounted on each bus. Such projects typically involve the design, construction,
testing, commissioning and maintenance/support of an integrated solution.
Systems integration or turnkey projects, with both customized and third-party
technology components in their fully integrated solution, typically involve many

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 19 of 117

solution providers working together led (or primed) by a main

party/contractor/systems Integrator. Such projects are complex involving multiple
parties, multiple delivery phases and possibly multiple project team locations.
3.6.3 IT Infrastructure Life Cycle
IT infrastructure projects involve the procurement, deployment, operation and
maintenance for hardware, network and telecommunication infrastructure.
IT infrastructure procurement includes the use of cloud-related service models, such
as Software-as-a Service (SAAS); Infrastructure-as-a Service (IAAS) and Platform-
as-a-Service (PAAS). These are further described in chapter 11.
IT infrastructure life cycle processes include planning, requirements analysis,
design, deployment, testing (such as hardening testing, network penetration testing
and load/stress testing), ongoing operations management and technical support.
3.7 Selecting the Life Cycle for a Project
An important aspect of planning a project is to select an appropriate life cycle to
address the various project attributes, requirements and constraints. It should be
noted that not every project life cycle will be suitable for every organisation and
project. The appropriateness of any specific project life cycle would depend on:
a. The organisation’s culture.
b. The nature of the application and infrastructure components.
c. The maturity of the technology to be used.
d. The project team’s familiarity with the application, infrastructure components
and the technology.
e. The nature of your software development/infrastructure management method.
f. Project constraints on staff effort and delivery schedule.
This would normally involve selecting from available sources (such as the
organisation’s standard process) and then customizing it to meet specific project
requirements.
3.8 Project Change Control
Projects typically undergo changes in requirements, timeline due to delay, etc.
These changes must be properly documented, deliberated, approved and
monitored. In addition, they must be reviewed holistically across scope, time, cost
and quality.
3.9 Project Closing, Lessons Learnt and Knowledge Management
When IT projects have completed their agreed deliverables, formal project closure
processes must be employed to ensure that:
a. User/client acceptance is documented and confirmed, which would involve
the creation and endorsement of formal acceptance and project closure
documentation.
b. Necessary administrative procedures are followed, such as human resources
(HR) appraisal and the release of resources, confirmation that financial/legal

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 20 of 117

contractual obligations have been completed, conduct of a procurement audit

and archiving of project files into a record management system.
c. Lessons learnt from the project are made available to the organization to
improve the performance of similar projects in the future. This can be
achieved through storing lessons learnt into a best practices database.
Lessons learnt can in fact be derived throughout a project and not just at the
project’s conclusion. As a project moves through its phases, project managers can
use the regular progress meetings as lessons learnt cum team-building sessions.
This would mean documenting and learning from what worked and what did not
work. Typical lessons learnt may take the form of issue resolution, risk mitigation,
overruns (time, cost) and quality challenges.
3.10 Post Implementation Review
After a system has been implemented and has gone through a period of system
stabilization, a post implementation review (PIR) should be held, typically to
measure the scope realization and business outcome from the project investment.
The PIR also typically outlines an action plan to address known or outstanding
issues.
Practical Tips
1. It is important to spend enough time in project planning with the team and stakeholders,
culminating in a Project Management Plan. This planning involves the coordination of all the
knowledge areas such as scope, time, cost, human resource, quality and risk; and these will be
described in the subsequent chapters.

2. The Project Management Plan forms the basis of all work to be done, allowing all project work to
be executed in a planned fashion and the project to be monitored and controlled.

3. Post Implementation Review (PIR) should be performed after the run-in of the system to measure
the business benefits achieved.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 21 of 117

4. Scope Management
This knowledge area describes the main techniques and processes associated with
planning, executing and controlling an IT project. This involves defining and
controlling what is to be included in the scope of a project to ensure that the
customer’s goals and objectives are achieved. The key topic areas are described
below.
4.1 Project Management Planning Process
On commencing a project, one of the first activities for the project manager to
perform is to plan the project work, to ensure that the functionality, quality
requirements, budget and schedule can be determined and achieved. The main
aspects of project planning process are described below.
a. Define the project scope. The first issues a project manager needs to address
in scope definition concern what needs to be delivered and which activities
need to be carried out to produce the required deliverables. This involves
specifying the functional and non-functional requirements of the project. The
latter may include:
• Performance.
• Availability.
• Capacity.
• Scalability.
• Reliability.
• Security (including compliance to regulatory standards e.g. cyber safety
standards).
• Integrity.
• Interfaces with, and dependencies on, internal or external systems in the
operational environment.
• Usability.
The project manager needs to not only specify the requirements, but also
understand and manage stakeholders’ expectations. For the project to be
successful, the project requirements implemented must also match the
expectations associated with the requirements, e.g. the ease of using the
system, and the ease of maintaining the system operations. As part of this
process, the project manager must try to influence the stakeholders to avoid
over-engineered and unnecessarily complex solutions which are often major
challenges to IT projects.
To establish desirable stakeholder expectations, it is important to understand
that not all requirements that are identified during the requirement gathering
exercise are automatically assumed to be part of the scope. In particular,
unnecessary or irrelevant requirements must be discouraged to avoid
incurring added expenses, complexity and risk. The project manager may
apply the “MoSCoW” principle to help stakeholders better define the scope of
the project requirements with respect to the objective of the project:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 22 of 117

• M equates to Must have. Requirements that, if omitted, will render the

team unable to fulfil its intended project objectives or benefits.
• S equates to Should have. Requirements that, if omitted, will diminish the
project’s ability to fulfil its intended objectives or benefits.
• C equates to Could have. Requirements that is good to have and could
enhance the project’s acceptance. These could only be provided if the
project has excess financial resources and time beyond the cost of Must
have and Should have requirements.
• W equates to Won’t have. Requirements that are irrelevant to the project
objectives or unnecessary, or not within the project team’s authority to
carry out. These requirements tends to be informal or lack clarity in
relation to the business and will complicates the project and strain project
financial resources and time unnecessarily.
If COTS components were being used in the project, then a further aspect of
this process would be to identify the gap between the user requirement and
the standard product functionality of these components and document the
scope of product customization required. Another aspects of COTS requiring
special attention is the conversion and migration of legacy data, which is often
a highly complex and risky endeavour that needs careful planning and high
user involvement such as data verification and data freeze/data catch-up
before transition to live environment. Specialist training for users and other
supporting staff on the user interface of the COTS software is also a major
area to be addressed in scope planning.
b. Define the project objectives. This would typically be specified in terms of the
required project deliverables, such as:
• The software/hardware system end-product.
• Requirements, analysis and design specifications.
• Test planning and results documentation.
• Management planning and control documentation, such as plans and
progress reports.
• User and system documentation.
c. Determine the project risks and appropriate risk resolution strategy. See
chapter 10 for further details.
d. Establish a suitable organisation structure for the project to facilitate effective
management. This structure should include the various in-house teams
involved in the projects as well as external parties, such as suppliers and
subcontractors, and interfaces with the customer and the company’s senior
management. Central to scope management is the management of change
which could be facilitated by a Change Control Board/Project Steering
Committee.
e. Select the development/infrastructure methodology, taking into consideration
the scope, objectives, risks and organisation structure. See sections 3.6 and
3.7 for further details.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 23 of 117

f. Create the Work Breakdown Structure (WBS)

g. Define the roles and responsibilities of each project team member with
respect to the WBS.
h. Determine the project schedule. See chapter 5 for further details.
i. Determine the estimated project costs. See chapter 6 for further details.
j. Determine the human resource requirements. See chapter 8 for further
details.
k. Determine the projects requirements for non-staff resources, such as
computer hardware, development environment and physical accommodation.
l. Determine the mechanisms to be used to assure the quality of the project
such as:
• Reviews of deliverables and documents.
• Code walkthroughs.
• Software/system testing.
• Standards and guidelines.
• Acceptance criteria and procedures for all deliverables.
• Software configuration management.
m. Prepare appropriate planning documents, such as the project management
plan and the quality plan.
4.2 Project Execution Process
Having planned the project, the project manager has clearly defined how the project
can achieve its objectives. The project can now be executed according to these
plans. This involves tasking the project staff to perform the planned activities,
tracking progress against the plans, and taking appropriate control actions to ensure
that the project stays on course to achieve the desired outcome. The main aspects
of the project execution process are described below.
a. Planning for control – ensuring that the project plans are specified to the level
of detail that would provide a suitable basis against which to control the
project. The key elements are:
• WBS, to define the activities to perform.
• Schedule, to specify activity start and end dates.
• Staff effort estimates, per staff member per activity.
• Cost budget for the whole project.
• Milestones, to indicate critical delivery dates.
b. Tasking the project staff to perform the activities defined in the plans, in terms
of:
• Deliverables to be produced.
• Standards and guidelines to be applied.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 24 of 117

• Acceptance criteria.
• Effort and cost budget.
• Timescales.
c. Progress reporting to determine the current status of each activity, and the
problems the project staff are facing that are impeding them from making the
required progress. Reporting can take the following forms:
• Quantitative reports in the form of timesheets, expense claims and
subcontractors invoices.
• Qualitative reports in the form of written progress reports describing the
work done during the reporting period, progress to date, plans for the next
period.
• Progress review meetings.
When monitoring work progress, it is also important to analyse trends.
Progress may appear slow at the beginning of the project, due to unfamiliarity
with the development environment or the newness of the team, but may
change significantly as the team becomes more experienced. However, if an
adverse trend is observed to be persistent, then the project manager should
analyse the root cause and take both corrective and preventive actions to
correct the trend and bring the project back on track.
4.3 Project Monitoring and Controlling Process
The main aspects of the project monitoring and controlling process to track and
monitor project progress to meet the stated performance objectives in the project
plans are described below:
a. Monitoring and assessing progress to determine the current status of the
project, identify divergence from the plan, and predict expected cost and/or
schedule over-runs. The following techniques can be employed:
• Assessment of written progress reports.
• Calculation of effort estimates to complete.
• Earned value analysis.
b. Performing progress control activities to address the issues that arise as a
result of monitoring and assessing progress. Typical control activities include:
• Schedule and effort control – taking action to address effort or schedule
over-runs.
• Quality control – putting in place preventative and corrective actions to
address quality problems in the product under development or
maintenance.
• Cost control – taking action to address actual or predicted cost over-
spends to ensure that the project is delivered within budget.
• Technical control – initiating actions to address difficulties in applying the
project’s technical strategy.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 25 of 117

c. Undertaking formal change control procedures to ensure that requests for

changes to the software/system requirements or to address defects are
managed such that:
• The impact of the change on the current project scope is understood.
• The technical feasibility of the change is assessed and confirmed.
• The additional effort and schedule required to implement the change is
understood and accepted by senior management.
A typical challenge in IT projects is that new requirements are requested by
users as they become more familiar with the IT solution or hear about new
developments in the IT landscape (especially via social media). The project
manager should note that the principles that were applied during requirement
gathering and prioritization (e.g. MoSCoW) in the scope planning stage
should also be used to assess these requests.
Practical Tips
1. Scope Management involves planning, definition, verification and change control of the project
scope.

2. Scope management entails the management of expectations and critically the management of
change control.

3. Managing expectations involves judicious build-up of trust and relationship with the key
stakeholders.

4. Scope creep is one of the most significant factors causing project delay. Change requests must
be formally managed, and their implication reflected in an updated project baseline (re-baselined).

5. Where a COTS solution (also termed “Packaged solution” or “out-of-the-box” solution) is adopted
in the project, the best-practice tip and advice is “Vanilla is Best” i.e. there should be minimal or
no customization of the product beyond the configurable features provided. COTS adoption
should be accompanied by a gap analysis of the fit of the business needs against the product
capabilities and features. If gap analysis results in major or substantial customization scope, it is
likely that the product is not a good fit or that use of COTS is not an appropriate approach. The
organization should consider re-engineering of their processes to align with the industry practice
as represented by the COTS functional design and features. Forcefully trying to fit a COTS to the
organization practice through major customization will lead to severe impact on total cost of
ownership or lifecycle cost due to the added cost of customization.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 26 of 117

5. Time Management
This knowledge area describes the main techniques and processes associated with
scheduling an IT project. IT project time management involves the following
processes:
• Defining and sequencing project activities.
• Estimating activity effort and duration.
• Creating the schedule.
• Controlling the schedule.
An overview of each of the above processes is described below.
a. Defining and Sequencing Project Activities
• Using the WBS as a starting point, define the project activities.
• Construct an activity precedence network diagram by establishing
dependency links between the activities. There are four types of
dependencies:
§ Finish-to-start.
§ Start-to-start.
§ Finish-to-finish.
§ Start-to-finish.
• Dependencies may be mandatory or discretionary. Lead and lag
relationships may also be included where:
§ Lead refers to a relationship whereby the successor activity begins
before the predecessor activity has completed.
§ Lag refers to a relationship whereby the successor activity cannot start
right after the end of its predecessor.
b. Estimating Activity Effort and Duration
• Estimate the staff effort (man-day/man-hour) requirements for each
activity (refer to chapter 6 for various effort estimation techniques). Care
must be taken to not over-budget any activity.
• Estimate the duration for each activity. The duration is the number of
working periods (hours, days, weeks) required to complete the activity with
the estimated resources.
• The assumptions underlying these estimates should be documented.
c. Creating the Schedule
• Use a network analysis method, such as the Critical Path Method (CPM)
or the Programme Evaluation and Review Technique (PERT), to calculate
the following:
§ Earliest start time (EST) and earliest finish time (EFT) for each activity.
§ Latest start time (LST) and latest finish time (LFT) for each activity.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 27 of 117

§ Total float for each activity – the time that activity can be delayed
without effecting the total project duration.
§ The critical path – the path through the network with the least total
float.
• Create a project schedule (usually in the form of a Gantt Chart) by
deducing start and end dates for each activity from the result of the
network analysis method, and then modifying the dates to take account of:
§ Weekends, public holidays and staff vacations.
§ The availability of staff resources (e.g. each staff member can only
work a limited number of hours per day on the project). Resource
optimization techniques include:
Ø Resource levelling - ensuring that a pre-defined level of resource
usage is not exceeded.
Ø Resource smoothing - minimizing fluctuations in individual
resource usage.
• Compare the computed end date for the project (and contractually agreed
intermediate dates if any) with the dates required by the project sponsor. If
necessary, take action to shorten the project schedule by using
techniques such as:
§ Crashing – reducing critical activity durations by adding resources.
§ Fast tracking – modifying the activity precedence network diagram to
maximize the number of activities performed in parallel.
§ De-scoping – negotiating a reduction in the requirements of the
project, which would lead to a reduction in the estimated effort for the
project, and hence a reduction in activity durations.
§ Phasing – negotiating the delivery of the project as a series of
releases, such that important requirements would be delivered by the
customer’s deadline (the first release), and the remainder would be
delivered in subsequent releases.
§ Downgrading the process – negotiating a reduction in the process
used to perform the project, such as by reducing the documentation
produced, testing methods employed etc, which would lead to a
reduction in the number of project activities (in the WBS) and the
estimated effort for affected activities, which would reduce the project
duration. Such process degradation should balance the expected gains
in reduced project cost and schedule with the possible increased risk of
delivering a poor quality product, and the consequential effect on
customer satisfaction.
• IT project scheduling would not usually be performed totally manually, but
would be substantially supported by computer-based project management
tools that specialize in scheduling.
d. Controlling the Schedule
• This involves:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 28 of 117

§ Determining the current status of the project schedule.

§ Influencing the factors that can cause schedule changes.
§ Adjusting the project schedule.
§ Managing changes to the project schedule.
Practical Tips
1. Time management involves the definition, sequencing and estimation of duration of activities
before project work starts. Once project work has started, it will involve monitoring and controlling
the schedule and proper assessment of the impact on scope and cost when the schedule needs
to be modified.

2. The management of project activities, including the identification of the critical path (CPM),
monitoring and facilitating the completion of interdependent activities is important to achieve the
overall project completion deadline.

3. Over-budgeting of activity durations must be avoided. Parkinson’s Law states that work expands
so as to fill the time available for its completion. Nevertheless, experts in chaos theory
suggest that project managers account for complex behaviour in organizations by
arranging for additional resources to be committed to the project. Using the analogy of
avoiding traffic jams on highways, they suggest that project managers schedule resources
such that no single resource is utilized more than 75%. A fine balance must be struck to
set realistic schedules and allow for contingencies.

4. Changes in schedule normally impact project cost and quality. Therefore, it should only be
undertaken with the approval of senior management.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 29 of 117

6. Cost Management
This knowledge area describes the main techniques and processes associated with
estimating the costs and benefits for an IT project. This involves resource planning,
cost estimation, cost budgeting and cost controlling. The key topic areas are
described below.
6.1 Project Cost Estimation and Budgeting
Project cost estimation is one of the main activities of the project planning process.
The aim is to estimate and control each of the resources required by the project.
These estimates would be translated into dollar values in cases where the project is
being managed against an explicit cost budget. Otherwise, the numeric quantities of
each resource would be used to represent the project cost estimate. A project cost
template can be used as a checklist for the possible sources of project cost that
would need to be estimated. Typical sources would be:
• Software licensing (including the annual maintenance fees (AMF) chargeable
during the development period).
• Hardware/infrastructure.
• Professional services:
§ Staff effort (i.e. labour cost).
§ Subcontracted tasks (i.e. the value of the contracts).
§ Training costs (i.e. course fees).
• Expenses (e.g. project site, travel and entertainment allowance for customers).
• Contingency funds.
• Recurring cots:
§ Software maintenance costs.
§ Hardware/infrastructure maintenance costs.
§ Hardware hosting and managed services costs.
Of these, staff effort is normally the most difficult to estimate. Typical effort
estimating techniques include:
a. Expert judgment (e.g. Delphi technique) – where experts who are
experienced in the type of project under consideration (in terms of scope,
technology and methods) would assess the work to be done and construct an
estimate based on their experience of undertaking other similar projects.
b. Cost-by-analogy – where the project under consideration is compared with
other projects undertaken by the estimator. Based on the estimator’s
assessment of the degree of similarity of the current project with previous
projects (where the actual effort expended is known), an estimate is
constructed by taking a multiple of the actual effort of the most similar
previous project.
c. Transactional or bottom-up estimating – where the estimate is derived by
defining the WBS, then estimating the staff effort required to perform each
task and finally summing the effort across all tasks to give an estimate for the

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 30 of 117

whole project. This technique is typically facilitated by using software metrics

collected from previous projects.
d. Top-down estimating – where an agreed project effort budget (perhaps
derived by expert judgment or cost-by-analogy) is decomposed to produce
budgets for each activity in the WBS. These budgets are then analysed and
modified if necessary based on expert judgment and software metrics
collected from previous projects. The modified activity-level budgets are then
recombined to form an improved project effort budget estimate.
e. Model-based estimating – where parametric models are used to create an
objective estimate based on some form of quantified assessment of the size
of the system to be built. The elements of this approach are as follows:
• The main input to a parametric model is typically an estimate of the size of
the system, measured in lines of code. Estimates of size can be
determined by using a software sizing techniques, such as:
§ Function Point Counting
§ Use Case Points
§ Object Points
The size estimate can then be translated into lines of code by using
industry standard or company specific metrics for specific programming
languages.
• The parametric model is essentially a regression model (or similar) that
has been developed using data taken from a range of previous projects. It
takes the size estimate plus a set of factors defining various project
characteristics to produce an effort and schedule estimate. An example of
such a model is Barry Boehm’s COCOMO.
The resulting staff effort estimate would be combined with other items in the project
cost template to form the overall project cost estimate. To finalise the estimate,
additional effort and costs would typically be added to insure against the negative
effects of major project risks- this known as assigning contingency.
For an estimating technique to have any chance of creating an estimate that is close
to what will happen in reality, there is a high dependency on the availability of
relevant past experience and past objective data. Anyone claiming to perform
estimation without any past references is simply guessing.
Having past data and knowing the various estimation techniques listed above are
only two of the pre-requisites for successful project cost estimation. Ultimately, how
you choose to apply the various estimation methods will depend also on the nature
of the project being estimated. This information is found is the WBS. Estimating
without first establishing a WBS is baseless guess-work and unreliable. In other
words, the WBS is the fundamental foundation to any estimation task.
Given the importance of a WBS in the estimation tasks, estimation errors have a
very high correlation with the uncertainties in the project scope and scope creep.
Hence, reducing scope uncertainties as much as possible and avoiding future scope
creep (see chapter 4) are major factors in ensuring the reliability of estimates.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 31 of 117

6.2 Project Cost Control

The objective of cost control is to monitor the approved project budget and to
manage changes to the cost baseline. One useful technique is Earned Value
Management which is a project management technique for the objective
measurement of project performance, combining scope, schedule and cost
measurement in a single integrated manner.
A key concept of estimation that project managers should be conscious of is that the
variance between an estimate and the actual figure is a function of the project
timeline. So as a project progresses through its execution phases, assumptions
associated with the initial estimates of activities formed at the planning stage should
be validated. That is to say, past estimates of future activities should be continuously
reviewed as the project progresses and newer, clearer, and more detailed
information becomes available.
6.3 Project Cash Flow Management
As highlighted in the article “Three Perceptions of Project Cost – Cost Is More Than
a Four Letter Word” by DH Hamburger, published in the Project Management
Journal in 1986, the project manager’s responsibility in cost management goes
beyond just keeping the project cost within budget. For the project manager to be
effective, he must understand the nature of each cost and influence when each cost
impacts the project to optimize cash flow and improve the project and corporate
financial performance. The key mechanisms that the project manager can apply to
optimize project cash flow management are as follows:
a. Explore alternative development concepts or approaches during the planning
phase. It is financially prudent to carefully consider and explore alternative
approaches before deciding on the development strategy. For example,
choices such as the following should be considered:
• Outsourced versus in-house development.
• Buy versus lease.
• COTS/packaged solution versus bespoke development.
Related to this issue, is the need to consider the Total Cost of Ownership
(TCO) and not just the initial project capital investment cost.
b. Balance the cost of quality with the project’s quality requirements. Over
specified and excessive quality control and assurance will be
counterproductive to cost efficiency and effectiveness. For example, white-
box testing may be the ideal approach to test some software applications, but
it can be substantially more costly to conduct compared to other testing
methods without achieving significantly higher levels of quality.
c. Carefully set the payment milestones for the procurement of materials and
services. It is not always a good idea to defer payment as late as possible.
The project manager must remember that the vendor is also practicing risk
management and cost management. Undue prolonging of payments that add
cost to the vendor will be incorporated into the vendor’s overall price. The
project manager should therefore structure the progressive payment terms so
that they are commensurate with the project risk.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 32 of 117

d. Be aware of taxation expenses related to the project. These should be

managed in accordance with the organization’s business environment and the
tax regime it operate in. When procuring professional services of consultants
from overseas countries, additional withholding taxes may need to be
factored into the project costs.
Practical Tips
1. Cost Management involves resource planning and estimation, budgeting and control of cost.

2. The management of resources should include managing hardware, software, people, facilities
and logistics so as to ensure completion within budget.

3. A good cost reporting process will enable resources to be mobilised during different periods of
time from team to team to maximize productivity or minimize wastage.

4. Contingency funds should be controlled by the project manager and only released after
authorization by him when exceptional circumstances warrant it; emphasis on contingency should
also be on schedule contingency, not just effort contingency.

5. A typical approach to the task of estimation is illustrated by the following steps:

a. Create a proper WBS covering all deliverables expected of the project scope.

b. Break down and decompose the WBS to the appropriate level of activities and sub-activities as is
necessary to enable estimation to be made.

c. Analyse past experience captured in the form of data. For example, parameters or metrics that
influence the actual effort/time taken to undertake a piece of work or carry out an activity.

d. Consult appropriate expert. For example, colleagues across functional units, vendors, specialist
expert/consultants in the industry or type of product who are familiar with the activities or have
performed them before.

e. Document any assumptions used in the estimation tasks and in deriving the final estimates.
Review factors that affect the accuracy of past estimation experiences and if relevant to the
current context, factor them in to improve the reliability of the current estimate.

6. Where possible, the estimates of labour effort are best provided by the resources who are
assigned to perform the tasks. This is especially the case for technical tasks such as those in
software development. Estimates provided by the actual resources will also translate to better
commitment and ownership of the tasks. On the other hand, if the estimate is imposed on a
technical resource and if the estimate happens to be higher than is actually necessary, then the
outcome be may be an example of Parkinson Law i.e. work expands to include non-essential
activities just to fill the time given.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 33 of 117

7. Quality Management
This knowledge area describes the main techniques and processes associated with
ensuring the creation of high quality deliverables from an IT project. The basic
quality concept considerations are equally applicable to both infrastructure and
application software projects. This chapter focuses on system development quality
management techniques. These involve quality planning, quality assurance and
quality control by key stakeholders such as project team members, quality
assurance (QA)/peer reviewers and external subject matter experts (SME)/QA
consultants. The key topic areas are described below.
7.1 Basic Quality Concepts and Considerations
In the context of IT projects, the function of quality management is to ensure that
systems are developed that are fit for purpose, conform to specifications and meet
customer expectations. Two important concepts are:
a. Product quality – the degree to which customer needs and expectations are
satisfied. Such customer needs/expectations include functional requirements,
non-functional, required effort/cost budget and required delivery schedule.
b. Process quality – the effectiveness and efficiency of the process that
produces the product.
The basis of quality management is that product quality is a function of process
quality i.e. that to develop a good product you need a good process. The main
elements of a high quality development process are:
a. Contract Review – to ensure that the work to be done is adequately defined
and then reviewed to ensure commercial (effort, cost, and schedule) and
technical feasibility. This should result in organisation-level commitment to the
objectives and plans of the project.
b. Requirements Control – to ensure that the project requirements are
adequately defined and reviewed for completeness, consistency and
feasibility, and their ability to be quantified and verified. Requirements should
also be reviewed by the customer to ensure that the basis for the project is
acceptable. Further, a change control process should be established to
handle requests for changes to the agreed requirements.
c. Design Control – to ensure that the design for the system is adequately
specified and reviewed for correctness and consistency (with the agreed
requirements), and technical feasibility, effectiveness and efficiency. This
process should enable major defects to be identified and resolved prior to the
commencement of the construction activities.
d. Development Control – to ensure that the design is correctly and efficiently
translated into the required system. This is usually achieved through the use
of standards and guidelines to provide guidance to the developers on how to
perform each technical activity, and walkthroughs to check the code against
the design and the standards and guidelines.
e. Verification and Validation – to ensure that the developed system meets the
agreed functional and non-functional requirements. Verification refers to
confirming that the outputs from a project phase meet the requirements of the

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 34 of 117

inputs to the phase, e.g. ensuring that the design specification adequately
addresses all the elements of the requirement specification. Validation refers
to ensuring that the final end products of the development process meet the
initial requirements, e.g. using user acceptance testing to ensure that the
system delivered to the users meets their stated requirement (in the contract
and user requirement specification). Hence, a combination of verification and
validation processes will ensure that the customer’s requirements are
correctly translated through the phases of the development life cycle, to
create the required end product. Two classes of quality control techniques
support these processes (see section 7.3):
• Reviews.
• Testing.
f. Management Control – ensuring that project achieves the required delivery
schedule within the agreed staff effort/cost budget. This is typically achieved
through thorough project planning to establish feasible and achievable
schedules and effort/cost estimates, and the use of effective progress control
mechanisms to monitor progress against the plans, and take the necessary
actions to ensure that project keeps on track.
7.2 Quality Management Frameworks
The role of quality management is to provide a programme of planned and
systematic activities to determine, achieve and maintain the required level of quality
in the delivered system. At the organisation-level, this is normally achieved by
implementing a quality management system (QMS) that defines the policies,
standards, procedures, methods and guidelines for managing the development and
maintenance of systems. A QMS broadly addresses three main areas of concern:
a. Quality Planning – to establish a system to achieve quality goals and
objectives.
b. Quality Control – to detect and correct problems during development.
c. Quality Improvement – to take corrective and preventative action to raise
the level of quality delivered to customers.
A QMS is usually developed by adhering to an internationally accepted framework
standard. These frameworks provide quality system requirements and form a basis
for third-party, independent certification. With such certification, customers can be
given the confidence that a supplier has internal processes that facilitate the
development of products with an acceptable level of quality. The most widely applied
QMS framework across all development and service industries (including system
development and maintenance) is the ISO9001:2008 published by the International
Organisation for Standardisation (ISO). ISO9001 is industry neutral, but can be
interpreted in the context of software and systems. An important alternative to
ISO9001, which was specifically developed for systems development and
maintenance, is the Capability Maturity Model Integration (CMMI) by the Software
Engineering Institute (SEI), Carnegie-Mellon University, USA.
The developed QMS is usually realised as a set of quality system documentation.
This documentation is usually structured as follows:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 35 of 117

a. Quality Manual – this defines the organisation’s quality policy and quality
objectives and details how the QMS operates.
b. Procedures – these describe the implementation of policy with reference to
the requirements of the selected QMS framework – these can be thought of
as the laws or rules and regulations of the QMS. For instance, the procedures
of an ISO9001 quality system would normally explain how the requirements of
that standard are satisfied.
c. Standards and Guidelines – these explain how to adhere to the procedures
by providing guidance on what needs to be done in the context of an actual
project. For instance, a procedure may state that all tests should be planned.
To support this, there could be a guideline giving the format of a document
e.g. the test plan. Templates and checklists may be provided to guide the
project team.
An important characteristic of the procedures is the need to create quality records.
These records provide a documented basis for all the activities performed by a
project, and objective evidence that the requirements defined by the procedures
have been adhered to. Internal quality audit is used to sample evidence from a
range of projects to confirm that the requirements of the QMS are being followed,
and to identify areas of the system that can be improved. Third party certification
organisations also use auditing along with reviews of documented QMS, to confirm
that the system adheres to the requirements of the QMS framework standard.
7.3 System Quality Control Techniques
In IT projects, two broad categories of quality control techniques are employed:
reviews of the deliverables of the project life cycle, and
software/system/infrastructure testing. These techniques are described below.
7.3.1 Reviews
The review is the basic quality control technique that can be applied in any industry
to verify work products. In IT projects, reviews can be conducted on all the
deliverables, both management as well as technical, so that:
a. Defects can be identified and corrected.
b. Non-conformances to standards can be identified and corrected.
c. Improvements can be suggested and implemented.
Reviews can be conducted in a variety of styles depending on the degree of
formality required, and the objective of the review. Typical review styles are as
follows:
a. Inspections. The objective of a system inspection is to detect and identify
defects of a system element in a rigorous, formal, peer examination that:
• Verifies that the system element satisfies both its specification and
preceding intermediate work products.
• Verifies that the system element conforms to applicable standards.
• Identifies actual or potential deviations from standards and specifications.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 36 of 117

• Collects engineering data (i.e. defect and effort data) that can be analysed
using techniques, such as Cause-and-Effect Analysis, Control charts,
Pareto charts, Scatter diagrams and Run charts.
• Does not examine alternatives or stylistic issues.
b. Walkthroughs. A walkthrough is a less formal verification technique in which
life-cycle work products or system elements are examined by a group of
peers to:
• Find defects, omissions, and contradictions.
• Improve the system elements.
• Consider alternative implementations.
• Exchange techniques and style variations.
• Educate the participants.
• Point out efficiency and readability problems or modularity problems if the
system element is software code.
c. Desk Checks. A desk check is the least formal style review in which peers
will individually review (literally at their desk) life-cycle work products or
system elements and provide comments to the originator/author, typically
based on the reviewer’s own criteria.
To optimize the effectiveness of reviews, it is recommended that written procedures
are used to govern how reviews are conducted and the roles and responsibilities of
the participants. An important aspect of such procedures is typically the use of
checklists to focus the reviewers on the issues to address during their review.
Checklists can also be used by project team members to govern the quality aspects
of their individual deliverables. In addition, defect classification schemes are used to
reflect the severity of the problems/issues identified, and provide guidance on the
necessity (and urgency) for corrective action to be carried out.
7.3.2 Software/System Testing
In any engineering process, testing is used to exercise control over the developed
product. In IT projects, software/system testing is used to achieve the following:
a. Establish confidence that the software/system meets user requirements.
b. Make lack of quality visible.
c. Execute the software/system with the intent of finding errors.
To comprehensively test a system, a testing strategy comprising different levels of
testing is required to validate each of the main specifications produced by the project
life cycle against appropriate aspects of the developed system. A typical strategy
might be:
a. Unit Testing - aims to validate the individual coded modules (classes,
subprograms, subroutines or procedures) against their detailed design. It
focuses on test statements, branches, and paths through discrete pieces of
code. The following questions summarise the objectives of unit testing:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 37 of 117

• Does the logic work properly? Does the code do what was intended? Can
the program fail?
• Is all the necessary logic present? Are any functions missing? Does the
module do everything specified?
• Has any unplanned functionality been added?
b. Integration Testing - aims to validate the integrated modules against the
high level system design by testing the module interfaces and confirming that
the modules have been linked together correctly. The objectives of integration
testing include:
• To detect improper calling sequences or mismatched parameters.
• To obtain a working skeleton of the system.
• To establish confidence that the skeleton parts interface and link correctly.
• To demonstrate that simple test cases and transactions are being handled
properly by the system.
c. System Testing – aims to validate the completed integration-tested system
against the software requirements (as might be defined in the functional
specification). System testing would typically include:
• Functional tests – to determine, from the developer’s point of view,
whether the functional requirements of the system have been achieved
• Non-functional tests – to demonstrate that the non-functional requirements
have been achieved by means of:
§ Recovery testing – to test the response to hardware failures.
§ Security testing – to test the security measures provided. For internet
or public facing systems, Vulnerability Assessment and Penetration
Testing (VAPT) is usually carried out.
§ Stress/load testing – to test the ability of the system to handle high
volumes of data, and transactions (typically via automated tools).
§ Performance testing – to check that response times (for online user
functions) and throughput (for batch jobs) are acceptable.
§ Configuration testing – to demonstrate that the system can operate
satisfactorily on all required hardware and operating systems
environments.
§ Usability testing - systematic observation under controlled conditions to
determine how well typical users can use the system.
d. Independent Testing – aims to provide an additional level of assurance by
getting another party, who has not been involved in the development process,
to test the application software based on the stated business requirements.
This is especially applicable for mission critical projects.
e. Acceptance Testing – aims to validate the completed system against the
user requirements (as might be defined in the user requirements
specification), and confirm that the system is ready for operational use. The

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 38 of 117

selection of tests would normally be agreed with the user, and would typically
include tests to demonstrate important functional requirements, performance
requirements and operational requirements – particularly reliability and
usability. If the developed system is to be accessed by internet users either
on the desktop or mobile devices, the validation would include
browser/operating system compatibility testing (BCT). Note that the BCT
requirement (which browser/operating system to support) would be normally
be specified in the user or system requirements specification.
The requirements for the system could also include government, industry and
organizational regulations or standards that must be complied with, such as:
• The Payment Card Industry Data Security Standard (PCI DSS) for
transmitting, storing and processing credit card information.
• Singapore government agencies require systems developed for them to
comply with their instruction manuals on IT management.
• USA Food and Drug Administration (FDA) standards for medical software.
The acceptance process should also include tests to validate compliance to
these regulations or standards.
f. Operational Readiness Testing (ORT) – tests performed to ensure that
adequate processes and procedures are in place to allow the system to be
used and maintained. This is undertaken by simulating the production
environment, with all the hardware and application software installed and
configured, and then performing tests that aim to discover technical and
operational issues/problems prior to production release. These tests may
include aspects of the system related to the front office customer touch
points, back-up facilities and procedures, procedures for disaster recovery
(business continuity planning), training for end users, maintenance
procedures and security procedures.
g. Regression Testing - should be performed whenever something in or around
a working system has changed. It aims to verify that the system continues to
meet its requirements after changes have been made (i.e. it tests that the
parts of the system that were not changed continue to function correctly).
Regression tests would normally be a selection from the unit, system and
integration tests.
7.3.3 Testing Process
Appropriate management control is required to ensure the effectiveness of a
project’s testing strategy. The following testing process is recommended for any of
the levels of testing described above:
a. Test Planning – this involves identifying the tests to be performed, the
associated testing activities and test organisation, estimates of the resources
and schedule required and the test level entry and exit criteria. For example,
for unit testing the criteria could be:
Entry Criteria:
• Coding is completed.
• Test scenarios are reviewed.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 39 of 117

Exit Criteria:
• All identified Unit Test scenarios are executed and achieve the “pass”
criteria.
• Test results are reviewed.
b. Test Design – this involves defining the tests to be performed, in terms of the
precise instructions (or script) to be followed to perform each test, including
the expected results. There are two basic testing methods:
• Black box testing – focuses on the functionality as defined in
specifications, but disregards the control and logic structures found in the
detailed design and actual code e.g. demonstrate that a specific input to a
module would lead to the generation of a specific output, without
considering the code statements executed to produce the output.
• White box testing – which focuses on testing the code logic to demonstrate
that logical paths can be correctly traversed e.g. determining sets of input
parameters to demonstrate that sequences of statements can be correctly
executed.
To improve test case design productivity, test cases should be stored in a
reuse repository. Then when designing tests for a project, the test designer
should first attempt to identify suitable existing test cases from the repository
that can be reused before starting to design new tests.
c. Test Execution – involves the testers following the test plan and design
(which could be presented as one test planning document) to execute the
tests. As part of running through the test scripts, the actual results of each
test should be documented, and objective evidence should be collected to
demonstrate the results e.g. screen dumps or log files. The efficiency of
conducting tests can be significantly improved by using automated testing
tools, particularly to capture results and compare with the expected outcome.
Such tools also make re-testing (after correcting errors) faster and more
effort-efficient. However the cost/benefit of using automated testing tools
depends on how often the automated test will be executed.
d. Test Follow-up – a test incident report should be issued for each test that
fails to achieve its expected results. These reports should then be logged,
prioritized and tracked to closure in a test incident register. The development
team is responsible for fixing the test incident before passing the system
element back for re-testing (according to Service Level Agreement (SLA) set,
if defined). In addition, the impact of test incidents should be assessed by the
test manager or test lead to avoid the execution of related tests that are
certain to fail, until the test incident is resolved. The documented results from
each test should be reviewed to confirm that they have all been conducted
satisfactorily. Any additional errors found as a result of the review should be
reported and followed-up as described above.
e. Test Monitoring and Control - the purpose of test monitoring is to give
feedback on and visibility to the testing activities. The test execution and
follow-up activities should continue until the exit criteria is achieved. To
access test progress, Test Metrics (e.g. percentage of test cases passed)
could be used.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 40 of 117

f. Test Result Analysis and Reporting – at the end of the testing process,
data resulting from tests (e.g. test metrics) should be analysed to determine
whether the testing needs of the project were met. In the case of deficiencies,
analysis reports should document the degree of success or failure and
propose probable causes of failure. The collected test results should be
compared with established evaluation criteria to determine whether failure is
related to the testing process or whether there is a need to address
requirements or design issues in the requirements development or technical
solution processes. If the failure is deemed to be due to the testing process,
then the test incident logs could be analysed to determine whether it is due to
a testing procedure problem or a test environment problem. The project test
result analysis could be reported as part of the test report to the project
management committee.
g. Test Closure - during the closure phase of the testing process, data should
be collected from completed activities to consolidate experience, facts and
artefacts, and to evaluate the process. From these data, lessons can be
learned to improve the test process for future projects. In addition, the
project’s test cases should be stored in a test case reuse repository for future
reuse.
7.4 System Configuration Management (SCM)
The purpose of SCM is to establish and maintain the integrity of the products of the
project throughout the project’s system development life cycle. Poor configuration
management causes many system quality problems, such as:
• The latest version of source code cannot be found.
• A difficult bug that was fixed at great expense suddenly reappears.
• A developed and tested feature is mysteriously missing.
• A fully tested program suddenly does not work.
• The wrong version of the code was tested.
• There is no traceability between the software requirements, documentation, code
and test cases.
• Programmers are working on the wrong version of the code.
• No one knows which modules comprised the software system delivered to the
customer.
The basic SCM activities are as follows:
a. Configuration Identification. Identifying and defining the configuration items
in a product. In particular, unique identifiers assigned to each part of the
product, which can be used to support traceability between a software
element and all other related software elements (including specifications,
code, test scripts etc).
b. Change Control. Controlling the release and change of these items
throughout the product life cycle. This involves establishing a change control
process that specifies:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 41 of 117

• The items that are subjected to change control. These are usual baselined
items, which are normally items that have been reviewed, approved and
accepted for use, e.g. the user requirement specification after the customer
has accepted it.
• The individuals that are permitted to initiate a change request.
• The individuals or group (often referred to as the Change Control Board
(CCB) who are responsible for evaluating, accepting or rejecting, and
tracking the change proposals for the various baselined products.
• The “change impact” analysis expected for each requested change. This
will include any revised cost, schedule and risk assessment.
• The requirements to keep a change history to document all the changes
made to each configuration item.
c. Status Accounting. Recording and reporting the status of configuration
items and change requests. This enables a continuous record to be
maintained of the status and history of all baseline items and proposed
changes to them. The following questions can be answered:
• What changes have been made to the system?
• What changes remain to be implemented?
d. Configuration Auditing. Verifying the completeness and correctness of
configuration items. This involved conducting audits to:
• Verify that the system is built according to the requirements, standards, or
contractual agreement.
• Verify that all system elements have been produced, correctly identified
and described, and that all change requests are properly managed, tracked
and resolved.
A project team can define their SCM approach by producing an SCM Plan.
Alternatively, SCM can form part of a project’s Quality Plan.
Practical Tips
1. Quality management is a management function involving Planning, Assurance and Control of
quality.

2. The management of quality assurance and quality control processes to ensure timely
completion according to requirements, minimize rework and system failures, including
development of mechanism to prevent problem recurrences, obtaining client’s participation in
quality management process, publication and enforcement of standards.

3. Quality is owned by everyone in the project. Checklists must be used to operationalise the
practice of quality within the project team. QA checkpoints, together with their associated
objectives and QA/Peer Reviewers, must be identified at the start of the project and reflected in
the project schedule.

4. QA review points must be shared and response/outcome to each review point documented.

5. QA review activities must be planned into the project schedule.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 42 of 117

8. Human Resource Management

This knowledge area describes both the processes and competencies required in
managing Human Resources of a project team. The tasks of a project manager are
to acquire and deploy the appropriate resources and manage their work and
deliverables. This involves making the most effective use of the people selected as
project team members, organizing them according to their project roles, and
maximizing their strengths. The key topic areas are described below.
8.1 Qualities of an Effective Manager
An effective manager applies a combination of people, process and technical
management skills to successfully lead the project team:
a. People skills. These include:
• Empathy.
• Understanding of personality types and interaction styles.
• Ability to listen.
• Ability to motivate.
• Ability to convey clear expectation e.g. Key performance indicator (KPI)
setting/review during on-boarding/off-boarding stages.
• Ability to coach.
b. Process skills. Examples of process skills required to manage a team
include:
• Team on-boarding (inducting team members into the project team).
• Team communications.
• Team problem resolution and decision making.
• Project team training and upskilling (technical and non-technical).
• Team and individual performance evaluation.
• Team progress meeting and work reviews.
• Responsibilities reassignment during team member’s transition (exit and
new hires).
c. Technical skills. It is helpful if a project manager has the relevant technical
skill sets, but in the event that he does not have technical skills, he must
recognize the limits of his skills. This allows him to:
• Decide which technical skills are needed. Note that such skills are not
solely related to application development, computer science, network
engineering etc, but can also include necessary domain-specific skills
such as accounting and financial regulations.
• Appoint technical advisors or consultants.
• Know when it is appropriate to consult technical advisors or consultants.
• Know how to evaluate the advice of technical advisors or consultants.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 43 of 117

8.2 Planning for Project Team Resources

The project scope, timeline, technology requirements and estimated size of the
project serve as inputs when planning for project team resources. The management
strategy of the project, e.g. outsourced, in-house or a hybrid model, would determine
if the project team is staffed by internal, in-sourced or external resources. There may
also be other non-technical skills required by the project e.g. behavioural traits and
specific talents. The project manager needs to work with various sources to acquire
the necessary resources.
8.3 Forming Project Teams
The issues associated with selecting, organizing and controlling a team are
described below.
8.3.1 Skills Requirements Analysis
To select an appropriate project team, an assessment needs to be made of the skills
required of the team in terms of the technical skills (e.g. Java programming,
architecting, network and infrastructure, testing and documentation), domain
(industry specific knowledge) and the required competency levels (e.g. experience).
8.3.2 Team Selection
To support the selection of appropriately skilled resources for a project, it would be
useful to initially refer to the organization’s skills inventory, which would present key
information on each potential resource, such as:
• Skill description.
• Domain that the skill is associated with– which might be: leadership, process-
related or technical (including application domain-specific skills).
• Level of competency for the resource.
• Supporting evidence – such as a course attendance certificate or a successful
project.
Resources that meet the project requirements are then added to a shortlist the
potential candidates. In addition to looking for candidates that match the project’s
skill requirements, personality analysis can also be a useful profiling tool. Personality
analysis provides behavioural information that can be used to match the suitability of
the candidate to the intended role e.g. a business analyst should prefer working with
people to resolve problems as opposed to working alone. Examples of personality
analysis tools are the Myer Briggs Type Indicator (MBTI) and Dominance,
Inducement, Submission and Compliance Assessment (DISC). In the subsequent
stages of the project, the personality analysis provides inputs for appropriate levels
of supervision and conflict management.
8.3.3 Setting up the Project Team Structure
In a project structure, all team members, regardless which business unit they
originate from, will report directly or indirectly to the project manager over the
duration of the project assignment. This is important to preserve clarity of line of
reporting and work assignment for the project.
Every team must have a structure, a pattern of relationships based on cooperation,
review, reporting and leadership. This structure will influence, and be influenced by,

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 44 of 117

the technical competencies, maturity of the team members, their personality and the
team manager’s leadership style.
8.4 Managing the Project Team
The key processes and knowledge areas associated with managing the project team
are described in the following subsections.
8.4.1 The Team Life Cycle
A project team goes through several developmental stages. An understanding of the
stages helps the project manager to better manage the work and the team:
a. Forming: Members of the team get to know one another on a personal level.
This is also a good opportunity to see how each member of the team works
as an individual and how they respond to pressure.
b. Storming: Initial trust has been developed between team members that they
start to feel comfortable expressing discontent and challenge others' opinions.
This stage is necessary to the growth of the team. This phase can become
destructive to the team and will lower motivation if allowed to get out of
control.
c. Norming: The team manages to have one goal and come to a mutual plan for
the team at this stage. A lot of give and take to function as a team and work
together for the success of the team’s goals.
d. Performing: The team functions as a unit as they find ways to get the job
done smoothly and effectively without inappropriate conflict or the need for
external supervision. They are motivated and knowledgeable. The team
members are competent, autonomous and able to handle the decision-
making process without supervision. Dissent is expected and allowed as long
as it is channelled through means acceptable to the team.
e. Adjourning: When the project ends and the team is disbanded.
A project manager needs to apply the appropriate leadership style adapted to the
team’s developmental stage as well as to individual team member’s developmental
progress in the project. See section 8.5.3 for further details.
8.4.2 Assigning and Managing Work
To assign and manage the work of the project team, the following best practices
should be considered:
a. Use a resource breakdown structure (RBS) to highlight the types of
resources utilized by the project.
b. Create a responsibility assignment matrix (RAM) chart to present the roles
and responsibilities of the project team.
c. Use a RACI chart (a subset of RAM) to assign team members to project
activities, indicating their role for each assigned activity as either Responsible,
Accountable, Consult, or Inform (RACI).
d. The assigned activities should be selected from the project WBS and should
have clear output descriptions (e,g. in the form of templates, sample
documents and checklists).

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 45 of 117

e. Discuss all assignments with the staff involved and get their agreement to the
deadlines and expectations.
f. Monitor the work to ensure that the task loading on all staff members is fair
and equitable, and that tasks are being performed as planned.
8.4.3 Managing Cross-Functional Teams
Enterprise wide projects that solve organizational problems and issues typically span
several functional areas. These cross-functional projects draw their members from
diverse parts of an organization for relevant representation of knowledge,
experience, perspective, and practice. They may also include members from outside
the organization, such as from suppliers, key customers or consultants.
The richness of backgrounds, cultural values, orientations and styles fosters a high
creative capacity for the project. When working together, the team tends to learn
more about other disciplines and develop new technical and job skills more readily
as they work across job functions. Also, members of cross-functional teams promote
more effective teamwork by acting as a single source of information and decision-
making regarding projects and customers.
8.4.3.1 Success Factors of Cross-Functional Teams
For a cross-functional team to function well, it requires:
a. A senior level project sponsor.
b. Clear team goals and plans for achieving them. Team members must be clear
about the deliverables that they are committed to produce.
c. The team size should be small. Some organizations use small core groups
within larger teams to make the key decisions and accomplish most of the
work.
d. The team should be empowered to make and implement decisions. Cross-
functional team leaders should clarify their teams' authority to decide key
issues.
e. There must be good group dynamics since the diversity within the team
makes it especially susceptible to poor interpersonal relationships, conflicts
between team members, and a lack of trust and candour.
f. Recognition and rewards which are team based rather than individual based.
g. Access to the breadth and depth of information within the company for
strategic, tactical and operational decisions.
8.4.3.2 Skills for Managing Cross-Functional Teams
In addition to the personal competencies described in section 8.1, a project manager
also needs the following to effectively manage cross-functional teams:
a. Strategic thinking techniques for “seeing” the business situation.
b. Strong financial, statistical and risk management skills.
c. Political and communication skills to gain the approval of project plans and
commitment of team members.
d. Knowledge of the technical issues addressed by the team.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 46 of 117

8.4.4 Managing Geographically Dispersed Teams

Geographically dispersed teams do not have the advantage of face-to-face
interactions. Also known as virtual teams, they are identified by the following
characteristics:
a. A team of individuals who work across time, space and organizational
boundaries with links strengthened by webs of communication technology.
b. They have complementary skills and are committed to a common purpose,
have interdependent performance goals, and share an approach to work for
which they hold themselves as mutually accountable.
c. The team membership can shift depending on work priorities.
8.4.4.1 Creating Virtual Teams
The following factors and attributes would be required to create successful virtual
teams:
a. The availability of reliable communication and collaboration tools for all team
members.
b. The existence of written goals, project specifications and performance
metrics.
c. Opportunities for some of the key virtual team members to meet face to face
at the start of the project to build up the required human relationships.
d. Human resource policies and reward/recognition systems to address the
unique needs of virtual workers.
e. Training methods to accommodate continual and just-in-time learning.
f. A “high trust” culture; teamwork and collaboration are the norm.
g. Leaders who set high performance expectations.
h. Team leaders and members who exhibit competence in working in virtual
environments.
8.4.4.2 Tools for Remote Interaction
The most basic tools used by virtual teams are the telephone and email. Other tools
include:
a. Video and audio conferencing.
b. Internet chat and whiteboard.
c. Project web sites.
d. File transfer and program sharing.
e. Remote desktop sharing.
f. Mobile messaging apps.
8.4.4.3 The Trust Factor
One of the most critical issues in the use of virtual teams is the establishment of trust
amongst team members. Studies have shown that trust in virtual teams and team
members needs to be established at the outset in order for the project to proceed

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 47 of 117

with the trust intact. They further suggest that virtual teams with the highest levels of
trust tend to share three traits:
a. They began their interactions with social messages before focusing on the
work at hand.
b. Clear roles were defined for each team member.
c. Team members consistently display eagerness, enthusiasm, and an intense
proactive action orientation in all of their messages.
Additionally, these high trust teams typically have the following characteristics:
a. Display a task versus procedural orientation.
b. Rotate leaders – alternate members “rise to the occasion”.
c. Discuss and clarify team goals.
d. Engage in time management and project management activities.
e. Give substantial feedback oriented toward improving the content of another’s
work.
f. Engage in frequent interaction, notifying members of their whereabouts and
absences.
8.4.4.4 Obstacles to Success
Virtual teams also face various obstacles to success such as those described below:
a. Soft issues e.g. false consensus, unresolved overt conflict, closure
avoidance, uneven participation, lack of accountability and “forgetting the
customer”.
b. Technology adoration – a belief that all virtual team problems can be solved
by establishing an email list, opening chat rooms and mounting desktop
conferencing sessions.
c. Technological barriers e.g. slow network computers, poor architecture and
lack of collaborative software.
d. Timing issues – difficulties finding the “right” time for meetings due to time
zones.
8.4.4.5 Virtual Leadership
Leading a virtual team not only involves communication complexities but also
requires a specific project leadership approach as described below:
a. The project manager must manage the boundaries – the environment that
surrounds the team. A few of these include introducing members to key
external contacts, intermediating with headquarters and building systems for
data linking.
b. Project tracking requires a new paradigm of managing people and progress of
the project. The project manager has to contend with:
• An increase in structure and flexibility - flexibility in the sense of the work
environment and structure as it relates to the pattern of interaction.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 48 of 117

• Greater individuality and more teamwork - individual effort is needed due

to the distance, but there needs to be unity and commitment by the team
members on objectives.
• An increase and decrease in control - control over the worker is reduced,
but managers must maintain strong control over the structure of the group.
• Software exists that can aid in the evaluation of team members. One
avenue is monitoring software, but this erodes the concept of trust. The
leader should instead keep the channels of communication open and
promote a culture characterized by “clan control”.
Management of virtual teams requires many of the same skills as traditional project
teams. However, it is impossible to micromanage a virtual project. Coordination skills
are more important because of the reduced communication of virtual teams.
8.5 The Project Manager’s Skills
The ability to manage others begin with the ability to manage oneself. For project
managers who have increasing responsibilities for managing more complex projects
which are cross-functional, cross-cultural and geographically dispersed in nature, a
more advanced level of personal mastery is required. Personal mastery is an
individual’s journey of awareness, discovery, accountability and growth. In this new
level of soft skills development, project managers will first need to understand their
own personal motivators and barriers to growth before mastering these skills to bring
out the best in their team members and associates.
8.5.1 Effective Leadership
When leaders drive emotions positively, they bring out everyone’s best, creating
resonance. Conversely, when they drive emotions negatively, they spawn
dissonance. Whether a project flourishes or withers depends to a great extent on the
resonant leadership of the project manager. Emotionally intelligent leaders use
resonant leadership styles to develop healthy and effective working relationships
that constitute a powerful force in energizing and motivating their self-directed team
members into a high-performance team. The key emotional domains for resonant
leadership are:
• Personal competence.
• Self-awareness.
• Self-management.
• Social competence.
• Social awareness.
• Relationship management.
In the journey of personal mastery, leaders become aware of the following:
• Their own strengths/weaknesses, and how to compensate their weaknesses.
• Their goals and how to achieve these goals.
• When to pursue their mission relentlessly, and when to change course.
• Set high standards for self and others.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 49 of 117

• Maintains an open and honest relationship.

8.5.2 Difference between Leadership and Management
What distinguishes leadership from management are the following:
a. A leader is a person you will follow to a place you would not go by yourself.
b. You manage within a paradigm and you lead between paradigms.
c. The manager administers, the leader innovates.
d. The manager has a short range view, the leader has a long range
perspective.
e. The manager asks how and when, the leader asks what and why.
f. The manager has his eye on the bottom line, the leader has his eye on the
horizon.
g. The manager accepts the status quo, the leader challenges it.
8.5.3 Leadership Styles
The following are the typical leadership styles:
a. Authoritarian or Directing – The leader takes all decisions, assigns all tasks
and supervises task accomplishment
b. Coaching - The leader continues to direct and closely supervises task
accomplishment, but also explains decisions, solicits suggestions, and
supports progress
c. Consensus or Supporting - The leader facilitates and supports
subordinate’s efforts toward task accomplishment and shares responsibility
for decision-making with them. Project issues are debated until all members
are in agreement, and tasks are then taken on voluntarily
d. Leadership/Followership or Delegating - The leader turns over
responsibility for decision-making and problem-solving to appropriate
subordinates. Ideally, each task has a self-selected “natural” leader to whom
the other team members defer to on that task.
Effective leadership requires knowledge of situational leadership skills where leaders
apply “different strokes for different folks” and “different strokes for same folks”. The
goal of an effective leader is to meet people where they are and to give them the
direction and support they need, when they need it. In particular, the leader needs to
understand the development levels of his followers, and match these to his
leadership styles as follows:

Development Level of Follower(s) or Associates Leadership Style of Leader

Low Competence/High Commitment Authoritative/Directing

Some Competence/Low Commitment Coaching

High Competence/Low Commitment Consensus/Supporting

High Competence/High Commitment Delegating

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 50 of 117

8.5.4 Leadership Skills

The key skills of an effective leader are:
a. Flexibility – The ability to use a variety of leadership styles comfortably
b. Diagnosis – The ability to analyse the situations and the people involved
c. Contracting for Leadership Style – The ability to match and get agreement
on the expectations and actions of the people involved.
d. Versatility – The ability to adapt the leadership style to suit the development
level of followers or associates.
8.5.5 Conflict Management
Whenever two or more staff members have to work together, there is a possibility of
conflict. Conflict can lower the morale and productivity of a team. If conflicts are not
promptly detected and properly resolved, then the team’s effectiveness would be
significantly degraded. In most cases, there are four sources of conflict:
a. Miscommunication.
b. Technical disagreement.
c. Personality clashes.
d. Mismanagement.
In particular, common causes of conflicts in a project include:
a. Misaligned project priorities.
b. Unclear administrative procedures.
c. Inability to deal with differing technical opinions and trade-offs.
d. Insufficient staffing or inequitable distribution of workload.
e. Inability to set clear guidelines to guide decisions impacting project cost.
f. Inability to anticipate and manage project progress which impacts the project
schedule.
g. Allowing personalities to influence the conduct of project activities.
Conflicts in projects are inevitable with the increasing complexities of today’s project
environment that poses enormous managerial challenges for directing, coordinating
and controlling teamwork. The following can help foster a conducive project
environment:
a. Clarify at project start-up on the decision-making process (including the
empowerment of decision-making with specific roles and escalation path)
within the project context.
b. Clarify the roles and responsibilities, as well as KPI and targets set for each
member.
c. Bring conflicts or differences in opinions into the open rather than hiding
them.
d. Understand that conflicts are natural, and it is permissible to disagree.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 51 of 117

e. Multiple opinions help to refine the problem solving and decision-making

process as more alternatives are available for consideration.
f. Focus on facts, not opinions.
As these causes are usually more apparent in the early stages of the project or
whenever there are changes in the project team composition, it is helpful to use
team-building activities to foster teamwork and co-operation in the early stages of
the project. The sense of esprit de corps fostered during project initiation phase will
augur well for the team, and help the team members to weather any conflicts that
may arise during the subsequent phases of the project.
8.5.6 Techniques for Resolving Conflicts
The prime responsibility for detecting and resolving conflicts resides with the project
manager. Typical techniques for resolving conflicts are as follows:
a. Win-or-Lose (Forcing) - struggle for dominance. An individual pursues his or
her own concerns at the other person's expense. This is a power-oriented
mode in which one uses whatever power seems appropriate to win one’s own
position.
b. Negotiation (Compromising) - each party compromise. The objective of
negotiation is to find some expedient, mutually acceptable solution that
partially satisfies both parties.
c. Problem-Solving or Win-Win (Confrontation) - pinpoint problem and
resolve it objectively. It involves an attempt to work with the other person to
find some solution that fully satisfies the concerns of both persons. It also
includes identifying the underlying concerns of the two individuals and finding
an alternative that meets both sets of concerns.
d. Avoidance (Withdrawal) - passive and stop-gap way of dealing with
problem. When a person does not pursue her/his own concerns or those of
the other person. He/she does not address the conflict, but rather sidesteps,
postpones or simply withdraws.
e. Accommodation (Smoothing) - search for common ground of agreement
while avoiding points of disagreement. This is the opposite of win-or-lose.
When accommodating, an individual neglects his/her own concerns to satisfy
the concerns of the other person. There is an element of self- sacrifice in this
mode.
In practical terms, if a conflict remains undetected, it can erupt as a crisis situation
where immediate and decisive action is required by the manager. This would
normally involve containing the damage, resolving the conflict and repairing the
damage.
8.5.7 Negotiation Skills
Good negotiation skills help project managers forge win-win strategies in resolving
conflicts that arise among the stakeholders in the project. Negotiation is a problem
solving process with the following objectives:
a. Think beyond traditional bargaining, and seek a win-win solution.
b. Focus on interests of negotiating partners, and look for points of agreement.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 52 of 117

c. Adopt an open and non-judgmental mind-set so that a trusting relationship

can be built.
d. Avoid self-limiting assumptions.
8.5.7.1 Planning for Negotiations
The following need to be considered in planning for negotiations:
a. Consider various alternatives. Rank these alternatives according to your
organization’s interests and develop fall-back plans.
b. Understand the various stakeholders in the negotiation process, in terms of
their interests, expectations and proposed alternatives.
c. Set goals for your organization, in terms of their interests, relationships and
preferred alternatives.
8.5.7.2 Conducting Negotiations
The following need to be considered in conducting negotiations:
a. Negotiate both on relationship and outcome:
• Separate people issues from the problem.
• Agree to disagree.
b. Communicate effectively during negotiation:
• Listen more than talk.
• Ask questions about your negotiating partners’ interests.
• Discuss your organization’s interests in the light of your negotiating
partners’ interests.
c. Consider your negotiating partners’ ideas:
• Do not reject these ideas.
• Treat these ideas as possible options.
• Ask hard questions, especially around objective criteria.
d. Make wise commitments:
• Be confident in what is agreed to.
• Develop action plans for follow-up.
8.5.7.3 Negotiation Style
Two factors determine the negotiation style:
• Desired outcome of the negotiation process.
• Relationship with negotiating partner(s).
These negotiation styles utilize the five conflict resolution techniques described in
section 8.5.6:
a. Avoidance (Withdrawal) - where neither outcome nor relationship are
important.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 53 of 117

b. Win-or-Lose (Forcing) - where outcome is important and relationship is not.

c. Accommodation (Smoothing) - where outcome is not important and
relationship is.
d. Negotiation (Compromising) - where both outcome and relationship are
somewhat important.
e. Problem-Solving or Win-Win (Confrontation) - where both outcome and
relationship are important.
8.5.8 Problem Solving/Decision Making Skills
Project managers need to make many decisions each day. The nature of these
decisions are varied, as they may relate to decisions on development, business,
procurement, personnel or purchasing. The decisions to solve problems usually
have multiple solutions or alternatives. Each time a decision is made to solve a
project problem, new activities are initiated or changes are made to existing activities
which lead to time, money and resources being committed. So, if a poor decision is
made, and is subsequently changed, the time and expenditure are for the most part
unrecoverable. The difficulties associated with problem solving/decision-making
include the following:
• There is no way to know all the alternatives to a problem.
• It is not easy to develop a complete set of criteria to measure the alternatives.
• Every stakeholder has a different perception of what is important.
• Evaluation information is never complete or certain.
• Problems are continually evolving and changing.
An approach to help deliver more robust problem solving/decision-making comprises
the following four steps:
a. Follow a strategy.
b. Eliminate possible uncertainties concerning resources.
c. Select a satisfactory alternative.
d. Disregard the unselected alternatives, and move forward.
With this approach, the symptoms characteristic of poor problem solving/decision-
making can be reduced. It is important that the decision has the buy-in of all
stakeholders. This ensures that all stakeholders are involved in solving the problem
resulting in decisions that stick. In a robust problem solving/decision-making
process, the role of the project manager is to facilitate and build consistency, clarity,
comprehension, communication and consensus amongst stakeholders.
Practical Tips
1. It is crucial that the project manager is able to build a team and motivate the team members. The
project manager’s mastery of project politics will inevitably determine the outcome of the project.

2. Team building activities at the start of the project are often helpful is breaking the ice and
establishing rapport amongst the team members. Maintaining a balance of work and social
activities facilitates a healthy working relationship.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 54 of 117

3. Partnering junior staff with senior staff to ensure that the necessary coaching and guidance is
provided.

4. Assignments in written form for junior staff is helpful as it gives them an official reference point for
expectations, communications and evaluation of completed tasks.

5. When working together, team dysfunctions may develop. The project manager should look out for
such signs as group think, cliques and social loafing and take appropriate action to address them.

6. The over-riding role of the project manager is to be a performance coach to forge a synergistic
team. As individual project team members develop at different speeds (form-storm-norm-perform
as illustrated in Tuckman’s evolving team development stages), there is no one-shoe-fits-all
approach apart from continual training, mentoring, coaching and confronting.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 55 of 117

9. Communications Management
This knowledge area describes the main techniques and processes associated with
effective communications with stakeholders (e.g. project members, project sponsor,
customers) during an IT project. This involves the collection and dissemination of
project information through information gathering, distribution techniques,
expectation management and performance reporting. The key topic areas are
described below.
9.1 Managing Team Communications
A Project consists of groups of people, coordinated by work processes and
agreements working together to plan, study, define, design, implement, verify,
validate and deliver all the necessary aspects of a product (and/or solutions).
These groups, called stakeholders, include:
• Development/maintenance/infrastructure teams comprising a multidisciplinary
collection of individuals performing a wide variety of tasks. This includes project
management, requirements gathering, prototyping, design, coding/programming,
installation and setup, testing, commissioning and documentation.
• Company management and administration, such as senior management, finance,
contracts department, human resource department, procurement department,
sales and marketing.
• Customer representatives, such as end-users, end-user management, quality
assurance, procurement and contracts officers.
• Teams from external organizations (such as subcontractors, consultants)
providing products and services to the project.
A project’s success relies heavily on the effectiveness of the work performed within
and between these groups. There is heavy reliance on communication mechanisms
to establish common understanding for all parties to perform their role. The typical
communication mechanisms are described below:
9.1.1 Documentation
Project documentation records the project’s processes, deliverables and milestones
for each phase of the project life cycle. These deliverables provide the essential
baselines used to control the project. They also facilitate the gathering, recording
and updating of all pertinent information needed by the various parties involved in
the project: managers, developers, administrators, users, etc. There are two broad
categories of documents that need to be created:
a. Process Documents facilitate the management and control of the
software/infrastructure process, and are significant deliverables of each
phase:
• Project initiation and planning documents (e.g. the Project Management
Plan).
• Technical planning documents (e.g. Test Plans).
• Progress reporting and control documents (e.g. Progress Report, Test
Report).

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 56 of 117

b. Product Documents specify, define or describe the software product that is

being developed or infrastructure component that is being tested.
• Technical specifications (e.g. Requirements Specification, System Design
Specification).
• User and system manuals (e.g. Installation Guide, User Guide).
• Technical reports (e.g. Feasibility Study Report).
9.1.2 Presentations
Documents provide information to the reader, but it is not possible to determine if the
reader understands them for many reasons, such as language used, complexity of
the material or lack of pre-requisite knowledge of the readers. To overcome such
problems, presentations can be used to:
• Summarize the important issues.
• Provide detailed explanations where required.
• Allow for an interactive dialogue to clarify and confirm points of contention and
misunderstanding.
• Provide a forum for the various reviewers of a document to develop a consensus
view.
• Accelerate the approval process.
9.1.3 Meetings
Project meetings are a highly effective way to achieve coordination between
individuals who work independently. They provide a forum for understanding
progress, recognizing and resolving differences of interpretation, problems in making
progress, and difficulties in understanding instructions. Such meetings can be used
by the development/maintenance team to control technical progress and with the
customers to manage their expectations.
9.1.4 Collaborative Tools
Collaborative tools are available for information exchange on project artefacts and
project status. These allows the project team to keep abreast of the latest status.
9.1.5 Confidentiality of Information
Company-in-confidence data and all personal data need to be managed carefully.
Regulatory policies such as the Personal Data Protection Act (PDPA) apply to both
project team members’ data as well as the personnel data required by the IT
systems. Permission should be sought for the release of personal data.
9.2 Managing Customer Involvement
Effective liaison between the development/maintenance team and the customer is
essential to ensure that requirements are achieved. Involving the relevant customer
in requirements definition is clearly an important step toward delivering the required
system. However, the customer’s involvement in the project must be sustained at
appropriate points throughout the project life cycle to achieve their eventual
acceptance of the completed system. Such involvement would include the following:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 57 of 117

a. Defining Requirements. An important responsibility of the

development/maintenance team is to ensure that they understand and
correctly record the customer’s needs. This requires an interactive
communication process with active listening to ensure that all requirements
are collected, defined, analysed (both within the project scope and out of
scope), verified and agreed in a controlled, structured manner. Typical
approaches to eliciting requirements include:
• Interviews – meeting with individual users to understand their perceptions
of the system’s requirements. A questionnaire would normally be used to
ensure completeness of coverage and consistency across interviews.
• Workshops – meeting with groups of users to brainstorm requirements for
the system, and achieve consensus. Diagrams, systematic workflows,
decision trees etc should be used to facilitate the discussion and recording
process.
• Iterative Prototyping – creating a series of prototypes and walking
through with users to clarify, correct, confirm the requirements. By
providing feedback on each prototype, the users gradually elaborate on
the requirements. The feedback from each review session would normally
become requirements for the next version of the prototype.
• Mapping/Blue-printing/Gap Analysis – for projects based on COTS,
conducting meetings/workshops to understand the solution’s out-of-the-
box functionalities and the gaps with respect to the must-have business
and regulatory requirements.
b. Design Process. Design can be seen as the developer’s response to the
customer’s requirements. Therefore, it is important for representatives from
relevant department to participate in the various design review processes
(such as system architecture design review, user interface design review etc).
c. Verifying and Testing the Software/System/Infrastructure. To confirm that
their requirements have been met, the customer should play an active part in
the acceptance process by:
• Participating in the preparation of the test plans to provide the specific test
scenarios and data.
• Participating in producing the acceptance plan, by agreeing acceptance
criteria and the details of acceptance tests to demonstrate that the agreed
criteria have been achieved.
• Conducting the acceptance tests, which could be in the form of a user trial,
a series of user tests or a parallel run.
• Providing feedback on the problems encountered.
d. Production of User Documentation and User Training Material. The users
will learn how to internalize, operate and use the system primarily through the
documentation and training provided to the customer. Hence, to ensure that
these provide effective guidance, the customer should be involved in their
development by:
• Participating in their design.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 58 of 117

• Undertaking document and courseware reviews.

e. Progress Meetings and Reporting. These help to build mutual
understanding and appropriately situate customer expectations. Good
practices include:
• Identifying who will attend the meetings/receive the report.
• Determining when the meetings will be held/reports will be issued and their
frequency.
• Determining the means of communication.
• For meetings, getting all involved parties to pre-book the meeting dates
and times.
9.3 Managing External Communications
If the project impacts the public or the new system is used by the public, the project
manager should collaborate closely with the organization’s public communications
department to communicate changes and manage expectations (alternatively, to
invite the organization’s public communications team to participate in the rollout
planning). This is to facilitate greater buy-in and minimize potential fallout. The
project manager should be cognizant of the communication channels to reach out to
the public, which can be categorised as follows:
a. Traditional media – Corporate website, press release and annual reports.
b. New Media – Facebook, LinkedIn, Twitter, Blogs.
9.4 Reporting Project Performance
Project progress performance reporting involves collecting and distributing project
performance information (e.g. status reports, progress measurements - earned value
metrics, forecasts). Typically such project performance reporting will follow an
established frequency and reporting standards. The use of a PMIS greatly reduces
the time required to prepare (collecting, collating, analysis, formatting) these reports.
9.5 Communicating Effectively
For project managers to communicate effectively, they should appreciate the
following issues:
a. Recognize the barriers to communications at both the individual (e.g.
personal dynamics) and organization (e.g. different goals) levels.
b. Understand that 80-90% of a project manager’s time is spent on
communications (e.g. face-to-face meetings, formal reports, informal reports,
emails, etc).
c. Recognize the need to provide timely information updates to all stakeholders
for timely decision-making.
d. Be able to use persuasion and influencing techniques by:
• Paying attention to the language they use and recognizing cultural
differences.
• Connecting with others on an emotional level by using symbols,
metaphors and stories to express messages.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 59 of 117

• Presenting hard facts and figures, and evidence of the compatibility of

stories.
• Recognizing the vital behaviours that will enable the desired change to
manifest.
Practical Tips
1. Communications management involves planning, information collection and distribution,
performance reporting and administrative closure.

2. The setting up of communication channels within and without the project teams, include
project managers and client’s management interface, definition of reporting structures, project
team/clients’ interface, identification of liaison or coordinating parties, definition of documentation
standards, version control standards, lead time for review and approval, escalation processes etc.

3. Project managers are judged by their ability to persuade and influence stakeholders for a win-win
outcome. They need to learn to deliver “bad news” and have the courage to say “NO” for the good
of the project.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 60 of 117

10. Risk Management

This knowledge area describes the main techniques and processes for conducting
risk management including the identification, assessment, planning and monitoring
of risks of an IT project. The key topic areas are described below.
10.1 Principles of Risk
A risk is a possible future event with a probability of occurrence and a potential for
loss. Many problems that arise in software/systems/infrastructure development
efforts could have been earlier identified as risks by someone on the project. Caught
in time, risks can be avoided, negated or have their impacts reduced.
10.1.1 Project Risk Categories
The four main categories of project risks are:
a. Technical, quality or performance risks. Technical risks are associated
with new, unproven, or complex technologies being used on the project.
Changes to the technology during the project implementation can also be a
risk.
Quality risks are quality expectations of impractical quality and performance
given the current processes. Changes to industry quality standards during the
project can also be included in this category.
b. Project management risks. These risks deal with faults in the management
of the project: the unsuccessful allocation of time, resources, and scheduling,
unacceptable work results (low-quality work), and poor project management
as a whole.
c. Organisational risks. The performing organisation can contribute to the
project’s risks through unreasonable cost, time, and scope expectations; poor
project prioritization; inadequate funding or the disruption of funding; and
competition with other projects for internal resources.
d. External risks. These risks are outside the control of the project manager but
directly affect the project: subcontractors and vendor issues (e.g. key project
member resigned), external partner issues, loss of customer’s information,
legal issues, labour issues, a change in organisational policies or priorities,
and natural disasters.
10.1.2 Major Technical Risks
The major technical risks associated with an IT project are as follows:
a. Requirements risks – due to problems concerning the specification of the
requirements (incomplete, unclear etc), or the specific nature of the
requirements (infeasible, unprecedented, unstable etc).
b. Design risks – due to the degree of technical difficulty associated with
designing the system (e.g. the problem may not have a tried and tested
solution or the system requires complex integration of different technologies
and solutions) or the severe constraints within which the design must operate
(e.g. demanding performance levels required on low end hardware).
c. Development risks – due to problems concerning the development process
caused by a lack of formality (absence of deliverables and standards), a lack

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 61 of 117

of familiarity with the tool, techniques and methods and/or poor process
control (lack of, or ineffective, quality control and progress control
mechanisms). While agile software development methodology has been
increasingly been adopted by organisations to improve time to market for
software delivery, some risk may also arise from lack of management support
and project team acceptance and familiarity with the agile methodology. A
successful agile methodology adoption requires both a culture and a mind-set
change for both development team members and business users who are
used to the traditional Waterfall methodology.
10.1.3 Key Risk Concepts
The key concepts associated with IT risk management are as follows:
a. Probability – a quantitative estimate of the likelihood a specific event will
occur during a specific time.
b. Impact – a quantitative estimate of the loss caused by a future event, if it
does occur.
c. Exposure – the product of probability and impact for the purpose of risk
prioritization (also known as risk score and risk index).
d. Mitigation – anything that reduces ones exposure to the risk, such as
insurance or contingency planning.
10.2 Risk Management Process
Risk management is informed decision making under conditions of uncertainty i.e.
making informed decisions by consciously assessing what can go wrong and the
resulting impact. Such decision-making can be facilitated by developing a risk
management strategy and assigning risk contingencies that will prevent the
identified risks from becoming a problem or limit their impact if they do occur. These
are important aspects of project planning and control, and significantly influence
most of the planning and control activities (such as estimating, scheduling etc).
The risk management process is used to ensure that all risks identified on a project
are appropriately documented, assessed, mitigated and monitored. The risk
management process typically involves the following four phases:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 62 of 117

These are described in the following subsections.

10.2.1 Identify Risk
The first stage of the risk management process involves identifying the risks of a
project. This should concentrate on the identification of hazards, threats and
vulnerabilities that could negatively affect the project. The following sources of risk
should be considered:
a. Requirements specification. Are the requirements complete and
unambiguous specified? Is the project scope compatible with the project’s
effort, cost and schedule budgets? Are the requirements stable?
b. Project environment. Will the project be affected by the surrounding physical
(such as weather) or political environment (such as labour strikes, political
changes and elections)?
c. Project management plan. Does the plan cover all aspects of the
requirement? Does the WBS include all aspects of the work to be done?
d. Technology. Is required architecture available? Is required support software
available? Are proposed methodologies and development systems tried and
proven? Is help available? Has the development methodology been applied to
similar systems? Is staff properly trained for the project?
e. Complexity. Is the project domain and proposed development technology
difficult to understand? Is the software likely to require complex programming
logic? Are there extensive interfaces with other systems?
f. Procurement. Are there likely to be any delays in the delivery of procured
critical hardware and software, including development tools?
To identify the risks that pertain to a specific project, review sessions should be held
focusing on the sources above. Questionnaires or checklists are typically used to
guide these reviews. Participants should include the project team members,
representatives from the customer and experts in the project’s domain and proposed
development technology. Other techniques to identify risks include seeking the
opinions of SMEs and reviewing the known risks in past projects that were tracked
by a project management tool and captured in the organisation’s knowledge base.
All risks identified should be captured in a risk register.
10.2.2 Assess Risk
To determine the significance to the project of each identified risk, the following
assessment is required to be performed:
a. Assess the likelihood or probability of the risk occurring i.e. how likely is a
future problem to occur?
b. Assess the consequences or impact of the risk, if it occurs. Ideally, the impact
should be quantified in terms of the cost (in terms of manpower effort and
schedule) of resolving the problem.
c. Determine the time frame in which the risk is likely to occur.
Based on these three dimensions of the assessment, the identified risks can be
prioritized, and decisions can be made as to which risks will be explicitly addressed
in the project’s plans and other strategies. Risks should be assessed qualitatively

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 63 of 117

first, but if the need arises then quantitatively. Risk quantification extends the value
of the understanding, documenting and reporting on risks, by attempting to assign
each risk to an easily understood numerical scale. These assist in realizing and
focusing on the true impact of each risk, and in the prioritization of the risk
prevention and mitigation activities identified. The following two parameters for each
risk should be quantified:
a. Impact. This is an estimate of the overall scale of the impact following an
occurrence of each risk. The following is an example of a 5-point scale:
5 Critical Threatens success of the project
4 High Significant disruption to project schedule,
cost, and products over the medium and
long terms
3 Medium Progress disrupted with large extensions to
schedule and cost, across short and medium
terms
2 Low Progress disrupted with manageable
extensions to schedule and cost, across
short and medium terms
1 Marginal Slight exposure

b. Probability. This is an assessment of the likelihood of occurrence of each

risk. The following is an example of a 5-point scale:
5 Extremely likely occurrence
4 Very probable occurrence
3 Probable occurrence
2 Possible occurrence
1 Unlikely occurrence

The risk exposure rating is calculated for each risk as follows:

Risk Exposure = Impact x Probability
The following shows an example of a risk assessment matrix:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 64 of 117

The following shows an example of the risk exposure rating categorized into Low,
Medium and High:

Risk Exposure Rating Value Range Risk Category

15 to 25 (RED) High

6 to 14 (YELLOW) Medium

1 to 5 (GREEN) Low

10.2.3 Mitigate Risk

Having determined the important risks, the next stage of the risk management
process is to determine the most effective strategy to mitigate each risk. Possible
risk strategies include:
a. Acceptance - conscious decision to live with the risk, having determined that
the mitigation effort would be more expensive than the problem.
b. Avoidance - eliminate the risk altogether in order to avoid a lose-lose
situation (e.g. decision not to bid on a request for proposal).
c. Protection - employ redundancy to mitigate the risk (e.g. two systems
backing up each other).
d. Reduction - decrease the risk through mitigation, prevention and anticipation.
Reduction can be applied to either the probability or the consequences.
e. Research - investigate and obtain more information.
f. Reserves - use contingency funds and build in schedule slack to cover
uncertainties.
g. Transfer - shift the risk to another person or group that is better able to act
upon it.
h. Contingency plans – an alternative course of action that would be taken if
the risk actually occurs (e.g. renting hardware if the purchased hardware is
not delivered on time).
For each risk, there is likely to be more than one possible mitigation strategy. Hence
each strategy should be defined in terms of effort/cost, schedule and benefits (in
terms of risk reduction). A set of strategies would then be selected that achieved the
greatest risk reduction for the lowest increase in budget and least delay to the
schedule. The selected strategies could be documented in a risk management plan
or as part of the project management plan.
Risks which are deemed to have a high impact on the project will be updated and
managed actively with a mitigation plan. However, there may also be risks for which
the impact and/or likelihood of happening is not high enough to justify committing
resources to active mitigation and/or prevention activities, but are important enough
to warrant monitoring and planning. In these cases, the project manager would work
with the stakeholders to agree ahead of time on the actions to take should any of
these risks become a reality.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 65 of 117

The decision to take action on risk mitigation actions is often initiated based on the
risk exposure rating. The following is an example of a risk mitigation plan:

Risk Exposure Rating Mitigation Actions

15 to 25 (RED) Risk has a Risk Mitigation owner. Risk Mitigation

Actions are incorporated into the work plan as
necessary, are in progress and are actively
monitored.

6 to 14 (YELLOW) Risk is assigned a Risk Mitigation owner. Risk

Mitigation Actions are documented, and the Risk
Mitigation owner actively monitors the risk
exposure.

1 to 5 (GREEN) No active Mitigation Actions in process.

10.2.4 Monitor Risk

Having put in place a risk mitigation strategy, it can then be enacted in the same way
as other aspects of the project’s plans, through the regular project control activities.
In particular, risks should be appraised during progress reviews, and planned
mitigation strategies should be initiated as required. Risk mitigation strategies may
need to change due to changes in the project’s progress, such as:
a. A new risk appears.
b. An existing risk disappears.
c. Changes to the project’s risk exposure.
d. A mitigation plan succeeds or fails.
e. A contingency plan becomes infeasible.
Hence, progress reviews should also monitor the factors/triggers that affect the risks
and the risk mitigation strategy, and make timely changes to the plan.
10.3 Disaster Recovery and Business Continuity Planning
With the increase in reliance on complex IT systems and operations, there is also a
corresponding increase in risks of managing and implementing complex IT projects.
The following lists some of the general threats to IT systems and data:
a. Data confidentiality.
b. Data integrity.
c. Data loss.
d. Data corruption.
e. Fraud.
f. Endpoint security.
g. Virus infection / Cyber attacks.
h. Hardware and software failures.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 66 of 117

i. Spam, scams and phishing.

j. Hackers.
k. Denial-of-service attacks.
l. Password thefts.
An IT incident can be confined to the IT infrastructure of an organization, such as a
denial-of-service attack that aims to disrupt business. An IT incident can also be part
of a larger business crisis, such as widespread damage to servers and networks due
to a fire or a natural disaster.
Organizations often have a plan in place that is aimed at helping the business
survive and recover from a crisis. This plan is usually referred to as an IT disaster
recovery (DR) plan” or a business continuity (BC) plan, and typically defines critical
business activities, risks, response plans and recovery procedures. For companies
where IT plays an important role, the DR/BC plan would have more focus and
priority on systems recovery, in parallel with strategies to recover business activities
in the shortest possible time.
10.4 Regulatory Compliance
The evolving fields of mobile computing, cloud computing, analytics (Big data),
social media and payment technology are characterised by risks associated with
privacy and security. Risks will vary depending on the sensitivity of the data to be
stored or processed and how the chosen service provider has implemented their
specific services.
To manage these risks, there are also regulations and standards that organisations
need to comply with. It is important for project managers to fully understand the
scope and implications of the government and industry regulations and standards
and the associated obligations for organisations. The following are examples of
these regulations and standards:
a. The Personal Data Protection Act 2012 (PDPA 2012), which was established
to govern the way organisations in Singapore collect, use, disclose and
process personal data.1
b. To better address existing and emerging technology risks faced by financial
institutions, the Monetary Authority of Singapore (MAS) issued the
Technology Risk Management Guidelines (TRM Guidelines) and Technology
Risk Management Notices (TRM Notice) on 21 June 2013.
c. Organizations that transmit, store and process credit card information face
significant security risks. The Payment Card Industry Data Security Standard
(PCI DSS) was created to help these organizations secure their operating
environments against hacking, credit card fraud and other security
vulnerabilities.
d. US FDA regulations for medical software.

1
Personal data refers to data, whether true or not, about an individual who can be identified from that data;

or from that data and other information to which the organisation has or is likely to have access.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 67 of 117

Practical Tips
1. Every stakeholder can raise risks but the project manager should evaluate all risks and assign
them to the parties best positioned to mitigate e.g. technology risks to the chief technology officer
(CTO), business risks to project sponsor, etc.

2. Risks should be captured in risk register and reviewed on a regular basis.

3. Risk review activities must be planned into the project schedule.

4. The project manager must be aware of the scope and implications of the government and industry
regulations and the associated obligations for organizations (e.g. the PDPA, PCI DSS, MAS TRM
guidelines etc).

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 68 of 117

11. Procurement Management

This knowledge area describes the main techniques and processes associated with
project procurement which includes the purchase of the both IT products and
services.
The nature of project implementation approaches have evolved to emphasize project
procurement strategies that involve the use of external agents requiring a
specialized skill set to manage vendors and subcontractors. Detailed considerations
specific to IT outsourcing or sub-contracting are described in detail in the
Certification in Outsourcing Management for IT Body of Knowledge (COMIT BOK).
In addition to the outsourcing and sub-contracting of IT products and services,
project procurements will typically include:
a. Software licensing (e.g. MS Office etc).
b. Packaged software solutions.
c. Turn-key solutions.
d. IT Infrastructure procurement.
Regardless of the type of project procurement, a comprehensive selection process
must be carried out to ensure that the selected IT products and services are suitable
and meet the organization’s requirements. There must be a strategy for evaluating
and selecting the most appropriate solution – similar to evaluating and selecting IT
Contractors as detailed in the COMIT BOK. In addition, a structured governance (for
both IT and data) and risk management strategy are critical contributors to a
successful evaluation and selection process.
11.1 IT Outsourcing and Subcontracting
Outsourcing is defined as the use of external agents to perform one or more
organisational activities, and involves contracts that specify a service that the market
is to provide. A variation on this is Insourcing, which involves contracts that call for
the market to provide resources to be deployed under the buyer’s management and
control.
11.1.1 Why Outsource or Subcontract?
The outsourcing and subcontracting of all, or parts, of IT functions or individual IT
projects has gradually become established as an effective IT strategy. This trend to
outsource has been substantially influenced by the following factors:
a. Perceived lack of cost effectiveness of the IT function - high costs incurred by
the IT function compared with low quality of the service provided.
b. Perceived poor performance of the IT function, in terms of low productivity,
lack of proficiency in the latest technologies and problematic relationships
with user communities.
c. Changes in the focus of organisations to concentrate on their core
competencies, and to de-emphasise supporting functions such as IT.
d. Desire to reduce IT investment, while maintaining and improving service
levels, by selecting the most cost effective external service provider rather
than the costly internal alternative. In so doing, fixed internal IT costs can be

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 69 of 117

transformed into variable performance-based expenditure, and the

organisation’s IT assets can be liquefied while they continue to receive the
required business value from IT.
11.1.2 IT Outsourcing and Subcontracting Risks
IT outsourcing and subcontracting can deliver benefits to address the issues listed
above. However, to enjoy these benefits, several risks may be incurred, including:
a. Irreversibility of outsourcing – having broken up the internal IT function, it
may be a difficult task to reconstitute it, finding all the necessary application-
specific and domain-specific expertise. However, this can be managed
through the implementation of an effective transition management plan.
b. Leakage in confidential information – vendors taking over the management
of the organisation’s IT operations could learn how the company uses IT for
their competitive advantage, and then use this knowledge to set-up similar
applications for the company’s competitors. However, the disclosure of
confidential information can be addressed through the enforcement of non-
disclosure agreements.
c. Dependence on a specific vendor – once a vendor gains the application-
specific and domain-specific expertise to manage an organisation’s IT
operations, it can be difficult to replace them with a similarly qualified
alternative. This will leave the organisation open to price increases by the
entrenched vendor, as well as reduced operational efficiency if the
entrenched vendor has to be replaced. However, price escalation and
efficiency degradation can be managed through the effective review of the
vendor’s execution and delivery plans.
11.1.3 IT Outsourcing and Subcontracting Approaches
To determine the appropriate outsourcing strategy for each aspect of an
organisation’s IT function, business, technical and economic factors need to be
considered. Appropriate strategies associated with each of these factors are
described below:
a. Business Factors. When considering the effect on business operations and
business positioning, the following strategies can be considered:
• In Source – use insourcing to retain control of an activity that is a strategic
differentiator
• Best Source - use a best .source for an activity that is a strategic
commodity (quality is important but over-performance is not rewarded).
• Out Source - useful commodities are prime candidates for outsourcing
(maximizing economic benefits).
• Eliminate - remove the unnecessary differentiating feature and outsource
the resulting useful commodity (a useful differentiator is a commodity with
non-strategic features).
b. Technical Factors. When considering the effect of IT integration and
technology maturity risks, the following strategies can be considered:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 70 of 117

• Buy In - when the technology maturity risk and the IT integration risk are
both low, then it is appropriate to buy in the required resources from a
leading supplier.
• Preferred Supplier - when the technology maturity risk is low but the IT
integration risk is high, then it is appropriate to link up with a preferred
supplier who is judged to have the breadth and staying power in the long
term.
• Contract Out - when the technology maturity risk is high but the IT
integration risk is low, then it is appropriate to contract out the required
services while focusing in-house on strategic and innovative applications.
• Strategic Alliance - when the technology maturity risk and the IT
integration risk are both high, then it is appropriate to forge a strategic
partnership with one or more reputed suppliers.
c. Economic Factors. When considering the contractual models available in
the market, the following strategies can be considered:
• Contract Out – this is suitable when there is a clearly defined need for a
particular end product or service. In such an arrangement, the vendor is
required to deliver the contracted results at contracted price and terms.
The customer is required to provide full specifications at the start of the
project, and any subsequent amendments may require renegotiation of the
price and terms.
• Buy In – in this arrangement, the customer specifies the resources
required and retains the responsibility for deploying them. The contract
would be based on a fixed rate per time period for each resource
• Preferred Supplier – this involves adopting a close, long term buyer-
supplier relationship. This leads to increased mutual understanding and
commitment. In this case, there is an overall service contract defining the
domain of the services that can be provided, general terms and rates.
Then each actual customer request is separately contracted based on
these terms
• Strategic Alliance – this involves developing a long-term business
agreement whereby the customer and vendor agree to share the relevant
risks and rewards.
11.1.4 Evaluating and Selecting IT Contractors
Having decided upon the part of the IT function to outsource and the appropriate
outsourcing strategy, the next step is to select contractors to perform the required
services. The details of the evaluation and selection process are described in the
COMIT BOK.
11.1.5 Managing and Monitoring Contracts and Contractors
The responsibility of the project manager is to manage the contract, to ensure
effective execution and delivery of the project. This involves performing the following
activities:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 71 of 117

11.1.5.1 Reviewing Progress and Performance

The performance expectations of the contractor is defined by the SLAs. Using the
SLAs, the project manager should monitor and manage the contractor at regular
intervals by reviewing progress reports and attending regular progress meetings.
11.1.5.2 Dealing with Non-Conformance to the Contract
Non-conformance usually occurs when the contractor fails to meet the service levels
stipulated in the contract. The typical process for handling a non-conformance would
be as follows:
a. Confirm the validity of the non-conformance. To do this, the project manager
should ensure that the customer organisation has fulfilled its contractual
obligations, and that there are no other mitigating circumstances such as
unclear contractual requirements, or change requests made by the customer
organisation that may have negatively impacted the vendor’s ability to meet
the agreed service levels.
b. Give written notice to the vendor of the valid non-conformance that has been
identified, and request them to submit a plan for their corrective action.
c. Check their progress in resolving the problem during regular progress
meetings with the vendor.
d. Escalate the problem if there is no, or inadequate, response from the vendor.
Initially, this would typically involve raising the issue with the organisation’s
senior management, who might be able to resolve the problem through direct
negotiation with their counterparts in vendor organisation. However, if this
less formal approach fails, then, as a final resort, the escalation procedure in
the contact would be enacted, which might involve using penalty clauses,
mediation or arbitration.
11.1.5.3 Dealing with Contract Changes
It is inevitable that the contract will not cover all aspects of the services required by
the users, and that changes will be required. Typical reasons for such changes
would include:
a. Change in the customer’s business environment.
b. Need for further functionality/services not addressed in current contract.
c. Changes in the customer’s technical environment or infrastructure.
d. Regulatory/external change affecting the customer’s business/operations.
The customer’s project manager would be responsible for managing these changes
when they occur. A typical change management process would be:
a. The customer’s project manager would define the change in collaboration
with appropriate user department managers.
b. The vendor would determine the feasibility and cost of the change. This would
typically require a formal proposal to be issued by the vendor.
c. The customer’s project manager would review the proposal, and negotiate
with the vendor until acceptable terms are agreed.
d. The customer’s project manager would obtain senior management approval.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 72 of 117

e. The customer’s project manager would then arrange for the change to be
implemented, which would involve:
• Changing contract and obtaining approvals from the customer and vendor
management.
• Implementation of the actual change in service by the vendor.
• Review of progress by the customer’s project manager at the regular
progress meetings.
11.1.6 Contract Closure
When a project is completed, the project manager should close out all contractual
issues and obligations. The project manager should also ensure all project artefacts
are completed and confidential materials are handed over.
For pre-mature contract termination, apart from legal issues, there are various
practical issues to consider, such as:
a. Business Implications – e.g. would the termination affect the customer
organisation’s image or credibility?
b. Operational Implications – e.g. what is the cost of setting-up the
infrastructure for your system? What is the required lead-time? What is the
effect on operational efficiency?
c. Turnback Effort – e.g. what effort would be required to collect the customer’s
hardware, software, date etc. from the vendor, and re-install at the customer’s
premises?
11.2 Software Licenses
This section discusses software licensing with respect to project procurement. There
are two broad categories of software licenses.
a. Open-source software licenses. These licenses allow software to be freely
used, modified and shared. In addition, they allow programmers and
developers to review, modify and customize the software to meet their
specific requirements. Such licenses must go through the Open Source
Initiative (OSI) license review process and must meet the OSI definition of an
open-source license before they can be categorized accordingly. Most open-
source licenses are available free-of-charge. However, some require fee
payment.
b. Traditional software licenses. For these licenses, a fee is paid to the
principal software vendor to use the software. Some such licenses allow or
provide the licensee with the necessary rights to modify or re-use the existing
components. However, there are also licenses that restrict or do not allow
updating or changing of the source code.
It is normal practice for principal software vendors to release changes and updates
to their software, typically to address new functional requirements and address
security threats. When appropriate, licensed software should be purchased with
ongoing authorized vendor support and maintenance to maintain its currency.
Maintaining this currency provides the licensee with the flexibility and options to
leverage on changes and updates.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 73 of 117

11.3 Packaged Solutions

Packaged solutions are also known as out-of-the-box solutions or COTS. Most
organizations tend to have specific business and IT requirements. Hence, not
surprisingly, standardized packaged solutions might not be able to meet all of an
organization’s requirements. Therefore, a comprehensive strategy must be in place
to facilitate the selection process to ensure their suitability to meet most of the
organization’s requirements. In addition, requirements for integrating these solutions
with other existing systems must also be considered resulting in more complex
system integration. A possible mitigation might be to include the provision of open
interfaces as an important evaluation criteria.
In some cases, the licensing conditions of such solutions may be restrictive with
respect to their use and customization. It may result in an untenable situation where
the vendor or supplier has the ability to exert undue control and influence over the
organization. A structured governance (for both IT and data) and risk management
strategy will provide some mitigation but will not be able to eliminate this issue.
11.4 Turn-key Solutions
In general, any customer requirements can be developed from scratch or integrated
from existing components by software houses or system integrators. Such turn-key
solutions tend to be complex and highly customized to meet the organization’s
specific requirements. They definitely require a structured governance (for both IT
and data) and risk management strategy to be in place to ensure a successful
evaluation and selection process. Other areas that require special attention include:
a. User acceptance testing.
b. Knowledge transfer and training.
c. Appropriate documentation – the availability of documentation in both hard
and soft copies.
d. Support and maintenance.
e. Contracts management including turn-back.
f. Data security.
11.5 IT Infrastructure Procurement
IT infrastructure procurement includes cloud services models such as SAAS; (IAAS
and PAAS. The procurement of such IT infrastructure requires a comprehensive
strategy to be in place to facilitate its selection and ensure its suitability to meet most
of the organization’s requirements. As described above, a structured governance
(for both IT and data) and risk management strategy is critical to ensure a successful
evaluation and selection process.
The cloud deployment strategy adopted will depend of the organization and its types
of business. Generally, there are three types of deployment:
a. Public cloud.
b. Private cloud.
c. Hybrid cloud.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 74 of 117

The choice of deployment should be based on the comprehensive evaluation and

selection process that normally will include risk management; contracts; turn-back
and data security as important criteria. These will facilitate the choice between the
flexibility of the cloud deployment and data security.
Practical Tips
1. Procurement management involves planning, conducting, administering and closing procurement
activities (management of the procurement of resources, including hardware, software,
human resources, facilities, and sub-contracting, etc).

2. The whole process includes planning, budgeting, specification, solicitation, evaluation, selection,
negotiation, administration etc.

3. It is critical to involve the project managers at the start of the procurement process so as to
enable them to engage and build relationship with participating vendors. As more than 50% of
sampled contracts are problematic, the recommended approach is to harness win-win
relationships through a vendor management office (VMO) mechanism that is based on KPIs.
These indicators are quality benchmarks in nature involving both penalties and incentives.

4. Risk management process and practices must be in place.

5. Both IT and data governance strategies and policies are critical components. These must also be
in place. They facilitate the procurement process, but also ensure alignment of IT services with
the overall mission, vision and business strategy of the organization.

6. Develop a common framework that can be used to facilitate the evaluation and selection process
required. This framework should be customizable and be able to achieve a baseline and
quantitative scoring of the all critical factors or requirements.

7. As part of the evaluation and selection process, where relevant and possible, always leverage the
use of proof of concept testing. It providers the users an opportunity to use the system in order to
find out more of the system to be procured and will also allow the users to analyse and rationalize
their requirements.

8. It is critical to understand the user requirements. In addition to the use of the proof of concept, the
requirements gathering process can be facilitated through the conduct of requirements gathering
workshops, brain storming etc.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 75 of 117

12. Stakeholders Management

IT projects are conducted to solve business problems which have become
increasingly complex due to their cross-functional and cross-organizational nature.
Effective project managers build alliances to support organizations and upper
management to assure organizational visibility, priority, resource availability and
overall support to the multifunctional activities of the project. It is common for these
cross-functional and/or cross-organizational project teams to have differing priorities,
and often the priorities of their “home” departments/organizations conflict with the
project priorities.
The project manager is required to manage the diversity of stakeholders and their
interests in the project, including individual nuances that can affect project risk.
Stakeholder management covers the processes required to identify the people,
groups and organizations, analyse their expectations and develop management
strategies for effective engagement. It also draws upon the interpersonal skills of a
project manager to build trust, resolve conflict and effectively communicate and his
management skills to influence others, negotiate agreements, and facilitate
consensus towards project objectives.
12.1 The Stakeholder
Stakeholders are individuals or groups, who may have interest in the project or its
outcome, rights or ownership affected by the project, can contribute to the outcome
of the project or can impact or impacted by the outcome of the project. The typical
stakeholders can be internal to the organization i.e. project team, management, or
outside the organization e.g. regulatory bodies, public and press:

Social Economic
Cultural and Financial

Functional Top
Managers Management
Public
Suppliers, Project Service and
Vendors, Team and Press
Contractors Support

Staff and
Other
Personnel
Project
managersEnvironmental
Regulatory and Legal
Agencies

From Organizing Projects for Success by VK Verma

12.2 Processes in Stakeholder Management

Processes in stakeholder management provide a structure and framework for better
analysis, planning, and monitoring:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 76 of 117

a. Identify and analyse project stakeholders. This involves identifying the

stakeholders who will have impact on or be impacted by the project and
analysing their underlying interests, involvement, interdependencies,
importance and influence on project success. The stakeholder analysis
matrix is a tool to segment them so that the appropriate level of attention can
be given to each category of stakeholders. As there can be many
stakeholders in a project and only limited time and resources, prioritization is
very important. There are several types of stakeholder analysis matrices that
can be used. The more common examples include the power/interest grid
and the influence/impact grid.
b. Plan for engagement. This involves developing management strategies to
effectively engage stakeholders throughout the project, based on the analysis
of their needs and the desired levels of engagement.
c. Manage stakeholder engagement. This involves communicating and
working with stakeholders to meet needs and expectations, which heavily
relies on the interpersonal and management skills of the project manager.
d. Control Stakeholder Engagement. This involves monitoring the stakeholder
relationships and adjusting the plans for engagement as required.
12.3 Managing Stakeholder Relationships
Based on the stakeholders in the project, typical relationships in the project are:
• Project team and sponsor/management.
• Project manager and project team.
• Project team and user representatives.
• Project team with hardware/software vendors.
• Client and vendor.
• Other external relationships e.g. Company with Regulatory bodies or public and
press.
Each relationship should be managed based on the importance of the stakeholder
with respect to the project success, goals, needs of the stakeholder, and the
decision making authority and role of the stakeholder. The roles and responsibilities
of each stakeholder need to be clear and agreed to and the stakeholder must be
educated on what is required from him.
12.3.1 Principles of Relationship Management
Regardless of the relationship, several fundamental principles for managing
relationships apply:
a. Maintain fairness and confidentiality.
b. Maintain honesty and openness.
c. Provide efficiency and effectiveness.
d. Maintain professionalism.
e. Manage cultural differences.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 77 of 117

The key to achieving the above principles is to practice good communication.

Consistent communication throughout the management levels reduces differences in
perspectives which may mask problems in the relationships. Easy accessibility
keeps lines of communication open, facilitates information exchange and builds
trust. Frequent communications in general help avoid conflicts, facilitate solutions to
problems, reduce uncertainty levels, and manage expectations by minimizing
dissatisfaction.
12.3.2 Building Client-Vendor Relationships
Developing an effective long-term relationship with clients/customers, is dependent
on the success of the projects undertaken where both parties work together to meet
the requirements of the business. Relationship management involves setting up
effective reporting arrangements; it also involves the promotion of attitudes and
behaviour that encourage mutual success. It is important to draw the distinction
between:
a. Formal reporting and management arrangements, which is governance.
b. Soft issues facilitated by informal communications and often related to cultural
aspects.
Relationship management is important as major contracts typically involve a high
degree of dependence between the two parties. The success of the
client/customer’s projects depends heavily on the successful completion of the
portion contracted out to the vendor. A relationship needs to be fostered that is
characterized by mutually agreed expectations. This involves the delivery of services
that meet client/customer requirements and commercial arrangements that are
acceptable to both parties. For example, offering clients/customers value for money
and at the same time adequate profit to the vendor. In addition to such contractual
and commercial aspects, the relationship between the parties such as the way they
regard each other and the way in which the relationship operates, is important to
making a success of the contractual arrangement.
12.3.3 Assessing the Relationship
Assessing the relationship with regard to the intent and objectives, provides a means
of improving aspects of the working relationship and management processes. This
will be valuable in highlighting aspects that are perceived to be working well and
those that require attention. Such assessment factors are largely subjective but are
typically perceptions of how each party sees the relationship that matter. To move
forward in the relationship, it needs both parties to be involved in the following:
a. A willingness to learn from mistakes.
b. Being open about causes of conflict or poor performance.
c. Being prepared to agree counter measures to help towards improving the
relationship over time.
In today’s world of complex outsourcing, success will depend on investing in and
managing the relationship. Relationship needs time to mature. This process requires
vigilance and hard work, but the rewards to the committed client/customer and
vendor are well worth the effort.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 78 of 117

12.3.4 Managing Client - Vendor Relationships in Complex Projects

Client and vendor relationships in complex large scale projects involve different
levels of relationship that operate in the organization. The contractual relationships
generally set out the management structures and formal communication channels
that will be put in place. Such partnership relationships go beyond the sphere of the
project and will require the following:
a. Setting and managing strategic direction.
b. Identifying opportunities for innovation.
c. Agreeing and implementing policies.
The basis of the partnership’s overall strategy should be set out in the form of a
framework of principles, a non-binding partnering agreement or a simple mission
statement, which determines the aims, objectives and long-term goals of the
relationship. These should identify the benefits of the relationship to both the
client/customer and the vendor.
Part of the role of senior managers must be to ensure that long and short-term
issues are kept in balance: that short-term requirements and problems are given
proper attention but not to the exclusion of the strategic development of the
relationship.
Practical Tips
1. Client-vendor relationship management goes beyond the project level, but is necessary for the
success of the project. When there is mutual trust and respect on a management level, the long
term relationship matters as much as the individual project success.

2. Vendor-client relationships involve developing common objectives and mission with the client
management, promoting and understanding of strategies and project plans employed,
developing relationship with clients in planning, issues resolution, quality assurance and control.

3. The proven ability to value-add to the client in a transparent manner to deliver the desired
outcome is a winning formula for repeat/referral business.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 79 of 117

13. Managing Programmes

This knowledge area describes the management of programmes to ensure that
candidates are capable of undertaking IT projects that are considered complex. A
complex project is one that has many varied but interrelated parts. Project
management researchers and practitioners also speak of “project complexity” as a
concept for measuring the differentiation and interdependency of the parts in a
project. In addition, the concept is used in the following contexts:
a. Technological complexity – which relates to the difficulty of task
performance and is usually dealt with as an aspect of the planning process in
project management.
b. Organisational complexity – which is concerned with the functions of a
project organisational structure.
This section specifically addresses organisational complexity and, in particular,
issues that are pertinent to the following types of project organisational structures:
a. Managing multiple projects.
b. Managing cross-functional teams.
c. Managing geographically dispersed teams.
Since project managers who lead complex projects in general have to contend with
problems that are of a behavioural nature, this section also takes into account the
important area of change management.
In managing complex projects or a broader IT-enabled business transformation
program, it is not unusual to find that the requisite capabilities are not entirely
encapsulated within the organization. One has to work with business partners,
suppliers and customers in the value chain, as well as with key technology
providers. In so doing, another aspect of resource management concerns the use of
an appropriate business model to finance these collaborations. Full ownership via
outright purchase/ complete funding provides an organization with the fullest control,
but is also the most costly. Organisations will increasingly want to consider various
alternatives to financing such technology ventures.
13.1 Managing a Programme with Multiple Projects
The management of multiple related projects, also known as programme
management, can be defined as a group of projects that are managed in a
coordinated way to obtain benefits not available from managing them individually.
Most organisations that depend on the accomplishment of projects to create new
products, enhance profits or improve business processes do so with shared
resources that must be managed in a coordinated way. In such endeavours,
proficiency in managing single projects individually without proactively dealing with
the interactions between them is unlikely to assure the attainment of the goals of the
organisation.
13.1.1 Success Factors
Various factors contribute to the success of programme management which include
the following:
a. Overall direction and leadership responsibility must rest with one individual.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 80 of 117

b. Active stakeholder management.

c. Clear vision of the required change and how success will be measured.
d. Active coordination of programme components, the relationship with other
programmes and the interface with business strategy.
e. Clearly assigned responsibility for the delivery of business benefits.
f. The availability of appropriate personnel with relevant skills and experience to
set up, manage and deliver the programme.
g. Appropriate program management and support processes are in place.
13.1.2 Challenges
Project managers face many challenges in programme management which include
the following:
a. Inadequate visibility on the detail being performed by project teams e.g.
developers, testers, etc.
b. Tight deadlines do not allow adequate time to attend to meetings and to track
tasks and milestones.
c. Managing multiple risks and resolving multiple issues.
d. Lack of experience in juggling multiple tasks and meetings.
e. Limited resources within the resource pool.
f. Conflicting priorities among projects.
g. Integration of all projects when their target dates are not always clear.
h. Communications among too many individuals affecting performance.
13.1.3 Programme Management Organisation Structure
The organisation structure for managing a programme should address the following
roles.
a. Programme sponsorship. A programme requires sponsorship from the most
senior executives of the organisation or group of organisations committed to it
to ensure support of the business case and its fit with organisational
objectives. Sponsorship also includes senior management support for the
changes introduced by the programme and commitment to achieve the
required outcomes.
b. Programme management. There are two primary roles for managing a
programme:
• The programme director who provides overall leadership and has ultimate
responsibility for the successful delivery of the programme.
• The programme manager who carries the responsibility for operational
aspects of the programme and for ensuring they are focused on delivery of
the required deliverables
c. Programme support. For most programmes, a programme support office
should be established to assist with the management of programme
information, i.e. budget control, status reports, programme documentation.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 81 of 117

13.1.4 Programme Planning

In programme management the planning task is not simply project planning on a
larger scale, but requires an overall management of quality, risk communications
and benefits whilst reconciling project objectives with overall programme goals.
Programme planning should take into consideration the following:
a. Benefits management. This involves identifying, optimizing and tracking the
expected benefits from business change to ensure that they are achieved.
b. Stakeholder management. Programme success relies on co-operative
contributions and support from all involved. A continuing and two-way
approach to communications is essential between the programme and its
stakeholders to secure commitment and maintain momentum.
c. Issues management and risk management. The programme must have a
clear strategy covering how issues will be handled, and in particular, how risks
will be identified, monitored and managed throughout the running of the
programme.
d. Quality management. This ensures that the deliverables from the
programme are fit for purpose and are delivered within an overall quality
management strategy.
e. Configuration management. This helps keep information about the
programme up-to-date and accurate by continuous review, monitoring and
control of changes.
f. Audit. The involvement of audit will help to assure the programme’s sponsors
and stakeholders that it is being managed effectively and the delivery of
changes are aligned with the required outcomes.
13.2 Financing Complex Projects/Programmes
In determining the appropriate financing model, the organization’s business goals,
the need for and the degree of control, the scope of decision rights, as well as the
value of the intellectual property (IP) rights arising from the projects are relevant
factors for consideration. When moving away from full cost ownership, it often
involves some amount of trade-off in these factors which warrant organizational
management decision. Well-designed business models will motivate performance of
partners in their respective roles. The following are some possible alternate
financing models to full ownership:
a. Cost sharing amongst stakeholders – this can be designed along
percentages of the total cost, or each party contributing and operating specific
components such as hardware infrastructure, development services,
operation management etc. Division by component is used typically when the
various contributing partners have complementary business focus.
b. Revenue sharing amongst stakeholders – this is a variation of cost-sharing
mechanism in (a) above, where revenue opportunities are used to defray part
of overall project costs.
c. Formation of joint venture or taking equity stake in partners – this is
used to cement longer term commitment, or where specific parties hold

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 82 of 117

valuable technologies/IPs with growth promises beyond the immediate project

needs or timeline.
d. Leveraging research or government grant – the National Research
Foundation (NRF), the Agency for Science, Technology and Research
(A*STAR) and various government agencies such as the Economic
Development Board (EDB), Spring, the Civil Aviation Authority of Singapore
(CAAS), the Maritime and Port Authority of Singapore (MPA) and IDA provide
incentives and subsidies to drive development and adoption of advanced
technologies, transformation of enterprises and sectors, or simply for
productivity improvements. Organisations may also consider these schemes
in their programme rollout.
Practical Tips
1. Complexities in projects could arise when managing multiple projects programme, managing
distributed project teams, change management, managing cross-organisation projects and cross-
functional projects (management of multiple and distributed project teams with cross-
functional or cross-organisation to accomplish the same project mission, including change
management).

2. The differentiator in managing complexities in projects often relies on creating a harmonious

working relationship with the various interlocking parties. Change management is of paramount
importance.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 83 of 117

14. Change Enablement

The aim of this knowledge area is to ensure that candidates understand the role of
change enablement in driving the execution of many major change journeys that
directly impact the success of IT project implementations. Change enablement
ensures that the organization is ready, willing, and able to function in a new business
environment. Implementing various change efforts can fundamentally alter:
a. The organization’s structure.
b. Organizational roles and how work is performed.
c. Processes and systems that support the organization.
d. Policies and standard operating procedures.
14.1 Value Proposition for Change Enablement
Change enablement is the process to ensure that potential business benefits are
realized and that the transition process to the target state is smooth. Managing
change is certainly fundamental to the implementation of IT projects. Recent
research has shown that projects with excellent change enablement effectiveness
are six times more likely to meet or exceed project objectives. Effective application
of change enablement increases the success rate of organizational changes to as
high as 96%.
Change enablement increases the success of organizational change and project
initiatives by applying a structured framework of methods, tools and processes
managing the change from a current state to a future state. Regardless of the scale
of change, applying a change enablement framework increases the probability of
staying on schedule and budget, resulting in higher benefit realization and return on
investment (ROI).
In today’s fast-paced world, every organization can benefit from a better way to
manage change. Leading corporations, governmental entities, institutions and non-
profits are adopting change enablement as an organizational competency, viewing it
as a competitive advantage in our ever-changing business world. Some of the risks
that may occur if change is not managed effectively are as follows:
a. Productivity declines.
b. Passive resistance escalates.
c. Active resistance emerges and sabotages the change.
d. Valued employees leave the organization.
e. Morale deteriorates.
f. Projects go over budget and past their deadline.
g. Employees find workarounds to avoid the new way of doing things or revert to
the old way.
h. Divides are created in the organization between ‘us’ and ‘them’.
i. The organization builds a history of failed and painful changes.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 84 of 117

14.2 Objectives of Change Enablement

Change enablement is a proactive approach that:
a. Anticipates and addresses the potential impacts of the change.
b. Anticipates and addresses potential resistance to change.
c. Plans, guides, and controls the implementation process.
d. Enables the target audience of the change to perform in the new
environment.
e. Plans for sustaining the new ways of working and for continuous
improvement.
The main objective of change enablement is to elevate the users from the
awareness state (what is changing?) to the commitment state (I am fully committed
to this change). Individuals typically go through predictable stages of behaviour
before committing and internalizing change. The purpose of the change initiatives is
to move people further up the change commitment curve from awareness to
commitment. The diagram below shows some of the typical questions that users will
ask as they move along the commitment curve. As shown below, the likely
consequences of the resistance to change are testament to the importance of the
phase.

14.3 Understanding the Stakeholders and the Impact of Change

The various stakeholder groups are elevated differently depending on their role and
involvement in the project. Hence, the role of change enablement is to carry out
targeted interventions for the various stakeholder groups to move them from their

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 85 of 117

current state (of support to this project) to the desired state within the expected
timelines. It is important to ensure that the unique and varied needs of the diverse
stakeholders are thoroughly understood to appropriately manage and cascade the
change. The team typically does this by conducting a stakeholder analysis to
determine stakeholder profiles, concerns and motivations. This helps the project
team manage a healthy working relationship with the key stakeholders, which is
critical for the success of any project. Furthermore, this can be achieved by:
a. Developing common objectives with the stakeholder’s management and
understanding their strategies and plan.
b. Understanding how to build and manage the relationships with the
stakeholders.
In addition, a change impact assessment evaluates how each of the stakeholder
groups will be impacted by the project. The key findings from this assessment will
identify target areas for action as part of the change journey for each of these
groups.
14.4 Change Enablement Plan
The successful execution of change enablement is typically guided by a change
enablement plan that provides planning, management and enablement of change
through a structured approach. The focus of the plan is to ensure that the right
change activity is carried out to the right audience at the right time to manage the
entire IT implementation journey.

There are various components that can constitute the change enablement plan.
Depending on the change impacts assessed by the project, they may consist of
different change initiatives, ranging from training, communications, to behavioural
change efforts, etc.
Training builds the skills of the users and impacted stakeholders, while
communication engages end users to increase awareness to eventually build
commitment. For some projects, a cultural and behavioural shift may be necessary.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 86 of 117

Definite and time bound action plans are then developed to align individual users to
the new behaviours in the continuum through various methods such as gamification.
The various change initiatives should complement each other to ensure a holistic
change enablement delivery approach that addresses behaviours, mind set and
skills for impacted stakeholders.
14.5 Change Enablers
Leadership and sponsorship are pivotal to ensure the successful execution and buy-
in of the change enablement efforts. Having executive sponsorship significantly
influences the success of most projects, especially those that impact a large number
of stakeholders. As part of the on-going IT implementation journey, it is important to
maintain the cycle of communication between the project teams, the leadership team
and various stakeholders.

In additional to leadership support, it is recommended to establish a change

network to act as a liaison between project leadership and target stakeholders,
ensuring that the stakeholder organization understands the change and is ready to
perform in the target state. A change network is a hierarchy of supporters which
foster sponsorship and ownership of the potential changes to the organization. The
change network raises the visibility of anticipated changes, building support ahead of
the actual change. They will be integral to supporting the change enablement team
in deploying the agreed change initiatives. Personnel from all levels within the
impacted organization make up the change network.
14.6 Change Readiness Assessment
As the change enablement efforts are deployed, it is important to assess the
organization to determine the effectiveness of the initiates and the readiness of the
employees for the upcoming change. For example, a change readiness survey can
be performed to ascertain the level of progress made along the change journey.
Analysing these results from surveys of the individuals going through the change will
provide the project team with an assessment of individual readiness and enable the
addition of further intervention measures where necessary. This is essential to make
sure that change is sustainable and lasting and adopted by all envisaged
stakeholders.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 87 of 117

Practical Tips
1. One size does not fit all. It is vital to thoroughly understand your unique stakeholder groups and
tailor your communications and engagement activities accordingly to ensure the needs of different
stakeholder groups are met.

2. Leverage multiple channels, e.g. electronic and face-to-face channels to ensure stakeholders are
prepared and supportive of the upcoming changes. Consider new and creative avenues such as
social media to reach a more tech-savvy crowd. There are also various gamification tools and
apps that can diversify the communication methods to end users.

3. It might be helpful to create a Change Brand in the beginning of the project to build a stronger,
collective project identity. It becomes the visual representation of the program using a symbol and
style that permeates communications and training reinforcing the value and desired sentiment of
the program.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 88 of 117

15. Abbreviations
AMF Annual Maintenance Fees

APM Agile Project Management

BC Business Continuity

BCT Browser/Operating System Compatibility Testing

BOK Body of Knowledge

BPM Business Process Management

CBA Cost-Benefit Analysis

CCB Change Control Board

CEO Chief Executive Officer

CET Continuing Education and Training

CITPM Certification in IT Project Management

CIO Chief Information Officer

CMMI Capability Maturity Model Integration

COMIT Certification in Outsourcing Management for IT

COTS Commercial-Off-The-Shelf

CPM Critical Path Method

CR Change Request

DISC Dominance, Inducement, Submission and Compliance

Assessment

DR Disaster Recovery

EFT Earliest Finish Time

ERP Enterprise Resource Planning

EST Earliest Start Time

FDA USA Food and Drug Administration

FDD Feature Driven Development

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 89 of 117

HR Human Resources

IAAS Infrastructure-as-a Service

IDA Info-Communications Development Authority of Singapore

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IP Intellectual Property

ISO International Organization for Standardization

ISS Institute of Systems Science

IT Information Technology

ITPM IT Project Management

KPI Key Performance Indicator\

LED Light-Emitting Diode

LFT Latest Finish Time

LST Latest Start Time

MAS Monetary Authority of Singapore

MBTI Myer Briggs Type Indicator

ORT Operational Readiness Testing

OSI Open Source Initiative

PAAS Platform-as-a-Service

PCI DSS Payment Card Industry Data Security Standard

PDPA Personal Data Protection Act

PERT Programme Evaluation and Review Technique

PMI Project Management Institute

PMIS Project Management Information System

PMP Project Management Plan

PSC Project Steering Committee

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 90 of 117

QA Quality Assurance

QMS Quality Management System

RACI Responsible, Accountable, Consult, or Inform

RAM Responsibility Assignment Matrix

RBS Resource Breakdown Structure

ROI Return On Investment

SAAS Software-as-a Service

SCM System Configuration Management

SCS Singapore Computer Society

SDLC Systems Development Life Cycle

SEI Software Engineering Institute

SLA Service Level Agreement

SME Subject Matter Expert

TCO Total Cost of Ownership

TDD Test Driven Development

TOC Table of Contents

TRM Technology Risk Management

UAT User Acceptance Testing

VAPT Vulnerability Assessment and Penetration Testing

WBS Work Breakdown Structure

WIP Work in Progress

XP eXtreme Programming

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 91 of 117

16. Bibliography
a. Anne Mette Jonassen Hass (2008), Guide to Advanced Software Testing,
Artech House Inc, Boston and London.
b. Babich, Wayne, “Software Configuration Management”, Addison-Wesley
Publishing Company, 1986.
c. Beck, Kent; et al. (2001), Agile Manifesto, http://www.agilemanifesto.org/.
d. Beizer, Boris, “Software Testing Techniques”, Van Nostrand Reinhold, 1990.
e. Bersoff, Edward H, Henderson, Vilas D,Siegel, Stanley G, “Software
Configuration Management”, Prentice-Hall, 1980
f. Besle, Jean-Yves, “Software Quality Management Guidelines”, Alcatel
Alsthom, 1994.
g. Boehm, Barry W, “Software Engineering Economics”, Prentice-Hall, 1981
h. Brooks, Frederick P Jr, “The Mythical Man-Month”, Addison Wesley, 1978,
ISBN 0-201-00650-2
i. Buckley, Fletcher J, “Implementing Configuration Management”, Computer
Society Press, 1996
j. Burke, Rory, “Project Management: Planning and Control Techniques”, Wiley,
1992.
k. Burnett, R, “Outsourcing IT, The Legal Aspects”, Grover, 1998, ISBN 0-566-
076985
l. Capers Jones, “Applied Software Measurement”, McGraw-Hill, 1991, ISBN 0-
07-032813-7
m. Cohn, Mike. (2010), Succeeding with Agile Software Development Using
Scrum, Addison-Wesley, Boston.
n. Covey, Stephen. (1999), The 7 Habits of Highly Effective People, Simon &
Schuster Ltd, USA.
o. DeMarco, Tom, “Controlling Software Projects”, Yourdon Press, 1982
p. Deming, WE, “Out of the Crisis”, MIT Press, 1982.
q. Deutsch and Willis, “Software Quality Engineering: A Total Technical and
Management Approach”, Prentice-Hall, 1988.
r. Domberger, Simon, “The Contracting Organization”, Oxford University Press,
1998, ISBN 0-19-877457-5
s. Dreger, JB, “Function Point Analysis “, Prentice-Hall, 1989, ISBN 0-13-
332321-8
t. Dunn, Robert, “Software Quality Concepts and Plans”, Prentice-Hall, 1990.
u. Dunn, Robert, Ullman, Richard, “Quality Assurance for Computer Software”,
McGraw Hill, 1982.
v. Evans, M and Marciniak, J, “Software Quality Assurance & Management”,
Wiley Interscience, 1987.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 92 of 117

w. Fenton, Norman, “Software Metrics - A Rigorous Approach”, Chapman & Hall,

1991
x. Ferraby, Lyn, “Change Control During Systems Development”, Prentice-Hall,
1991
y. Gilb, T, “Principles of Software Engineering Management”, Addison-Wesley,
1987
z. Gilb, Tom and Graham, Dorothy, “Software Inspections”, Addison-Wesley
Publishing Co., 1993
aa. Grady, R and Caswell, D, “Software Metrics - Establishing a Company Wide
Program”, Prentice-Hall, 1987
bb. Halstead, M, “Elements of Software Science”, Elsevier North-Holland, 1975
cc. Hamburger, D. (1986). Three Perceptions of Project Cost - Cost is More Than
a Four Letter Word. Project Management Journal, (June 1986).
dd. Hersey, Blanchard, Johnson (2007), Management of Organizational
Behaviour (9th Edition)
ee. Hetzel, William, “The Complete Guide to Software Testing”, QED Information
Sciences, 1988.
ff. Humphrey, Watts S, “Managing the Software Process”, Addison-Wesley,
1989
gg. IEEE, “IEEE Software Engineering Standards Collection”, IEEE Press, 1994.
hh. Juran, JM, “Juran on Planning for Quality”, Free Press, 1988.
ii. Keyes, J, “Software Engineering Productivity Handbook”, McGraw-Hill, 1992,
ISBN 0-07-911366-4
jj. McDermid, John, “Software Engineer’s Reference Book”, CRC Press, Inc.,
1994.
kk. McNurlin, Barbara C, and Sprague, Ralph H, Jr, "Information Systems
Management in Practice ", Prentice-Hall International, Inc, 2002.
ll. Meredith, J. (2008). Budgeting and Cost Estimation. In Project management:
A managerial approach. (7th ed.), Hoboken, N.J, Wiley.
mm. Meyers, Glenford J, “The Art of Software Testing”, John Wiley & Sons, 1979.
nn. Mikulski, FA, “ Managing Your Vendors”, Prentice-Hall, 1993
oo. Milgate, Michael, “Alliances, Outsourcing, and the Lean Organization”,
Quorum Books, 2001, ISBN 1-56720-365-5
pp. Mylott, Thomas III, “Computer Outsourcing” Prentice-Hall, 1995
qq. Open Source Initiatives, http://opensource.org/licenses
rr. Ould, Martyn A and Unwin, Charles, “Testing in Software Development”,
Cambridge University Press, 1986.
ss. Parker, Marilyn M, "Strategic Transformation and Information Technology",
Prentice-Hall, Inc, 1996

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 93 of 117

tt. Paulk, Mark C, Curtis, Bill, Chrissis, Mary Beth, and Weber, Charles V,
"Capability Maturity Model for Software, Version 1.1", Software Engineering
Institute, CMU/SEI-93-TR-24, February 1993.
uu. Paulk, Mark C, Weber, Charles V, Garcia, Suzanne M, Chrissis, Mary Beth,
and Bush, Marilyn, "Key Practices of the Capability Maturity Model Version
1.1", Software Engineering Institute, CMU/SEI-93-TR-25, February 1993.
vv. SPRING Singapore, “Singapore Standard SS ISO 9001 : 2008, Quality
Management Systems - Requirements”, 2008
ww. Porter-Roth, Bud, “Request for Proposal”; Addison-Wesley, 2002; ISBN 0-
201-77575-1
xx. Pressman, Roger S, “Software Engineering, A Practitioner's Approach”,
McGraw-Hill, 1992 (Third Edition)
yy. Project Management Institute (2013), A Guide to the Project Management
Body of Knowledge (PMBOK Guide), 5th edition
zz. Project Management Institute (2013), Software Extension to the PMBOK
Guide Fifth Edition, PMI, USA
aaa. Radice, Ron, “Software Inspections”, 1995
bbb. Remeni, Money and Twite, “A Guide to Measuring & Managing IT Benefits “,
NCC Blackwell, 1991, ISBN 1-85554-138-6
ccc. Schulmeyer, G and McManus, J, ed, “Handbook of Software Quality
Assurance”, Van Nostrand, 1987.
ddd. Schwalbe, Kathy (2010), Information Technology Project Management 6e,
Course Technology, Cengage Learning, US
eee. Schwalbe, Kathy (2010), Information Technology Project Management 6e,
Course Technology, Cengage Learning, US
fff. SPMI (2013), “Regulatory Compliance – Scope and Implication for Project
Managers”, 12 November 2013, SPMI Website, Singapore
ggg. Sturm, Morris, Jander, “Foundations of Service Level Management”, SAMS,
2000; ISBN 0-672-31743-5
hhh. Tuckman, B. W. and Jensen, M. A. (1977) Stages in small group
development revisited. Group and Organisation Studies 2; 419-427
iii. Ward, John and Griffiths, Pat, "Strategic Planning for Information Systems",
John Wiley & Sons, 1999
jjj. Whitgift, David, “Methods and Tools for Software Configuration Management”,
John Wiley & Sons, 1991
kkk. Williams, Oakie, “Outsourcing, A CIO’s Perspective”, St. Lucie Press; 1998;
ISBN 1-57444-216-3

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 94 of 117

Appendix A.
Agile Project Management
A.1 Introduction
Agile software development is a group of development methods based on iterative
and incremental development approaches. Each iteration (typically 1-4 weeks) is
required to create software releases with business value that are potentially
shippable. In particular, when the project scope is highly volatile and the technology
used are still not matured, the agile approach is often used to manage these
complexities.
Agile methods are planning driven and recognize that system details are typically
not fully known at the beginning. No matter how elaborate the initial planning is,
changes are inevitable. Hence, there is a need to constantly review the planning
through the entire project and adopt a progressive elaboration approach. This is in
sharp contrast to other more heavyweight methods (e.g. the waterfall model) that are
planned driven, where the practice is to create an elaborate plan in the beginning
through thorough analysis, and then try to keep execution as close to the plan as
possible.
This group of agile development methods have been gaining traction over the last
few years due to their responsive to changes in requirements, higher quality and
faster time to market. Commonly and widely adopted agile development methods
include Scrum, eXtreme Programming (XP), Kanban and feature driven
development (FDD).
A.2 Agile Manifesto
In February 2001, 17 highly regarded developers met at the Snowbird Utah (USA)
resort, to discuss lightweight development methods. They published the Manifesto
for Agile Software Development to define the approach now known as agile
software development. The manifesto reads in its entirety.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more.
Agile teams value individuals and interactions over processes and tools.
Ultimately, regardless of what method is being followed, it is always the quality of the
people and the combined strengths through synergetic interactions that determine
the success of the working system. A well-functioning team of great individuals with
mediocre tools will always outperform a dysfunctional team of mediocre individuals
with great tools and heavy weighted processes that are little understood. Agile
thinking acknowledges the unique strengths (along with inevitable weaknesses) of

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 95 of 117

individuals and capitalizes on these differences through providing plentiful

opportunities for learning from each other.
Agile teams value working software over comprehensive documentation.
Through regular delivery, having working software which the customer can interact
with makes it possible to collect early, frequent feedback on both the product and the
process. Feedback from these users is fed back into the development process to
make sure that the team is always working on the highest-valued features and that
those features will satisfy user expectations. Other than requirement specifications
written in a testable way, efforts spent in all other items of documentation which are
not part of the end-product going to customers (architecture, design documentation
etc.) are deemed as a waste of time. The efforts can be better spent working on the
actual working software.
Customer collaboration is valued over contract negotiation by agile teams. All
parties in the project need to be working toward the same set of goals and not try to
outsmart one another through creative interpretation of contractual clauses. Contract
negotiation sometimes sets the development team and the project customer at odds
right from the start, creating a zero sum game which makes management of change
requests a very tiring experience for all. Collaboration is a key ingredient towards
building software that is of value to the customer versus building software that
follows the requirements specifications by the book, but yet very often may not be
exactly what the customer truly requires. Developers need to go beyond their
technical comfort zone and start thinking from the perspective of the customer, while
at the same time, customers should learn more about constraints faced by
development teams to come to feasible solutions that meet the required timeline.
Agile teams value responding to change over following a fixed plan because the
focus should be on delivering as much value as possible to the customer and users.
It is inevitable that plans start to deviate from reality from the moment that the plans
are created. It is impossible for users to know every detail of every feature they
want. Users will come up with new ideas, market conditions may demand a different
type of product and policies may change during project execution that invalidates
some of the original assumptions in the plan.
A.3 Principles behind the Agile Manifesto
In addition to the four agile values, a set of twelve guiding principles for agile
software development is laid out by the authors of the Agile Manifesto. These
principles are meant to supplement and explain what it means to be agile. They are
listed in the table below:

S/No Principle Key Points

1 Our highest priority is to satisfy the Value:

customer through early and These principles focus on providing
continuous delivery of valuable value to the customer and users,
software. through:
2 Welcome changing • Early, frequent, continuous
requirements, even late in delivery of a working IT solution
development. Agile processes or system.
harness change for the customer's

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 96 of 117

competitive advantage. • Accepting and adapting to

changes using a light-weight and
3 Deliver working software fast approach.
frequently, from a couple of weeks
to a couple of months, with a
preference to the shorter timescale.

4 Business people and developers Teamwork:

must work together daily These principles focus on teamwork
throughout the project. in an agile project environment,
where teams performance can be
5 Build projects around motivated
optimized through:
individuals. Give them the
environment and support they • Co-location of team members to
need, and trust them to get the job foster face-to-face conversation
done. and osmotic communication.

6 The most efficient and effective • Empowerment of team members

method of conveying information to in work assignment and decision-
and within a development team is making.
face-to-face conversation.

7 Working software is the primary Execution:

measure of progress. These principles focus on the project
execution to deliver excellence
8 Agile processes promote
through:
sustainable development. The
sponsors, developers, and users • Working software as primary
should be able to maintain a focus of the project’s reason for
constant pace indefinitely. existence.

9 Continuous attention to • Constant and sustainable pace

technical excellence and good of development to prevent
design enhances agility. burnout or fatigue.
• Efficient and clean design.
10 Simplicity - the art of maximizing
the amount of work not done - is
essential.

11 The best architectures, Team Improvement:

requirements, and designs emerge These principles focus on the team’s
from self-organizing teams. continuous improvement efforts
through:
12 At regular intervals, the team
reflects on how to become more • Self-organization of team and
effective, then tunes and adjusts ownership of work.
its behaviour accordingly.
• Regular and frequent reviews to
reflect on lessons learned and
areas of improvement.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 97 of 117

A.4 Differences between Waterfall and Agile

The main differences between a waterfall-based project and an agile project are
described below:
a. Typical Payment Model: Waterfall projects are paid based on deliverables
denoting the completion of software development lifecycle (SDLC) phases,
such as payment after requirements baseline, and payment upon completion
of user acceptance testing (UAT). Agile software projects are often paid
based on actual working software releases to the production environment.
This change in payment timing drives the development team to faster delivery
and higher focus on software quality.

b. Frequency of Releases: With the waterfall model, there is usually one major
release at the end of the project while an agile project breaks the
development into a series of releases and in each release, there are a few
iterations between 1-4 weeks producing a usable product at the end of the
iteration. Agile development teams perform regular code integration, reducing
the complexity and risks associated with “big bang” integration seen in
waterfall projects.
c. Scope Management: In a waterfall project, the end of the requirements
phase will typically baseline the project scope and subsequently changes in
scope are managed through change requests. Due to the difficulty in
identifying all the requirements when none of the software has been built, the
users often have challenges in defining the baseline requirements early,
which eats into the timeline of the rest of the development lifecycle. Waterfall
development teams, in an attempt to protect themselves against scope creep,
typically discourage requirements changes by making the change requests
workflow a long winded and highly controlled process. In contrast, in an agile
project, requirements are ranked according to priority from the most
valuable to the least valuable. These requirements are typically captured in a
product backlog as a prioritized list of all features and functionality that are
required to complete a project. Requirements are then elaborated, designed
and developed in the order of their priority. Scope that has not entered into
development is not fixed and is allowed to evolve to fit the actual usage model
of the end users, thus embracing reasonable changes. When the time-box
and resources runs out, the least valuable requirements are often not
developed, particularly when the cost of developing these requirements far

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 98 of 117

outweigh the benefits that can be derived from implementing these least
valuable requirements.
According to Chaos Manifesto 2012 report, agile projects are three times more likely
to be successful compared to a traditional projects. However, agile is not a silver
bullet to solving all development and organizational problems. Some agile projects
do fail. In fact, adopting agile makes the weaknesses of the team more visible
and exposes them earlier. Unlike the complex, bureaucratic waterfall structure,
where project failure is typical more visible towards the testing stage, the agile
yardstick of project progress is by the amount of working software increments per
sprint (velocity). This will expose issues in an incapable team earlier. Also, if
someone in a team is not contributing to the team’s overall effort, it only takes a few
stand-up meetings for everyone in the team to recognize the black sheep in the fold.
Failing early is not a bad thing. This allows for early actions to be taken before
more efforts and resources are wasted.
A.5 Requirements Analysis
In agile projects, requirements analysis begins during the release planning phase,
and the requirements are progressively elaborated during the development
iterations. The following lists some of the common ways adopted by agile methods
to capture requirements based on user needs:
a. User Stories.
b. User Scenarios.
c. Use Cases.
d. User Flows / Storyboards.
A.5.1 User Stories
A user story is a common format used by agile development teams to describe a
functional requirement. It is typically written by users and subsequently refined
together with the development team. A classic template of a user story is “As a
<role>, I want <goal> so that <benefit>”. Example: “As a student, I want to find my
grades online so that I don’t have to wait until the next day to know whether I
passed.”
A user story may also be written by developers to capture a non-functional
requirement, such as security, performance, reliability, etc. It usually contains just
enough information so that the developers can produce a reasonable estimate of the
effort to implement it. It is commonly used during an iteration where it is often broken
down into tasks through conversations amongst the various stakeholders, such as
the product owner, users, and developers. A set of acceptance criteria is also
determined for each user story prior to its implementation.
A.5.2 User Scenarios
A user scenario expands upon the user stories by including details about how a
system may be used by one of more individuals or organizations. It describes the
steps, events, and actions that occur during an interaction. For example, the
following shows a scenario whereby a user (Susan) makes an online booking for a
public course:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 99 of 117

a. Susan wants to book a course on Agile Project Management (APM) from her
computer.
b. Susan goes to a Continuing Education and Training (CET) centre’s website
and selects a public APM class.
c. She enters her details such as first name, last name, email address, etc.
d. She selects the payment option, enters the payment details and confirms her
booking.
e. She receives an email confirmation of her booking.
A.5.3 Use Cases
A use case is another common format that is widely adopted by both agile and non-
agile projects. It describes a set of interactions between a system and one or more
actors, and generally include the following information:
a. Use Case Name or Title.
b. Rationale or Goal.
c. Actor or User.
d. Preconditions (the things that must have already happened in the system).
e. Interaction and Primary Flow (what will usually happen, described as a set of
steps).
f. Alternate Flow(variation on the primary flow).
g. Post conditions (what the system will have done by the end of the steps).
A.5.4 User Flows / Storyboards
A user flow or a storyboard is a form of visual documentation that depicts how a user
encounters a website’s content and the sequence of interactions required to achieve
a goal. This is where the user stories, scenarios and use cases can be mapped out
in a way that shows the visual sequence and interconnectedness of use cases and
user stories. The following shows an example based on the same scenario above:

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 100 of 117

A.6 Requirements Prioritization Techniques

In Steven R Covey’s bestselling book “The 7 Habits of Highly Effective People”,
habit number 3 “Put First Thing First” emphasizes the strong need to prioritize in
order to best maximize the usage of our time. Similarly, for a project to be
successful, we should invest the effort on the most important features first before
proceeding down to work on the less important ones. In many IT projects, most
requirements are always given only high priorities, which defeats the purpose of
prioritization in the first place. An agile project religiously forces prioritization and
ranking of product features so that the development team has a clear, simple but
effective rule on what they should be working on next – the highest ranked
unfinished feature. Prioritization techniques often used in agile development
methods are as follows:
a. Top Down Ranking: Each feature is ranked from top to bottom based on
business value, effort to implement the feature and the risks associated with
the implementation.
b. MoSCoW: Each feature is classified based on “Must Have”, “Should Have”,
“Could Have”, and “Won’t Have”. Refer to section 4.1 for further details.
c. Buy Me a Feature: Participants who are given a limited amount of monopoly
money are asked to purchase features which they desire. Particulars are
forced to prioritize their desires in a group and negotiate with each other.
d. Kano Analysis: A classification model which divides customer preference of
product features into categories of Basic Needs, Exciters/Delighters,
Performance Needs, Dis-satisfiers.
e. Financial Prioritization Techniques: These include Internal Rate of
Investment, Net Present Value and Pay Back Period. These values are
calculated for each requirement and then used to rank them according to their
financial viability.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 101 of 117

A.7 Lifecycle of an Agile Project

The activities in the lifecycle of an agile project are described below.
a. The initial planning phase involves the following:
• The overall scope of the project is examined by both the business users
and the IT development team.
• The functional scope is broken into user stories. From these stories,
themes (groupings of related user stories) and epics (stories too large to
fit into a single iteration) are stored in a product backlog.
• User research to specify the personas of the end users is carried out to
better understand the perspective of the end users of the system.
• High level architecture and design are defined.
b. For each Iteration, the following cycle of activities take place:
• Development work first starts with the crafting of unit tests. This is carried
out often with pair programming (a technique in which two programmers
work together at a single workstation) and the test driven development
(TDD) approach (writing a test before writing just enough code to pass the
test).
• Automated test cases are created for regression tests. These regression
tests are executed per software build using a continuous integration
server. Continuous integration is the practice of frequently integrating
one’s new or changed code with the existing code repository, usually
several times a day.
• At end of each iteration, the output is an executable piece of software that
is tested.
c. For each release, the following activities take place:
• Tested software is rolled out to production.
• Feedback from actual users is incorporated into the subsequent release
planning.
A.8 Agile Project Progress Tracking
The following charts and artefacts are typically produced by agile teams to monitor
progress and make adaptive changes as the project progresses:
a. A burn down chart is a graphical representation of work left to do. The
outstanding work is shown on the vertical axis. Unlike the earned value chart
which is common in waterfall methodology, an agile burn down chart focuses
on what is left to do rather than how much effort has been expended in
the past. A burn down chart is forward looking, i.e. it looks forward and
reports how much work is remaining.
• Product burn down chart: Tracks the total amount of work to be carried
out in the project from iteration to iteration.
• Iteration burn down chart: Tracks the progress of tasks and left over
hours within an iteration.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 102 of 117

b. A velocity chart measures the team’s rate of progress by counting the total
amount of story points completed in each iteration. Typically, a team velocity
is expected to increase as the team matures in the initial stage and later
stabilize to a sustainable rate. Management must be careful when using this
velocity information to gauge teams’ performance. Velocity change can be
due to a wide variety of reasons such as team composition changes,
performance of individual staff, holiday season during the last sprint,
increasing technical debt (also known as design debt or code debt) and
dependency on other teams output. An agile project manager must try to
understand the underlying reason for changes in velocity and reflects these
reasons in a transparent, truthful way so that both the development team and
management can make conscious decisions and steps to improve the team
velocity and productivity.

A.9 Project Management Considerations for Agile Projects

There are the agile specific considerations that a project manager should take into
account when overseeing a project carried out using the agile approach:
a. Obtain customer active participation: Engage the customers throughout
the entire project. Make sure that the customer and end users participate in
requirement gathering and regular iteration demonstrations so that the
constant flow of ideas and valuable feedback can continuously improve the
software. If the customers are not able to actively participate, this creates a
high risk of building the wrong product, and is often the reason for project
failure. Customers engaging in agile projects must be willing to commit their
time regularly.
b. Make early integration / test environment availability: An agile project
utilizes regular software integration and user acceptance testing. The project
should plan to setup the testing environments as soon as development work
starts. Software licensing and hardware support to enable these
environments to be ready early should be planned for.
c. Employ adaptive and servant leadership: Adaptive and servant leadership
focus on building self-organizing teams, establishing a trusting environment
where everyone’s viewpoints are respected and utilizing participatory decision
making. A leader’s main priority is to help remove impediments for the team
instead of micromanaging all the various activities. A good leader allows for
the team to learn through making mistakes, but proactively guides the team to
conduct reflection on these mistakes so that they are not repeated.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 103 of 117

d. Cater for earlier application support: Due to the earlier and more frequent
release of software increment into the production environment, an agile
project is able to gather user feedback on the usefulness of the software
much earlier. This earlier rollout however requires the attention of the
development team to provide application support and potential bug fixes.
Typically, a portion of the time in an agile team is spent on fixing issues that
arise in production.
e. Build a stable team: Agile project teams should stay stable in size
throughout the entire project. The same team members who are involved in
the initial project inception should stay throughout the entire project, working
on the requirements, design, code implementation and production rollout.
This stability in team structure allows for substantial tacit knowledge
retention, reducing the need for unnecessary project documentation work
that is mainly useful to facilitate the handoff between the teams of IT
professionals that are only involved for part of the whole project. The project
manager should plan for a stable team structure as the quality of the working
product has a strong correlation with the team stability.
f. Build your teams around small, cross functional, self-organizing feature
teams: Central to the concept of agile development is the small, dynamic,
cross functional feature teams that have most of the skillsets within the team
to deliver software increments. Each team should have no more than ten IT
professionals, otherwise the number of communication channels will incur too
much overhead. Team members should be empowered to make their own
technical decisions so as to keep the level of motivation high and encourage
ownership of the tasks. For complex and large projects, multiple features
teams should be assigned to build different parts of the system with a central
integration team to ensure that all the software modules developed by the
different teams are regularly integrated into the overall platform.
g. Train the development team and business owners: If the project team
members are new to the concept of agile software development, then
appropriate training should be made available to both the development team
and business owners to facilitate the transition from a traditional software
development approach towards an agile one. Correct understanding of the
agile values and practices by both the development project team and
business owners are critical to the success of the project. The addition of an
experienced agile coach to a new team should be considered to smoothen
this transition process.
h. Invest in test automation: Agile projects require frequent software releases.
Before each software release can be made, thorough testing including testing
of features developed in previously releases are required. Hence investment
in scripting and automating the tests is highly important to maintain a highly
productive team. Failure to do so will result in the team spending a significant
amount of time on manual regression testing in later releases, thus reducing
the time available to work on new feature development.
i. Assign only a small number of concurrent tasks for each team member:
Doing multiple tasks concurrently very often leads to poorer performance.
This is due to the impact of multitasking. Establish a work in progress (WIP)
limit for the entire team so that every individual in the team can concentrate

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 104 of 117

on the most important tasks at hand, working on finishing perhaps only one or
two tasks concurrently before taking up additional tasks.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 105 of 117

Appendix B.
Sample Templates
a. Project Management Plan (PMP) Table of Contents (TOC).
b. Change Register Template.
c. Issue Register Template.
d. Defect Register Template.
e. QA/Peer Review Memorandum Template.
f. Risk Register Template.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 106 of 117

B.1 Sample Project Management Plan (PMP) Table of Contents

1. OVERVIEW

1.1 Project Charter

1.1.1 Business Needs & Benefits
1.1.2 Project Objectives
1.1.3 Stakeholders Involvement
1.1.4 Assumptions & Constraints
1.1.5 Schedule and Cost/Budget Summary

2. PROJECT INTEGRATION MANAGEMENT APPROACH

3. PROJECT SCOPE MANAGEMENT

3.1 Project Scope Statement

3.1.1 Project Deliverables
3.1.2 Project Requirement
3.1.3 Project Constraints
3.1.4 Cost Estimate
3.1.5 Approval Requirements

3.2 Work Breakdown Structure (WBS)

3.2.1 Project Defects (none in the beginning)
3.2.2 Project Changes (none in the beginning)

4. PROJECT TIME MANAGEMENT

4.1 Activity Definition & Sequencing

4.2 Activity Resource Estimating

4.3 Activity Duration Estimating

4.4 Schedule Development

4.4.1 Critical Path
4.4.2 Project Gantt Chart

5. PROJECT COST MANAGEMENT

5.1 Cost Estimating

5.2 Cost Budgeting

5.3 Cost Variance Management

6. PROJECT QUALITY MANAGEMENT

7. PROJECT HUMAN RESOURCE

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 107 of 117

7.1 Roles and Responsibilities

7.2 Responsibility Assignment Matrix (RAM)

7.3 Staffing Management Plan

8. PROJECT COMMUNICATIONS MANAGEMENT

8.1 Communications Methods

8.2 Communications Management Plan

8.3 Performance Reporting

9. PROJECT RISK MANAGEMENT

9.1 Risk Identification

9.2 Qualitative & Quantitative Risk Analysis

9.3 Risk Response Plan

10. PROJECT PROCUREMENT MANAGEMENT

APPENDIX A - HIGH LEVEL PROJECT WORK PROGRAMME

A.1 - Detailed Project Schedule

A.2 - Detailed Costing

A.3 - Detailed Quality Checklists

A.4 - Detailed Resource Levelling

A.5 - Sample Communications (Weekly, Monthly, etc)

A.6 - Detailed Risk Register, Issue Log, CR Log, etc

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 108 of 117

B.2 Sample Change Register Template

S/N Change Priority Impact & Effort Resp. Due Date Status &
Proposed Remark
Resolution
1
2
3

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 109 of 117

B.3 Sample Issue Register Template

S/N Issue Severity Proposed Resp. Due Date Status &
Resolution Remark
1
2
3

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 110 of 117

B.4 Sample Defect Register Template

S/N Defect Severity Impact & Effort Resp. Due Date Status &
Proposed Remark
Resolution
1
2
3

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 111 of 117

B.5 Sample QA/Peer Review Memorandum Template

To:
From:
Date:
Subject:
1. Purpose

a.
b.
c.
2. Background

a.
b.
c.
3. Main Points Discussed

Dates and Personnel Involved:

Quality Assurance Checklists Reviewed & Previous Outstanding Issues:
a.
b.
c.
Adequacy of Estimates to Complete & Defect Summary
a.
b.
c.
4. Points Arising from Review and Action Required
Point Proposed Resolution Responsibility Due
Date

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 112 of 117

5. Next Reviews

Venue:
Dates:
QA Checkpoint Objective QA Deliverable
Date/Timeframe

6. Reviews Sign-off

Prepared By: Acknowledged By:

XXXX XXX
QA Reviewer Project Manager
7. Distribution List

a.
b.
c.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

 Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 113 of 117

B.6 Sample Risk Register Template Example

S/N Date Risk Area, Risk Impact Probability Risk Mitigation Trigger To Contingency Risk Owner Risk
Raised Context, Category Exposure Action Initiate Action closure
Conditions & Contingency Date
Possible Action
Consequences

1 13- Delay in User Schedule High Medium 6 Seek & 2 weeks Arrange Project
May-12 Requirement negotiate delay in with users Manager
confirmation due with user schedule and Project
to new business for early team to
area that has not submissio work for
done before and n of extended
which is still papers to hours to
pending HQ HQ to complete
policy seek Requireme
confirmation… finalization nt validation
of relevant and
policies. confirmatio
n

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 114 of 117

Appendix C.
Preface to the 3rd Edition

By Ms. Wu Choy Peng,

Chief Editor

The 1st edition of the Book of Knowledge (BOK) for the Certification in IT Project
Management was published in May 2003. The 2nd edition was published in March
2004. It is timely for the Singapore Computer Society to review and publish the 3rd
edition in 2011.
All the knowledge domains in the 2nd edition BOK remain relevant. The resource
panel has made an attempt to make the BOK more readable. Some sections have
been updated with references to the latest tools and methods. Many IT projects
today involve an in-house IT team working closely with a vendor; the differences in
roles and accountabilities of the Project Manager in both teams have been
highlighted, where applicable.
Project management is more than creating spreadsheets and charts, setting up
meetings, tracking issues and updating progress reports and registers. At the heart
of IT project management is the management of scope, resource and time, which
requires making trade-offs. A good IT project manager uses all his or her business,
technical, technology and project management knowledge, skills and experience to
help the business stakeholders and users make such trade-offs.
This BOK is a valuable repository on managing IT projects. Although the BOK is
targeted at candidates of the Certification in IT Project Management (CITPM), it is
highly readable and suitable for all IT professionals. I would like to thank Chee Peng
for the thought and energy that has gone into this revised edition. Needless to say,
all my colleagues in the Resource Panel have also spent significant time and effort
on this endeavour. I hope you will find this BOK useful and relevant.

Ms Wu Choy Peng
Chairperson
CITPM BoK Review Panel

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 115 of 117

Chief Editor
Wu Choy Peng
Group Chief Information Officer, Neptune Orient Lines Ltd

Writers
Tan Chee Peng
Group CEO, Business Technovise International/Team SYNthesis

Review Panel
Wu Choy Peng (Chairperson of Review Panel)
Tang Wai Yee (Deputy Chairperson), Inland Revenue Authority of Singapore
Daniel Boey Swee Kee, Institute of Systems Science
Cheong Pik May, Integrated Health Information Services
Foong Swee Yu, Associate Lecturer, PSB Academy
Ki Gaik Neoh, NCS Pte. Ltd.
Seow Keng Tain, Senior Vice President, Great Eastern Life Assurance Co. Ltd.
Tan Wee Liang, Hewlett Packard Singapore (Sales) Pte Ltd
Yap Chee Yuen, Resorts World at Sentosa Pte Ltd
Yong Teck Thong, NCS Pte. Ltd.

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 116 of 117

Appendix D.
Preface to the 1st and 2nd Editions

By Mrs Tan Ching Yee,

Chief Executive Officer
Infocomm Development Authority of Singapore

IT projects are complex undertakings. They require the coming together of experts in
different domain areas and precise timing. Good project management makes the
difference between an IT project that meets objectives, deadlines and the budget,
and one that does not.
It is therefore no surprise that project management has been making its way to the
top five critical skills required by both the infocomm and end-user industries in recent
years. The CITPM programme was launched in 1998 in response to the industry’s
call for the certification of project management skills. Certification of project
management skills is important as it benchmarks the professional capabilities of the
project manager against accepted industry best practices. Appropriately for a
profession that is internationalised, the CITPM programme has been benchmarked
against similar programmes in Japan, India and USA.
I commend the Singapore Computer Society in compiling this body of knowledge to
serve as a benchmark reference for current and potential IT project managers. This
book also reinforces the need for project managers to constantly demonstrate high
standards and leadership on the job.
The recently launched Connected Singapore blueprint for infocomm development
envisages that Singapore’s infocomm industry will contribute 10% of Singapore’s
gross domestic product by 2012, from the present 7.9%. We can realize this if we
continue to put strong emphasis on developing the capabilities of Singapore’s
infocomm professionals, so that their skills will always remain relevant.
I encourage all infocomm professionals to constantly upgrade and re-skill to meet
the challenges ahead.

Mrs Tan Ching Yee

Chief Executive Officer
Infocomm Development Authority of Singapore

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved

Certification in IT Project Management (CITPM) Body of Knowledge (BOK) Page 117 of 117

Editor
Mr Howard Russon,
Institute of Systems Science (ISS), Singapore

Authors
Ms Wong Ai Luen
Ms Loong Chay Ching, ISS
Ms Tan Lay Ngan, ISS
Ms Tan Wui Gee, ISS

Advisory Panel
Associate Professor Chua Tat Seng,
Chairman, CITPM Board of Assessors
Mr Goh Lin Piao,
Chairman, SCS Certification Resource Panel

Review Panel
Mr Jerry Dimos, PricewaterhouseCoopers
Ms Lau Lai Quen, IBM Singapore Pte Ltd
Ms Low Kim Lian, Infocomm Development Authority of Singapore
Ms Ng Tok Sung, Singapore Computer Systems Ltd

CITPM BOK 4th Edition ©2015 SCS, All Rights Reserved