Information Systems Project Management

PAPER NO.
CT 62
SECTION 6
CERTIFIED
INFORMATION COMMUNICATION
TECHNOLOGISTS
(CICT)
INFORMATION
SYSTEM PROJECT MANAGEMENT
STUDY TEXT
1 www.someakenya.com Contact: 0707 737 890

KASNEB SYLABUSS
GENERAL OBJECTIVE
This paper is intended to equip the candidate with the knowledge, skills and attitude thatwill enable
him/her to manage information systems projects
LEARNING OUTCOMES
A candidate who passes this paper should be able to:
• Manage project scope using various techniques
• Use information system project management software
• Implement information systems projects
• Monitor and control project risk
• Prepare project schedules using project management software tools
• Manage information systems project procurement process
CONTENT
1. Overview of an Information systems project
 Definition of a project
 Project management principles
 Purpose of project management
 Project roles and responsibilities
 Information system project environment
 Characteristics of project
 Examples of information system projects
2. Information systems project lifecycle

 Project identification
 Feasibility study
 Project selection
 Project objectives
 Project proposal
 Project design
 Project development
 Project implementation
 Project monitoring
 Project review
3. Project scope management
 Scope definition
 Scope verification
 Scope control
 Using a software tool to assist in project scope management
4. Project planning
 Determining project tasks
 Work breakdown structures
 Milestones schedules

 Task dependencies and relationships
 Planning time scales
 Materials and equipment management
 Tools and techniques of project planning and scheduling
 Using a software tool to assist in project planning
5. IS project resource management

 Information system project resources
 Resource planning
 Resource allocation framework
 Information resource portfolio management
 Resource schedules
 Cost management
 Using software tools to assist in resource management
6. IS project organizational structures

 Organizational structures
 Integrating project work and project organizational structures
 Team management
 Project team life cycle
 Change management
 IS project quality management
 Quality management
 Quality planning
 Quality assurance
 Quality control
 Tools and techniques for quality control
 Project quality factors
 Overview of project management standards {PRINCE 2)
 Software tools in project quality management
 ISO certification
 Using a software tool to assist in quality management
7. IS project communication management

 Communication management
 Essentials of project documentation
 Progress reporting
 Report writing
 Managing stakeholders
 Using a software tool to assist in project communication management
8. IS project risk management

 Risk identification process

 Common sources of risk
 Risk management tools and techniques
 Risk analysis
 Risk monitoring and control
 Using a software tool in risk management
9. IS project procurement management

 The procurement planning process, tools and methods
 Request for proposal and quotations
 Evaluation of proposals and quotations
 Contracting and contract administration
 Using a software tool in project procurement management
10. IS project implementation, completion and evaluation

 Managing transition
 Project evaluation
 Team evaluation
 Using a software tool to enhance project evaluation
11. Emerging issues and trends
CONTENT PAGE
Topic 1: Overview of an Information systems project ……………………………………….…..……5

Topic 2: Information systems project lifecycle ……………………………………………….…..….24
Topic 3: Project scope management ...…………………………………………………………….….45
Topic 4: Project planning ………………………………………………………………………….....50
Topic 5: IS project resource management….…………………………………………………………74
Topic 6: IS project organizational structures……………………………………………………….....96
Topic 7: IS project communication management.........................................................................…...123
Topic 8: IS project risk management ……………………………………….…………………….…137
Topic 9: IS project procurement management ………………...…………….………………………153
Topic 10: IS project implementation, completion and evaluation…………………………….….…159
Topic 11: Emerging Issues and trends

TOPIC 1
OVERVIEW OF AN INFORMATION SYSTEMS PROJECT
Project management is the discipline of carefully projecting or planning, organizing,

motivating and controlling resources to achieve specific goals and meet specific success criteria.
A project is a temporary endeavor designed to produce a unique product, service or result with a
defined beginning and end (usually time-constrained, and often constrained by funding or
deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial
change or added value. The temporary nature of projects stands in contrast with business as usual
(or operations), which are repetitive, permanent, or semi-permanent functional activities to
produce products or services. In practice, the management of these two systems is often quite
different, and as such requires the development of distinct technical skills and management
strategies.
The primary challenge of project management is to achieve all of the project goals and objectives
while honoring the preconceived constraints. The primary constraints are scope, time, quality
and budget. The secondary — and more ambitious — challenge is to optimize the allocation of
necessary inputs and integrate them to meet pre-defined objectives.
Approaches
There are a number of approaches for managing project activities including lean, iterative,
incremental, and phased approaches.
Regardless of the methodology employed, careful consideration must be given to the overall
project objectives, timeline, and cost, as well as the roles and responsibilities of all participants
and stakeholders.
The traditional approach
A traditional phased approach identifies a sequence of steps to be completed. In the "traditional

approach" five developmental components of a project can be distinguished (four stages plus
control):

Typical development phases of an engineering project
1. initiation
2. planning and design
3. execution and construction
4. monitoring and controlling systems
5. completion and finish point
Not all projects will have every stage, as projects can be terminated before they reach
completion. Some projects do not follow a structured planning and/or monitoring process. And
some projects will go through steps 2, 3 and 4 multiple times.
Many industries use variations of these project stages. For example, when working on a brick-
and-mortar design and construction, projects will typically progress through stages like pre-
planning, conceptual design, schematic design, design development, construction drawings (or
contract documents), and construction administration. In software development, this approach is
often known as the waterfall model, i.e., one series of tasks after another in linear sequence. In
software development many organizations have adapted the Rational Unified Process (RUP) to
fit this methodology, although RUP does not require or explicitly recommend this practice.
Waterfall development works well for small, well defined projects, but often fails in larger
projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as
the planning made on the initial phase of the project suffers from a high degree of uncertainty.
This becomes especially true as software development is often the realization of a new or novel
product. In projects where requirements have not been finalized and can change, requirements
management is used to develop an accurate and complete definition of the behavior of software
that can serve as the basis for software development. While the terms may differ from industry to
industry, the actual stages typically follow common steps to problem solving—"defining the
problem, weighing options, choosing a path, implementation and evaluation."
PRINCE2

The PRINCE2 process model
PRINCE2 is a structured approach to project management released in 1996 as a generic project

management method. It combines the original PROMPT methodology (which evolved into the
PRINCE methodology) with IBM's MITP (managing the implementation of the total project)
methodology. PRINCE2 provides a method for managing projects within a clearly defined
framework.
PRINCE2 focuses on the definition and delivery of products, in particular their quality
requirements. As such, it defines a successful project as being output-oriented (not activity- or
task-oriented) through creating an agreed set of products that define the scope of the project and
provides the basis for planning and control, that is, how then to coordinate people and activities,
how to design and supervise product delivery, and what to do if products and therefore the scope
of the project has to be adjusted if it does not develop as planned.
In the method, each process is specified with its key inputs and outputs and with specific goals
and activities to be carried out to deliver a project's outcomes as defined by its Business Case.
This allows for continuous assessment and adjustment when deviation from the Business Case is
required.
PRINCE2 provides a common language for all participants in the project. The governance
framework of PRINCE2 – its roles and responsibilities – are fully described and require tailoring
to suit the complexity of the project and skills of the organisation.
Critical chain project management
Critical chain project management (CCPM) is a method of planning and managing project
execution designed to deal with uncertainties inherent in managing projects, while taking into
consideration limited availability of resources (physical, human skills, as well as management &
support capacity) needed to execute projects.
CCPM is an application of the theory of constraints (TOC) to projects. The goal is to increase the
flow of projects in an organization (throughput). Applying the first three of the five focusing
steps of TOC, the system constraint for all projects is identified as are the resources. To exploit
the constraint, tasks on the critical chain are given priority over all other activities. Finally,
projects are planned and managed to ensure that the resources are ready when the critical chain
tasks must start, subordinating all other resources to the critical chain.
The project plan should typically undergo resource leveling, and the longest sequence of
resource-constrained tasks should be identified as the critical chain. In some cases, such as
managing contracted sub-projects, it is advisable to use a simplified approach without resource
leveling.
In multi-project environments, resource leveling should be performed across projects. However,

it is often enough to identify (or simply select) a single "drum". The drum can be a resource that

acts as a constraint across projects, which are staggered based on the availability of that single
resource.
One can also use a "virtual drum" by selecting a task or group of tasks (typically integration
points)) and limiting the number of projects in execution at that stage.
Process-based
based management
The incorporation of process-based

based management has been driven by the use of Maturity models
such as the CMMI (capability maturity model integration; see this example of a predecessor) and
ISO/IEC15504 (SPICE – software process improvement
improvement and capability estimation).
Agile project management
The iteration cycle in agile project management
Agile project management encompasses several iterative approaches, based on the principles of
human interaction management and founded on a process view of human collaboration. Agile Agile-
based methodologies are "most typically" employed in software development as well as the
"website, technology, creative, and marketing industries." This sharply contrasts with traditional
approaches such as the Waterfall method.
method In agile software development or flexible product
development,, the project is seen as a series of relatively small tasks conceived and executed to
conclusion as the situation demands in an adaptive manner, rather than as a complet
completely pre-
planned process.
Advocates of this technique claim that:
 It is the most consistent project management technique since it involves frequent testing
of the project under development.
 It is the only technique in which the client will be actively involved
involved in the project
development.
 The only disadvantage with this technique is that it should be used only if the client has
enough time to be actively involved in the project.

Agile is an umbrella term for multiple project management methodologies, including:
 Scrum - A holistic approach to development that focuses on iterative goals set by the
Product Owner through a backlog, which is developed by the Delivery Team through the
facilitation of the Scrum Master.
 Extreme Programming (XP) - A set of practices based on a set of principles and values,
with a goal to develop that provides real value by implementing tight feedback loops at
all levels of the development process and using them to steer development. XP
popularized Test Driven Development (TDD) and Pair Programming.
 eXtreme Manufacturing (XM) - An agile methodology based on Scrum, Kanban and
Kaizen that facilitates rapid engineering and prototyping.
 Crystal Clear - An agile or lightweight methodology that focuses on colocation and
osmotic communication.
 Kanban (かんばん(看板)?) - A lean framework for process improvement that is
frequently used to manage work in progress (WIP) within agile projects. Kanban has
been specifically applied in software development.
 Scrum ban a mixed scrum and kanban approach to project management. It focuses on
taking the flexibility of kanban and adding the structure of scrum to create a new way to
manage projects.
Lean project management
Lean project management uses the principles from lean manufacturing to focus on delivering
value with less waste and reduced time.
Extreme project management
Planning and feedback loops in Extreme programming (XP) with the time frames of the multiple
loops.

In critical studies of project management it has been noted that several PERT based models are
not well suited for the multi-project company environment of today.Most of them are aimed at
very large-scale, one-time, non-routine projects, and currently all kinds of management are
expressed in terms of projects.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven
to cause unnecessary costs and low maneuverability in several cases. The generalization of
Extreme Programming to other kinds of projects is extreme project management, which may be
used in combination with the process modeling and management principles of
humaninteractionmanagement.
Benefits realization management (BRM)
Benefits realization management (BRM) enhances normal project management techniques

through a focus on outcomes (the benefits) of a project rather than products or outputs, and then
measuring the degree to which that is happening to keep a project on track. This can help to
reduce the risk of a completed project being a failure by delivering agreed upon
requirements/outputs but failing to deliver the benefits of those requirements.
In addition, BRM practices aim to ensure the alignment between project outcomes and business
strategies. The effectiveness of these practices is supported by recent research evidencing BRM
practices influencing project success from a strategic perspective across different countries and
industries.An example of delivering a project to requirements might be agreeing to deliver a
computer system that will process staff data and manage payroll, holiday and staff personnel
records. Under BRM the agreement might be to achieve a specified reduction in staff hours
required to process and maintain staff data.
Processes
The project development stages

Traditionally, project management includes a number of elements: four to five process groups,
and a control system. Regardless of the methodology or terminology used, the same basic project
management processes will be used. Major process groups generally include:
 Initiation
 Planning
 Production or execution
 Monitoring and controlling
 Closing
In project environments with a significant exploratory element (e.g., research and development),
these stages may be supplemented with decision points (go/no go decisions) at which the
project's continuation is debated and decided. An example is the Phase–gate model.
Initiating
Initiating process group processes
The initiating processes determine the nature and scope of the project. If this stage is not
performed well, it is unlikely that the project will be successful in meeting the business’ needs.
The key project controls needed here are an understanding of the business environment and
making sure that all necessary controls are incorporated into the project. Any deficiencies should
be reported and a recommendation should be made to fix them.
The initiating stage should include a plan that encompasses the following areas:
 analyzing the business needs/requirements in measurable goals

 reviewing of the current operations
 financial analysis of the costs and benefits including a budget
 stakeholder analysis, including users, and support personnel for the project
 project charter including costs, tasks, deliverables, and schedules
Planning
After the initiation stage, the project is planned to an appropriate level of detail (see example of a
flow chart). The main purpose is to plan time, cost and resources adequately to estimate the work
needed and to effectively manage risk during project execution. As with the Initiation process
group, a failure to adequately plan greatly reduces the project's chances of successfully
accomplishing its goals.
Project planning generally consists of

 determining how to plan (e.g. by level of detail or Rolling Wave planning);
 developing the scope statement;
 selecting the planning team;
 identifying deliverables and creating the work breakdown structure;
 identifying the activities needed to complete those deliverables and networking the
activities in their logical sequence;
 estimating the resource requirements for the activities;
 estimating time and cost for activities;
 developing the schedule;
 developing the budget;
 risk planning;
 Gaining formal approval to begin work.
Additional processes, such as planning for communications and for scope management,
identifying roles and responsibilities, determining what to purchase for the project and holding a
kick-off meeting are also generally advisable.
For new product development projects, conceptual design of the operation of the final product
may be performed concurrent with the project planning activities, and may help to inform the
planning team when identifying deliverables and planning activities.
Executing
Executing process group processes
The execution/implementation phase ensures that the project management plan’s deliverables are
executed accordingly. This phase involves proper allocation, co-ordination and management of
human resources and any other resources such as material and budgets. The output of this phase
is the project deliverables.

Monitoring and controlling
Monitoring and controlling process group processes
Monitoring and controlling consists of those processes performed to observe project execution so
that potential problems can be identified in a timely manner and corrective action can be taken,
when necessary, to control the execution of the project. The key benefit is that project
performance is observed and measured regularly to identify variances from the project
management plan.
Monitoring and controlling includes:
 Measuring the ongoing project activities ('where we are');

 Monitoring the project variables (cost, effort, scope, etc.) against the project management
plan and the project performance baseline (where we should be);
 Identify corrective actions to address issues and risks properly (How can we get on track
again);
 Influencing the factors that could circumvent integrated change control so only approved
changes are implemented.
In multi-phase projects, the monitoring and control process also provides feedback between
project phases, in order to implement corrective or preventive actions to bring the project into
compliance with the project management plan.
Project maintenance is an ongoing process, and it includes:
1 Continuing support of end-users

2 Correction of errors
3 Updates of the software over time
Monitoring and controlling cycle
In this stage, auditors should

hould pay attention to how effectively and quickly user problems are
resolved.
Over the course of any construction project, the work scope may change. Change is a normal and
expected part of the construction process. Changes can be the result of necessary design
modifications, differing site conditions, material availability, contractor-requested
contractor requested changes, value
engineering and impacts from third parties, to name a few. Beyond executing the change in the
field, the change normally needs to be documented to show
show what was actually constructed. This
is referred to as change management. Hence, the owner usually requires a final record to show all
changes or, more specifically, any change that modifies the tangible portions of the finished
work. The record is made on the contract documents – usually, but not necessarily limited to, the
design drawings. The end product of this effort is what the industry terms as-built
as built drawings, or
more simply, “as built.” The requirement for providing them is a norm in construction contracts.
Construction document management is a highly important task undertaken with the aid an online
or desktop software system, or maintained through physical documentation. The increasing
legality pertaining to the construction industries maintenance
maintenance of correct documentation has
caused the increase in the need for document management systems.
When changes are introduced to the project, the viability of the project has to be rere-assessed. It is
important not to lose sight of the initial goals and targets
targets of the projects. When the changes
accumulate, the forecasted result may not justify the original proposed investment in the project.
Successful project management identifies these components, and tracks and monitors progress so
as to stay within time and
d budget frames already outlined at the commencement of the project.

Closing
Closing process group processes.
Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned.
This phase consists of:
 Contract closure: Complete and settle each contract (including the resolution of any
open items) and close each contract applicable to the project or project phase.
 Project close: Finalize all activities across all of the process groups to formally close the
project or a project phase
Also included in this phase is the Post Implementation Review. This is a vital phase of the
project for the project team to learn from experiences and apply to future projects. Normally a
Post Implementation Review consists of looking at things that went well and analysing things
that went badly on the project to come up with lessons learned.
Project controlling and project control systems
Project controlling should be established as an independent function in project management. It

implements verification and controlling function during the processing of a project in order to
reinforce the defined performance and formal goals. The tasks of project controlling are also:
 The creation of infrastructure for the supply of the right information and its update.
 The establishment of a way to communicate disparities of project parameters.
 The development of project information technology based on an intranet or the
determination of a project key performance indicator system (KPI)
 Divergence analyses and generation of proposals for potential project regulations.
 The establishment of methods to accomplish an appropriate project structure, project
workflow organization, project control and governance.
 Creation of transparency among the project parameters.
Fulfillment and implementation of these tasks can be achieved by applying specific methods and
instruments of project controlling. The following methods of project controlling can be applied:
 investment analysis
 cost–benefit analysis
 value benefit analysis
 expert surveys
 simulation calculations
 risk-profile analysis
 surcharge calculations
 milestone trend analysis
 cost trend analysis
 target/actual-comparison
Project control is that element of a project that keeps it on-track, on-time and within budget.
Project control begins early in the project with planning and ends late in the project with post-
implementation review, having a thorough involvement of each step in the process. Projects may
be audited or reviewed while the project is in progress. Formal audits are generally risk or
compliance-based and management will direct the objectives of the audit. An examination may
include a comparison of approved project management processes with how the project is actually
being managed. Each project should be assessed for the appropriate level of control needed: too
much control is time consuming, too little control is very risky. If project control is not
implemented correctly, the cost to the business should be clarified in terms of errors and fixes.
Control systems are needed for cost, risk, quality, communication, time, change, procurement,
and human resources. In addition, auditors should consider how important the projects are to the
financialstatements, how reliant the stakeholders are on controls, and how many controls exist.
Auditors should review the development process and procedures for how they are implemented.
The process of development and the quality of the final product may also be assessed if needed
or requested. A business may want the auditing firm to be involved throughout the process to
catch problems earlier on so that they can be fixed more easily. An auditor can serve as a
controls consultant as part of the development team or as an independent auditor as part of an
audit.
Businesses sometimes use formal systems development processes. These help assure that
systems are developed successfully. A formal process is more effective in creating strong
controls, and auditors should review this process to confirm that it is well designed and is
followed in practice. A good formal systems development plan outlines:
 A strategy to align development with the organization’s broader objectives

 Standards for new systems
 Project management policies for timing and budgeting
 Procedures describing the process
 Evaluation of quality of change
 Definition of a project
What is a Project? A project is a sequence of unique, complex, and connected activities

having one goal or purpose and that must be completed by a specific time, within budget,
and according to specification.

 Project management principles
Principle 1: Vision & Mission
In order to be successfully executed, every project or initiative should begin with the end
in mind. This is effectively accomplished by articulating the Vision and Mission of the
project so it is crystal-clear to everyone. Creating a vision and mission for the project
helps clarify the expected outcome or desired state, and how it will be accomplished.
 Principle 2: Business Objectives

The next step is to establish 2-3 goals or objectives for the project. Is it being
implemented to increase sales and profit, customer loyalty, employee productivity and
morale, or product/service quality? Also, it's important to specifically quantify the
amount of improvement that is expected, instead of being vague.
 Principle 3: Standards of Engagement

Simply put, this means establishing who will be part of the project team? What will be
the frequency of meetings? What are the meeting ground rules? Who is the project
owner? Who is designated to take notes, and distribute project meeting minutes and
action steps? This goes along with any other meeting protocol that needs to be clarified.
 Principle 4: Intervention & Execution Strategy

This is the meat of the project and includes using a gap analysis process to determine the
most suited intervention (solution) to resolve the issue you are working on. There are
many quality management concepts that can be applied ranging from a comprehensive
"root cause analysis" to simply "asking why five times." Once the best possible
intervention has been identified to resolve the issue, then we must map out our execution
strategy for implementing the intervention. This includes identifying who will do what,
when, how, and why?
 Principle 5: Organizational Alignment

To ensure the success and sustainability of the new initiative or process brought on by
this project, everyone it will directly impact must be onboard. To achieve organisational
alignment (or buy-in), ongoing communication must be employed in-person during team
meetings, electronically via email and e-learning (if applicable), and through training.
The message must include the WIIFM "what's in it for me" at every level; otherwise most
stakeholders will not be interested or engaged around the new initiative.
 Principle 6: Measurement & Accountability

And last, how will we determine success? Well, a simple project scorecard that is visually
interesting is a great way to keep everyone updated and engaged. A scorecard is an
excellent resource for holding employees, teams, and leaders accountable for the

implementation, refinement, and sustainability of the new initiative or project.
Accountability means that consistently, top performers will be rewarded and recognized;
while those needing improvement will be coached with specific expectations and
consequences clearly outlined.
While my six principles of project management may not be all inclusive, my hope is that
it has ignited creative juices as you think about how you will approach your next project -
whether implementing a new system/process or refining one that is already in place to
enhance its effectiveness.
 Purpose of project management
Project Management has developed in order to plan, co-ordinate and control the complex
and diverse activities of modern industrial and commercial projects. All projects share
one common characteristic i.e. the projection of ideas and activities into new endeavors.
The purpose of project management is to foresee or predict as many dangers and
problems as possible; and to plan, organize and control activities so that the project is
completed as successfully as possible in spite of all the risks. The ever-present element
of risk and uncertainty means that events and tasks leading to completion can never be
foretold with absolute accuracy. For some complex or advanced projects, even the
possibility of successful completion might be of serious doubt.
Project management can involve the following activities:
• Planning - deciding what is to be done;
• Organizing - making arrangements;
• Staffing - selecting the right people for the job;
• Directing - giving instructions;
• Monitoring - checking on progress;
• Controlling - taking action to remedy hold ups;
• Innovation - coming up with new solutions;
• Representing - liaising with users.
 Project roles and responsibilities

Project Manager
The person responsible for developing, in conjunction with the Project Sponsor, a definition of
the project. The Project Manager then ensures that the project is delivered on time, to budget and
to the required quality standard (within agreed specifications).
He/she ensures the project is effectively resourced and manages relationships with a wide range
of groups (including all project contributors).

Responsibilities
• Managing and leading the project team.
• Recruiting project staff and consultants.
• Managing co-ordination of the partners and working groups engaged in project
work.
Detailed project planning and control including:

• Developing and maintaining a detailed project plan.
• Managing project deliverables in line with the project plan.
• Recording and managing project issues and escalating where necessary.
• Resolving cross-functional issues at project level.
• Managing project scope and change control and escalating issues where necessary.
• Monitoring project progress and performance.
• Providing status reports to the project sponsor.
• Managing project training within the defined budget.
• Liaises with, and updates progress to, project board/senior management.
• Managing project evaluation and dissemination activities.
• Managing consultancy input within the defined budget.
Project Sponsor
The person who commissions others to deliver the project and champions the cause throughout
the project. They will normally be a senior member of staff with a relevant area of responsibility
that will be affected by the outcome of the project. They are involved from the start of the
project, including defining the project in conjunction with the Project Manager. Once the project
has been launched they should ensure that it is actively reviewed.
 Acts as champion of the project.
• Is accountable for the delivery of planned benefits associated with the project.
• Ensures resolution of issues escalated by the Project Manager or the Project
Board.
• Sponsors the communications programme; communicates the programme’s goals
tothe organization as a whole.
• Makes key organisation/commercial decisions for the project.
• Assures availability of essential project resources.
• Approves the budget and decides tolerances.
• Leads the Project Board.
• Ultimate authority and responsibility for the project
Project Board
This group, normally containing management grade personnel, is responsible for overseeing the
progress of the project and reacting to any strategic problems. The group is optional, as the
Sponsor-Manager relationship may be seen as the best means of control, but is usually required
in large projects that cross-functional boundaries.
Responsibilities
• Championing the project and raising awareness at senior level.

• Approving strategies, implementation plan, project scope and milestones.
• Resolving strategic and policy issues.
• Driving and managing change through the organization.
• Prioritizing project goals with other ongoing projects.
• Communicating with other key organizational representatives.
Senior Consultant or Supplier side

Project Manager The person responsible for managing supplier-side input to the project.
Ensures that mandatory supplier requirements are met.
• Manages the production and approval of the supplier side of the budget.
• Makes effective use of supplier resources within the approved budget.
• Tracks performance of consultants and takes appropriate action.
• Proactively develops a collaborative relationship with the organisation to
Projectsteering Board level.
• Ensures that there are clear communication paths within the project team and
theorganisation and supplier.
• Acts as main point of contact between the supplier and the organisation.
• Produces and monitors financial reports including entry and maintenance of all
actualtime and expense against the master plan.
• Day to day management of supplier staff assigned to the project.
• Quality Assures the work of supplier staff assigned to the project.
• Encourages the transfer of product knowledge and skills to the appropriate
staffwithin the organisation.
Project Team Members

The staff who actively work on the project, at some stage, during the lifetime of the project.
Some may have a specific role – for example, the Team might include a Project Administrator.
Responsibilities
Team member roles will vary depending on the type of project. Typically they might be to:
• Provide functional expertise in an administrative process
• Work with users to ensure the project meets business needs
• Documentation and analysis of current and future processes/systems
• Identification and mapping of information needs
• Defining requirements for reporting and interfacing
• User training
System Administrator
Management and support of the IT system environments
Responsibilities
• Management and support of the various environments.
• Network operating systems management and support.
• Database management and support.
• Back-up and disaster recovery measures.
• Contributing to technical strategy, policy and procedure.
• Development and operation of technical testing programmes.

• Production of technical documentation to agreed quality standards.
 Information system project environment
Knowing what you’re getting into can sometimes be half the battle. What is the climate in the
customer organization? Who is cooperative and who isn’t. What’s happening in your
organization that may affect this project or may inhibit your ability to be successful on it?
Perception is key i.e. a project manager and his team must always be aware because there are so
many factors – aside from the ones that you will encounter daily on your project – that can have
positive and negative effects on your project. You can’t control all of them – or even most of
them – and you certainly can’t prepare for everything, but you can work hard at being aware and
keeping your team aware.
Virtually all projects are planned and implemented in a social, economic, and environmental
context, and have intended and unintended positive and/or negative impacts. The project team –
starting at the top with the project manager - should always consider the project in its cultural,
social, international, political, and physical environmental contexts. Perception of the project
from these standpoints will help the team prepare for issues, plan for risks, and better understand
that factors at work around, and possible even against, your project.
Cultural and social environment

The team needs to understand how the project affects people and how people affect the project.
This may require an understanding of aspects of the economic, demographic, educational,
ethical, ethnic, religious, and other characteristics of the people whom the project affects or who
may have an interest in the project. The project manager should also examine the organizational
culture and determine whether project management is recognized as a valid role with
accountability and authority for managing the project.
International and political environment

Some team members may need to be familiar with applicable international, national, regional,
and local laws and customs, as well as the political climate that could affect the project. Other
international factors to consider are time-zone differences, national and regional holidays, travel
requirements for face-to-face meetings, and the logistics of teleconferencing. This certainly
comes into a bigger view for remote project managers working with virtual teams stretched
across a country or around the world. This wasn’t nearly the common occurrence 20 years ago
that it is today with our ability to use technology to collaborate with our team at a moment’s
notice from just about any location.

 Characteristics of project
Five Characteristics of a Project
Projects differ, but they have some commonalities. Table 1.1 presents some characteristics of a
project.
Table 1.1 Project Characteristics

Change Projects are a way to introduce change.
Example: A new sales website will change how clients purchase items.
Temporary There is always a specific start and end to a project, and it should cease once the
mandatory products are created. Ongoing maintenance of a product occurs after
the project and is not considered part of the project.
Example: The production of software to manage sales.

Cross- A project engages people from different seniority and business departments that
Functional work together for the period of the project.
Example: To develop sales software, people from marketing and sales

departments should work closely with the IT department.
Unique Every project is unique.
Example: Building a fiftieth school is different from building the forty-ninth

one. The location is different, the design is different, and there are different
categories of students.
Uncertainty Parts of the project are unique, which brings uncertainty. The project manager
is not 100% sure how this is going to work out.
Example: The owners might keep changing their minds about the components
and functionalities of the sales software.
5 Characteristics of a clearly defined project

In order for a project to be useful, effective and achieving its full objective, it must be clearly
defined. Clearly defined projects share the following 5 criteria:-
i. Specific.
The project must be specific. Being specific includes detailing out the project’s structure,
goals, benefits, milestones and costs. All these requires careful planning and inputs from
the project team members involved and if necessary the external consultants or experts.
Detailed reporting and planning including command structure, personnel list,
communication avenues, gantt chart and the project’s costing should be drawn up to
detail out the project’s responsibilities, timeline, costs and work to be performed by the
respective parties. Periodic project meetings should also be scheduled to discuss relevant
matters pertaining to the project and any issues arising therefrom.

ii. Measurable
A clearly defined project must be measurable in terms of its benefits and achievements.
This should not only be in terms of monetary benefits but also other tangible and
intangible benefits derived from the project’s execution. A clear and precise plan devised
during the project’s planning stage will enable objective measurements be executed to
analyse the project’s achievements and if any shortcomings.
iii. Achievable
A project will only be meaningful if it is achievable. Being too ambitious in planning for
the project will not be helpful and may result in the project being unachievable. This may
also lead to the project team morale being affected. All these unhealthy things may lead
to the project’s costs being overrun and timing of the deliverables being significantly
affected.
iv. Relevant
The project needs to bring relevant benefits to theentity concerned. This may be in the
form of reducing its overall production costs, increasing its operational efficiency or
other specific purposes relevant to the entity. If it fails to address this, the project will not
be beneficial to the entity and will ultimately result in a waste of resources to the entity
and its stakeholders.
v. Time bound
The final ingredient to ensure that becomes clearlydefined is that it should be time bound.
It means that the project should come with a time frame for its completion including its
planning, development, execution, fine tuning before its full run instead of taking forever
to be completed.Any adjustments to this time table should be clearly justified by the
parties involved bearing in mind the costs involved in the project’s execution,
opportunity costs and finance costs related to the project
 Examples of information system projects

TOPIC 2
INFORMATION SYSTEMS PROJECT LIFECYCLE
The Project Life Cycle (Phases)

The project manager and project team have one shared goal: to carry out the work of the project
for the purpose of meeting the project’s objectives. Every project has a beginning, a middle
period during which activities move the project toward completion, and an ending (either
successful or unsuccessful). A standard project typically has the following four major phases
(each with its own agenda of tasks and issues): initiation, planning, implementation, and closure.
Taken together, these phases represent the path a project takes from the beginning to its end and
are generally referred to as the project “life cycle.”
Initiation Phase
During the first of these phases, the initiation phase, the project objective or need is identified;
this can be a business problem or opportunity. An appropriate response to the need is
documented in a business case with recommended solution options. A feasibility study is
conducted to investigate whether each option addresses the project objective and a final
recommended solution is determined. Issues of feasibility (“can we do the project?”) and
justification (“should we do the project?”) are addressed.
Once the recommended solution is approved, a project is initiated to deliver the approved
solution and a project manager is appointed. The major deliverables and the participating work
groups are identified, and the project team begins to take shape. Approval is then sought by the
project manager to move onto the detailed planning phase.
Planning Phase
The next phase, the planning phase, is where the project solution is further developed in as much
detail as possible and the steps necessary to meet the project’s objective are planned. In this step,
the team identifies all of the work to be done. The project’s tasks and resource requirements are
identified, along with the strategy for producing them. This is also referred to as “scope
management.” A project plan is created outlining the activities, tasks, dependencies, and
timeframes. The project manager coordinates the preparation of a project budget by providing
cost estimates for the labor, equipment, and materials costs. The budget is used to monitor and
control cost expenditures during project implementation.
Once the project team has identified the work, prepared the schedule, and estimated the costs, the
three fundamental components of the planning process are complete. This is an excellent time to
identify and try to deal with anything that might pose a threat to the successful completion of the
project. This is called risk management. In risk management, “high-threat” potential problems
are identified along with the action that is to be taken on each high-threat potential problem,
either to reduce the probability that the problem will occur or to reduce the impact on the project
if it does occur. This is also a good time to identify all project stakeholders and establish a
communication plan describing the information needed and the delivery method to be used to
keep the stakeholders informed.
Finally, you will want to document a quality plan, providing quality targets, assurance, and
control measures, along with an acceptance plan, listing the criteria to be met to gain customer

acceptance. At this point, the project would have been planned in detail and is ready to be
executed.
Implementation (Execution) Phase

During the third phase, the implementation phase, the project plan is put into motion and the
work of the project is performed. It is important to maintain control and communicate as needed
during implementation. Progress is continuously monitored and appropriate adjustments are
made and recorded as variances from the original plan. In any project, a project manager spends
most of the time in this step. During project implementation, people are carrying out the tasks,
and progress information is being reported through regular team meetings. The project manager
uses this information to maintain control over the direction of the project by comparing the
progress reports with the project plan to measure the performance of the project activities and
take corrective action as needed. The first course of action should always be to bring the project
back on course (i.e., to return it to the original plan). If that cannot happen, the team should
record variations from the original plan and record and publish modifications to the plan.
Throughout this step, project sponsors and other key stakeholders should be kept informed of the
project’s status according to the agreed-on frequency and format of communication. The plan
should be updated and published on a regular basis.
Status reports should always emphasize the anticipated end point in terms of cost, schedule, and
quality of deliverables. Each project deliverable produced should be reviewed for quality and
measured against the acceptance criteria. Once all of the deliverables have been produced and
the customer has accepted the final solution, the project is ready for closure.
Closing Phase
During the final closure, or completion phase, the emphasis is on releasing the final deliverables
to the customer, handing over project documentation to the business, terminating supplier
contracts, releasing project resources, and communicating the closure of the project to all
stakeholders. The last remaining step is to conduct lessons-learned studies to examine what went
well and what didn’t. Through this type of analysis, the wisdom of experience is transferred back
to the project organization, which will help future project teams
 Project identification
Project ideas may be due to:

• Prevailing problems in a given area.
• availability of resources in a given location
Clear project identification allows you to answers questions like:
a) How do the projects come about?
b) Where do projects come from?
c) Why are projects where they are?
Approaches to project identification

There are two major approaches to project identification
(a) Top-down approach
(b) Bottom-up approach

A. Top-Down Approach
• Projects are identified based on demands from beyond the community.
• This may include directives from:
 International conventions (such as Kyoto Protocol/climate change).
 International institutions or NGOs that have determined particular priorities and
thus projects.
 National policy makers identifying projects that pertain to party manifestos and/or
national plans.
Advantages of Top-Down Approach

• It may be a rapid response to disasters like floods, war outbreak because there is limited
time and chance to consult the beneficiaries.
• It can be effective in providing important services like education, health, water, roads etc.
• It can contribute to wider national or international objectives and goals and therefore
potentially be part of a wider benefit (as in the case of trans-boundary resources, such as
climate, water or others)
Limitations of Top-Down Approach

 Does not help in modifying strongly established ideas and beliefs of people.
 Assumes external individuals know better than the beneficiaries of the service.
 Communities have little say in planning process rendering approach devoid of
human resource development.
 Community develops dependency syndrome on outside assistance and does not
exploit their own potential.
 The development workers (change agents) become stumbling blocks to people-led
development
 Tendency to impose their own biases, etc. on people.
B. Bottom-Up Approach
• In this approach community/beneficiaries are encouraged to identify and plan the projects
themselves with or without outsiders.
Advantages of Bottom-Up Approach

 Interveners accomplish more with limited resources since people tend to safeguard what
they have provided for themselves.
 Develops people’s capacity to identify problems and needs and to seek possible solutions
to them.
 Provides opportunities of educating people.
 Helps people to work as a team and develop a “WE” attitude - makes project progressive
and sustainable.
 Resources are effectively managed; dependence reduces, there is increased equity,
initiative, accountability, financial and economic discipline.
Limitations of Bottom-Up Approach

 Not always effective for projects that require urgency to implement.
 Time-consuming and requires patience and tolerance.

 People sometimes dislike approach because they do not want to take responsibility for
action.
 The agency using this approach is never in control and cannot guarantee the results it
would want.
 The priorities of communities may not fit with national or international priorities that
seek to have a broader impact.
Top-down approaches to project identification

1. The household (socio-economic) survey
 Studies social and economic situations of a given area
 e.g. climate, geographical set-up, economic activities, political set up,
education system, culture, diet, social services, physical infrastructure
etc.
 Method is popular with the UBOS.
 Uses questionnaires, interviews, documentation, and direct observation.
 Data is collected, processed and analyzed and projects are then identified
 Top-down approaches to project identification
2. Rapid appraisal
 Called Rapid Rural Appraisal (RRA) when carried out in a rural areas, and Rapid
Urban Appraisal(RUA) in an urban area.
 Method collects and assesses data quickly using any data collection techniques.
 Primary purpose is to acquire the information in the shortest time possible and it
lowers the cost.
• It is rapid because investigation, assessment and identification of
projects are done at the same time .
 Rapid appraisal uses the following data collection techniques:
• Analysis of secondary data sources
• Interviews
• Direct observation at site
• Visualization of Resources like social organizational maps and time
series maps.
 Top-down approaches to project identification
3.Needs Assessment Survey
 Also referred to as situation analysis (SITAN). It involves:-
• Fact finding about problems or needs in a given area or community.
• Finding out what is lacking in a given area or community.
• Investigating a situation in a given area.
NAS is carried out to:
 Find out the problem in a given community so as to identify the most appropriate
solution (s)/project (s) to solve the problem (s) in question.
 Analyze the causes of the problems and seek likely solutions to the problems
leading to project identification.
 Bottom-up approaches to project identification
4. Animation
 Process of stimulating people to become more aware and conscious of problems
they suffer from.
• To gain confidence in their ability to deal with these problems and
take initiatives to improve situation.

 Animation makes the community better understand and be prepared to overcome its
problems and take decisions with full responsibility
 Carried out by Animators / Helpers / Change agents.
(Internal Animators if they come from within the community or External
Animators if from outside.)
Bottom-up approaches to project identification
Facilitation/Community action
 An attempt to assist people to get over problems by (say) training them in certain
skills, providing them with the needed information e.g. market information, linking
them up with relevant agencies and organizations to improve access to the needed
resources etc.
Bottom-up approaches to project identification
Participatory Appraisal
 Project identification should be participatory, and should involve local communities
in identifying and prioritizing their needs.
 The DTPC should consider the views of the communities during the screening and
selection of various project proposals and the selection of the preferred proposals for
implementation.
• PRA (participatory rural appraisal) when carried out in rural areas; and PLU
(participatory urban appraisal) when carried out in urban areas
• PRA/ PUA can be described as a family of approaches, methods and behaviours that
enable people to express and analyze the realities of their lives and conditions, to plan for
themselves what action to take, and to monitor and evaluate the results.
• The key to PRA/PUA is that the only external involvement is in facilitation. The
communities themselves determine the issues, priorities and courses of action.
The problem statement
• The process of project identification ends with the formulation of a problem statement.
• It takes the form of:
 Listing all the problems/needsin the community/area/ organization.
 Prioritizing the problems and selecting 1 – 3 core (major) problems.
 Finding out the root causes of the problems.
 Sitting the likely effects of the problems on the community.
 Suggesting the probable solutions to the problems.
 Identifying the (projects) from the solutions.
 Feasibility study
A feasibility study aims to objectively and rationally uncover the strengths and weaknesses of an
existing business or proposed venture, opportunities and threats present in the environment, the
resources required to carry through, and ultimately the prospects for success. In its simplest
terms, the two criteria to judge feasibility are cost required and value to be attained.
A well-designed feasibility study should provide a historical background of the business or

project, a description of the product or service, accounting statements, details of the operations
and management, marketing research and policies, financial data, legal requirements and tax
obligations. Generally, feasibility studies precede technical development and project
implementation.
A feasibility study evaluates the project's potential for success; therefore, perceived objectivity is
an important factor in the credibility of the study for potential investors and lending institutions.

It must therefore be conducted with an objective, unbiased approach to provide information upon
which decisions can be based.
Common factors
The acronym TELOS refers to the five areas of feasibility - Technical, Economic, Legal,
Operational, and Scheduling.
Technical feasibility
This assessment is based on an outline design of system requirements, to determine whether the
company has the technical expertise to handle completion of the project. When writing a
feasibility report, the following should be taken to consideration:
 A brief description of the business to assess more possible factors which could affect the
study
 The part of the business being examined
 The human and economic factor
 The possible solutions to the problem
At this level, the concern is whether the proposal is both technically and legally feasible
(assuming moderate cost)
The technical feasibility assessment is focused on gaining an understanding of the present

technical resources of the organization and their applicability to the expected needs of the
proposed system. It is an evaluation of the hardware and software and how it meets the need of
the proposed system.
Economic feasibility
The purpose of the economic feasibility assessment is to determine the positive economic
benefits to the organization that the proposed system will provide. It includes quantification and
identification of all the benefits expected. This assessment typically involves a cost/ benefits
analysis.
Legal feasibility
Determines whether the proposed system conflicts with legal requirements, e.g. a data processing
system must comply with the local data protection regulations.
Operational feasibility
Operational feasibility is a measure of how well a proposed system solves the problems, and
takes advantage of the opportunities identified during scope definition and how it satisfies the
requirements identified in the requirements analysis phase of system development.

The operational feasibility assessment focuses on the degree to which the proposed development
projects fits in with the existing business environment and objectives with regard to development
schedule, delivery date, corporate culture, and existing business processes.
To ensure success, desired operational outcomes must be imparted during design and
development. These include such design-dependent parameters such as reliability,
maintainability, supportability, usability, producibility, disposability, sustainability, affordability
and others. These parameters are required to be considered at the early stages of design if desired
operational behaviors are to be realized. A system design and development requires appropriate
and timely application of engineering and management efforts to meet the previously mentioned
parameters. A system may serve its intended purpose most effectively when its technical and
operating characteristics are engineered into the design. Therefore, operational feasibility is a
critical aspect of systems engineering that needs to be an integral part of the early design phases.
Schedule feasibility
A project will fail if it takes too long to be completed before it is useful. Typically this means
estimating how long the system will take to develop, and if it can be completed in a given time
period using some methods like payback period. Schedule feasibility is a measure of how
reasonable the project timetable is. Given our technical expertise, are the project deadlines
reasonable? Some projects are initiated with specific deadlines. It is necessary to determine
whether the deadlines are mandatory or desirable.
Other feasibility factors
Market and real estate feasibility
Market feasibility studies typically involve testing geographic locations for a real estate
development project, and usually involve parcels of real estate land. Developers often conduct
market studies to determine the best location within a jurisdiction, and to test alternative land
uses for given parcels. Jurisdictions often require developers to complete feasibility studies
before they will approve a permit application for retail, commercial, industrial, manufacturing,
housing, office or mixed-use project. Market Feasibility takes into account the importance of the
business in the selected area.
Resource feasibility
This involves questions such as how much time is available to build the new system, when it can
be built, whether it interferes with normal business operations, type and amount of resources
required, dependencies, and developmental procedures with company revenue prospectus.
Cultural feasibility
In this stage, the project's alternatives are evaluated for their impact on the local and general
culture For example, environmental factors need to be considered and these factors are to be well
known. Further an enterprise's own culture can clash with the results of the project.
Financial feasibility
In case of a new project, financial viability can be judged on the following parameters:
 Total estimated cost of the project

 Financing of the project in terms of its capital structure, debt equity ratio and promoter's
share of total cost
 Existing investment by the promoter in any other business
 Projected cash flow and profitability
The financial viability of a project should provide the following information:
 Full details of the assets to be financed and how liquid those assets are.
 Rate of conversion to cash-liquidity (i.e. how easily can the various assets be converted to
cash?).
 Project's funding potential and repayment terms.
 Sensitivity in the repayments capability to the following factors:
o Time delays.
o Mild slowing of sales.
o Acute reduction/slowing of sales.
o Small increase in cost.
o Large increase in cost.
o Adverse economic conditions.
In 1983 the first generation of the Computer Model for Feasibility Analysis and Reporting
(COMFAR), a computation tool for financial analysis of investments, was released. Since then,
this UNIDO software has been developed further, to also support the economic appraisal of
projects. The Computer Model for Feasibility Analysis and Reporting (COMFAR III Expert) is
intended as an aid in the analysis of investment projects. The main module of the program
accepts financial and economic data, produces financial and economic statements and graphical
displays and calculates measures of performance. Supplementary modules assist in the analytical
process. Cost-benefit and value-added methods of economic analysis developed by UNIDO are
included in the program and the methods of major international development institutions are
accommodated. The program is applicable for the analysis of investment in new projects and
expansion or rehabilitation of existing enterprises as, e.g., in the case of re-privatization projects.
For joint ventures, the financial perspective of each partner or class of shareholder can be
developed. Analysis can be performed under a variety of assumptions concerning inflation,
currency revaluation and price escalations.
Market research study

This is one of the most important sections of the feasibility study as it examines the marketability
of the product or services and convinces readers that there is a potential market for the product or
services. If a significant market for the product or services cannot be established, then there is no
project.

Typically, market studies will assess the potential sales of the product, absorption and market
capture rates and the project's timing.
The feasibility study outputs the feasibility study report, a report detailing the evaluation criteria,
the study findings, and the recommendations
 Project selection
A detailed investigation of a project’s technical, social and economic feasibility is conducted in

the Feasibility Study Stage. The Project Selection Stage is a first process to assess each project
idea and select the highest priority project(s) for further investigation.
At this Stage, possible projects may only be ideas or suggestions (e.g. individual observation,
most serious invasive plant in an inventory, most important site, species with greatest
conservation needs), so you may need to write a brief description of each project before
continuing with the selection process.
Selection of projects is based on:
 Benefits: A measure of the positive outcomes of the project. These are often described
as “the reasons why you are undertaking the project”. The benefits of invasive species
management projects include:
 Biodiversity,
 Economic,
 Social and cultural,
 Fulfilling commitments made as part of national, regional or international plans
and agreements.
 Achievability: An “educated guess” measure of the likelihood of the project being a

success, i.e. achieving its objectives. Projects vary greatly in complexity, risk and cost.
By evaluating likelihood of success when selecting projects it means the most-likely-to-
succeed projects with the greatest benefits are given priority.
Why Do Project Selection?
Often you will have a number of project ideas but not enough resources, money or time to
undertake all of the projects. The ideas for invasive species management projects may have
come from many sources including: the community, funders, local and national governments and
non-governmental organisations (NGOs). You will therefore need a way of deciding on the
priority order of projects.
If your organisation has limited experience in conducting invasive species management projects
then it is recommended to concentrate on a small number of projects, ideally one project at a
time, until the people in your organisation have developed the skills and experience. Start small,

grow capacity and build up to undertaking multiple projects at any one time. Do the
straightforward projects first. Work towards the most difficult and rewarding projects. Use the
easiest projects to help answer questions/solve issues for the more difficult projects. These are
the best opportunities to learn.
You may have a mix of straightforward and difficult projects and do not know where to start.
The Project Selection Stage will assist you by providing a process to compare the importance of
the projects and select the most suitable project to undertake.
By following the Project Selection Stage you will use a step-by-step objective method for
prioritizing projects – this can be used to explain to stakeholders the reasoning behind why you
selected a particular project.
The advantages of completing the Project Selection Stage are:
 A transparent and documented record of why a particular project was selected is produced
 A priority order for projects, that takes into account their importance and the benefits and
achievability of the project, is established.
When to Do?
Undertake a Project Selection exercise when you:
 Have more ideas than the number of projects you can undertake and need to select the
project(s) that should be given priority.
Note: If you only have one project, it may still be useful to score it against a set of criteria to
identify the strengths and weaknesses of the project. The results may be useful later in the
Feasibility Study Stage.
Who Should Be Involved?
Agency Management:
 Set selection criteria to ensure the selection process aligns with agency strategies.
 Selection processes are often run as a management initiative before the implementing
Project Manager is appointed.
Stakeholders:
 Stakeholder participation from the start of a project creates strong community ownership
and support, and increases the chances of a successful outcome.
 Stakeholder input should be included at the ideas stage; consult widely as you are
developing the ideas for projects as the community will be the source of many of the best
project ideas.

 Stakeholders must be informed of the outcome of the Project Selection Stage.
Project Manager:
 Involving the Project Manager in the Project Selection process will help build ownership
in the project and support a successful project in the long run.
 Project objectives
The project objective describes the project’s outcomes: intended and direct, short and medium
term effects on the target group. The project objective must lie within the scope of the project,
and one must be able to directly attribute the effects to the project. The project objective is often
formulated in terms of the project’s utility for the target group: “Better… higher…” It also
makes sense to formulate the project objective as a situation to be achieved in the future.
The project objective ought also to describe an outcome, meaning the effect/change that the
project is supposed to cause for the target group. In practice it is often not quite so simple to
distinguish outcomes from outputs, i.e. the project’s products and deliverables. Well-formulated,
genuine outcome (and impact) objectives are therefore of great importance if the outcome and
impact assessment is to have any significance.
A well-formulated project objective
 Provides a concrete description of the project’s effect at the outcome level;

 Was developed in a participatory process;
 Is accepted by the target group and other stakeholders;
 Is clear and concise.
N/B
• Do not simply summarize the outputs, but describe the effects that should be triggered at
a higher level.
 Distinguish clearly between objectives and indicators. There are various ways to
distinguish between objectivesandindicators. However, individual variants should not be
mixed up.

Defn 2
Goals and Objectives
Goals and objectives are statements that describe what the project will accomplish, or the
business value the project will achieve.
Goals are high level statements that provide overall context for what the project is trying to
achieve, and should align to business goals.
Objectives are lower level statements that describe the specific, tangible products and
deliverables that the project will deliver.
The definition of goals and objectives is more of an art than a science, and it can be difficult to
define them and align them correctly.
Goals
Goals are high-level statements that provide the overall context for what the project is trying to
accomplish. Let's look at an example and some of the characteristics of a goal statement. One of
the goals of a project might be to "increase the overall satisfaction levels for clients calling to the
company helpdesk with support needs".
 Because the goal is at a high-level, it may take more than one project to achieve. In the above
example, for instance, there may be a technology component to increasing client satisfaction.
There may also be new procedures, new training classes, reorganization of the helpdesk
department and modification of the company rewards system. It may take many projects over a
long period of time to achieve the goal.
 The goal should reference the business benefit in terms of cost, speed and / or quality. In this
example, the focus is on quality of service. Even if the project is not directly in support of the
business, there should be an indirect tie. For instance, an IT infrastructure project to install new
web servers may ultimately allow faster client response, better price performance, or other
business benefit. If there is no business value to the project, the project should not be started.
 Generally, non-measurable: If you can measure the achievement of your goal, it is probably at too
low a level and is probably more of an objective.
 If your goal is not achievable through any combination of projects, it is probably written at too
high a level. In the above example, you could envision one or more projects that could end up
achieving a higher level of client satisfaction. A goal statement that says you are trying to achieve
a perfect client experience is not possible with any combination of projects. It may instead be a
vision statement, which is a higher level statement showing direction and aspiration, but which
may never actually be achieved.
It is important to understand business and project goal statements, even though goals are not a part of the
TenStep Project Definition. Goals are most important from a business perspective. The project manager

needs to understand the business goals that the project is trying to contribute to. However, you do not need
to define specific project goals. On the other hand, objectives definitely are important.
Objectives
Objectives are concrete statements describing what the project is trying to achieve. The objective should
be written at a lower level, so that it can be evaluated at the conclusion of a project to see whether it was
achieved or not. Goal statements are designed to be vague. Objectives should not be vague. A well-
worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound
(SMART).
An example of an objective statement might be to "upgrade the helpdesk telephone system by December
31 to achieve average client wait times of no more than two minutes".
 Note that the objective is much more concrete and specific than the goal statement.
 The objective is measurable in terms of the average client wait times the new phone system is
trying to achieve.
 We must assume that the objective is achievable and realistic.
 The objective is time-bound, and should be completed by December 31.
Objectives should refer to the deliverables of the project. In this case, it refers to the upgrade of the
telephone system. If you cannot determine what deliverables are being created to achieve the objective,
then the objective may be written at too high a level. On the other hand, if an objective describes the
characteristics of the deliverables, they are written at too low a level. If they describe the features and
functions, they are requirements, not objectives
 Project proposal
Project proposals are documents designed to present a plan of action, outline the reasons why
the action is necessary, and convince the reader to agree with and approve the implementation
of the actions recommended in the body of the document. In many cases, the document is
drafted as a response to a Request for Proposal(RFP) that is issued by a current or prospective
client. However, a document of this type may also be prepared to serve an internal purpose,
especially when someone within the company has an idea of how to make the company more
profitable or efficient and needs authorization and backing to implement the action.
In any situation, a project proposal will be clearly arranged so that readers can follow a logical
progression of thought to the conclusion. Many sample proposals offer a basic guideline that can
help even novices get into the swing of effective proposal writing. The guidelines usually

identify five key components or sections of any project proposal: the introduction, background,
strategy, budgeting or financing, and outcome.
With the introductory section of a project proposal, the idea is to tell readers what the project is
all about, and why it is worth taking the time to consider the project in the first place.
Essentially, this section serves to validate the time and effort spent in presenting the data as well
as the time required to read and consider the merits and feasibility of the project itself. The
introduction is not the place to present the nuts and bolts of the project, only to establish its
potential and cultivate enough interest to encourage the reader to learn more.
The background expounds on the basic points of the introduction, often citing specific reasons
why the project plan is a good one, based on historical data, projections of future needs and
performance, and the current circumstances of the business. The background helps to build the
case for how the project can meet the needs that have arisen due to past actions while also
anticipating future needs and addressing them in a timely manner. For the most part, the
background section will firmly establish that something must be done and pave the way for
learning how that something can be accomplished.
With the strategy section of the project proposal, the goal is to outline all procedures that are
necessary to make the project successful. Often, the strategy helps to define short term and long
term goals for the project, explains how to systematically accomplish each step and what type of
return can be expected from the effort. Here, the reader begins to get an idea of how important
the project is and the potential it has to help the company make better use of available resources
while positioning itself for the future.
Thebudgetsection gets down to what most decision makers must know before approving any
project: what is the cost involved with the implementation of the project proposal. In this section,
the detail must be backed up with facts and figures that are well researched and cover every
imaginable aspect of the financing needed to launch and maintain the project over time. Many
proposals fail here, due to a lack of detail and supporting evidence for the detail that is included.
Finally, the project proposal points to the outcome of implementing the project. This is the
section where all of the benefits are spelled out clearly. The advantages may include such items
as reducing operating costs, increasing the public profile of the business, generating more sales,
or increasing profits due to more efficient use of available resources. As with the budget detail, it
is important that every benefit named can be supported by other data in order to be seriously
considered.
Writing a proposal is sometimes easier when a formal RFP is provided. Often, the RFP will lay
out the basic structure of the proposal, provide invaluable clues as to specific information that is
of interest to the potential client, and define the order in which data is presented. When an RFP is
provided, it is essential to follow the specifications of the document to the letter. Otherwise, the
proposal will be set aside and one of the other vendors who did follow the provisions closely will
be awarded the business

 Project design
Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development. There is some overlap with the disciplines
of systems analysis, systems architecture and systems engineering.
Overview
If the broader topic of product development "blends the perspective of marketing, design, and
manufacturing into a single approach to product development," then design is the act of taking
the marketing information and creating the design of the product to be manufactured. Systems
design is therefore the process of defining and developing systems to satisfy specified
requirements of the user.
Until the 1990s systems design had a crucial and respected role in the data processing industry.
In the 1990s standardization of hardware and software resulted in the ability to build modular
systems. The increasing importance of software running on generic platforms has enhanced the
discipline of software engineering.
Object-oriented analysis and design methods are becoming the most widely used methods for
computer systems design. The UML has become the standard language in object-oriented
analysis and design. It is widely used for modeling software systems and is increasingly used for
high designing non-software systems and organizations.
Architectural design
The architectural design of a system emphasizes on the design of the systemsarchitecture which
describes the structure, behavior, and more views of that system and analysis.
Logical design
The logical design of a system pertains to an abstract representation of the data flows, inputs and
outputs of the system. This is often conducted via modelling, using an over-abstract (and
sometimes graphical) model of the actual system. In the context of systems design are included.
Logical design includes ER Diagrams i.e. Entity Relationship Diagrams.
Physical design
The physical design relates to the actual input and output processes of the system. This is
explained in terms of how data is input into a system, how it is verified/authenticated, how it is
processed, and how it is displayed as In Physical design, the following requirements about the
system are decided.
1. Input requirement,
2. Output requirements,

3. Storage requirements,
4. Processing Requirements,
5. System control and backup or recovery.
Put another way, the physical portion of systems design can generally be broken down into three
sub-tasks:
1. User Interface Design

2. Data Design
3. Process Design
User Interface Design is concerned with how users add information to the system and with how
the system presents information back to them. Data Design is concerned with how the data is
represented and stored within the system. Finally, Process Design is concerned with how data
moves through the system, and with how and where it is validated, secured and/or transformed as
it flows into, through and out of the system. At the end of the systems design phase,
documentation describing the three sub-tasks is produced and made available for use in the next
phase.
Physical design, in this context, does not refer to the tangible physical design of an information
system. To use an analogy, a personal computer's physical design involves input via a keyboard,
processing within the CPU, and output via a monitor, printer, etc. It would not concern the actual
layout of the tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard
drive, modems, video/graphics cards, USB slots, etc. It involves a detailed design of a user and a
product database structure processor and a control processor. The H/S personal specification is
developed for the proposed system.
 Project development
Project Development is the process that takes a transportation improvement from concept
through construction. There are several goals for this process:
• To ensure context sensitivity through an open, consensus-building dialog among project
proponents, reviewers, the public, and other parties.
• To foster thinking beyond the roadway pavement to achieve the optimum
accommodation for all modes.
• To encourage early planning, public outreach, and evaluation so that project needs, goals
and objectives, issues, and impacts can be identified before significant resources are
expended.
• To achieve consistent expectations and understanding between project proponents and
those entities who evaluate, prioritize, and fund projects.
• To ensure allocation of resources to projects that address local, regional, and statewide
priorities and needs.

Project delays and escalating costs are discouraging to everyone involved. Projects that are
ultimately built but do not meet expectations in addressing needs are also frustrating. This
project development framework, and the principles that it embraces, will:
• Help carry out projects effectively;
• Ensure good project planning, design, and implementation; and,
• Set the stage for long-term success.
 Project implementation
Implementation is the carrying out, execution, or practice of a plan, a method, or any design,
idea, model, specification, standard or policy for doing something. As such, implementation is
the action that must follow any preliminary thinking in order for something to actually happen.
Implementation is defined as a specified set of activities designed to put into practice an activity
or program of known dimensions. According to this definition, implementation processes are
purposeful and are described in sufficient detail such that independent observers can detect the
presence and strength of the "specific set of activities" related to implementation. In addition,
the activity or program being implemented is described in sufficient detail so that independent
observers can detect its presence and strength.
It is common to read about "implementation" of a program or practice as if it were an
accomplished fact when the context of the statement makes it clear that some process (more or
less clearly described) had been put in place to attempt the implementation of that program or
practice. When faced with the realities of human services, implementation outcomes should not
be assumed any more than intervention outcomes are assumed.
Project implementation (or project execution) is the phase where visions and plans become
reality. This is the logical conclusion, after evaluating, deciding, visioning, planning, applying
for funds and finding the financial resources of a project.
Objectives of the Implementation Phase

The objectives of the implementation phase can be summarised as follow:
 Putting the action plan into operation (PHILIP et al. 2008).

 Achieving tangible change and improvements (PHILIP et al. 2008).
 Ensuring that new infrastructure, new institutions and new resources are sustainable in
every aspect (MORIARTY et al. 2007).
 Ensuring that any unforeseen conflicts that might arise during this stage are resolved
(MORIARTY et al. 2007).
 Ensuring transparency with regard to finances (MORIARTY et al. 2007).
 Ensuring that potential benefits are not captured by elites at the expenses of poorer social
groups (MORIARTY et al. 2007).
The basic requirement for starting the implementation process is to have the work plan ready and
understood by all the actors involved. Technical and non-technical requirements have to be
clearly defined and the financial, technical and institutional frameworks of the specific project
have to be prepared considering the local conditions. The working team should identify their
strengths and weaknesses (internal forces), opportunities and threats (external forces). The

strengths and opportunities are positive forces that should be exploited to efficiently implement a
project. The weaknesses and threats are hindrances that can hamper project implementation. The
implementers should ensure that they devise means of overcoming them. Another basic
requirement is that the financial, material and human resources are fully available for the
implementation” (NETSSAF 2008). Other actions need to be taken before work can begin to
implement the detailed action plan, including:
 Scheduling activities and identifying potential bottlenecks.

 Communicating with the members of the team and ensuring all the roles and
responsibilities are distributed and understood.
 Providing for project management tools to coordinate the process.
 Ensuring that the financial resources are available and distributed accordingly.
Tips for Implementing Successful Projects

(Adapted from PHILIP et al. 2008)
 Field management staff must make time to establish an atmosphere of candour and trust
with partners during implementation so that concerns may be raised (and often resolved)
informally.
 Realistic long-term planning of finances is key to the implementation of an action plan
(see also financing and sources of funding).
 A communication strategy can be used to raise awareness of the positive benefits for the
community, as well as explaining that there are necessary trade-offs, such as the
introduction of water pricing, which will not please everybody. This will help to further
strengthen local ownership of the plan and encourage public participation in the
implementation of projects.
 At the end of a planning and implementation cycle, a press release is useful to highlight
successful stories and announce the publication of a final document such as a water report
(see also media campaigns).
 Expectations among stakeholders and the general public are likely to be high following
the participatory approach to the development of the preceding stages of the planning
process. It is therefore important that actions are visible and demonstrate tangible results
early to build confidence in the process.
Advantages
 Implementation gives the opportunity to see the plans become a reality
 Execution of projects allows end-users to have access to better services and living
environment
 Success stories and experiences can be shared with specialists from other cities and
towns, encouraging others to adopt similar approaches, which in turn may improve water
resources management in the local area
Disadvantages
 Evidence of corrupt practices in procurement will undermine the entire process and waste
precious resources (PHILIP et al. 2008)
 Poor financial planning can lead to budget constraints in the midst of implementation
 The decision on when a project is complete often causes friction between implementers
and the community. Completion for the implementer is quite straightforward. It is defined

by contracts, drawings, and statutes. Communities have a more practical approach to
completion. Once the project produces the benefits for which they agreed to undertake it
they see no reason to spend further time and money on it (DFID 1998)
 Project monitoring
What is Monitoring?
Monitoring is the regular observation and recording of activities taking place in a project or
programme. It is a process of routinely gathering information on all aspects of the project.
To monitor is to check on how project activities are progressing. It is observation; ─ systematic

and purposeful observation.
Monitoring also involves giving feedback about the progress of the project to the donors,
implementers and beneficiaries of the project.
Reporting enables the gathered information to be used in making decisions for improving project
performance.
Purpose of Monitoring:
Monitoring is very important in project planning and implementation.
It is like watching where you are going while riding a bicycle; you can adjust as you go along
and ensure that you are on the right track.
Monitoring provides information that will be useful in:
 Analysing the situation in the community and its project;

 Determining whether the inputs in the project are well utilized;
 Identifying problems facing the community or project and finding solutions;
 Ensuring all activities are carried out properly by the right people and in time;
 Using lessons from one project experience on to another; and
 Determining whether the way the project was planned is the most appropriate way of
solving the problem at hand.
 Project review
These activities have many names: Project Reviews, Debriefs, Retrospectives, Post Project
Reviews, Mid Project Reviews, Project Audits, and Lessons Learned.
Most often called Postmortems on software projects, Project Reviews are examinations of
projects or events for the purposes of:
 Reviewing the events that occurred.

 Evaluating not only what happened, but also why those events happened.
 Determining the correct actions to take to improve the results of the next event or project.

Project Reviews can occur at any time during a project and can be used to evaluate the success of
both events and projects
Goals of a Project Review?
 Put into place a set of documented, well-understood procedures and guidelines that are
available to all participants prior to the event.
 Make clear to all participants that the process will be positive and blame-free.
 Provide an environment that fosters openness and candor.
 Ensure that lessons learned from Project Reviews are shared widely and have a positive
effect on future projects.
 Provide an appropriate balance between the cost of Project Reviews (precious people
time) and the return on investment to the team and organization. This includes the benefit
of getting closure, as well as insight into root causes and their effects, and actions taken -
real changes in behavior on the part of the organization.
 Provide a flexible set of tools and methods that will allow project teams of all sizes and
complexity to analyze significant project events and synthesize the findings into a plan of
action for remediation.
 Provide a link from lessons learned to solutions implemented on future projects.
The program (or project) evaluation and review technique, commonly abbreviated PERT, is
a statistical mathematics tool, used in General project management, which was designed to
analyze and represent the tasks involved in completing a given project. First developed by the
United States Navy in the 1950s, it is commonly used in conjunction with the critical path
method (CPM), in U.S. Navy original year 1950. The "mathematics matrix is PERT table"
(Operation, Prepared - operation, Time) evaluation’s - Vectorial - Program in Quantitative
Matrixes.
Why do a Project Review? (What are the Benefits?)
Lessons learned from Project Reviews are useful from many perspectives. The real benefit from
Project Reviews is the opportunity to step back and tack a deeper look into the system. During
the throes of delivery when a problem is observed, the inclination is to fix things quickly without
a thorough examination of what is really happening. We call this the ready, fire, aim approach.
Sometimes this works. We get lucky; smart team members use their insight to aim the arrow
correctly. Project Reviews that follow this process allow us to take a deeper look and examine
the underlying values, practices, and assumptions that got us in trouble in the first place. We can
then precisely craft an appropriate solution and monitor the solution carefully.
What's in it for Management?
 Management benefits by gaining insight into the way that the organization is working.
 It enhances our ability to distinguish between common causes and special causes of
variation in the project development process.

 The organization can work collaboratively towards a common understanding of the
system.
 It builds common metrics so we can track our efforts across projects.
 It provides an opportunity to exercise fact based management.
 It facilitates the development of a clearer vision of improvement in the system.
 It helps in visualizing what change would look like.
What's in it for Teams?
 Teams learn how roles and responsibilities can be redesigned to enhance product
development.
 It provides an historical link through which we can build or accumulate theory and
knowledge.
 It provides an opportunity for teams to take effective action and have control over the
future that increases job satisfaction, morale, and our ability to take joy in work.
 Teams can build on their understanding of common assumptions.
 It provides a structured process for developing shared learning and shared meaning.
What's in it for Project Managers?
 Project managers learn how to improve project management methods and infrastructure
to enhance productivity and ensure that project goals are met.
 It helps us identify and work towards common, known, related goals.
 It separates the people from the system.
 It provides different points of view and perspectives so we can evaluate our assumptions.
 It enhances our understanding of the current reality.
What's in it for Individual Contributors?
 Individual contributors learn how to improve tasks and deliverables to increase

effectiveness.
 It increases our understanding of key elements needed to support productive work.
 It helps us see how our actions impede or enhance the success of the project.
 It reveals weakness and strengths in our project documentation and communication
methods.
 It provides an opportunity to get closure.

TOPIC 3
PROJECT SCOPE MANAGEMENT

Project scope is the part of project planning that involves determining and documenting a list of
specific project goals, deliverables, tasks, costs and deadlines.
The documentation of a project's scope explains the boundaries of the project, establishes
responsibilities for each team member and sets up procedures for how completed work will be
verified and approved. The documentation may be referred to as a scope statement, statement of
work (SOW) or terms of reference. During the project, this documentation helps the project team
remain focused and on task.
The scope statement also provides the project team leader or facilitator with guidelines for
making decisions about change requests during the project. It is natural for parts of a large
project to change along the way, so the better the project has been "scoped" at the beginning, the
better the project team will be able to manage change. When documenting a project's scope,
stakeholders should be as specific as possible in order to avoid scope creep, a situation in which
one or more parts of a project ends up requiring more work, time or effort because of poor
planning or miscommunication.
Effective scope management requires good communication to ensure that everyone on the team
understands the scope of the project and agrees upon exactly how the project's goals will be met.
As part of project scope management, the team leader should solicit approvals and sign-offs from
the various stakeholders as the project proceeds, ensuring that the finished project, as proposed,
meets everyone's needs.
Plan Scope Management
 Scope Management Plan: how the scope will be defined, validated and
controlledincluding how to prevent scope creep, how to handle change requests,
escalation path for disagreement on scope elements between stakeholders, process for
creating scope statement, WBS, processing Change Request, how the deliverables will be
accepted
 Requirements Management Plan: how the requirements will be managed, documented
and analyzed,including how to process requirements, address missed requirements,
configuration management, prioritize requirements, metrics (and rationale) for defining
the product, define the traceability structure (in RTM requirement traceability
matrix), authorization level for approving new requirements
 important: primary means to understand and manage stakeholder expectations
Collect Requirements
 Requirement: a condition/capability that must be met /possessed by a deliverable to

satisfy a contract/standard/etc., including quantified/documented needs, wants,
expectation of the sponsor/stakeholder/customer

 Business requirements – support business objectives of the company
 Stakeholder requirements
 Solution requirements – functional (product behavior)
and nonfunctional requirements (reliability, security, performance, safety, etc.)
 Transitional requirements : temporary capability including data
conversion/tracking/training
 Project requirements : actions/processes/conditions the project needs to met
 Quality requirements : quality criteria defined by stakeholders
 Requirements Collection Tools
 interviewing (expert interviewing)

 focus groups (with SME and pre-qualified stakeholders)
 facilitated workshops (QFD (Quality Function Deployment) – capture VOC voice
of customer, translate customer needs into requirements; JAD (Joint Application
Design) – facilitated workshop for IT and knowledge workers)
 questionnaires and surveys
 observation (shadowing or Gemba)
 prototypes
 context diagrams (diagrams showing input/source and output, to show how
people interact with the system)
 document analysis
 Group Creativity Techniques: brainstorming, nominal group technique (to rank

brainstormed ideas by voting anonymously), mind-mapping, affinity diagram (KJ
method – group ideas into larger categories based on their similarity and give titles to
each group), Delphi technique (for experts with widely varying opinions, all participants
are anonymous, evaluation of ideas funneled by a facilitator), Multi-criteria Decision
Analysis (with a decision matrix)
 Group Decisions-making Techniques: Analytic Hierarchy Process (AHP, for complex
decisions, give different weights to factors to build an hierarchy), Voting (unanimous,
majority >50%, plurality, dictatorship)
 Requirements Traceability Matrix tracks requirements from origins to deliverables,
including source of requirements and completion status, effective to prevent gold plating
(also work with work authorization system)
 requirement documentation needs to be unambiguous, traceable, compete, consistent
and acceptable to key stakeholders and is approved by the customer and other
stakeholders

 Scope definition
Define Scope
 Project& product scope, outlines what will be and what will NOT be included in the
deliverables, including details of risks, constraints and assumptionsvs project
charter which includes high-level descriptionsprovides alternatives if the budget and
schedule could not meet management’s expectations.
 Product analysis includes techniques such as product breakdown, systems analysis,
requirements analysis, systems engineering, value engineering, and value analysis.
 Value engineering is a part of the product analysis technique (Value Engineering (value
analysis, value management, value methodology) – finding alternatives to constraints to
improve product/reduce cost without sacrificing the scope)
 Project scope statement includes objectives, (project and product) scope, requirements,
boundaries, deliverables, acceptance criteria, constraints, assumptions, milestones, cost
estimation, specifications, configuration management requirements, approval
requirements, etc.
 The scope statement is progressively elaborated
Create WBS( work breakdown structures)
 the WBS must be created (if you take on a running project without WBS, stop the
project and prepare the WBS first)
 WBS is a structured hierarchy created by the organization/stakeholders, can be in an
organization chart or table form, based on the project deliverables (not tasks needed).
 can be a template in OPA
 a higher level above a work package is ‘control account‘ (control point where scope,
cost and schedule are compared to earn value for performance measurement), a work
package can have only ONE control account
 WBS includes 100% of scope (100% rule)
 code of accounts: a numbering system to identify WBS components
 chart of accounts: a list of all account names and numbers
 1.1 for the 2nd level, 1.1.1 for the 3rd level
 WBS is a decomposition tool to break down work into lowest level manageable (time and
cost can be estimated, work package can be assigned to a team member) work packages,
e.g. by phase or major deliverables
 different work packages can be at different levels of decompositions
 WBS does not show dependencies between work packages, but a WBS dictionary does
(WBS dictionary clarifies WBS by adding additional information)
 the major deliverables should always be defined in terms of how the project will actually
be organized, for a project with phases, the decomposition should begin with the phase
first
 scope baseline, an output from Create WBS, is created by the project team
 The work packages are broken down enough to delegate to a staff, usually. 8 – 80 hours
work

Validate Scope
 Gain formal acceptance of deliverables from customer/stakeholders (e.g. obtain

customer sign off, requirements validations, etc.) near the end of project/phase/each
deliverable, e.g. user acceptance test
 work performance data tells how the deliverables were created, work performance data
includes non-conformance and compliance data
 change requests may be an output
 if no formal sign off is received as stipulated, follow the pre-defined process in PM plan,
e.g. escalation to management
 often preceded by Control Quality Process to give the verified deliverable as input to
this process, verified deliverables is fed from the control quality process
 vs Control Quality: the process of monitoring/recording results of executing quality
activities to assess performance and recommend necessary changes, e.g. unit testing -high
quality vs low quality
 need to perform even in case of early termination/cancellation of the project to save
any usable deliverables for other projects
Control Scope
 assessing additional requirements by the customer or proactively overlooking the

project scope
 measure the work product against the scope baseline to ensure the project stays on track
proactively, may need preventive, corrective actions or defect repair
 to prevent unnecessary changes (either internally or externally requested) to the
project
 a documented and enforced change control process
 the customer has the ultimate authority to change scope while the senior management
can make use of management reserves
 variance analysis – method to compare planned (baseline) and actual work and
determine the causes/actions e.g. update baseline (keep the variance) or
preventive/corrective actions, both need CR
 work performance info – scope variance, causes, recommended action
 may update the inputs – requirements documentation & requirement traceability matrix
& lessons learnt in OPA
 in general, disagreement should be resolved in favor of the customer
 Scope verification
Scope Verification is the process by which the project manager gets "the formalized
acceptance of the completed project deliverables”. The scope of the project in its inherent
sense is the work, which must be done to meet the required targets. But whether the work has
successfully been done or not can only be measured by comparing the generated targets of
the project with the required targets. Nevertheless, scope verification is "obtaining the

stakeholders' formal acceptance" by commonly “reviewing the deliverables to ensure that
each is completed satisfactorily"
 Scope control
Scope Control is the process of "controlling changes to the project scope". Naturally the
project management has to manage scope changes too. The world is a collection of changes.
Therefore changes are allowed. But they must be integrated into the existing project scope
statement by referring to a defined change process. Undocumented 'by the way'-changes are
not state of the art. Hence scope control is both: avoiding of "unaccepted" new workpackages
and integrating "accepted" new workpackages into the project scope statement and/or into the
WBS.
Tools and Techniques
Mentioned Methods
 A Change Control System is a documented process by which the scope can officially be
changed
 The Variance Analysis determines the causes of variances relative to the scope baseline
 Re-planning can be evoked by the approved change requests and may be realized by
modifications of the WBS, the WBS Dictionary and so on.
 The Configuration management system is a system for identifying releases of
deliverables
 Using a software tool to assist in project scope management

TOPIC 4
PROJECT PLANNING
Project planning is part of project management, which relates to the use of schedules such as
Gantt charts to plan and subsequently report progress within the project environment.
Initially, the project scope is defined and the appropriate methods for completing the project are
determined. Following this step, the durations for the various tasks necessary to complete the
work are listed and grouped into a work breakdown structure. Project planning is often used to
organize different areas of a project, including project plans, workloads and the management of
teams and individuals. The logical dependencies between tasks are defined using an activity
network diagram that enables identification of the critical path. Project planning is inherently
uncertain as it must be done before the project is actually started. Therefore the duration of the
tasks is often estimated through a weighted average of optimistic, normal, and pessimistic cases.
The critical chain method adds "buffers" in the planning to anticipate potential delays in project
execution. Float or slack time in the schedule can be calculated using project management
software. Then the necessary resources can be estimated and costs for each activity can be
allocated to each resource, giving the total project cost. At this stage, the project schedule may be
optimized to achieve the appropriate balance between resource usage and project duration to
comply with the project objectives. Once established and agreed, the project schedule becomes
what is known as the baseline schedule. Progress will be measured against the baseline schedule
throughout the life of the project. Analyzing progress compared to the baseline schedule is
known as earned value management.
The inputs of the project planning phase 2 include the project charter and the concept proposal.
The outputs of the project planning phase include the project requirements, the project schedule,
and the project management plan.
The Project Planning can be done manually. However, when managing several projects, it is
usually easier and faster to use project management software.
Project planning is a discipline for stating how to complete a project within a certain timeframe,
usually with defined stages, and with designated resources. One view of project planning divides
the activity into:
 Setting objectives (these should be measurable)
 Identifying deliverables
 Planning the schedule
 Making supporting plans
Supporting plans may include those related to: human resources, communication methods, and
risk management.
Computer hardware and software project planning within an enterprise is often done using a
project planning guide that describes the process that the enterprise feels has been successful in
the past.
Tools popularly used for the scheduling part of a plan include the Gantt chart and the PERT
chart.

Defining the Project Tasks, Cost and Schedule

Cost & Schedule Estimates
• The principal measures of a project are cost, time (schedule) and performance
• For a given project one or more of these measures may be constrained.
• Initial estimates on cost and schedule are essential to determine if your plan is realistic
o May need to plan for (or implement) trade-offs according to established priorities
• Cost and schedule needs to be monitored throughout the project life-cycle
Steps to defining the project tasks
Determine the primary characteristics of the project

• Establish the project scope
• Establish the project priorities
Determine how best to organize the project tasks

• Organization by deliverable
• Organization by process
• Combination of two
Create the Work Breakdown Structure (WBS)

• Establish highest level, most general tasks
• Establish “tree structure” of lower level tasks
• Lowest level used to identify “work packages
Determining the project scope

Defining the project scope is a necessary precursor to developing an effective project plan.
Determining the scope includes addressing the following questions:
• What are the major objectives for the project?
• What are the major deliverables or outputs over the life of the project and when are
they due?
• What are the significant events or milestones that will happen during the project?
• What technical requirements must be satisfied?
• What are the project constraints or limits that must be taken into account?

This effort goes hand-in-hand with development of the system requirements.
Determining the project priorities
Better
Faster Cheaper
The primary measures of a project are in terms of cost, schedule and performance
Usually very difficult (impossible?) to enhance or optimize all three of these measures at the
same time
Establishing the priorities at project start provides guidance for trade-offs
Organizing the project tasks

Are tasks focused on producing a tangible result?
• Project and tasks are structured by concrete products or deliverables (e.g. building
a hydroelectric dam)
• Task definitions breakdown into sub-deliverables, further sub-deliverables and
work packages
• Can be run in a highly parallel fashion
Are tasks focused on processes or phases?
• Project evolves over time where results from one phase affect tasks in subsequent
phases
• Tasks and “deliverables” defined as outputs needed to move to next phase
Many aerospace projects are actually a combination of these two structures
• Phases allow new innovations to be defined and developed
• Tangible results (e.g. spacecraft) occur during the project
The Work Breakdown Structure
NASA definition of the WBS
• A family tree subdivision of effort to achieve an end objective
• Developed by starting with the end objective required and successively subdividing it
into manageable components in terms of size and complexity
• Product or task oriented and should include all the effort necessary to achieve the end
objective

MIL-HDBK-881 definition of the WBS
• Product-oriented family tree composed of hardware, software, services, data, and facilities.
A WBS displays and defines the product, or products, to be developed and/or produced.
• Relates the elements of work to be accomplished to each other and to the end product
• Expressed down to any level of interest. However the top three levels are as far as any
program or contract need go unless the items identified are high cost or high risk.
Why use a WBS?
• Identifies the tasks, subtasks and units of work necessary to complete the project
• Identifies the relationships between tasks
• Increases the probability that every requirement will be accounted
• Organize areas of responsibility and authority
• Used to estimate project cost and schedule
• Can be used to track the costs of each element
• Can be used to monitor progress by completion of tasks
WBS Structure
The WBS has a hierarchical structure
• Most general units at the highest level
• Most specific units at the lowest level
Use a “tree structure” to provide task details
WBS Subunits
Each WBS subunit is a deliverable of some kind
• Entities necessary for exiting the current phase such as system requirements, ICD documents,
test results, etc.
• Concrete products such as power system, real-time clock software module, sensor readout
system, etc.
Lowest WBS level is defined by Work Packages
The content of a Work Package includes:
• Description of the work to be done including a time schedule
• The resources needed and the cost of the work
• The person responsible for assuring the work is completed
Multiple work packages may be needed for each low level WBS unit
A sum or “roll up” of the Work Packages yields a cost and time estimate for the unit

Steps to developing the estimates
 Develop the general project definition and set of tasks
 Perform a rough cost and time estimate
 Develop the detailed project definition, tasks and WBS
 Estimate the cost and time for each individual, lowest level element of the WBS
 Roll-up (add) the cost and time for each low level WBS elements to obtain the estimates
for higher level elements
 Establish the project schedules
 Reconcile differences between the macro and micro estimates
Factors affecting the estimate

 Task Definition: The completeness of your project definition will determine if all tasks
have been taken into account.
 People Productivity: People do not focus on a task with 100% efficiency. The difference
between “calendar time” and effort must be considered.
 Project Structure: A dedicated project team will be able to focus its effort on
completing the project effectively.
 Padding: People may increase estimates to take into account unknown risks and this may
force an unnecessary trade-off.
 Culture: What is deemed acceptable behavior by the organization (e.g. padding vs.
accuracy) will affect estimates.
 Downtime: Equipment repairs, holidays, vacations, exam schedules can all affect the
time estimate.
Estimating Techniques
 Scaling: Given a cost for a previous project then an estimate for a new project can be
scaled from the known cost. E.g. NASA, at times, uses spacecraft weight to estimate
total cost.
 Ratio: Costs for subunits of the new project would be proportional to similar subunits in
a previous project. For example, if it takes 1 day to build & test a particular sensor unit,
then an instrument with 10 sensors would take 2 technicians, 5 days to complete.
 Learning Curve: If the same task is repeated a number of times there will be a cost /
time savings relative to the first time the task is done.
 WBS Roll-up: Times and costs associated with the lowest level WBS work packages are
estimated and then these are added or rolled-up to yield the costs for higher level units.

Guidelines for Estimates
• Estimates should be done by the person most familiar with the task
• If possible obtain estimates from several people and use the variance for risk assessment
• Multiple estimates should be done independently to avoid “GroupThink”
• Base the estimates upon normal conditions.
• Use consistent units when estimating task time.
• Work package estimates should not include contingencies
• Use a separate risk assessment for estimating the effect of abnormal conditions and
contingencies.
Example WBS Cost Roll-up
The factors that determine task priority

Is it common to assign a task's priority based solely on its due date? For example, is the
following system valid for all scenarios?
Urgent = less than 24 hours
High = Not more than 24 hours
Medium = 24 to 48 hours

Low = within the business week
None = no set timeframe
Here's the question: is it not possible to have a High priority item that must be done on 22
December, 2012? So with this task, I'm assuming that the severity (impact) of it not being
accomplished on that date is being taken into account when assigning it a priority of "High".
Hope the question makes sense. To make things simple, what factors determine a task's priority?
Would it be:
a. Timeline
b. Severity
c. Both
Any other factors that should be taken into account to determine a task's priority.

A work breakdown structure (WBS), in project management and systems engineering, is a
deliverable-oriented decomposition of a project into smaller components. A work breakdown
structure is a key project deliverable that organizes the team's work into manageable sections.
The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure
as a "deliverable oriented hierarchical decomposition of the work to be executed by the project
team."
A work breakdown structure element may be a product, data, service, or any combination
thereof. A WBS also provides the necessary framework for detailed cost estimating and control
along with providing guidance for schedule development and control.
Example of a product-oriented work breakdown structure of an aircraft system.

 Milestones schedules
Milestones are tools used in project management to mark specific points along a project
timeline. These points may signal anchors such as a project start and end date, a need for external
review or input and budget checks, among others. In many instances, milestones do not impact
project duration. Instead, they focus on major progress points that must be reached to achieve
success.
Milestones can add significant value to project scheduling. When combined with a scheduling
methodology such as Program Evaluation and Review Technique (PERT) or the Critical Path
Method (CPM), milestones allow project management to much more accurately determine
whether or not the project is on schedule. By constraining the dates associated with milestones,
the critical path can be determined for major schedule intervals in addition to the entire project.
Slack/float can also be calculated on each schedule interval. This segmentation of the project
schedule into intervals allows earlier indication of schedule problems and a better view into the
activities whose completion is critical.
Milestones are frequently used to monitor the progress, but there are limitations to their
effectiveness. They usually show progress only on the critical path, and ignore non-critical
activities. It is common for resources to be moved from non-critical activities to critical activities
to ensure that milestones are met. This gives the impression that the project is on schedule when
actually some activities are being ignored.
Milestones are like dashboard reviews of a project. Number of activities which were planned at
the beginning of the project with their individual timelines are reviewed for their status. It also
gives an opportunity to check the health of the project.

Understanding Task Dependencies in Project Management
Dependencies are the relationships among tasks which determine the order in which activities
need to be performed. There are four (4) types of dependency relationships.
 Types of dependencies
Finish to Predecessor must finish before Successor can start. [Land

Start must be purchased before road building can start]
Start to Predecessor must start before Successor can start. [Road

Start excavating must start before Asphalt can be laid]

Finish to Predecessor must finish before Successor can finish.
Finish [Laying Asphalt must be complete before line painting
can be completed]
Start to Predecessor must start before Successor can finish. [Road

Finish excavating must start before line painting can be
completed
Dependencies are the relationships of the preceding tasks to the succeeding tasks. Tasks may
have multiple preceding tasks and multiple succeeding tasks. The mostmost common dependency
relationship is a finish-to-start
start relationship. Task P (predecessor) must be finished before task S
(successor) can start. The least common relationship is the start-to-finish
start finish relationship. Project
Insight, project management software, supports all four dependency relationships.
In a project network, a dependency is a link amongst a project's terminal elements
The A Guide to the Project Management Body of Knowledge (PMBOK Guide) does not define
the term dependency, butt refers for this term to a logical relationship,, which in turn is defined
as dependency between two activities, or between an activity and a milestone.
milestone
Standard types of dependencies
There are four standard types of dependencies:
1. Finish to start (FS)

o A FS B means "B can't start before A is finished", or in other words, "activity A
must be completed before activity B can begin".[2]
o
o (Foundations
undations dug) FS (Concrete poured)
2. Finish to finish (FF)
o A FF B means "B can't finish before A is finished" or in other words "activity A
must be complete before activity B can finish".[2]
o (Last chapter written) FF (Entire book written)

3. Start to start (SS).
o A SS B = B can't start before A starts or in other words Activity B can start after
started [2]
Activity A has started.
o (Project work started) SS (Project management activities started)

4. Start to finish (SF)
o A SF B = B can't finish before A starts
o (New
w shift started) SF (Previous shift finished)
Finish-to-start
start is considered a "natural dependency". The Practice Standard for Schedul
Scheduling
recommends, that "Typically , each predecessor activity would finish prior to the start of its
successor activity (or activities)(known as finish-to-start
finish start (FS) relationship). Sometimes it is
necessarily to overlap activities; an option may be selected to use start-to-start
start (SS), finish
finish-to-
finish (FF) or start-to-finish
finish (SF) relationships....Whenever possible, the FS logical relationship
should be used. If other types of relationships are used, they shall be used sparingly and with full
understanding of how the relationships have been implemented in the scheduling software being
used. Ideally, the sequence of all activities will be defined in such a way that the start of every
activity has a logical relationship from a predecessor and the finish of every activity has a logical
relationship to a successor".
SF is rarely used, and should generally be avoided. Microsoft recommends to use SF dependency
for just-in-time
time scheduling. It can be easily shown however, that this would only work in case
resource levelling is not used, because resource levelling can delay a successor activity (an
activity, which shall be finished just-in-time)
just time) in such a way, that it will finish later th
than the start
of its logical predecessor activity, thus not fulfilling the just-in-time
just time requirement.

There are three kinds of dependencies with respect to the reason for the existence of dependency:
1. Causal (logical)
o It is impossible to edit a text before it is written
o It is illogical to pour concrete before you dig the foundations of a building
2. Resource constraints
o It is logically possible to paint four walls in a room simultaneously but there is
only one painter
3. Discretionary (preferential)
o I want to paint the living room before painting the dining room, although I could
do it the other way round, too
Early critical path-derived schedules often reflected only on causal (logical) or discretionary
(preferential) dependencies because the assumption was that resources would be available or
could be made available. Since at least the mid-1980s, competent project managers and
schedulers have recognized that schedules must be based on resource availability. The critical
chain method necessitates taking into account resource constraint-derived dependencies as well.
Leads and Lags
Dependencies can be modified by leads, and lags. Both leads and lags can be applied to all 4
types of dependencies.
PMBOK defines lag as "the amount of time whereby a successor activity will be delayed with
respect to a predecessor activity".
For example: When building two walls from a novel design, one might start the second wall 2
days after the first so that the second team can learn from the first. This is an example of a lag in
a Start-Start relationship.
In accordance to PMBOK a lead is "the amount of time whereby a successor activity can be
advanced with respect to a predecessor activity For example, on a project to construct a new
office building, the landscaping could be scheduled to start prior to the scheduled punch list
completion. This would be shown as a finish-to-start with two-week lead".[1]
Example
If you are building a building, you can't paint the walls before putting the water pipes into the
walls. Well, maybe you can, but it is going to be expensive, because you need to tear down the
wall, put the pipes, test them, then fill the holes and finally paint.
It would be much faster and less expensive, to put the pipes first, put the cement to actually build
the wall around the pipes, and finally paint the walls.

Advanced cases of activities dependencies
Maximal-Type Relationships
Activity A and Activity B are said to have a Maximal-Type Relationship, if Activity B can start
after Activity A, but with the delay of no more than X. Real life examples, which are simulated
by Maximal-Type Relation:
 Shoring of the trench has to be done not necessarily immediately after excavation, but
within certain time, otherwise the trench will collapse.
 Vaccination of baby has to be done not immediately after birth, but within certain time
 Renewal of the passport has to be done some time after the current one has been issued,
but before it expires.
 Invoice payment does not have to be done immediately, but within certain time after it
has been issued.
Maximal-type relationships are rarely implemented in the project management software, most
probably because with this feature it is too easy to create contradictory dependencies.
Build dependency
The process of converting source code (human readable form) to executable code (computer
executable form), is called compilation.
Projects can be compiled separately, meaning that one project can be converted into a library that
other projects use to compile, thus each project can be compiled without having to compile the
other at the same time.
Projects are said to depend on their libraries, since without their respective libraries they can't
compile, while libraries can compile without the other being around.
These dependencies are also called build dependencies, for obvious reasons. As you can imagine,
circular dependencies are very bad, because it means you can't compile from scratch.
One way to avoid this is to have a machine dedicated to compile from scratch (like Jenkins),
using a build script (like Maven
Overview
Project management enables you to create child tasks that are nested under a parent task and
successor tasks that are dependent on the completion of a predecessor task. This page explains
how to create such relationships and dependencies.

To create and editit portfolios, projects, and tasks, users must have the project manager role in
their user profile record.
Key Concepts and Terms for This Topic
 Predecessor task: a project task that, upon completion, is followed by another task. A
predecessor task has a dependent relationship with its successor task.
 Successor task: a project task that cannot start until another task finishes. The successor
task has a dependent relationship with its predecessor task.
 Lag time: a manually specified time break between predecessor and successor tasks.
Configure a lag time, if necessary, when creating a predecessor-successor
predecessor successor dependency.
The system applies the project schedule in the v3 application (available starting with the Dubl
Dublin
release). For the v2 application, the system converts lag time to hours and does not consider the
project schedule when applying lag time.
 Parent task: a project task with smaller tasks, referred to as child tasks, underneath it.
Child tasks break down the work of a parent task into more manageable subsets. Certain
fields for child tasks, such as planned end date, roll up and affect the same field in the
parent task.
 Child task: a project task that is a subset of a larger task. Child task start dates ccannot
occur before the start date of the parent task.
 Rollup task: another term for a parent task in the context of aggregating child task items,
such as effort or resources, into a larger parent task calculation. All fields on rollup task
forms are read-only
only in the v3 application.
 Roll down: state changes roll down from the project to project tasks, and from parent
tasks to child tasks in the v3 application.
Task Dependencies
A finish-to-start dependency
A task dependency is created when one task is forced to start after another task finishes. For
example, subtask 17.8 can only start when the State field of subtask 17.7 changes to Closed. The
Project application only supports this kind of dependency, referred to as a finish-
finish-to-start
dependency.

Creating a Task Dependency
The easiest way to create a task dependency is with the Gantt chart.
Another option is to use related lists to create dependencies:
1. If the successor task does not already exist, navigate to the project form and create it.
Do not create the task from the predecessor task form. Doing so creates a parent-child
relationship.
2. Navigate to the predecessor task.

3. Configure the related lists for the Project Task form and add Planned Task Relationship
> Parent. Do not select Predecessor of or Successor of.
This adds the Planned Task Relationships related list to the Project Task form. This
related list shows successor tasks.
4. In the Planned Task Relationships related list, click New.

5. On the Planned Task Relationship form, click the lookup icon and select the appropriate
successor task.
6. Verify that the relationship Type is Predecessor of::Successor. Do not change this
relationship type.
7. Enter the Lag time, if any, in either days or hours.
o In the v3 application, the lag time takes the project schedule into consideration. If
the lag time is 10 hours and the default schedule of an 8-hour work day is in use,
the lag time pushes the task to the following day to cover the additional hours.
o In the v2 application, the system converts the lag time to total hours. Therefore, a
lag value of 1 day is equivalent to 24 hours. The lag time does not take the project
schedule into consideration.
8. Click Submit.
Task Time Constraints

The Project Task form includes theTime Constraint field: either Start ASAP or Start on
specific date.
 If the successor task is set to Start ASAP:
The successor task appears on the Gantt chart as starting immediately after the
predecessor completes without any lag time. However, the successor task can start on a
later date if it has a value in the Lag field. To enter a lag value, double-click the
relationship line in the Gantt chart and enter a Lag value. Alternatively, open the
predecessor task and enter a Lag value for the successor task in the Planned Task
Relationships related list.
 If the successor task is set to a Start on Specific Date that is later than the finish date of
the predecessor:

The successor task starts at the time specified. On the Gantt chart, a lag aappears just as if
you set the Lag value on the relationship. However, the actual Lag value is not actually
modified.
 If the successor task is set to a Start on Specific Date that is earlier than the finish date
of the predecessor:
ServiceNow changes the successor task time constraint to Start ASAP and the task starts
immediately after the predecessor finishes, unless a Lag value exists.
State Changes
hanges on Tasks in Dependencies
Dependencies do not affect the ability to change the state of predecessor or successor tasks. For
example, if a project is already in progress, you can still change a successor task to Work in
Progress even if the predecessor task has not finished. Also modify
modify the successor task to start on
specified date that is earlier than the planned end date of the predecessor. Although this would
violate the dependency for planning purposes, ServiceNow provides this kind of flexibility in
modifying the project. You can n also perform actions like closing a successor task, and then
opening a predecessor task. Although you are allowed to make these kinds of modifications to
predecessors and successors, the related project tasks and the way they are represented in the
Gantt chart might show unexpected results.
A successor task prematurely changed to Work in Progress
Modifying Dependencies
To modify an existing dependency from the Gantt chart:
1. Double click the relationship line in the Gantt chart.

2. Enter a different task
k in the Successor task field.
To modify an existing dependency from a related list:
1. Open the Project Task form for the successor task and click the existing predecessor task
in the Planned task relationships related list.
2. Enter a different task in the Successor field.

Removing Dependencies
Remove a dependency that is no longer necessary from either the Gantt chart or the Project Task
form. Removing the dependency also deletes the dependency record in the Planned Task
Relationship table.
To remove a dependency from the Gantt chart:
1. Double-click
click the relationship.
2. In the Planned Task Relationship form, click Delete.
To remove a dependency from the Project Task form:
1. Open the predecessor task in the Project Task form and go to the Planned Task
Relationships related list.
2. Select the check box beside the relationship being removed.
3. On the Actions on selected rows menu, select Delete.
Deleting the relationship record
Parent-Child
Child Task Relationships
If a task is relatively large and requires
requires several users with different skills to manage, break the
task into subtasks and create parent-child
parent child relationships. A child task should be a relatively
smaller, manageable size of work. When you group child tasks together under a parent, values
such as Estimated cost aggregate and roll up to the parent task. So the parent task takes on the
form of a summary task or rollup task for its child tasks. Planned start date and Planned end
date rollup occurs when you create child tasks: the duration of the parent
parent automatically adjusts
to cover its child tasks.

A parent-child
child relationship is different from a dependency relationship. In a dependency, one
task must finish before another begins. In a parent-child
parent child relationship, any number of tasks can be
nested under
der a parent task with or without any dependencies. When you create a parent
parent-child
relationship, the parent task number is saved in the Parent field in the Project Tasks table. All
project management tasks have a parent: either another project task or the project itself.
Creating a Parent-Child
Child Task Relationship
The easiest method is to create parent-child
parent relationships is on the Gantt chart.
To create parent-child
child relationships with related lists:
1. Navigate to the parent task in the relationship.

2. In the Project Tasks related list, click New.
The same Project Task form appears for all tasks regardless of the parent
parent-child
relationship.
3. Create the task and click Submit.
The newly created task becomes the child task in the relationship.
To help remember what the parent of any task is, view the breadcrumb at the top of the Project
Task form. It is also helpful to configure the form layout to include the Parent field.
The Parent
rent field. In this example the project is the parent.
Changing the Parent Task

To change the parent of a child task:
1. Navigate to the child task in the relationship.

2. Configure the form to add the Parent field, if needed.
3. In the Parent field, select the
the new parent task for this child task. To have the task stand
alone in the project, select a project instead of a task.
Modifying Parent-Child
Child Relationships
To modify a parent-child
child relationship by using the Gantt chart, drag a child task to any other tas
task
(no matter whether it is a child or parent task). If you drag a child task up to the project name, it
becomes a standalone task and is no longer considered a child task.

Moving a child task
To modify a parent-child
child relationship from a related list:
1. Navigate to the child task in the relationship.

2. Configure the form to add the Parent field if needed.
3. In the Parent field, select the new task that you want the child task assigned to. To have
the task stand alone in the project, select a project instead of a task.
Unlike a dependency, a parent-child

child relationship is not saved as a record in any table. The only
modification that takes place
lace when a parent-child
parent relationship is modified is the Parent field in
the child task record.
Time Constraints in Parent-Child

Parent Relationships
 If a child task is set to Start ASAP,

ASAP, the child task starts at the same time the parent task
starts (as long as it does not have dependencies with other child tasks).
 If the parent task is set to Start ASAP and child tasks are set to Start on specific date
date,
the earliest child task start date
date determines the start date of the parent (assuming no other
dependencies). In this case, the parent's Time constraint field remains Start ASAP but
the actual start date is changed to the start date of the earliest child task.
 If both the parent and first child task are set to Start on specific date but the first child
starts later than the parent, the parent start date remains Start on Specific Date but the
actual start date is pushed to the start date of the child. For example, if the parent task
starts on October 1 and the earliest child task starts on October 2, the Planned start date
of the parent is changed to October 2.
 Child precedence also applies to end dates. If the child task's estimated end date is later
than the parent task's end date, the parent
parent task's estimated end date extends to cover the
child. For actual values, a parent has the same start date as the earliest start date of its
children and the latest actual end date as the latest end date of its children, assuming the
child tasks are Closed Complete If the child tasks are not in the Closed Complete state,
osed Complete.
the actual end date of the parent is empty.
 For the planned start date of the parent task:

o The planned start date is the earliest planned start date of all the children that do
not have an actual start date.
o If all child tasks have actual start dates, the parent task's planned start date is set to
the actual start date.
 For the planned end date of the parent task, the latest planned end date or actual end date
of the child tasks determines the parent's planned end date.
Dependencies with Parent or Child Tasks

Options exist to create predecessor-successor relationships between child tasks with different
parents, between two different parent tasks, or between a child task and another parent task.
However, if the predecessor task finishes after the successor task starts, creating a dependency
between child tasks that have different parents is not allowed.
Parent-Child (Rollup) Task Calculations
Rollups involve date changes, state changes, and value calculations.
 Date changes involve modifying the planned start or end date of a parent task based on
those values in child tasks.
 State changes involve modifying the state of the project record or parent task records if
all child records are set to a certain state.
 Calculations involve summing the values of child tasks and then automatically updating
the parent to reflect a new total.
Rollups work differently on these fields in the v3 application (available starting with the Dublin
release):
 Planned Start date: set to read only for parent tasks. Remains editable for the project
record (also considered the top-level task).
 Planned End Date: becomes read only.
 Planned Duration: becomes read only.
 Actual Start Date: becomes read only.
 Actual end date: becomes read only.
 State: becomes read only.
Duration Rollups
Rollups are calculated for the following:
 Planned duration and planned effort: the sum of all planned duration and planned
effort values for all child tasks.
 Actual duration and actual effort: the sum of all actual duration and actual effort
values. Actual duration and actual effort values are calculated when all child tasks are in
the Closed Complete state. Actual effort values can include rollups from time cards.

Verify that the time card property Update the task's 'Actual effort' based on
Note:Verify
the hours entered in the time card is enabled. Navigate to Time cards >
Administration > Properties to enable this property.
Cost Rollups
Cost calculations roll up when the Project Management Costing Add-on
Add on is active.
 Estimated cost: the sum of all cost estimates at the beginning of a project. Estimated
costs of child tasks roll up to parent tasks and to the project.
 Actual cost: by default for the project, the sum of all costs of all the project's expense
lines, which are typically
ally associated with aa time card and a labor rate. To track costs,
define rate cards for the task and labor expenses. These rate cards automatically generate
expense lines showing actual expenditures, which are associated with the projects. If rate
cards are defined, the task expense lines are generated as each project task closes, and
labor expense lines are generated when time cards are approved. Expense lines are visible
in the Expense Lines related list, which requires the Advanced view on a both Proje Project
and Project Task forms.
For actual costs of child tasks to properly roll up to the project and be added to project expense
lines, the following must be true:
 The com.snc.project.rollup.cost property must be set to true.. To enable this property,

navigate to Project > Administration > Properties and select the Enable project cost
rollup check box.
 The glide.cost_mgmt.process_task_top_task property must be set to false. To enable this
property, navigate to Financial Management > Admin > Properties and se select the
When creating a task expense line should the system also create expense lines for the
task's top task check box.
 The glide.cost_mgmt.calc_actual_cost property must be set to true. To enable this
property, navigate to Financial Management > Admin > Properties and select the For
planned tasks types, calculate the actual cost field using the total of expense lines for
the task check box.
Enabling Cost Rollup Calculations
To use rollup calculations:
1. Navigate to Project > Administration > Properties.

Properties
2. Select Enable project cost rollup and click Save.
Rollup values are read-only

only on forms. Point to the icon beside the field for a tooltip message.

A rollup task for an estimated cost. The field is not directly editable on the parent.
Project State Rollups and Roll Downs

Project task states roll up. The state of parent tasks becomes read only in the v3 application, and
changes automatically when you change the states of child tasks.
Project task states can roll up if:
 The state of the child task is manually changed and there are no other conditions on the
parent task.
 The state of the child task is changed to Work in Progress or Closed.. These states roll
up to the parent. Pending and Open do not roll up to the parent task.
Project states can also roll down in the v3 application. If you change the state of a project to
closed, all tasks under it change to the default closed value (Closed
( Complete).). If a closed
project or closed task is reopened, all tasks under it change as follows:
 Project or parent
nt changed from closed to Pending or Open:: child tasks change to Open.
 Project or parent changed from closed to Work in Progress:
 Child tasks with a Start on date that has passed are changed to start ASAP and
the state is changed to Work in Progress.
 Child
ild tasks with a Start on date that has not yet passed retain the same start on
date but the state is changed to Open.
 Planning time scales
time scale - an arrangement of events used as a measure of duration; "on the geological time scale
mankind has existed but for a brief moment"
A major critical success factor for projects is to meet the deadline

dead
Some deadlines are pre-defined

defined by management or external
external forces; others are calculated by the
project manager

See the pptprovided
Scheduling tools and techniques

Project Managers can use a range of tools and techniques to develop, monitor and control project
schedules. Increasingly, many of these can be applied digitally (using programs such as Excel,
Microsoft Project and so on).
GANTT chart
This is a horizontal bar chart plotted over time (e.g. days, weeks or months). Each activity is
shown as a bar (its length based on a time estimate). Depending on task dependencies and
resource availability, these bars may be sequential, or run in parallel.
parallel. Each bar is plotted to start

at the earlier possible start date. The plan laid out when the GANTT Chart was created can be
compared with actual times taken (plotted below the planned time bars in the chart).
Schedule Network Analysis
The schedule network is a graphical display (from left to right across a page) of all logical
interrelationships between elements of work — in chronological order, from initial planning
through to project closure. As a project progresses, regular analysis of this network diagram are a
check to ensure the project is proceeding ‘on track’.
Critical Path Method
The critical path of a project is the sequential string of activities that takes the longest time to
complete, recognizing any dependencies between tasks in this sequence (e.g. one cannot start till
another finishes). Arrowed lines represent activities with circles at each end representing
milestones (start and finish).
The critical path method (CPM) determines by adding the times of all activities on the critical
path, the earliest time that the project can be completed
Non-critical activities have an earliest and latest start time (ES and LS, respectively) and an
earliest and latest finish time (EF and LF, respectively). The ES and EF are found by working
forwards through the project network and the LS and LF by working backwards. The difference
between the LF and EF of each activity have zero float; they must be done when planned or the
project overall will be delayed.
PERT (Program Evaluation and Review Technique)
PERT charts differ from CPM charts in the way times are calculated for activities. They allow
better for uncertainty. For each activity, three estimates of time are obtained: the shortest time
(SP), the longest time (LT) and the most likely time (MT). The estimate assigned for the activity
is a weighted average of these three estimates. The formula is:
Expected time = (SP + 4(MT) + LT) /6.
Schedule Compression
A schedule can be shortened two ways:

• crashing: using more resources than planned on the task
• fast-tracking: adjusting the schedule so, mindful of task dependencies, more activities are done
in parallel than was planned
Risk multipliers
This involves building in a time or resource contingency for tasks considered to be at high risk of
overrun.

Resource tools and techniques
• Levelling: This involves adjusting the activities within the schedule so as to ensure there
are minimal peaks and troughs in resource use. This ensures efficient use of resources. It
also allows the Project Manager to direct resources, where required, to more critical
activities.
• Critical chain method: Activities are planned in the light of their latest possible start and
finish dates. The extra time that results between some activities can be used to better use
resources.
• Resource histograms: This is a column chart that depicts the resources used on a project
over time.
 Using a software tool to assist in project planning

TOPIC 5
IS PROJECT RESOURCE MANAGEMENT

In organizational studies, resource management is the efficient and effective development of an
organization's resources when they are needed. Such resources may include financial resources,
inventory, human skills, production resources, or information technology (IT).
In the realm of project management, processes, techniques and philosophies as to the best
approach for allocating resources have been developed. These include discussions on functional
vs. cross-functional resource allocation as well as processes espoused by organizations like the
Project Management Institute (PMI) through their Project Management Body of Knowledge
(PMBOK) methodology of project management. Resource management is a key element to
activity resource estimating and project human resource management. Both are essential
components of a comprehensive project management plan to execute and monitor a project
successfully. As is the case with the larger discipline of project management, there are resource
management software tools available that automate and assist the process of resource allocation
to projects and portfolio resource transparency including supply and demand of resources. The
goal of these tools typically is to ensure that:
 There are employees within our organization with required specific skill set and desired
profile required for a project,
 Decide the number and skill sets of new employees to hire, and
 Allocate the workforce to various projects.
Corporate Resource Management Process
Large organizations usually have a defined corporate resource management process which
mainly guarantees that resources are never over-allocated across multiple projects. Peter Drucker
wrote of the need to focus resources, abandoning a less promising initiatives for every new
project taken on, as fragmentation inhibits results.
Techniques
One resource management technique is resourceleveling. It aims at smoothing the stock of
resources on hand, reducing both excess inventories and shortages.
The required data are: the demands for various resources, forecast by time period into the future
as far as is reasonable, as well as the resources' configurations required in those demands, and
the supply of the resources, again forecast by time period into the future as far as is reasonable.
The goal is to achieve 100% utilization but that is very unlikely, when weighted by important
metrics and subject to constraints, for example: meeting a minimum service level, but otherwise
minimizing cost. A Project Resource Allocation Matrix (PRAM) is maintained to visualize the
resource allocations against various projects.

The principle is to invest in resources as stored capabilities, and then unleash the capabilities as
demanded.
A dimension of resource development is included in resource management by which investment

in resources can be retained by a smaller additional investment to develop a new capability that
is demanded, at a lower investment than disposing of the current resource and replacing it with
another that has the demanded capability.
In conservation, resource management is a set of practices pertaining to maintaining natural

systems integrity. Examples of this form of management are airresource management,
soilconservation, forestry, wildlife management and waterresource management. The broad term
for this type of resource management is naturalresourcemanagement (NRM).
 Information system project resources

In project management terminology, resources are required to carry out the projecttasks. They
can be people, equipment, facilities, funding, or anything else capable of definition (usually other
than labour) required for the completion of a project activity. The lack of a resource will
therefore be a constraint on the completion of the project activity. Resources may be storable or
non-storable. Storable resources remain available unless depleted by usage, and may be
replenished by project tasks which produce them. Non-storable resources must be renewed for
each time period, even if not utilized in previous time periods.
Resource scheduling, availability and optimization are considered key to successful project
management.
Allocation of limited resources is based on the priority given to each of the project activities.
Their priority is calculated using the Critical path method and heuristic analysis. For a case with
a constraint on the number of resources, the objective is to create the most efficient schedule
possible - minimizing project duration and maximizing the use of the resources available.
 Resource planning
What makes a good resource plan?
A good resource plan consists of a schedule that is as detailed as possible for the information
known, and the types of resources needed for each task. A good resource plan will have a single
task owner on each task.
Resource Assignments
Notice the columns called 'duration' and 'resource type' in our Product Development Activity List
below. Duration refers to the timeframe in which the task will be performed. Resource type is the
skill set required to accomplish the task. In order to assign tasks to individuals, it is necessary to

know the expected duration of a task as well as the individual resource availability. Before
assigning individuals to tasks, it is recommended to associate a task with a resource type. Then
enter the expected duration of that task based on the resource chosen. This provides the ability to
analyze a project schedule, assuming there are no resource constraints on an individual's
availability.
Duration is the expected timeframe needed to complete the task while taking into consideration
the skill level and general availability of the resource. Duration should account for reality. If the
activity 'identification of focus group targets' (WBSID 1.1.1.1) is expected to take two weeks,
but historically, employees are only available 70% of the time due to general meetings, holidays,
vacations, etc., then planning for a duration of three weeks would be more reasonable.
The resource types used in your organization may be different than what is depicted in this chart.
Utilize the resources types that exist in your own organization. The objective here is to associate
a responsible party with the appropriate skill set to each of the tasks.
The work package 'project management' has been identified as a level of effort (LOE) activity.
This means that the individual(s) assigned to that activity will perform various activities during
the full duration of the project. Level of effort is best used when individuals are 100% allocated
to the project.

There are two types of resource plans. One is hypothetical, based on resource type set without
any resource constraints. Resource type refers to the skill set that a task requires for completion.
The other is an actual resource plan, based on actual resource availability. A hypothetical
schedule based only on the resource types needed produces a hypothetical resource plan.
In our example activity list, the resource types were identified and duration was converted into a
network schedule and Gantt chart. When a schedule is created in Project Insight, project
management software, or imported from MS Project, Project Insight automatically creates a
Gantt chart.
Project Insight, project management software, permits the project manager to run 'what-if'
scenarios on projects in planning phase. Project managers or project schedulers may set up
schedules with tasks related to the resource type or skill set required to accomplish that task.
Then assignments may be made to team members.
Setting up Project Work
As mentioned earlier, the initial schedule and resource plan should be developed and analyzed
based on the resource type required, without considering resource availability. Assignments will
be made as a second step.
Assigning work is as much about psychology as it is about executing the project. Most
individuals prefer to have a clear understanding of the work that needs to be performed.
Resources require focused attention to the task in order to deliver the highest quality work.
Studies have shown that if an individual is juggling more than three tasks simultaneously, the
efficiency of his/her work is significantly hampered.
In addition, without clear prioritization of tasks, it is human nature for people to work on tasks
that they feel most comfortable with and not necessarily the ones that are most important to
complete. As the project manager, understanding basic human tendencies is critical in effective
execution of a plan.
Again, since projects are unique events, it is inevitable that schedule changes will occur and the
assignment of work will be modified. Therefore, smaller, more regular assignments to
individuals will minimize confusion and produce better results.
Project Insight assists the project manager with respect to these issues because the software
distributes and delivers project tasks or assignments to the team member automatically.
Creating a Resource Plan

The first step is to produce a detailed list of all the individual resources needed to complete the
project. Start by listing each of the major resource groups (e.g.: Labour, Equipment and
Materials), then list the individual components of each group.
 Labour: identify all the roles responsible for or involved with the completion of any
activity specified in the Project Plan. Remember to include any external or contract staff
that will be brought in for specific tasks.

 Equipment: identify all the equipment which will be needed to complete the project,
e.g.: office equipment (PCs, photocopiers, mobile phones etc.), telecommunications
equipment (cabling, switches etc.) and machinery (heavy and light machinery).
 Materials: consumables (e.g.: photocopy paper, stationery, ink cartridges) are often
needed to complete project activities. Other materials (e.g.: wood, steel and concrete)
may be needed to produce physical deliverables. Draw up a detailed list of all the
materials required to complete the project. This should be as accurate as possible, since it
will be used to produce the Resource Schedule and Expense Schedule.
 Resource allocation framework

Key to Effective Project Resource Allocation
1. Determine quickly what resource you will need

2. Determine who the best people are.
3. Approach their line manager and check on their availability
4. Assuming they are available put their name down against the relevant tasks in your
project plan
5. Get your project plan into the PMO(project management office) and get it baselined as
soon as possible
This won't guarantee you will get the resource you want, but it will ensure that in a bun fight
with another project manager you will at least be able to say that you booked the resource first.
Now admittedly you may not win the battle, but it will certainly help your cause. And this is
absolutely vital to do. After all good resources if managed correctly develop into successful
project teams which are invaluable when delivering tough projects.
Project Management Resource Allocation - Tip
Project managers often concentrate on the key individuals such as who will be taking on the role
of a business analyst or what stakeholder strategy they will employ in order to be effective when
working with stakeholders.
However a key thing to remember with project management resource allocation is that each
resource is a human being. Never forget that. You need to effectively be able to work with them
and make your life easier when managing project teams. More than anything you need to ensure
you have project resources who deliver to a high standard what they commit to. This will not
only make your reporting through the weekly project management report easier, but also your
project quality management much more straightforward.
 Information resource portfolio management

Project Portfolio Management (PPM) is the centralized management of the processes,
methods, and technologies used by project managers and project management offices (PMOs) to
analyze and collectively manage current or proposed projects based on numerous key

characteristics. The objectives of PPM are to determine the optimal resource mix for delivery
and to schedule activities to best achieve an organization’s operational and financial goals ―
while honoring constraints imposed by customers, strategic objectives, or external real-world
factors.
Key Capabilities
PPM provides program and project managers in large, program/project-driven organizations with
the capabilities needed to manage the time, resources, skills, and budgets necessary to
accomplish all interrelated tasks. It provides a framework for issue resolution and risk mitigation,
as well as the centralized visibility to help planning and scheduling teams to identify the fastest,
cheapest, or most suitable approach to deliver projects and programs.
Pipeline Management
This is the determination of whether (and how) a set of projects in the portfolio can be executed
by a company with finite development resources in a specified time. Fundamental to pipeline
management is the ability to align the decision-making process for estimating and selecting new
capital investment projects with the strategic plan.
Resource Management
The focus on efficient and effective deployment of an organization’s resources where and when
they are needed. These can include financial resources, inventory, human resources, technical
skills, production and design. In addition to project-level resource allocation, users can also
model ‘what-if’ resource scenarios, and extend this view across the portfolio.
Change Control
The capture and prioritization of change requests that can include new requirements, features,
functions, operational constraints, regulatory demands, and technical enhancements. PPM
provides a central repository for these change requests and the ability to match available
resources to evolving demand within the financial and operational constraints of individual
projects.
Financial Management
With PPM, the Office of Finance can improve their accuracy for estimating and managing the
financial resources of a project or group of projects. In addition, the value of projects can be
demonstrated in relation to the strategic objectives and priorities of the organization through
financial controls and to assess progress through earned value and other project financial
techniques.

Risk Management
An analysis of the risk sensitivities residing within each project, as the basis for determining
confidence levels across the portfolio. The integration of cost and schedule risk management
with techniques for determining contingency and risk response plans enable organizations to gain
an objective view of project uncertainties
Enterprise Project Portfolio Management

Enterprise Project Portfolio Management (EPPM) is the practice of taking a top-down approach
to managing all project-intensive work and resources across the enterprise. This contrasts with
the traditional approach of combining manual processes, desktop project tools, and PPM
applications for each project portfolio environment.
Evolution of PPM
In the early 2000s, many PPM vendors realized that project portfolio reporting services only
addressed part of a wider need for PPM in the marketplace. Another more senior audience had
emerged, sitting at management and executive levels above detailed work execution and
schedule management, who required a greater focus on process improvement and ensuring the
viability of the portfolio in line with overall strategic objectives. In addition, as the size, scope,
complexity, and geographical spread of organizations’ project portfolios continued to grow,
greater visibility was needed of project work across the enterprise, allied to improved resource
utilization and capacity planning.
Business Drivers for EPPM

The PPM landscape is evolving rapidly as a result of the growing preference for managing
multiple capital investment initiatives from a single, enterprise-wide system. This more
centralized approach, and resulting ‘single version of the truth’ for project and project portfolio
information, provides the transparency of performance needed by management to monitor
progress versus the strategic plan.
The key aims of EPPM can be summarized as follows:
 Prioritize the right projects and programs: EPPM can guide decision-makers to
strategically prioritize, plan, and control enterprise portfolios. It also ensures the
organization continues to increase productivity and on-time delivery - adding value,
strengthening performance, and improving results.
 Eliminate surprises: formal portfolio project oversight provides managers and executives
with a process to identify potential problems earlier in the project lifecycle, and the
visibility to take corrective action before they impact financial results.
 Build contingencies into the overall portfolio: flexibility often exists within individual
projects but, by integrating contingency planning across the entire portfolio of
investments, organizations can have greater flexibility around how, where, and when they

need to allocate resources, alongside the flexibility to adjust those resources in response
to a crisis.
 Maintain response flexibility: with in-depth visibility into resource allocation,
organizations can quickly respond to escalating emergencies by maneuvering resources
from other activities, while calculating the impact this will have on the wider business.
 Do more with less: For organizations to systematically review project management
processes while cutting out inefficiencies and automating those workflows and to ensure
a consistent approach to all projects, programs, and portfolios while reducing costs.
 Ensure informed decisions and governance: by bringing together all project collaborators,
data points, and processes in a single, integrated solution, a unified view of project,
program, and portfolio status can be achieved within a framework of rigorous control and
governance to ensure all projects consistently adhere to business objectives.
 Extend best practice enterprise-wide: organizations can continuously vet project
management processes and capture best practices, providing efficiency as a result.
 Understand future resource needs: by aligning the right resources to the right projects at
the right time, organizations can ensure individual resources are fully leveraged and
requirements are clearly understood. EPPM software also allows an organization to
establish complete project capacity.
Project Portfolio Optimization
A key result of PPM is to decide which projects to fund in an optimal manner. Project Portfolio
Optimization (PPO) is the effort to make the best decisions possible under these conditions.
 Resource schedules
Resource scheduling is a collection of techniques used to calculate the resources required

todeliver the work and when they will be required.
There are two broad categories of resource – consumable and re-usable. Scheduling these
resources ensures:
 efficient and effective utilization;

 confidence that the schedule is realistic;
 Early identification of resource capacity bottlenecks and conflicts.
The resource scheduling process has three steps:
 allocation;
 aggregation;
 Scheduling.
Allocation involves identifying what resources are needed to complete the work. In the case of
consumable resources it is simply the quantity required. In the case of re-usable resources it is
the total effort required and the number of individual resources.

Once time scheduling and resource allocation are complete, the resources can be aggregated on a
daily, weekly or monthly basis as appropriate. The aggregated data is usually presented in a
histogram that illustrates the fluctuating use of resources against time. In the case of consumable
resources a cumulative curve (which usually takes the form of ans-curve) is also used to show
the total amount consumed at any point in time.
Few re-usable resources are limitless, so the time schedule has to be adjusted to take into account
the limited availability of resources over time. There are two approaches to reconciling resource
limits and time constraints;
i. Resource smoothing (or time limited resource scheduling) and

ii. Resource levelling (or resource limited scheduling).
Resource smoothing is used when the time constraint takes priority. The objective is to complete
the work by the required date while avoiding peaks and troughs of resource demand.
A smoothed resource profile will be achieved by delaying some work. This will remove some
flexibility from the schedule and its ability to deal with unavoidable delays, but the advantage is
usually a more efficient and cost-effective use of resources.
Resource levelling is used when limits on the availability of resources are paramount. It simply
answers the question ‘With the resources available, when the work will be finished?’
In many situations a mixture of levelling and smoothing may be required. This is particularly
true in the programme and portfolio dimensions.
Other factors that can be considered include cost-efficiency measures, such as ‘just-in-time’
material deliveries; risks affecting resource availability; and the effect of learning curves on
performance.
The fully-resourced schedule has to be achievable and have the support of the management team.
Unless the team has input into the schedule, this support is likely to be limited at best and
withheld at worst.
Resource scheduling may well reveal that the original target, calculated through time scheduling,
and cannot be achieved. This must be explained to senior management so that expectations can
be managed. A fully resourced schedule, taking into account all constraints, will support the case
for an extension of time or budget. Without it any case will be less substantial and unlikely to be
accepted.
Project
The network analysis models used in time scheduling can be used to perform equally detailed
calculations for resource levelling and resource smoothing.

Software packages perform very sophisticated calculations that can result in schedules being
significantly changed. The danger with these calculations is that they make cause and effect
difficult to determine. For example, if a resource levelling calculation is done that takes limits on
five different resources into account and delays the project by a significant amount, it will be
virtually impossible to see which resource had the greatest impact.
It should also be borne in mind that concepts such as the critical path and float have little
meaning after a resource scheduling calculation has been applied.
An alternative to creating networks based on activity dependencies is to use a technique called

critical chain. This method considers the availability of resources and the interdependencies
between resources. Once a suitable resource is developed, ‘buffers’ of spare time are allowed at
the end of each path. Monitoring the rate of usage of the buffer time is key in controlling projects
based on critical chain.
Programme
The projects and change management activity within a programme will have varied requirements
for resource scheduling. The programme management team must decide how resources will be
scheduled in each context.
On some projects (or parts of projects) the programme manager may impose time constraints that
require the resource schedule to be smoothed. On others, resource constraints may be imposed
that require the schedule to be levelled.
The programme and its use of resources are a highly dynamic and complex environment.
Successful resource scheduling will depend upon a close working relationship between the
programme manager, project managers and business change managers, who all put the needs of
the programme ahead of individual projects and change management activity.
A strong programme-support function is vital. Specialist planners (schedulers) will aggregate

information from around the programme to show the overall resource profile and assist in
evaluating decisions about the allocation of resources and potential bottlenecks.
Portfolio
In general management usage, capacity planning is defined as ‘the maximum amount of work
that an organisation is capable of completing in a given period ’. Capacity planning, in this sense,
also applies to portfolios.
In the portfolio domain, resource scheduling is done at a very high level. It is not so much about
the timing of resource usage as ensuring that the overall capacity is compatible with the amount
of work to be done.
The portfolio practice of categorization helps break the problem down. Prioritization shows

where resources need to be focused and resource demand is one of the factors taken into account
when balancing the portfolio.
A portfolio support function should ensure that projects and programmes produce information
that can be aggregated in a consistent and timely manner, enabling the portfolio manager to make
informed decisions.
 Cost management
Project Cost Management is a series of activities for estimating, allocating, and controlling
costs within the project. It allows determining and approving budget for the project and
controlling spending. For example, in construction project cost management it is vital to estimate
cost of materials, equipment, salary of workers, etc. In IT project cost management it is critical to
estimate cost of software development, salary of IT staff, etc.
Effective project cost management allows each project to be specific and unique because that
project entails costs and requires specific funding. However, no matter whether you lead a
software development project (IT project cost management) or construction project (construction
project cost management), you should consider project cost management as a process that
consists of the three key steps (get more info at the PM Guidelines)
Process
The process of managing project costs is an activity for estimating costs, developing project
budget and controlling spending. The project cost management process includes the following
key steps:
 Cost Estimation. It is the project cost management process step when the project
manager cooperates with the financial department to estimate costs required for
purchasing all necessary good/services and undertaking necessary activities to deliver the
project. Project Cost Estimation is conducted at the planning phase. The project manager
uses project cost management software to develop spreadsheets and make calculations.
 Budget Determination. At this step of the cost management process, cost spreadsheets
are used to develop the budget framework and determine the budget. The project manager
can use project cost management software to work in collaboration with the financial
department to determine items of the budget and sources of funding and then to allocate
the budget. The step entails close cooperation with the project sponsor.
 Spending Control. It is the step of the project cost management process when the
allocated budget is reviewed and spending is tracked. The project manager takes
responsibility for control spending and to ensure that the budget allocation is optimized
and costs are fully covered with the planned and allocated budget.

Software
It is almost impossible to manage costs and determine budget for a project if cost management
software is not used. Such software lets take control of the process, collaborate with the project
team and communicate the result to the project stakeholders. Typical software for project cost
management combines the following functionality:
 Project Tree Builder: users can develop project trees and task hierarchies which help
estimate cost per work item (task or activity). Tree building tool of project cost
management software is also used to develop structured spreadsheets.
 Templates Builder: users can develop project cost management templates that to make
the process of managing project costs simpler. Project cost management templates are
helpful to plan typical projects.
 Custom Fields: users can add new fields to tasks and edit existing ones. A custom field
can be created to add such task attributes as “Cost”, “Duration”, “Price”, “Spending”,
“Quantity”, “Total Amount”, etc.
Cost management is the process of planning and controlling the budget of a business. Cost
management is a form of management accounting that allows a business to predict impending
expenditures to help reduce the chance of going over budget.
Many businesses employ cost management plans for specific projects, as well as for the over-all
business model. When applying it to a project, expected costs are calculated while the project is
still in the planning period and are approved beforehand. During the project, all expenses are
recorded and monitored to make sure they stay in line with the cost management plan. After the
project is finished, the predicted costs and actual costs can be compared and analyzed, helping
future cost management predictions and budgets.
Implementing a cost management structure for projects can help a business keep their over-all
budget under control. Several business intelligence (BI) programs, such as Oracle Hyperion,
offer cost management software to help businesses monitor costs and increase profitability.
While the software may help, it is not imperative that software is used when executing a cost
management plan.
Vendors may refer to cost management software applications as cost accounting, spend
management or cost transparency products.
Project Cost Management (PCM) is a method that uses technology to measure cost and
productivity through the full life cycle of enterprise level projects.
PCM encompasses several specific functions of project management including estimating, job
controls, field data collection, scheduling, accounting and design. PCM main goal is to complete
a project within an approved budget
Beginning with estimating, a vital tool in PCM, actual historical data is used to accurately plan
all aspects of the project. As the project continues, job control uses data from the estimate with
the information reported from the field to measure the cost and production in the project. From
project initiation to completion, project cost management has an objective to simplify and
cheapen the project experience.
This technological approach has been a big challenger to the mainstream estimating software and
project management industries. Organizations that deliver Project Cost Management software

include ARES Prism, EcoSys, Cleopatra Enterprise,[5] Hard Dollar Corp, and Monitor mpower,
as well as numerous others.
Project Cost Management is one of the ten Knowledge Areas outlined in the A Guide to the
Project Management Body of Knowledge (aka the PMBOK Guide). It is used during the
Planning and Monitoring & Controlling Process Groups.
There are 4 processes in this knowledge area including
 Planning Cost Management
 Estimating Costs
 Determining Budget
 Controlling Cost
A key technique for Project Cost Management is Earned Value Management (EVM).

Task management is the process of managing a task through its life cycle. It involves planning,
testing, tracking and reporting. Task management can help either individuals achieve goals, or
groups of individuals collaborate and share knowledge for the accomplishment of collective
goals. Tasks are also differentiated by complexity, from low to high.
Effective task management requires managing all aspects of a task, including its status, priority,
time, human and financial resources assignments, recurrences, notifications and so on. These can
be lumped together broadly into the basic activities of task management.
Managing multiple individual or team tasks may require specialized software, for example
workflow or project management software. In fact, many people believe that task management
should serve as a foundation for project management activities.
Task management may form part of project management and process management and can serve
as the foundation for efficient workflow in an organisation. Project managers adhering to task-
oriented management have a detailed and up-to-date project schedule, and are usually good at
directing team members and moving the project forward.
Task life cycle
The status of tasks can be described by the following states:
 Ready
 Assigned
 Terminated
 Expired
 Forwarded
 Finished
 Failed

The following state machine diagram describes different states of a task over its life cycle. This
diagram is referenced from IBM.
Activities supported by tasks

As a discipline, task management embraces several key activities. Various conceptual
breakdowns exist, and these, at a high-level, always include creative, functional, project,
performance and service activities.
 Creative activities pertain to task creation. In context, these should allow for task
planning, brainstorming, creation, elaboration, clarification, organization, reduction,
targeting and preliminary prioritization.
 Functional activities pertain to personnel, sales, quality or other management areas, for
the ultimate purpose of ensuring production of final goods and services for delivery to
customers. In context these should allow for planning, reporting, tracking, prioritizing,
configuring, delegating, and managing of tasks.
 Project activities pertain to planning and time and costs reporting. These can encompass
multiple functional activities but are always greater and more purposeful than the sum of
its parts. In context project activities should allow for project task breakdown, task
allocation, inventory across projects, and concurrent access to task databases.
 Service activities pertain to client and internal company services provision, including
customer relationship management and knowledge management. In context these should
allow for file attachment and links to tasks, document management, access rights

management, inventory of client & employee records, orders & calls management, and
annotating tasks.
 Performance activities pertain to tracking performance and fulfillment of assigned tasks.
In context these should allow for tracking by time, cost control, stakeholders and priority;
charts, exportable reports, status updates, deadline adjustments, and activity logging.
 Report activities pertain to the presentation of information regarding the other five
activities listed, including graphical display.
Task management software

Task management software tools abound in the marketplace. Some are free; others exist for
enterprise-wide deployment purposes. Some boast enterprise-wide task creation, visualization
and notification capabilities - among others - scalable to small, medium and Fortune 100 size
companies, from individual projects to ongoing corporate task management.
Project management software, calendaring softwareand workflow software also often provide
task management software with advanced support for task management activities and
corresponding software environment dimensions, reciprocating the myriad project and
performance activities built into most good enterprise-level task management software products.
Software dimensions crisscrossing nearly all lines of task management products include task
creation, task visualization, notifications, assign resources, compatibility, configurability,
scalability, and reporting
 Task creation encompasses collaborative capabilities for turning ideas into actions
(tasks). Includes activities involved before setting tasks, particularly patterns of
collaboration involving planning
 Task visualization encompasses presentation of tasks, most often through time and list
forms. Priority visualization encompasses classification (e.g., budget, time, and
stakeholder) and mechanism (e.g., color code or text). Calendaring covers scheduling
(e.g., availability, meetings, appointments and other potential conflicts) and notifications.
 Notifications encompass configurable settings for informing past, present and pending
deadlines.
 Assigning resources encompasses the ability to delegate tasks and tools to single or
multiple people.
 Compatibility encompasses the ability of a task management environment to connect to
other systems, software and environments. It includes setting a structure and restrictions
on communication going from the task management environment to other software,
systems and environments.
 Configurability encompasses ability to add, remove and manage functionality and
usability in task management environments.
 Scalability encompasses ability to perform a task properly when a change in the quantity
of users is done to meet the specific task requirements.
 Reporting encompasses presentation of information by displaying either in tabular or
graphical display

A work breakdown structure (WBS), (WBS), in project management and systems engineering, is a
deliverable-oriented
oriented decomposition of a project into smaller components. A work breakdown
structure is a key project deliverable that organizes the team's work into manageable sections.
The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure
as a "deliverable oriented hierarchical
archical decomposition of the work to be executed by the project
team."
A work breakdown structure element may be a product, data, service, or any combination
thereof. A WBS also provides the necessary framework for detailed cost estimating and control
along
ng with providing guidance for schedule development and control
Example of a product-oriented
oriented work breakdown structure of an aircraft system
Overview of wbs.
WBS is a hierarchical and incremental decomposition of the project into phases, deliverables and
work packages. It is a tree structure, which shows a subdivision of effort required to achieve an
objective; for example a program, project, and contract. In a project or contract, the WBS is
developed by starting with the end objective and successively
successivel y subdividing it into manageable
components in terms of size, duration, and responsibility (e.g., systems, subsystems,
components, tasks, subtasks, and work packages) which include all steps necessary to achieve
the objective.

Example of work breakdown structure applied in a NASA reporting structure.
The work breakdown structure provides a common framework for the natural development of the
overall planning and control of a contract and is the basis for dividing work into definable
increments from which the statement of work can be developed and technical, schedule, cost,
and labor hour reporting can be established.
A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into
their successively higher level “parent” tasks, materials, etc. For each element of the work
breakdown structure, a description of the task to be performed is generated. This technique
(sometimes called a system breakdown structure) is used to define and organize the total scope
of a project.
The WBS is organized around the primary products of the project (or planned outcomes) instead
of the work needed to produce the products (planned actions). Since the planned outcomes are
the desired ends of the project, they form a relatively stable set of categories in which the costs
of the planned actions needed to achieve them can be collected. A well-designed WBS makes it
easy to assign each project activity to one and only one terminal element of the WBS. In addition
to its function in cost accounting, the WBS also helps map requirements from one level of
system specification to another, for example a requirements cross reference matrix mapping
functional requirements to high level or low level design documents.
The development of the WBS normally occurs at the start of a project and precedes detailed
project and task planning.

Design principles
100% rule
An important design principle for work breakdown structures is called the 100% rule. It has been
defined as follows:
The 100% rule states that the WBS includes 100% of the work defined by the project scope and
captures all deliverables – internal, external, interim – in terms of the work to be completed,
including project management. The 100% rule is one of the most important principles guiding
the development, decomposition and evaluation of the WBS. The rule applies at all levels within
the hierarchy: the sum of the work at the “child” level must equal 100% of the work represented
by the “parent” and the WBS should not include any work that falls outside the actual scope of
the project, that is, it cannot include more than 100% of the work… It is important to remember
that the 100% rule also applies to the activity level. The work represented by the activities in
each work package must add up to 100% of the work necessary to complete the work package.
Mutually exclusive elements
Mutually exclusive: In addition to the 100% rule, it is important that there is no overlap in scope
definition between different elements of a work breakdown structure. This ambiguity could
result in duplicated work or miscommunications about responsibility and authority. Such overlap
could also cause confusion regarding project cost accounting. If the WBS element names are
ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The
WBS Dictionary describes each component of the WBS with milestones, deliverables, activities,
scope, and sometimes dates, resources, costs, quality.
Plan outcomes, not actions
If the work breakdown structure designer attempts to capture any action-oriented details in the
WBS, s/he will likely include either too many actions or too few actions. Too many actions will
exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The
best way to adhere to the 100% rule is to define WBS elements in terms of outcomes or results,
not actions. This also ensures that the WBS is not overly prescriptive of methods, allowing for
greater ingenuity and creative thinking on the part of the project participants. For new product
development projects, the most common technique to ensure an outcome-oriented WBS is to use
a product breakdown structure. Feature-driven software projects may use a similar technique
which is to employ a feature breakdown structure. When a project provides professional services,
a common technique is to capture all planned deliverables to create a deliverable-oriented WBS.
Work breakdown structures that subdivide work by project phases (e.g. preliminary design
phase, critical design phase) must ensure that phases are clearly separated by a deliverable also
used in defining entry and exit criteria (e.g. an approved preliminary or critical design review).

Level of detail
One must decide when to stop dividing work into smaller elements. This will assist in
determining the duration of activities necessary to produce a deliverable defined by the WBS.
There are several heuristics or "rules of thumb" used when determining the appropriate duration
of an activity or group of activities necessary to produce a specific deliverable defined by the
WBS.
 The first is the "80 hour rule" which means that no single activity or group of activities at
the lowest level of detail of the WBS to produce a single deliverable should be more than
80 hours of effort.
 The second rule of thumb is that no activity or group of activities at the lowest level of
detail of the WBS should be longer than a single reporting period. Thus if the project
team is reporting progress monthly, then no single activity or series of activities should
be longer than one month long.
 The last heuristic is the "if it makes sense" rule. Applying this rule of thumb, one can
apply "common sense" when creating the duration of a single activity or group of
activities necessary to produce a deliverable defined by the WBS.
A work package at the activity level is a task that:
 can be realistically and confidently estimated;

 makes no sense practically to break down any further;
 can be completed in accordance with one of the heuristics defined above;
 produces a deliverable which is measurable; and
 Forms a unique package of work which can be outsourced or contracted out.
Coding scheme
It is common for work breakdown structure elements to be numbered sequentially to reveal the
hierarchical structure. The purpose for the numbering is to provide a consistent approach to
identifying and managing the WBS across like systems regardless of vendor or service. For
example, 1.1.2 Propulsion (in the example below) identifies this item as a Level 3 WBS
element, since there are three numbers separated by a decimal point. A coding scheme also helps
WBS elements to be recognized in any written context.

A practical example of the WBS coding scheme is
1.0 Aircraft System
1.1 Air Vehicle

1.1.1 Airframe
1.1.1.1 Airframe Integration, Assembly, Test and Checkout
1.1.1.2 Fuselage
1.1.1.3 Wing
1.1.1.4 Empennage
1.1.1.5 Nacelle
1.1.1.6 Other Airframe Components 1..n (Specify)
1.1.2 Propulsion
1.1.3 Vehicle Subsystems
1.1.4 Avionics
1.2 System Engineering
1.3 Program Management
1.4 System Test and Evaluation
1.5 Training
1.6 Data
1.7 Peculiar Support Equipment
1.8 Common Support Equipment
1.9 Operational/Site Activation
1.10 Industrial Facilities
1.11 Initial Spares and Repair Parts
Terminal element
The lowest elements in a tree structure, a terminal element is one that is not further subdivided.
In a Work Breakdown Structure such (activity or deliverable) elements are the items that are
estimated in terms of resource requirements, budget and duration; linked by dependencies; and
scheduled. At the juncture of the WBS element and organization unit, control accounts and work
packages are established and performance is planned, measured, recorded and controlled. A
WBS can be expressed down to any level of interest. Three levels are the minimum
recommended, with additional levels for and only for items of high cost or high risk, and two
levels of detail at cases such as systems engineering or program management, with the standard
showing examples of WBS with varying depth such as software development at points going to 5
levels or fire-control system to 7 levels.
Consistent to Norms
The higher WBS structure should be consistent to whatever norms or template mandates exist
within the organization or domain. For example, shipbuilding for the U.S. Navy must respect that
the nautical terms and their hierarchy structure put into MIL-STD are embedded in Naval
Architecture and that matching Navy offices and procedures have been built to match this naval

architecture structure, so any significant change of WBS element numbering or naming in tthe
hierarchy would be unacceptable.
Example
The WBS construction technique employing the 100% rule during WBS construction.
The figure on the left shows a work breakdown structure construction technique that
demonstrates the 100% rule and the "progressive elaboration" technique. At WBS Level 1 it
shows 100 units of work as the total scope of a project to design and build a custom bicycle. At
WBS Level 2, the 100 units are divided into seven elements. The number of units allocated to
each elementt of work can be based on effort or cost; it is not an estimate of task duration.
The three largest elements of WBS Level 2 are further subdivided at Level 3. The two largest
elements at Level 3 each represent only 17% of the total scope of the project. Th
These larger
elements could be further subdivided using the progressive elaboration technique described
above.
WBS design can be supported by software (e.g. a spreadsheet) to allow automatic rolling up of
point values. Estimates of effort or cost can be developed
developed through discussions among project
team members. This collaborative technique builds greater insight into scope definitions,
underlying assumptions, and consensus regarding the level of granularity required to manage the
projects.

Misconceptions
 A WBS is not an exhaustive list of work. It is instead a comprehensive classification of

project scope.
 A WBS is neither a project plan, a schedule, nor a chronological listing. It specifies what
will be done, not how or when.
 A WBS is not an organizational hierarchy, although it may be used when assigning
responsibilities. See also: responsibility assignment (RACI) matrix (also called a Staffing
Matrix).

SEE THE PPT PROVIDED
COVERED. SEE PREVIOUS NOTES.
 Using software tools to assist in resource management

TOPIC 6
IS PROJECT ORGANIZATIONAL STRUCTURES
 Organizational structures
An organizational structure defines how activities such as task allocation, coordination and
supervision are directed towards the achievement of organizational aims. It can also be
considered as the viewing glass or perspective through which individuals see their organization
and its environment.
Organizations are a variant of clustered entities
An organization can be structured in many different ways, depending on their objectives. The
structure of an organization will determine the modes in which it operates and performs.
Organizational structure allows the expressed allocation of responsibilities for different functions
and processes to different entities such as the branch, department, workgroup and individual.
Organizational structure affects organizational action in two big ways:
 First, it provides the foundation on which standard operating procedures and routines rest.
 Second, it determines which individuals get to participate in which decision-making
processes, and thus to what extent their views shape the organization’s actions.
Types of organisation structure.
 3.1Pre-bureaucratic structures
 3.2Bureaucratic structures
 3.3Post-bureaucratic
 3.4Functional structure
 3.5Divisional structure
 3.6Matrix structure
 3.7Organizational circle: moving back to flat
 3.8Team
 3.9Network
 3.10Virtual
 3.11Hierarchy-Community Phenotype Model of Organizational Structure
A project organization is a structure that facilitates the coordination and implementation of

project activities. Its main reason is to create an environment that fosters interactions among the
team members with a minimum amount of disruptions, overlaps and conflict. One of the

important decisions of project management is the form of organizational structure that will be
used for the project.
Each project has its unique characteristics and the design of an organizational structure should
consider the organizational environment, the project characteristics in which it will operate, and
the level of authority the project manager is given. A project structure can take on various forms
with each form having its own advantages and disadvantages.
One of the main objectives of the structure is to reduce uncertainty and confusion that typically
occurs at the project initiation phase. The structure defines the relationships among members of
the project management and the relationships with the external environment. The structure
defines the authority by means of a graphical illustration called an organization chart.
A properly designed project organization chart is essential to project success. An organization
chart shows where each person is placed in the project structure. An organization chart is drawn
in pyramid form where individuals located closer to the top of the pyramid have more authority
and responsibility than members located toward the bottom.
It is the relative locations of the individuals on the organization chart that specifies the working
relationships, and the lines connecting the boxes designate formal supervision and lines of
communication between the individuals.
The Project Management Structures
Fig, Project Organization Chart (use another example)
Creating the project structure is only a part of organizing the project; it is the actual
implementation and application that takes the most effort. The project organization chart
establishes the formal relationships among project manager, the project team members, the
development organization, the project, beneficiaries and other project stakeholders. This
organization must facilitate an effective interaction and integration among all the major project
participants and achieve open and effective communication among them.
The project manager must create a project structure that will meet the various project needs at
different phases of the project. The structure cannot be designed too rigid or too lose, since the
project organization's purpose is to facilitate the interaction of people to achieve the project
ultimate goals within the specified constraints of scope, schedule, budget and quality. The
objective in designing a project structure is to provide a formal environment that the project

manager can use to influence team members to do their best in completing their assignment and
duties. The structure needs to be designed to help develop collaboration among individual team
members; all in a cost effective way with a minimum of duplication of effort and overlaps. The
organization chart has a limited functionality; it only shows the hierarchical relationship among
the team members but does not shows how the project organization will work, it is for that
reason that the design should consider factors that will facilitate the operation of the structure;
these include communications, information flows, coordination and collaboration among its
members.
 Integrating project work and project organizational structures
 Team management
Managing a Project Team

In managing a project team, a Project Manager needs to possess excellent analytical and
organizational skills. A technical proficiency in the specialist area of their project is also a
distinct advantage. Remember, though, that projects achieve their outcomes through people -a
variety of people working together in a coordinated way to produce the desired results.
How are you encouraging peak performance from your project team? As with any manager
getting the best out of their people, you will need to pay attention to your general leadership and
management skills. Some of these skill areas that you will need to pay attention to are:
 clarifying project team member roles

 setting team and individual goals
 monitoring and measuring team and individual performance
 feeding back team and individual performance
 resolving conflicts between team members constructively
 delegating responsibilities and tasks
 motivating using a combination of intrinsic and extrinsic rewards
 developing the skills of team members
 coaching team members
Effective teams are so much more productive than groups working on the same task because they
are able to leverage off each other’s' strengths and compensate for each other’s' weaknesses.
Making sure that you have the right mix of team members in your project team is therefore an
important consideration. Conducting a team profiling exercise is also an effective method for
getting each project team member to appreciate their respective strengths and weaknesses.
Team Ground Rules
If your project team gets stuck in a rut with lots of unproductive conflict, there are a number of
things you can try. If you haven't already done so, get your team together to clarify and agree the
"ground rules" that govern the team's behavior. Your "ground rules" should cover these five key
areas of team operation:
 team meetings
 team working
 team communication
 team member relationships
 team decision-making
Discussing the ground rules will uncover hitherto unspoken assumptions. Each team member
will come to see more clearly where other team members are coming from and what they need
from the team to get their job done. Be sure to post the agreed ground rules in a visible place
where the team meets regularly.
 Project team life cycle
The project life cycle consists of four phases, initiation, planning, execution (including
monitoring and controlling) and evaluation. The MPMM Project Management Methodology is
an excellent resource for this part of the Unit. The Initiation phase begins by defining the scope,
purpose, objectives, resources, deliverables, timescales and structure of the project. The next step
is to develop a Business Case, including several possible solutions and a cost/benefit analysis for
each. A Feasibility Study should then be carried out to ensure that the chosen solution is
feasible and has an acceptable level of risk. The next step is to define the Terms of Reference,
followed by the appointment of the project team. The final step is to carry out Phase Review
before seeking approval to proceed. The first step of the Planning phase is the creation of a
detailed Project Plan which the project manager will refer throughout the project to monitor and
control time, cost and quality. The project manager will then create the following plans:
 Resource Plan: to identify the staffing, equipment and materials needed
 Financial Plan: to quantify the financial expenditure required
 Quality Plan: to set quality targets and specify Quality Control methods
 Risk Plan: to identify risks and plan actions needed to minimize them
 Acceptance Plan: to specify criteria for accepting deliverables
Finally, a Phase Review is carried out to assess the deliverables produced to date and approve the
start of the Project Execution phase. During the Project Execution phase the project team
produces the deliverables while the project manager monitors and controls the project delivery
by undertaking:
 Time Management: tracking and recording time spent on tasks against the Project Plan
 Cost Management: identifying and recording costs against the project budget
 Quality Management: reviewing the quality of the deliverables and management
processes
 Change Management: reviewing and implementing requests for changes to the project
 Risk Management: assessing the level of project risk and taking action to minimize it
 Issue Management: identifying and resolving project issues
 Acceptance Management: identifying the completion of deliverables and gaining the
customers’ acceptance

 Communications Management: keeping stakeholders informed of project progress,
risks and issues
Once the customer has accepted the deliverables and a Phase Review has been carried out to
determine whether the project objectives have been achieved, the project is ready for Closure. A
Project Closure Report should list all of the actions required. When this has been approved, the
listed actions are completed to release project resources, hand over deliverables, and inform all
stakeholders that the project is now closed. Shortly after the project has been closed, an
Evaluation (also known as a Post-Implementation Review) should be carried out to determine
the project's overall success and find out whether the benefits stated in the original Business Case
were actually realized. Any lessons learned should be documented for future projects
The five main phases of the project life cycle are as follows:
START-UP This phase is where the project objectives are defined and the conceptual aspects
of the project agreed. This may be the phase where a problem is identified and potential solutions
suggested.
DEFINITION Once the project objectives have been clearly defined then the appraisal of the
solutions is conducted in terms of risks, financial commitment and benefits. The scope of work is
now defined in detail. (6 Important considerations when defining your Project)
PLANNING This phase is where the project is broken down into manageable areas of work
and planned in terms of time, cost and resources. This is a continuous process and will extend
throughout the execution phase of the project.
EXECUTION During this phase the work is implemented, controlled and monitored.
CLOSE-OUT The final phase of the project life cycle is close-out and demobilisation, where
resources are reassigned, the project is handed over and the post-project review is carried
out.(Project Close-out and handover – a general overview)
It is important to ensure the project life cycle used on your project is appropriate to the work
being carried out and split into distinct and manageable phases.
The project life cycle also allows for the gate procedure to be used. This is a tried and tested
method for delivering projects on time, within budget and to the expected quality targets. At each
stage, approval is generally required from outside the project team before proceeding to the next
stage.
 Change management
Change management is an approach to transition individuals, teams, and organizations to a

desired future state. In a project management context, change management may refer to a project
management process wherein changes to the scope of a project are formally introduced and
approved.
Reasons for change

Globalization and the constant innovation of technology result in a constantly evolving business
environment. Phenomena such as social media and mobile adaptability have revolutionized
business and the effect of this is an ever increasing need for change therefore, change
management. The growth in technology also has a secondary effect of increasing the availability
and therefore accountability of knowledge. Easily accessible information has resulted in
unprecedented scrutiny from stockholders and the media and pressure on management.
With the business environment experiencing so much change, organizations must then learn to
become comfortable with change as well. Therefore, the ability to manage and adapt to
organizational change is an essential ability required in the workplace today. Yet, major and
rapid organizational change is profoundly difficult because the structure, culture, and routines of
organizations often reflect a persistent and difficult-to-remove "imprint" of past periods, which
are resistant to radical change even as the current environment of the organization changes
rapidly.
Due to the growth of technology, modern organizational change is largely motivated by exterior
innovations rather than internal moves. When these developments occur, the organizations that
adapt quickest create a competitive advantage for themselves, while the companies that refuse to
change get left behind. This can result in drastic profit and/or market share losses.
Organizational change directly affects all departments from the entry level employee to senior
management. The entire company must learn how to handle changes to the organization.
Choosing what changes to implement

When determining which of the latest techniques or innovations to adopt, there are four major
factors to be considered:
1. Levels, goals, and strategies
2. Measurement system
3. Sequence of steps
4. Implementation and organizational change
CHANGE MANAGEMENT PROCESS
Regardless of the many types of organizational change, the critical aspect is a company’s ability
to win the buy-in of their organization’s employees on the change. Effectively managing
organizational change is a four-step process:
1. Recognizing the changes in the broader business environment

2. Developing the necessary adjustments for their company’s needs
3. Training their employees on the appropriate changes
4. Winning the support of the employees with the persuasiveness of the appropriate
adjustments
As a multi-disciplinary practice that has evolved as a result of scholarly research, organizational

change management should begin with a systematic diagnosis of the current situation in order to
determine both the need for change and the capability to change. The objectives, content, and
process of change should all be specified as part of a Change Management plan.
Change management processes should include creative marketing to enable communication

between changing audiences, as well as deep social understanding about leadership’s styles and
group dynamics. As a visible track on transformation projects, Organizational Change
Management aligns groups’ expectations, communicates, integrates teams and manages people

training. It makes use of performance metrics, such as financial results, operational efficiency,
leadership commitment, communication effectiveness, and the perceived need for change to
design appropriate strategies, in order to avoid change failures or resolve troubled change
projects.
Successful change management is more likely to occur if the following are included:
1. Benefits management and realization to define measurable stakeholder aims, create a

business case for their achievement (which should be continuously updated), and monitor
assumptions, risks, dependencies, costs, return on investment, dis-benefits and cultural
issues affecting the progress of the associated work
2. Effective communication that informs various stakeholders of the reasons for the change
(why?), the benefits of successful implementation (what is in it for us, and you) as well as
the details of the change (when? where? who is involved? how much will it cost? etc.)
3. Devise an effective education, training and/or skills upgrading scheme for the
organization
4. Counter resistance from the employees of companies and align them to overall strategic
direction of the organization
5. Provide personal counseling (if required) to alleviate any change-related fears
6. Monitoring of the implementation and fine-tuning as required
Taking a Principled Approach to Managing Change
Many change programs appear to the innocent bystander as a struggle for power amongst
competing interests within and without the organization. These programs can appear that way
because they are. In the short term, these kinds of implementation seem to succeed. However,
once the people forcing things in place start to weaken their grip, the change effort can fall apart
very quickly. Short term success gives way to longer term failure.
On the other hand, adopting a principled approach that engenders openness and trust and
displays integrity will see the change program through the hard times and on to lasting success.
Business Performance Pty Ltd promotes five key principles of successful change management.
Adopting these principles in both spirit and practice will enhance significantly the chances of
success for your change initiative. These five principles are summarized as follows:
1. Sponsorship
The change program has the visible support of key decision-makers throughout the
organization and resources are committed to the program.
2. Planning
Planning is conducted methodically before program implementation and committed to
writing. Plans are agreed with major stakeholders and objectives, resources, roles and
risks are clarified.
3. Measurement
Program objectives are stated in measurable terms and program progress is monitored
and communicated to major stakeholders.

4. Engagement
Stakeholders are engaged in genuine two-way dialogue in an atmosphere of openness,
mutual respect and trust.
5. Support structures
Program implementers and change recipients are given the resources and supporting
systems they require during and after change implementation.
Even if you are not articulating the principles governing your change initiative, your managers,
clients, employees and everyone else involved in your change program will sense the covert
principles operating and will act accordingly. What principles are your change program
embodying? Are they consistent with your and your organizations values? What are the
disconnects and what are you doing about it?
Change Management:
The Systems and Tools for Managing Change

Scope of change management
This tutorial provides a summary of each of the main areas for change management based on
Prosci's benchmarking research with more than 3400 organizations over the last 15 years.
The purpose of defining these change management areas is to ensure that there is a common
understanding among readers. Tools or components of change management include:
 Change management process

 Defining change management
 Readiness assessments
 Communication and communication planning
 Coaching and manager training for change management
 Training and employee training development
 Sponsor activities and sponsor roadmaps
 Resistance management
 Data collection, feedback analysis and corrective action
 Celebrating and recognizing success
Change management process
The change management process is the sequence of steps or activities that a change management
team or project leader would follow to apply change management to a project or change. Based
on Prosci's research of the most effective and commonly applied change, they have created a
change management process that contains the following three phases:

Phase 1 - Preparing for change (Preparation, assessment and strategy development)
Phase 2 - Managing change (Detailed planning and change management implementation)
Phase 3 - Reinforcing change™ (Data gathering, corrective action and recognition)
Figure 1 - Prosci 3-Phase

Phase Change Management Process

Defining change management
It is important to note what change management is and what change management is not, as
defined by the majority of research participants.
 Change management is not a stand-alone process for designing a business solution.

 Change management is the processes, tools and techniques for managing the people-side
of change.
 Change management is not a process improvement method.
 Change management is a method for reducing and managing resistance to change when
implementing process, technology or organizational change.
 Change managementis nota stand-alone technique for improving organizational
performance.
 Change management is a necessary component for any organizational performance
improvement process to succeed, including programs like: Six Sigma, Business Process
Reengineering, Total Quality Management, Organizational Development, Restructuring
and continuous process improvement.
 Change management is how we drive the adoption and usage we need to realize business
results.
Prosci's definition of change management: Change management is the application of a

structured process and set of tools for leading the people side of change to achieve a desired
outcome.
Readiness assessments
Assessments are tools used by a change management team or project leader to assess the
organization's readiness to change. Readiness assessments can include organizational
assessments, culture and history assessments, employee assessments, sponsor assessments and
change assessments. Each tool provides the project team with insights into the challenges and
opportunities they may face during the change process.
 Assess the scope of the change, including: How big is this change? How many people are
affected? Is it a gradual or radical change?
 Assess the readiness of the organization impacted by the change, including: What is the
value- system and background of the impacted groups? How much change is already
going on? What type of resistance can be expected?
 Assess the scope of the change, including: How big is this change? How many people are
affected? Is it a gradual or radical change?
 Assess the readiness of the organization impacted by the change, including: What is the
value- system and background of the impacted groups? How much change is already
going on? What type of resistance can be expected?
 Assess the strengths of your change management team.

 Assess the change sponsors and take the first steps to enable them to effectively lead the
change process.
Communication and communication planning
Many managers assume that if they communicate clearly with their employees, their job is done.
However, there are many reasons why employees may not hear or understand what their
managers are saying the first time around. In fact, you may have heard that messages need to be
repeated 6 to 7 times before they are cemented into the minds of employees. That is because each
employee’s readiness to hear depends on many factors. Effective communicators carefully
consider three components: the audience, what is said and when it is said.
For example, the first step in managing change is building awareness around the need for change
and creating a desire among employees. Therefore, initial communications are typically designed
to create awareness around the business reasons for change and the risk of not changing.
Likewise, at each step in the process, communications should be designed to share the right
messages at the right time.
Communication planning, therefore, begins with a careful analysis of the audiences, key
messages and the timing for those messages. The change management team or project leaders
must design a communication plan that addresses the needs of front-line employees, supervisors
and executives. Each audience has particular needs for information based on their role in the
implementation of the change.
Sponsor activities and sponsor roadmaps
Business leaders and executives play a critical sponsor role in change management. The change
management team must develop a plan for sponsor activities and help key business leaders carry
out these plans. Sponsorship should be viewed as the most important success factor. Avoid
confusing the notion of sponsorship with support. The CEO of the company may support your
project, but that is not the same as sponsoring your initiative.
Sponsorship involves active and visible participation by senior business leaders throughout the
process. Unfortunately many executives do not know what this sponsorship looks like. A change
agent's or project leader's role includes helping senior executives do the right things to sponsor
the project.
Coaching and manager training for change management
Supervisors will play a key role in managing change. Ultimately, the direct supervisor has more
influence over an employee’s motivation to change than any other person at work.
Unfortunately, supervisors as a group can be the most difficult to convince of the need for
change and can be a source of resistance. It is vital for the change management team and

executive sponsors to gain the support of supervisors and to build change leadership. Individual
change management activities should be used to help these supervisors through the change
process.
Once managers and supervisors are on board, the change management team must prepare a
coaching strategy. They will need to provide training for supervisors including how to use
individual change management tools with their employees.
Training and training development
Training is the cornerstone for building knowledge about the change and the required skills.
Project team members will develop training requirements based on the skills, knowledge and
behaviors necessary to implement the change. These training requirements will be the starting
point for the training group or the project team to develop training programs.
Resistance management
Resistance from employees and managers is normal. Persistent resistance, however, can threaten
a project. The change management team needs to identify, understand and manage resistance
throughout the organization. Resistance management is the processes and tools used by
managers and executives with the support of the project team to manage employee resistance.
Data collection, feedback analysis and corrective action
Employee involvement is a necessary and integral part of managing change. Managing change is
not a one way street. Feedback from employees is a key element of the change management
process. Analysis and corrective action based on this feedback provides a robust cycle for
implementing change.
Celebrating and recognizing success
Early successes and long-term wins must be recognized and celebrated. Individual and group
recognition is also a necessary component of change management in order to cement and
reinforce the change in the organization.
The final step in the change management process is the after-action review. It is at this point that
you can stand back from the entire program, evaluate successes and failures, and identify process
changes for the next project. This is part of the ongoing, continuous improvement of change
management for your organization and ultimately leads to change competency.
Summary

These eight elements comprise the areas or components of a change management progra
program.
Along with the change management process, they create a system for managing change. Good
project managers apply these components effectively to ensure project success, avoid the loss of
valued employees, and minimize the negative impact of the change on productivity and a
company's customers. The Prosci Change Management Certification Program is a great option
for hands-on
on learning about these eight elements and other
other tools for managing change.
 IS project quality management

Quality management is the process for ensuring that all project activities necessary to design,
plan and implement a project are effective and efficient with respect to the purpose of the
objective and its performance.
What is Quality?
Project quality management is all of the processes and activities needed to determine and
achieve project quality.
But what does "quality" really ly mean?
At its most basic level, quality means meeting the needs of customers. This is also known as
"fit for use."
I like this simple definition of quality because its focus is where it should be, on the customer.
This basic definition also implies that the requirements of the project have been met since the
requirements should reflect the customer's needs if collected properly.
Project Quality Management: Why, What and How

As the project manager, there are three key quality management concepts that will help you
deliver a high quality project.
 Customer Satisfaction
 Prevention over Inspection
 Continuous Improvement
3 Key Quality Management Concepts

Customer Satisfaction
Customer satisfaction is a key measure of a project's quality. It's important to keep in mind that
project quality management is concerned with both the product of the project and the
management of the project.
If the customer doesn't feel the product produced by the project meets their needs or if the way
the project was run didn't meet their expectations, then the customer is very likely to consider the
project quality as poor, regardless of what the project manager or team thinks.
As a result, not only is it important to make sure the project requirements are met, managing
customer expectations is also a critical activity that you need to handle well for your project to
succeed.

Prevention over Inspection
The Cost of Quality (COQ) includes money spent during the project to avoid failures and
money spent during and after the project because of failures. These are known as the Cost of
Conformance and the Cost of Nonconformance.
Nonconformance
Cost of Conformance Cost of Nonconformance
Prevention Costs Internal Failure Costs
 Training  Rework
 Document Processes  Scrap
 Equipment
 Time To Do It Right
Appraisal Costs External Failure Costs
 Testing  Liabilities
 Destructive Testing Loss  Warranty Work
 Inspections  Lost Business
The cost of preventing mistakes is usually much less than the cost of correcting them.
Continuous Improvement
Continuous improvement is a concept that exists in all of the major quality management
approaches such as Six Sigma and Total Quality Management (TQM).. In fact, it is a key
aspect of the last concept, prevention over inspection.
inspection
Continuous improvement is simply the ongoing efforteffort to improve your products, services, or
processes over time. These improvements can be small, incremental changes or major,
breakthrough type changes.
From a project perspective, this concept can be applied by analyzing the issues that were
encountered during
uring the project for any lessons learned that you can apply to future projects. The
goal is to avoid repeating the same issues in other projects.
Quality Management for Projects

Project Quality Management has three key processes that you should
should perform in your projects.
1. Plan Quality
Plan Quality involves identifying the quality
quality requirements for both the project and the product
and documenting how the project can show it is meeting the quality requirements. The outputs of

this process include a Quality Management Plan, quality metrics, quality checklists and a Process
Improvement Plan.
2. Perform Quality Assurance

Quality Assurance is used to verify that the project processes are sufficient so that if they are
adhered to, the project deliverables will be of good quality. Process checklists and project audits
are two methods used for project quality assurance.
Perform Quality Control

Quality Control verifies that the product meets the quality requirements. Peer reviews and testing
are two methods used to perform quality control. The results will determine if corrective action is
needed.
 Quality management
 Quality planning
Quality Planning is the process for "identifying which quality standards are relevant to the
project and determining how to satisfy them": Quality planning means planning how to fulfill
process and product (deliverable) quality requirements: "Quality is the degree to which a set of
inherent characteristics fulfill requirements.
By planning the quality one has to respect some principles:
 Customer satisfaction comes first: Quality is defined by the requirements of the

customer.
 Prevention over inspection: It's better to avoid mistakes than to inspect the result and
repair the defects.
 Management responsibility: Costs of quality must be approved by the management.
 Continuous improvement: Becoming better is an iteratively structured process.
Tools and Techniques
 Cost-benefit analysis is a method to determine whether the wished quality standards can
or should be played.
 Benchmarking may be thought as the process of comparing the actual project to other
projects for generating ideas for improvement and providing a basis by which to measure
performance.
 Design of experiments is a method for investigating the influence of single parameters
on the degree of quality of the whole product or process.
 Cost of quality. The total costs incurred by investment in preventing nonconformance to
requirements, appraising the product or service for conformance to requirements and
failing to meet requirements.
 Additional quality planning tools may support the quality planning process. Such tools
and techniques are brainstorming, affinity diagrams, force field analysis, nominal group
techniques, matrix diagrams, flowcharts, and prioritization matrices.

Process Output
 The Quality Management Plan is a document describing how the project management
team will implement the performing organization's quality policy.
 The Quality Metrics are building a system of scales and procedures for measuring the
quality.
 The Quality Checklists are building a set of documents to verify that a set of required
steps has been performed.
 The Process Improvement Plan details the steps for analyzing processes that will
facilitate the identification of waste and non-value added activity , for example process
boundaries, process configurations or process metrics or targets for improved
performance.
 The Quality Baseline is the set of quality objectives which must be met by the project
 Update of the Project Management Plan will at least implicitly be generated because the
Quality Management Plan is part of the Project Management Plan
 Quality assurance
Quality Assurance
The planned and systematic activities implemented in a quality system so that quality
requirements for a product or service will be fulfilled.
You can think of quality assurance as the activities and management processes that are done to
ensure that the products and services the project delivers are at the required quality level. It is
process driven and focused on the development of the product or delivery of the service.
Quality Assurance Tools & Techniques

There are many tools and techniques that form the basis of the key quality assurance principles.
Some of these include...
 Cost-Benefit Analysis
 Cost of Quality (COQ)
 Control Charts
 Benchmarking
 Design of Experiments (DOE)
 Statistical Sampling
 Flow Charting
 Quality Management Methodologies (i.e. Six Sigma, CMMI, etc.)
 Cause and Effect Diagrams (i.e. Fishbone Diagram)
 Histogram
 Pareto Chart
 Run Chart

 Scatter Diagram
 Inspection
Quality Assurance vs Quality Control

Quality assurance and quality control are sometimes confused with each other.
One of the key quality assurance principles that differentiate it from quality control is that quality
assurance is performed during the project to help make sure the product meets the quality
standards. For example, creating a Project Quality Management Plan, following a quality
assurance process, and performing audits.
Quality control, on the other hand, evaluates whether the resulting product produced by the
project met the quality standards. Quality control activities are performed after a product has
been created to determine if it meets the quality requirements. The results of the quality control
process are used by the quality assurance process to determine if any changes are needed to the
quality assurance process.
The focus of quality assurance is on the processes used in the project. Quality assurance
ensures that project processes are used effectively to produce quality project deliverables. It
involves following and meeting standards, continuously improving project work, and correcting
project defects.
The following table identifies:
1. The project processes subject to quality assurance.

2. The quality standards and stakeholder expectations for that process.
3. The quality assurance activity – e.g., quality audit or reviews, code review – that will be
executed to monitor that project processes are properly followed.
4. How often or when the quality assurance activity will be performed.
5. The name of the person responsible for carrying out and reporting on the quality
assurance activity.
 Quality control
Quality Control consists of the observation techniques and activities used to fulfill
requirements for quality.
You can think of quality control as the activities that are used to evaluate whether your product
or service meets the quality requirements specified for your project. It's important to note that
project quality control is performed throughout the project.
The quality requirements are defined during the quality planning process. They include both
project processes and product goals.

Quality Control Tools & Techniques
Some of the tools and techniques you can use to perform quality control include...
 Cause and Effect Diagram (i.e. Fishbone Diagrams)

 Control Chart
 Flow Chart
 Pareto Chart
 Histogram
 Run Chart
 Scatter Diagram
 Statistical Sampling
 Inspection
For some of these tools, it is helpful to have a basic understanding of sampling and probability.
These quality control tools and techniques can help you in three ways...
 Confirm that your project is meeting the quality standards

 Provide a basis for corrective action
 Provide feedback about your quality assurance process
Quality Control vs Quality Assurance

Many people get confused between quality control and quality assurance.
To differentiate between the two, remember that quality control is about evaluating whether the
product of your project meets the quality standards. It is performed after the product has been
completed.
Quality assurance, on the other hand, is about ensuring that the product is produced in the right
way. It is proactive and concerned about the processes and activities during the products
development.

Notable approaches to quality control
There is a tendency for individual consultants and organizations to name their own unique
approaches to quality control—a few of these have ended up in widespread use:
Terminology Approximate Description

year of first use
Statistical quality 1930s The application of statistical methods (specifically
control (SQC) control charts and acceptance sampling) to quality
control.
Total quality 1956 Popularized by Armand V. Feigenbaum in a Harvard
control (TQC) Business Review article and book of the same name.
Stresses involvement of departments in addition to
production (e.g., accounting, design, finance, human
resources, marketing, purchasing, sales).
Statistical process 1960s The use of control charts to monitor an individual
control (SPC) industrial process and feedback performance to the
operators responsible for that process. Inspired by
control systems.
Company-wide 1968 Japanese-style total quality control
quality control
(CWQC)
Total Quality 1985 Quality movement originating in the United States
Management Department of Defense that uses (in part) the techniques
(TQM) of statistical quality control to drive continuous
organizational improvement.
Six Sigma (6σ) 1986 Statistical quality control applied to business strategy.
Originated by Motorola.

Quality Assurance is process oriented and focuses on defect prevention, while quality control
is product oriented and focuses on defect identification.
Quality Assurance Quality Control

Definition QA is a set of activities for ensuring QC is a set of activities for ensuring
quality in the processes by which quality in products. The activities focus
products are developed. on identifying defects in the actual
products produced.
Focus on QA aims to prevent defects with a QC aims to identify (and correct)
focus on the process used to make defects in the finished product. Quality
the product. It is a proactive quality control, therefore, is a reactive process.
process.
Goal The goal of QA is to improve The goal of QC is to identify defects
development and test processes so after a product is developed and before
that defects do not arise when the it's released.
product is being developed.
How Establish a good quality management Finding & eliminating sources of
system and the assessment of its quality problems through tools &
adequacy. Periodic conformance equipment so that customer's
audits of the operations of the requirements are continually met.
system.
What Prevention of quality problems The activities or techniques used to
through planned and systematic achieve and maintain the product
activities including documentation. quality, process and service.
Responsibility Everyone on the team involved in Quality control is usually the
developing the product is responsible responsibility of a specific team that
for quality assurance. tests the product for defects.
Example Verification is an example of QA Validation/Software Testing is an
example of QC
Statistical Statistical Tools & Techniques can When statistical tools & techniques are
Techniques be applied in both QA & QC. When applied to finished products (process
they are applied to processes (process outputs), they are called as Statistical
inputs & operational parameters), Quality Control (SQC) & comes under
they are called Statistical Process QC.
Control (SPC); & it becomes the part
of QA.
As a tool QA is a managerial tool QC is a corrective tool

Differences between Quality Assurance and Quality Control
Definitions of QA and QC
 Quality Assurance (QA) refers to the process used to create the deliverables, and can be
performed by a manager, client, or even a third-party reviewer. Examples of quality
assurance include process checklists, project audits and methodology and standards
development.
 Quality Control (QC) refers to quality related activities associated with the creation of
project deliverables. Quality control is used to verify that deliverables are of acceptable
quality and that they are complete and correct. Examples of quality control activities
include inspection, deliverable peer reviews and the testing process.
 Quality control is about adherence to requirements. Quality assurance is generic and does
not concern the specific requirements of the product being developed.
 Quality assurance activities are determined before production work begins and these
activities are performed while the product is being developed. In contrast, Quality control
activities are performed after the product is developed.
 Tools and techniques for quality control

The Seven Basic Tools of Quality is a designation given to a fixed set of graphical techniques
identified as being most helpful in troubleshooting issues related to quality. They are called basic
because they are suitable for people with little formal training in statistics and because they can
be used to solve the vast majority of quality-related issues.
The seven tools are:
 Cause-and-effect diagram (also known as the "fishbone" or Ishikawa diagram)

 Check sheet
 Control chart
 Histogram
 Pareto chart
 Scatter diagram
 Stratification (alternately, flow chart or run chart)
The designation arose in postwar Japan, inspired by the seven famous weapons of Benkei. It was
possibly introduced by Kaoru Ishikawa who in turn was influenced by a series of lectures W.
Edwards Deming had given to Japanese engineers and scientists in 1950. At that time, companies
that had set about training their workforces in statistical quality control found that the complexity
of the subject intimidated the vast majority of their workers and scaled back training to focus
primarily on simpler methods which suffice for most quality-related issues.
The Seven Basic Tools stand in contrast to more advanced statistical methods such as survey
sampling, acceptance sampling, statistical hypothesis testing, design of experiments, multivariate
analysis, and various methods developed in the field of operations research.

The Project Management Institute references the Seven Basic Tools in A Guide to the Project
Management Body of Knowledge as an example of a set of general tools useful for planning or
controlling project quality.
Examples
Cause-and-effect
effect diagram
 Check sheet

Control chart
Histogram
Pareto chart


Scatter diagram

Flow chart
 Project quality factors

6 Success Factors for Managing Project Quality
Commentators have differing views on what constitutes a quality project. The generally agreed
parameters are that it delivers the desired outcomes on time and within budget. Through our long
experience, the Transformed team has identified 6 key factors that improve project quality:
Key Success Factor 1: A good plan
The Plan, Do, Check, Act cycle is fundamental to achieving project quality. The overall project
plan should include a plan for how the project manager and team will maintain quality standards
throughout the project's cycle.
Key Success Factor 2: Appropriate Communication

C
Despite good project planning and scheduling, poor or absent communication with team
members and stakeholders can bring a project undone. Project managers need excellent
communication skills and a comprehensive scheme that encourages formal and
and informal
discussion of expectations, innovation, progress and results.
Key Success Factor 3: Manage Stakeholders
Stakeholders include everyone who has an interest in, can influence or is affected by the project's
implementation or outcomes. To engage stakeholders,
stakeholders, identify who they are, analyse their

concerns and what they need to know, and then prepare a strategy to provide the appropriate
amount of information and opportunities for involvement.
Key Success Factor 4: Good Measurement
Early in the process it is important to identify the key outcomes and outputs of the project and
how you will measure whether they have been delivered. Implement processes that measure
progress, both qualitatively and quantitatively, throughout the project at individual, team and
whole project levels. This ensures that problems can be identified early and successful tactics can
be promulgated throughout the project.
Key Success Factor 5: Constant Review
Along with good measurement go good review mechanisms. Successful project managers
diligently and regularly review progress against the schedule, budget and quality elements of the
project. Regular review allows problems to be identified early so that corrective action can be
taken to keep the project on track. Review also helps team members to learn and improve their
skills.
Key Success Factor 6: Act early
Measurement and review are important but they are only effective if the project manager takes
action on issues identified. Leaving problems to be fixed up later is a recipe for disaster. Simple
issues should be addressed immediately. More complex issues should be added for action into
the project plan and resources allocated to address them.
 Overview of project management standards {PRINCE 2)

PRINCE2 Definition
PRINCE2 (an acronym for PRojects IN Controlled Environments) is a de facto process-based

method for effective project management. Used extensively by the UK Government, PRINCE2
is also widely recognized and used in the private sector, both in the UK and internationally. The
PRINCE2 method is in the public domain, and offers non-proprietorial best practice guidance on
project management.
Key features of PRINCE2:
 Focus on business justification

 Defined organisation structure for the project management team
 Product-based planning approach
 Emphasis on dividing the project into manageable and controllable stages
 Flexibility that can be applied at a level appropriate to the project

How PRINCE2 Can Benefit You or Your Organisation?
Using PRINCE2 provides you with greater control of resources, and the ability to manage
business and project risk more effectively. This will benefit:
 Individuals seeking leading project management skills and greater employment prospects
 Project managers
 Directors/executives (senior responsible owners) of projects, and
 Organisations.
For individuals, PRINCE2 certification is an invaluable asset to your career as it increases

employment prospects and helps you to do your job more effectively.
For organisations, PRINCE2's formal recognition of responsibilities within a project, together

with its focus on what a project is to deliver (the why, when and for whom) provides your
organization’s projects with:
 A common, consistent approach

 A controlled and organized start, middle and end
 Regular reviews of progress against plan
 Assurance that the project continues to have a business justification
 Software tools in project quality management
ISO certification
ISO Certification is a seal of approval from a 3rd party body that a company runs to one of the
internationally recognized ISO management systems. The certification can be used to tender for
business as a proof of a company’s credibility but also to install confidence in the potential client
that you will keep your promises.
The ISO 9000 family of quality management systems standards is designed to help organizations
ensure that they meet the needs of customers and other stakeholders while meeting statutory and
regulatory requirements related to a product. ISO 9000 deals with the fundamentals of quality
management systems, including the eight management principles upon which the family of
standards is based. ISO 9001 deals with the requirements that organizations wishing to meet the
standard must fulfill.
Third-party certification bodies provide independent confirmation that organizations meet the
requirements of ISO 9001. Over one million organizations worldwide are independently
certified, making ISO 9001 one of the most widely used management tools in the world today.
However, the ISO certification process has been criticizedas being wasteful and not being useful
for all organizations
 Using a software tool to assist in quality management

TOPIC 7
IS PROJECT COMMUNICATION MANAGEMENT

Communications management is the systematic planning, implementing, monitoring, and
revision of all the channels of communication within an organization, and between
organizations; it also includes the organization and dissemination of new communication
directives connected with an organization, network, or communicationstechnology. Aspects of
communications management include developing corporate communication strategies, designing
internal and external communications directives, and managing the flow of information,
including online communication.
Communication management and project management
In project management, communication management must address the following questions:
 What information needs to flow in and out of the project?

 Who needs what information?
 When is the information needed?
 What is the format of the information?
 Who will be responsible for transmitting and providing the information?
Weekly reporting method
One simple and popular communications method is called the weekly reporting method: every
employee composes an e-mail report, once a week, including information on their activities in
the preceding week, their plans for the following week, and any other information deemed
relevant to the larger group, bearing in mind length considerations. Reports are sent to managers,
who summarize and report to their own managers, eventually leading to an overall summary led
by the CEO, which is then sent to the board ofdirectors. The CEO then sends the board's
summary back down the ladder, where each manager can append an additional summary or note
before referring it to their employees.
Eventually, each employee will receive a long e-mail, containing many or all of the above-
mentioned summaries, from every level of management; reading the full result is rarely a
requirement. Curious or ambitious employees are considered more likely to read the result; task-
centered employees, however, are not.

 Communication management
What is Project - Includes the processes required to ensure timely and appropriate
Communications generation, collection, distribution, storage, retrieval and ultimate
Management? disposition of project information.
- Project managers report that they spend 90% of their time
communicating, which is not surprising since they are achieving results
through the effort of others
- Communication is the glue that connects the project stakeholders
Identify Stakeholders. - This is the process of identifying all people or organizations impacted
by the project, and documenting relevant information regarding their
interests, involvement, and impact on project success.
- Remember that stakeholders can have either a positive or negative
influence on a project; both are important to identify.
Why should you - It is critical to identify stakeholders as early as possible in the project,
identify stakeholders because each stakeholder is a potential source of project requirements
early? - Failure to identify a stakeholder may well lead to so-called "scope
creep" that in this case is really a failure to properly identify all
requirements in the beginning
- We also need a strategy for dealing with each stakeholder
What are the INPUTS 1. Project charter, which as an initial list of stakeholders
of the process - Identify 2. Procurement documents, which indicate parties to a contract that
Stakeholders? become stakeholders
3. Enterprise environmental factors, including organizational culture and
structure, and any relevant governmental or industry standards
4. Organizational process assets, including stakeholder register
templates, and historical information, including lessons learned.
What are the TOOLS 1. Stakeholder analysis
AND TECHNIQUES of 2. Expert judgment
the process - Identify
Stakeholders?
What are the 1. Stakeholder registers
OUTPUTS of the 2. Stakeholder management strategy
process - Identify
Stakeholders?
Describe Stakeholder - Identify all potential stakeholders and relevant information about them,
Analysis. such as their roles, departments, interests, knowledge levels,
expectations, and influence levels. Key stakeholders are those in
decision making or management roles. Also identify other stakeholders
during interviews with stakeholders.
- Identify the potential project impact or support the stakeholder could
provide, classifying them to help define an approach strategy. Prioritize
them.
- Assess how keep stakeholders are going to react or respond to various
project situations and issues, to plan how to influence them to enhance
their support and mitigate their negative impact.
Describe Stakeholder Classification models include power/interest grid, power/influence grid,

Impact Analysis influence/impact grid. Below is an example power/interest grid, with
power on the Y-axis and interest on the X-axis. Each stakeholder is
position within a quadrant.
Keep Satisfied | Manage Closely

---------------------------------------------------------------
Monitor (min effort) | Keep Informed
A salience model describes classes of stakeholders based on their power,

urgency, and legitimacy, driving the strategy for dealing with the
stakeholder.
The Stakeholder The Stakeholder Register contains all the details related to identified
Register stakeholders, including:
- Identification, such as name, position, role, contact information
- Assessment, such as major requirements, main expectations, potential
influence on the project and in what phase
- Classification, such as internal or external, attitude toward project
(support, neutral, resister)
The Stakeholder The Stakeholder management strategy is the approach to be used to
Management Strategy increase support and minimize resistance, including:
- Who can significantly impact the project
- Desired level of participation in the project
- Stakeholder groups, and their management, as groups
A common format for this output is a matrix or spreadsheet outlining the

stakeholder, his interest, assessment of impact, and potential strategies
Plan Communications - Determining the information needs and communication approach of
the stakeholders (Who needs what information, When they will need it,
How it will be given to them, and by whom)
- Identifying the informational needs of stakeholders and determining a
suitable means of meeting those needs is an important factor for project
success
- Tightly linked with enterprise environmental factors and organizational
influences such as project's organizational structure will have a major
effect on project communication requirements.
What are the INPUTS 1. Stakeholder register, output of Identify Stakeholders process
of the process - Plan 2. Stakeholder management strategy, output of Identify stakeholders
Communications? process
3. Enterprise environmental factors (all of them)
4. Organizational process assets, especially historical information and
lessons learned.
What are the TOOLS 1. Communications requirements analysis
AND TECHNIQUES of 2. Communications technology
the process - Plan 3. Communication models
Communications? 4. Communication methods

What are the 1. Communications management plan
OUTPUTS of the 2. Project document updates, including the project schedule, stakeholder
process - Plan register, and stakeholder management strategy
Communications?
Communications Information needs of stakeholders are analyzed, including type, format
Requirements Analysis and timing needs.
- Take care to avoid wasting resources on unnecessary information or
inappropriate technology
- Remember to consider the number of communications channels n*(n-
1)/2 to limit who will communicate with whom
Communications Analysis to consider methods and technologies suited to the project.
Technology Factors to consider:
- Urgency of need for information
- Availability of technology
- Expected project staffing
- Duration of the project
- Project environment
Communication - Interactive communication includes meetings, phone calls, video
Methods conferencing
- Push communication, when we send information to specific recipients.
Includes letters, memos, reports, emails, faxes, voice mails, press
releases. Without a confirming return, we cannot know this
communication reached its target.
- Pull communication, when the stakeholder actually has to act to
retrieve communication. Includes internet sites, knowledge repositories.
Communication Plan The Communications Plan, contained in, or a subsidiary of, the project
management plan. Contains:
- Stakeholder communication requirements
- Language, format, content, and level of detail
- Reason for distributing the information
- Timing and frequency of distribution
- Responsibility for authorizing and communicating
- Methods of conveying information
- Resources allocated for communications activities
- Issue escalation policies and procedures
- Update method for maintaining the plan
- Glossary of common terms
- Flowcharts of information flow
- Communication constraints
Distribute Information The process of making information available to project stakeholders as
planned. Includes implementing the Communications Management Plan,
as well as responding to unexpected requests for information.
Spans a number of techniques, including sender-receiver models, choice

of media, writing style, meeting management techniques, presentation
techniques, and facilitation techniques.

Why does sharing - Project personnel should communicate data honestly and thus share
information mean power.
sharing power? - Sharing data gives project personnel potential power
- Senior executives and the project manager are responsible for
establishing the conditions that encourage honest communication and
shared power.
What are the INPUTS 1. Project management plan, including communication management
of the process - plan
Distribute Information? 2. Performance reports to distribute project performance and status
information. This will include forecasts, perhaps from earned value
management techniques
3. Organization process assets, including templates, historical
information and lessons learned, and policies, procedures, and
guidelines regarding information distribution
What are the TOOLS 1. Communication methods, such as meetings, video and audio
AND TECHNIQUES of conferences, computer chats and so forth
the process - Distribute 2. Information distribution tools, including hard-copy documents, filing
Information? systems, press releases, shared access databases, electronic formats like
e-mail, fax, voice mail, telephone, websites, and electronic tools for
project management, such as web interfaces, virtual office, software
portals, etc.
What are the 1. Organization process assets updates including:
OUTPUTS of the - Lessons learned documentation
process - Distribute - Project records (includes correspondence, memos, and documents
Information? describing the project)
- Project reports (formal or informal reports on project status and/or
issues)
- Project presentations (formal or informal presentations to project
stakeholders customized based upon the needs of the audience)
- Feedback from stakeholders
- Stakeholder notifications
Manage Stakeholder - The process of communicating and working with stakeholders to meet
Expectations their needs and addressing issues as they occur
- Managing expectations can help to increase the probability of project
success by making sure that stakeholders understand the project
benefits, risks, and issues, thereby enabling them to be active project
supporters
- Managing stakeholder expectations is a project manager responsibility
What are the INPUTS 1. Stakeholder registers from Identify Stakeholders process
of the process - Manage 2. Stakeholder management strategy, from Identify stakeholders process
Stakeholder 3. Project management plan, which contains the communications
Expectations? management plan
4. Issue log, which documents issues, assigns ownership, and sets a
target data for closure
5. Change log, documenting changes that occur in the project
6. Organizational process assets, including issues management

procedures
What are the TOOLS 1. Communication methods

AND TECHNIQUES of 2. Interpersonal skills, including building trust, resolving conflict, active
the process - Manage listening, and overcoming resistance to change
Stakeholder 3. Management skills, including presentation skills, negotiating, writing
Expectations? skills, and public speaking
What are the 1. Organizational process updates, including causes of issues, reasons
OUTPUTS of the for corrective actions taken and lessons learned
process - Manage 2. Change requests, to be process in Perform Integrated Change Control
Stakeholder 3. Project management plan updates, including the communication
Expectations? management plan
4. Project document updates, including stakeholder management
strategy, the stakeholder register, and the issue log
Report Performance Involves collection and distribution of performance information,
including status reports, progress measurements, and forecasts to
stakeholders
- Can include how resources are being used to achieve project objectives
- Should provide information on scope, schedule, cost and quality
- May also require information on risk and procurement
- Reports may be prepared comprehensively or on an expectation basis
What are the INPUTS 1. Project Management Plan, which includes baselines
of the process - Report 2. Work performance information from Direct and Manage Project
Performance? Execution, including deliverable status, schedule progress, and costs
incurred
3. Work performance measurements, to generate project activity metrics,
including planned versus actual schedule, cost, and technical
performance
4. Budget forecasts from the Control Cost process
5. Organizational process assets including report templates, policies and
procedures defining the measures and indicators to use, and
organizational variance tolerance
What are the TOOLS 1. Variance analysis, to look at what caused variance
AND TECHNIQUES of 2. Forecasting methods
the process - Report 3. Communication methods
Performance? 4. Reporting systems, which are a standard tool to help the project
manager capture, store, and distribute information to stakeholders, using
software tools to assist.
What are the 1. Performance reports
OUTPUTS of the 3. Organizational process assets updates, including reports, lessons
process - Report learned, causes of issues and corrective action taken, and any other
Performance? historical information
3. Change requests, processed through Perform integrated change
control process. Could include recommended corrective or preventive

action.
What are examples of - Time series method, using history to estimate future outcomes
Forecasting methods? - Casual/econometric methods, including regression analysis, auto-
regressive moving average, and econometrics
- Judgmental methods, including composite forecasts, surveys, Delphi
method, scenario building, technology forecasting, and forecasting by
analogy
- Other methods including simulation, probabilistic forecasting, and
ensemble forecasting.
How are Performance Performance reports organize and summarize the information gathered
Reports used? and present the results:
- Information should include status, progress, and issues
- Format can be bar charts, S-curves, histograms, and tables
- Variance analysis, earned value analysis, and forecast data are often
included
What are some samples - Analysis of past performance
of information in - Current status of issues and risks
Performance Reports? - Work completed in period just ended
- Work to be completed in period coming up
- Summary of changes approved in period
- Results of any variance analysis
- Forecasted project completion (time and cost)
- Other relevant information
 Essentials of project documentation
 Progress reporting
Progress reporting is a key activity of project management. The project manager issues regular
reports of progress against budget, schedule and scope. Include these people on the circulation
list:
 Project Sponsor
 Budget Holder
 Senior Users
 Team Members
Keep the report brief and sum up the key points in the project. I recommend this simple format
on a maximum of two pages:
1. Report Date
2. Overall Status
3. Project Summary

4. Key Issues
5. Identified Risks
6. Tasks and Next Steps
7. Decisions Needed
8. Key Future Dates
9. Budgeted Cost
10. Spend to Date
Anyone reading the report must be made fully aware of progress and know when their help is
needed to keep the project on track.
Keeping people updated ensures they remain involved and committed. Regular communication is
essential to the well-being of any project. Common failings in this area are:
 Poor communication channels

 Lack of honest communication
 Unwillingness to communicate bad news
 Not asking for help when it's needed
Regular progress reporting creates a valuable written record of a projects' life. Later you can look
back and decide how to improve the running of future projects.
Your boss has asked you to take the lead on a project in your company. Maybe you are a project
manager, or maybe you are not. One thing is certain. Very few people know how to report status
on a project, even when they are expert project managers. The basic problem is most people do
not understand the perspective of a manager who is being pressed for information about a big
project. Here are some basic rules of reporting status that you can use to further your reputation
as someone who knows how to keep management and the project team informed and drive a
project to success.
The Management Perspective
If your project is important, your boss will be pressed hard to keep his superiors informed of its
progress. Smart managers consume status on important projects voraciously. Excellent status
reporting means that managers are fully informed of your projects health and overall direction
without having to get involved themselves. There is particular information your boss needs in
order to show her boss that she is on top of things and able to run the show effectively. Provide
this information in a way your boss can consume it on a regular basis, and you will fall upstairs
so fast your head will spin.
Even on relatively less important projects, effective status reporting allows your boss to spend
only a few seconds skimming your report to determine what sort of progress you have made.
Excellent status creates clarity from confusion. Your job as the manager of a project is to take a
swirling, chaotic cloud of information and distil it down into its most basic elements and then
present them so that hundreds and thousands of hours of work can be understood in 30 seconds.

To write excellent status, you must understand:
 The three components of status.

 How to write brief details.
 What key data is needed by management?
Three Components of Status
There are three major components to reporting project status:
 Overall: We need to see the overall project health. As managers, we want to be able to
detect a project in trouble. We also want to help make that determination sometimes. You
might not know everything we know despite our best efforts to communicate. Your
project might not be as healthy as you think it is.
 Milestones: Your project has major accomplishments which must be completed by
specific dates. We managers want to see which milestones are complete, which ones are
in progress, and which ones are coming up next. This allows us to analyse the schedule
and decide to either feel comfortable with it or challenge it.
 Issues: Your project also probably has one or more obstacles to completion which have
been discovered. We'd like to see brief details about each issue so that we can make a
decision about whether or not to step in and help if necessary.
Organizing Your Status
Just as you would clean a kitchen by starting up high and working your way down ultimately to
the floor, project statuses is best when it starts off with the highest levels of detail and works its
way down to lower and lower levels.
Thus:
Overall project health comes first. If I like what I see here, I can stop reading the rest. Major
milestones follow overall project health. If I don't like the project health, or if I am in need of
further details, I can read a little further and check out the scheduled dates we are driving toward
and your progress on them. Issues may be holding up those dates, so when I see a problem in
your project schedule, I can read further and see what it is. Really slick project managers report
the issues in priority order showing the issue causing the most jeopardy to progress first.
Brief Details
Your job is to report on the details of your project in concise, crisp status that we can consume
rapidly without having to spend much effort on it. It might take you thirty minutes to write your
status, but always remember that your manager does not have thirty minutes to spend reading it.
Your manager realistically only has about 30 seconds to consume your status as they may have
30, 40, 100, or even exponentially more projects for which they are responsible.

"Brief Details" may seem oxymoronic to a project manager, but to a supervisor with a team of
project managers, it is not. There is enormous value in a project manager who can report status
without narrative. My recommendation is that you write as though you were creating an old-
fashioned telegram. More information about how to do that is coming.
Brief Details
How can you provide details without being long-winded? It is a formidable task that most never
master, but it is not impossible. Here are some suggestions:
 Write in bullets, not in prose. There shall be no paragraph anywhere in your status.
 Avoid unnecessary use of titles and colons. We can see that 7/4/2008 is a date. Writing
date: 7/4/2008does not tell us anything that 7/4/2008 does not.
 Reduce, reduce, and reduce some more. Do your best to shorten all expressions and
sentences.
 Avoid adverbs (really, very, much) and avoid adjectives (good, bad, ugly).
Key Data
Management will need certain data from you in order to see overall health, performance against
milestones, and the threat that project issues present. For overall project health, these data points
might include:
 The project's name

 The project identification number if your company uses a tool to store projects.
 The overall project health (red yellow green - more on this in a future article).
 The % complete you expected to be at today (planned completion).
 The % complete you are actually at.
 The number of days behind or ahead against the plan.
 The number of blocking issues you face (more about this later in this article).
 The number of "normal issues" you face.
These data elements should provide a sound overview of project health for the average executive
who is not details minded and is not interested in getting more involved in your project.
If I am your supervisor, I need to see more than just the overall health of the project. I also want
to see where we are against certain milestones so that I can make a decision about whether or not
to get more involved. One of the hardest things a manager has to do all day is decide whether to
give you more room or get into your work with you. We don't want to carry your work for you,
but we also don't want you to fall flat on your face.
Providing project milestones is helpful in this regard. It lets us see your schedule at a high level,
determine if the schedule is acceptable as it stands, and predict pitfalls you might face down the
road.
Milestones have six components:

 The milestone name.
 The percent complete of the milestone.
 The planned start.
 The planned finish.
 The actual start.
 The actual finish.
Some people like to provide red, yellow, green (RYG) status for each milestone in their project. I
don't believe that adds any value. Of course the completed tasks are green. They are complete!
All following milestones have the same status as the current milestone, so there is no point in
differentiating them. The RYG status of the whole project is all that is necessary.
It's best to start with the earlier tasks first and the final delivery date at the bottom. If you list
them haphazardly, you will create more confusion than clarity.
Issue Management
The final portion of your status report is to list the major issues your project faces. Important data
that we need on your issues:
 Ticket number: if there is a ticketing system, give us a link to the ticket or the number of
the ticket.
 Issue name: this should be very descriptive and brief.
 Date and time reported: we need this to see ageing. The older an issue is, the more
likely someone is going to get in trouble for not solving it faster.
 Priority or severity of the issue: your issue is mega-important if it is a "blocking issue."
If the problem is stopping the project from moving forward and is single-handedly
responsible for endangering the delivery date, it is a blocking issue and is very important.
If the problem is just another bug in some software that will be resolved in short order, it
is not as important.
 Who has it? The name of the person who currently owns driving this issue forward.
 ETA: Managers are like children and always want to know when they are going to get
something. "Are we there yet? Are we there yet?" Provide a time and date for when the
issue will be resolved. If you cannot, then provide a time and date for when you will get
to the next step in the issue resolution process. If you cannot do that, then provide an
ETA for your next updated status on the issue.
 Current Activity: What is currently being done to resolve this issue? Are you firing up a
conference call? Are you calling out for reinforcements from a particular group? What is
being done to mitigate? Are there alternatives?
Expected Results
If you produce really great status on a project and provide it often enough and to the right people,
which are great topics for future articles, you should expect one of two results. Either
management will become very quiet and not engage with you very much, which usually means
they feel you are on top of the project and are capable of operating without their intervention, or

they will increase their communications with you in order to ferret out further details and
determine if they need to intervene.
Either result is better than the alternative: Management asking you for status. Your job as a
project manager is to create clarity from confusion for the project team and for management.
Essentially, the job is one of analysis and communication. If management is asking you for the
status, either you are not sending it to the right people, you are not sending it often enough, or
you are not sending a good status report.
Management should be able to passively absorb your status without having to reach out to you to
find out where things are at. The pace at which you send it, the audience you select, and the
content of your communications should be available to them easily and quickly.
A project manager that can present status of a project skilfully and briefly is a rare find. It should
not be necessary to create colorful slide shows or multi-page documents in order to provide
really great status reports. Many go that route and drown management in errata. Narratives and
prose are always unwelcome in status reports, and yet so many write as though they were
authoring a novel and create a report that management must spend inordinate amounts of time
with in order to get what they need. Others fail to provide enough information at all, or worse,
they provide status irregularly or rarely.
In all of the project management training and certification systems available today, almost none
teach how to report the current state and next steps of a project. Learn to status your projects
effectively and you have a competitive edge that goes beyond the standard project management
toolkit.
 Report writing
Report Writing: Formatting the Report Elements
Here are the main sections of the standard report writing format:
 Title Section - If the report is short, the front cover can include any information that you
feel is necessary including the author(s) and the date prepared. In a longer report, you
may want to include a table of contents and a definition of terms.
 Summary - There needs to be a summary of the major points, conclusions, and
recommendations. It needs to be short as it is a general overview of the report. Some
people will read the summary and only skim the report, so make sure you include all the
relevant information. It would be best to write this last so you will include everything,
even the points that might be added at the last minute.
 Introduction - The first page of the report needs to have an introduction. You will
explain the problem and show the reader why the report is being made. You need to give
a definition of terms if you did not include these in the title section, and explain how the
details of the report are arranged.
 Body - This is the main section of the report. The previous sections needed to be written
in plain English, but this section can include jargon from your industry. There needs to be

several sections, with each having a subtitle. Information is usually arranged in order of
importance with the most important information coming first. If you wish, a “Discussion”
section can be included at the end of the Body to go over your findings and their
significance.
 Conclusion - This is where everything comes together. Keep this section free of jargon as
most people will read the Summary and Conclusion.
 Recommendations - This is what needs to be done. In plain English, explain your
recommendations, putting them in order of priority.
 Appendices- This includes information that the experts in the field will read. It has all the
technical details that support your conclusions.
This report writing format will make it easier for the reader to find what he is looking for.
Remember to write all the sections in plain English, except for the Body. Also remember that the
information needs to be organized logically with the most important information coming first.
Tips for Good Writing
Here are a few tips for good writing.
 Keep it simple. Do not try to impress, rather try to communicate. Keep the sentences
short and to the point. Do not go into a lot of details unless it is needed. Make sure every
word needs to be there, that it contributes to the purpose of the report.
 Use an active voice rather than passive. Active voice makes the writing move smoothly
and easily. It also uses fewer words than the passive voice and gives impact to the writing
by emphasizing the person or thing responsible for an action. Here is an example: Bad
customer service decreases repeat business.
 Good grammar and punctuation is important. Having someone proofread is a good idea.
Remember that the computer cannot catch all the mistakes, especially with words like
“red, read” or “there, their.”
Communication Skills
There is a growing consensus among business executives that there is a lack of good writing
skills among job applicants, as reported in several recent surveys. Because of this, employers are
including writing skills as one of the skills they look for when hiring. Some even ask for a
sample report when screening applicants. It is even included in the job description that the job
requires a motivated communicator.
Good communication is essential in business. Usually there is more than one individual that is
working on a goal, and good communication will allow an exchange of ideas and concerns.
 There can be no team effort without communication, as it is necessary to coordinate the

efforts of everyone.
 Bad communication can waste valuable time and effort.

If a team member discovers a short cut or solves a problem, that information needs to go out to
every team member so they can benefit from it and reach their goal quicker.
 Managing stakeholders
Who Is a Stakeholder?
Project stakeholder management is a key stakeholder skill – as your stakeholders can either make
or break your project. Who are your project stakeholders? Your stakeholders are the people that
have an interest in the project outcome or process. That interest can either be positive, wanting
the benefits of the outcomes or process of your project, or negative, seeing the outcomes or
process as a hindrance to them.
Project stakeholders will include:
 project sponsors
 steering committee members
 business unit and line managers
 project team members
 end users of the products or services resulting from your project
 contractors and consultants supplying services to your project
 material and product suppliers
 departments supplying resources, infrastructure and expertise (such as IT and HR)
Tips for Managing Stakeholders
Your stakeholders will need to be managed through every phase of your project. Start with
involving them in clarifying the scope of your project and identifying possible solutions to the
organization's problem that the project is designed to solve. As the project proceeds, draw up a
communication strategy and a communication plan that identifies how, when and what to
communicate to each stakeholder group. Part of this involves project reporting. Think about how
and when and to what level of detail you will deliver project reports to each group.
You will find that different stakeholders will want very different outcomes from your project. A
vital part of stakeholder management is managing these competing expectations from the initial
phase through to final implementation. Finally, in the evaluation phase of your project, find out
from your stakeholders how well the project satisfied their needs. There will be valuable lessons
in there for your future projects.
 Using a software tool to assist in project communication management

TOPIC 8
IS PROJECT RISK MANAGEMENT

Project risk management is an important aspect of project management. According to the
ProjectManagementInstitute'sPMBOK, Risk management is one of the ten knowledge areas in
which a project manager must be competent. Project risk is defined by PMI as an uncertain event
or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
Good Project Risk Management depends on supporting organisational factors, clear roles and
responsibilities, and technical analysis skills.
Project risk management in its entirety, includes the following six process groups:
 Planning risk management

 Risk identification
 Performing qualitative risk analysis
 Performing quantitative risk analysis
 Planning risk responses
 Monitoring and controlling risks
Project Risk management is the identification, assessment, and prioritization of risks followed by
coordinated and economical application of resources to minimize, monitor, and control the
probability and/or impact of unfortunate events or to maximize the realization of opportunities.
Identifying Project Risks

Every project has risks that threaten to cause project failure. Project risk management involves
firstly identifying the risks that impact your project. These could be:
 a reliance on new and untried technology

 project funds contingent upon future profits
 inexperienced project team members
 late arrival of specialized equipment
You don't know everything, so it's best to get as many people involved in the risk identification
process as possible. The most efficient and effective process for identifying risks is to get your
key stakeholders together for a risk identification exercise all at one time. One person's idea will
then trigger a thought in someone else. Running this kind of brainstorming session gives you the
best chance for capturing all of the most important risks without them coming back to bite you
and your project team when you least expect.
Analyzing and Mitigating Risks

Your next task as Project Manager is to analyze the risks. Risk analysis can take many forms.
However, it usually revolves around providing answers to three key questions:
1. What is the probability of the risk event occurring?
2. What would be the impact on the project if the risk event were to occur?

3. What steps can be taken to minimize the impact of the risk event if it did happen?
Answering the third question provides your risk mitigation strategy for each risk. You then need
to decide for each risk who will implement the strategy and by when.
Don't forget to review risks continuously throughout your project. Previously identified risks
may disappear and new ones emerge. Don't be caught off guard! We recommend you maintain a
Risk Register to keep your project team updated on current risk status.
 Risk identification process

Definition: Risk identification is the process of determining risks that could potentially prevent
the program, enterprise, or investment from achieving its objectives. It includes documenting
and communicating the concern.
Identifying and Managing Project Risk by Tom Kendrick is a book about identifying and
managing risks on projects. It was published on April 25, 2003 by American Management
Association. The book is geared to be used by a junior Project Manager and Kendrick aligns the
chapters of the Book to the Project Management Institute's (PMI) Guide to the Project
Management Body of Knowledge, (PMBOK) 2000 edition.
Analysis
The introductory two chapters lay the groundwork for people that are new to project or risk
management. He starts with the definition of risk as the "loss multiplied by the likelihood" and
expands from there. He explains that this relates to uncertainty in estimates for duration and cost.
He identifies the benefits as:
 Lowering cost and confusion

 Prioritization and stakeholder support
 Input for portfolio management
 Mitigation
 Setting expectations and establishing reserves
 Communication and control
Project Risk Planning
Key Ideas: Project Risk Planning

Risk should be a primary driver for project selection
Project planning and definition are the foundation to controlling risk
Risk management should be maintained in a Project Risk Plan
He continues the introduction by justifying project planning and the challenges one might
encounter in an organization that feels a project planning methodology is not needed. He
describes ways one can address the need to set up a planning process and that the implementation
should be scaled to the size of the projects being performed.

The PERIL database is described and qualified while some of the biases in it are enumerated.
Within the three primary constraints on a project, the database shows the risk elements in the
order of frequency of occurrence as 1) schedule, 2) scopeand 3) resource. Implicitly the reader
can determine the database classifies each risk with a description, Project type (IT, Product
development, etc.), schedule impact, cost impact, class (scope, resource, and schedule) and
subcategory.
Scope Risk
Key Ideas: Scope Risk

Clearly define deliverables
Ensure the value of the deliverables exceeds the scope of work
Define a work breakdown structure small enough to ensure work is understood
Assign ownership and determine reasons any items are not accepted
Note all risks, including non-quantifiable risks due to size or complexity of project
Using the PERIL database Kendrick cites that even though the number of risks classified as
scope related are one-third of the entries, they account for approximately half of the cumulative
schedule delay. He enumerates the ranked sources as:
1. Scope creep
2. Hardware defect
3. Software defect
4. Scope gap (ill-defined scope)
5. Dependency change (unexpected legal, regulatory, etc.)
6. Integration defect (change due to unexpected behavior)
Kendrick describes a variety of methods for arriving at and defining deliverables and hence
defining the scope. He suggests using the "is/is not" method of bounding the scope.
Three high-level risk assessment tools are discussed — Risk Framework, Risk Complexity Index
and Risk Assessment grid. Risk Framework looks at the project's technology, the market and the
manufacturing effects and uses the relative change to each of these to determine the risk level of
the project. Risk Complexity Index looks at the technical aspects of the project (technology,
architecture and system) and generates a number from 0-99 to quantify risk. Risk Assessment
creates a grid of technology, structure and size to estimate the risk.
The risk issues addressed by a work breakdown structure (WBS) are then discussed. Often
considered only a project planning task Kendrick points out the uncertainty and risk introduced
into a project when the WBS is not fully defined and understood. A WBS at too high a level can
leave scope ill-defined not allowing for proper estimates or definition of work to be performed.
Often WBS elements that are defined at too high a level indicate work that is not understood and
indicates significant risk due to uncertainty on the project.

Schedule risk
Key ideas: Schedule risk

Estimates with wide variations should be investigated for thorough understanding
Identify source of estimates, especially if not empirical
Identify high risk dependencies
Compare estimates to historical values looking for large variations
Pull risk forward to allow time to react
Identify all potential critical paths
Note project duration risk
Schedule is the second level of risks effecting project duration in the PERIL database. The top
five (the book lists ten) categories are:
1. Project Dependencies
2. Parts Delays
3. Estimation errors
4. Decision Delay
5. Hardware Delay
Dependency on external parties is the largest sub-categorization of schedule risk in the database
(editor’s note: as might be expected since it is always safe to blame the other party) followed by
poor estimations.
To assist in reducing these risks, Kendrick explains that the process should start with the WBS
and apply estimates for effort and resources. This is an iterative process. A number of things
should be kept in mind:
 Historical data should be used where applicable.

 Resources planning (done next) will affect these estimates so these processes will need to
be iterative.
 Be cognizant of people hesitating to give estimates, it may imply additional uncertainty.
 If the durations are greater than two weeks they should be broken down further.
 Make sure to incorporate holidays, vacations and other non-project time.
He summarizes a number of estimating techniques:
 Project-level Think-Do-Check based on project size.

 Historical data
 Prior experience
 Delphi Group Estimating (a form of Consensus estimates)
 Program Evaluation and Review Technique (PERT)

He spends significant time throughout the book discussing the PERT method and clearing up
misconceptions on the PERT process. He explains that the PERT method of estimation generates
the expected duration of a task by adding the pessimistic, optimistic and four times the most
likely durations and dividing them by six. The standard deviation is determined by taking the
difference of the pessimistic and optimistic durations and dividing them by six. The standard
deviation is a reflection of the uncertainty in the estimates.
After determining the durations and sequencing, the critical path can be determined. The Critical
Path is the longest contiguous path of tasks with no lag. The easiest way to do this is by using
one of the many computerized tools on the market. He cautions that an increase in critical and
near-critical paths will bias or significantly increase the probability that the project will not
complete by the projected time. This is due to the statistical probabilities of multiple paths
causing failure.
As with many sections of the book, he provides lists of general items to use when planning.
Resource Risk
Key Ideas: Resource Risk

All skills required to finish the project must have a named resource
Do not over commit staff
Identify tasks with unreliable resource estimates
Identify all understaffed tasks
Document all outsourcing risks
Build in funding for training, equipment and travel
Determine the complete project cost
The final categories of risks are the resource risks. The top five (ten are provided in the book)
are:
 Outsourcing delays
 Lack of funds
 Attrition of resources
 People joining the team late
 Scarcity of skills
When planning one must determine the skill set required and to identify and reserve the people
with those skills. As with schedule sequencing he recommends a computerized tool to properly
look at staff loading. The loading will need to be compared to other project's needs and resource
availability. Conflicts need to be resolved and documented since this also indicates inherent risk
in the project.
Outsourcing, the primary cause of resource induced delay in the database, is mitigated best by
thorough planning, proper RFP (Request for Proposal) generation, a clear and succinct contract

and monitoring the subcontractor for progress. Although incoming inspection is required, this is
too late to mitigate risk.
Funding issues were small in the PERIL database but the sources of error are due to overlooked
staffing, travel, training and equipment costs. Funds for all of the anticipated financial outlays
must be defined and planned for early in the project planning cycle.
Throughout the sections that discuss scope, schedule and resource risk, Kendrick repeats that
analyzing these items must be an iterative process since they are the primary constraints and
changes in one will affect the others.
Constraint Management
Key Ideas: Constraint Management and Risk Discovery

Align project plan and objective
Document project priorities
Identify project alternatives (mitigation)
Explore Project Opportunities
Remove unnecessary project scope
Document risk and impact of proposed changes
Use all means to identify unknown project risk
When controlling project constraint it must be understood that only two of the three constraints
can be defined, the third will be determined by the other two. It should be determined which of
the three (resource, scope or schedule) is the controlling constraint and which is the most
acceptable to change. Determining this and insuring the stakeholders understand the consequence
of this is of utmost importance.
If scope is the least important, determine methods to achieve the most for the customer while
using less resource, trim low priority scope, suggest alternative solutions to the problem being
addressed, and look for reusable components from other projects.
For resource constraints look at cross-training staff or training new people. Outsourcing is an
option but introduces significant risk.
If schedule constraints are an issue, it is possible to use schedule float. Also carefully analyze the
schedule for tasks that can overlap, if they exist, look at defining the tasks with more
granularities. Lastly, if the funds are available, add more resources to try to compress the
schedule. All of these introduce their own risk.
Continually analyze the project for other risks. Kendrick provides a general list of risk categories
to assist in brainstorming, analyzing historical data or previous projects.

Quantifying and Analyzing Activity Risk
Key Ideas: Quantifying and Analyzing Activity Risk

Determine probability and impact for each risk
Use qualitative methods to prioritize risk
Apply quantitative analysis to specific risks
Do not over complicate PERT analysis
The key to assessing risk is determining the probability and impact of the risk and knowing when
these values cannot be determined. Trying to make quantitative decisions from qualitative data is
not sensible. To this end, Kendrick describes some standard and accepted methods of presenting
non-quantifiable risks for the project. A majority of his time in spent discussing two methods in
of quantitative analysis — two dimensional bubble charts and PERT analysis. As in previous
areas on the book he presents beta-distributions of for risks and he lays the groundwork for the
understanding of why simulation products are important when analyzing risk in complex
projects. He presumes a modicum of knowledge of statistics but no knowledge of beta-
distributions is required.
Managing Activity Risk
Key Ideas: Managing Activity Risk

Do root cause analysis
Use one of the three methods of handling risk — mitigate, avoid, transfer
Develop contingency plans for all risk
Publicly display risks
Look for ways to prevent risk
Risks fall into three broad categories — controllable known, uncontrollable known and
unknown. For the former two, one must understand the risks before they can determine how to
manage them. This is done using root cause analysis. As the name implies its goal is to look for
the root cause on the problem and solve it at that point. Kendrick briefly discusses the use of
fishbone diagrams as a tool to assist in this process. Even unknown elements should be handled
in this manner, but obviously do them as they are incurred.
The four ways of handling risk are:
 Avoidance - Take action to avoid the risk

 Mitigation - Define actions to take when the risk occurs
 Transfer - Have someone else handle the risk i.e. insurance
 Acceptance - Identify the risk as acceptable and let it happen.

Determining which option to choose is primarily financial, but schedule and manpower may be
involved. As a tool, Kendrick provides a number of "checklist" opinions for looking at each of
these options.
Contingency planning is briefly discussed for scope, resource and schedule.
Quantifying and Analyzing Project Risk
Key Ideas: Quantifying and Analyzing

Generate a formal survey project risk
Determine project uncertainty based on prior estimates
Use effort months to determine project size.
Kendrick highlights the common project level risks as (citing Capers Jones as the original
source):
1. Estimates that are excessively inaccurate

2. Too aggressive a schedule
3. Poor management
4. Scope creep (poor change management)
5. Large projects not staffed appropriately
Kendrick provides a suggested survey where all responses are on a scale of one-to-three and
using the weighted average (1:3:9) of the responses to determine the risk of the project biasing
the negative impact. Results in the 2.51 - 6.00 range are considered medium and anything above
high risk.
He then returns to the PERT modeling data generated by task and explains the use, limitations
and additional theory. He uses simulations to generating an approximation of the logical
outcomes.
He describes two less rigorous approaches for the looking at project risk compared to other
project. Project Scale compares the total effort months of the project to other projects, the higher
the ratio the more risky. Project Appraisal uses a process similar to appraising a house to
determine risk based on other completed projects.
The remainder of this section is devoted to measuring projects and determining whether a project
is tracking to plan or deviating in a negative manner. He discusses a number of soft techniques
(qualitative judgments) and hard techniques (financial base on actuals) to determine the "health"
of the project.

Managing Project Risk
Key Ideas: Managing Project Risk

Start the project with a kick-off workshop
Determine the appropriate metrics
Set the project reserve
Validate and adjust the objectives
Implement and use a Change Management Process
This section is an assortment of activities that Project Managers may do to align the project team
and the stakeholders for the upcoming project. These items include:
 A recommended list of documentation that summarizes general best practices for a

project, cautioning that quality, not quantity, is the measure.
 A project start-up workshop; including its preparation and execution. The goal is to align
people to the goals and educate them on the challenges.
 Determining the appropriate metrics for the project, ensuring they are not burdensome
and affect behavior in a positive manner. Too often, metrics change behavior to provide
better metrics not better performance.
 Setting the amounts and conditions for use of the project reserves.
 Negotiating the final objectives of the project with stakeholders to improve the chances
of project success.
 Validate that all team members and stakeholders accept the plan of record.
 Describe to all team members and stakeholders the change management process and how
it will be enforced
Key Ideas: Monitoring and Controlling Projects

Be religious on collecting status information ensure that it is only the status you need
Monitor status and trends continuously
Promptly address problems
Communicate, communicate, communicate
Monitoring and Controlling Risky Projects
Execution of the project entails the Project Manager applying the plan, leading the team and
monitoring the project status looking for trends that can indicate variations (good and bad) in the
project execution. Results of the analysis need to be communicated and adjustments made
through a change management and/or issue resolution process.
Communication is imperative. Kendrick describes a variety of tools to aid in communication and

notes where challenges may be become more difficult (remote projects, multiple languages, large
number of stakeholders with differing goals). He also provides the obligatory how-to-run-a-
meeting discussion.

Project traceability is important and Kendrick outlines the needs and requirements of a Project
Management Information System. This system should be a repository for all project documents
and appropriately accessible to all people.
For longer projects Kendrick suggests a periodic project review and assessment. He provides a
checklist of the items this should include and show to conduct the meeting.
Closing Projects Key Ideas: Closing Projects

Document the project results
Proper closure of a project has significant benefits for reducing Recognize contributors
risk on future projects. Whether the project is considered a success Conduct a retrospective
or a failure the results should be documented and reviewed. These
data can then be used in future planning processes to improve planning and reduce risk.
A project retrospective should be conducted and actions taken on the suggestions to improve
processes for the future. Lack of action will reduce participation in subsequent retrospectives.
 Common sources of risk

Here are some places where risks hide out waiting for the innocent project team to drive by.
1. Unknown Stakeholders – These are people who have influence over a project’s goals,
deliverables, resources or schedule. Yet the project team is unaware of them at the outset
of the planning process. These folks represent a major risk factor because they often
display unexpected resistance.
2. Fuzzy Project Scope – Every project has goals but unless the goals are detailed enough
and clear enough, the result is a lack of a common understanding about what the project
is intended to accomplish. If the business doesn’t agree on what they are attempting to
accomplish, the project team can’t possibly get it done.
3. Gold Plated Requirements – Many project teams find themselves in possession of
business requirements that resemble a wish list. There are just too many nice-to-have
features that someone deems critical. Prioritize early and avoid unnecessary gold plating.
4. Inappropriate Staffing – The project plan shows that ten people need to be assigned to
the team to deliver the application, so management assigns ten people. But are they the
right people? Do they have the proper skill sets? It takes more than just warm bodies to
get to done.
5. Infrequent Deliverables – The software industry is notorious for delivering what
nobody wants, later than anyone expected, at a cost no one can afford. Demand frequent
deliverables and checkpoints. The longer the time period between checkpoints, the
greater the risk of the team getting off track.
6. Inadequate Controls on External Providers – Any external provider depended upon
for success of the project must be monitored. Never assume a supplier will deliver simply
because they always have or because there is a forfeiture clause in their contract. They
don’t have skin in the game. You do.

7. Disastrous Events – External events beyond your control can have a profound effect on
a project. Natural disasters, accidents, competitor announcements, mergers, etc. can all
stop a project dead in its tracks. Ask the “what if” questions up front and be prepared for
the unlikely.
Risks can be accepted, avoided, transferred or mitigated. I suppose you could also ignore them
but I wouldn’t recommend it.
 Risk management tools and techniques

What are Risk management tools and techniques?
Risk management tools and techniques are the things and ideas which are used to help to control
risk in a company. They can help an organisation to identify, evaluate, reduce or remove risk, so
that these risks will not have as much of a potential impact onto that organisation. Tools and
techniques may be formal or informal.
What are Risk management tools and techniques like?
Risk management tools and techniques are like kitchen utensils. Without good kitchen utensils
and the right baking techniques, it can be hard to bake a really good cake. For instance, without a
whisk and the right egg-white whisking technique, it can be very hard to make a great meringue.
Without the right tools and techniques, it is highly likely that your attempts at risk management
will fall flat!
What is the purpose of using Risk management tools and techniques?
The purpose of risk management tools and techniques are to give organisations a good way to
create the best possible risk management strategy. Tools and techniques draw upon best practice
to help to create guidelines and tricks which can help to make the risk management process much
easier to complete.
What are the different types of Risk management tools and techniques?
 Flowchart – A flowchart can be used to help to guide an organisation through all of the
main steps of risk management.
 Checklist – A checklist can include step-by-step guides and tick boxes to help to ensure
that everything has been done correctly and on time.
 Standards – Standards are formal techniques of risk management which have been
created to encourage best practice. Completing standards may help to gain an
organization an accreditation.
 SWOT Analysis – Creating one of these diagrams can help an organisation to analyse
potential risks as well as potential opportunities.
 Data Gathering – Finding quantifiable data which can be used to show risk and risk
probability.

What’s involved with selecting a Risk management tool and technique?
The risk management tool or technique which is selected can depend on the mission statement of
the organisation, or the risk which is being addressed. Some techniques will not work when used
to confront certain risks, whereas others will work particularly well. It is a good idea to choose
techniques based on precedence. Some tools and techniques are specifically designed to help to
identify risk, whereas other tools are designed to reduce or remove risk. The tool should
therefore be used at the right stage of the process.
Where does selecting Risk management tools and techniques fit into the risk management
process?
Risk management tools and techniques are usually chosen after setting the context. Tools and
techniques can be used to identify and evaluate risk, and these tools are usually chosen directly
after the context has been set. Tools which are designed to address risk are usually chosen once
the risk has been identified.
How do Risk management tools and techniques impact on managing organisational risk?
The tools which are chosen can have a negative or a positive impact upon managing
organisational risk. If you choose the correct tools and techniques, it will be much easier for you
to monitor and prevent risks, however if you choose the wrong tools and techniques, you could
inadvertently make the whole process much more complicated than it needs to be.
What terms are used in Risk management tools and techniques?
 Risk – A problem which may occur

 Tool – Something which can be used to help to complete an action or process
 Technique – A method which can be used to do something well.
 Risk analysis
Introduction
Project risk analysis is concerned with the assessment of the risks and uncertainties that threaten
a project. Project risk analysis has a broad range of applications, just as the definition of a project
is broad.
For the purposes of this guide, we consider a project to be the following:
A project is any set of inter-related tasks designed to achieve a certain goal or set of goals,
with a limited set of resources, to a particular quality standard and within a particular
budget and time frame.
There are two main elements that confound our ability to determine whether a proposed project,
or a project already underway, will achieve its goals within the set restrictions:

 The general uncertainty surrounding the duration and cost of tasks within the planned
project.
 The set of risk events that may occur, which inhibit the smooth progress of the project.
Typically, a project risk analysis consists of analysingscheduleandcostrisk, though other aspects

like the quality of the final product are sometimes included. There will also often be an analysis
of the cash flow of the project, especially at the conception and bidding stages.
A cost risk analysis consists of looking at the various costs associated with a project, their
uncertainties and any risks or opportunities that may affect these costs. Risks and opportunities
are defined as discrete possible events that will increase and decrease the project costs
respectively. They are both characterised by estimates of their probability of occurrence and the
magnitude of their impact. The distributions of cost are then added up in a risk analysis to
determine the uncertainty in the total cost of the project.
A schedule risk analysis looks at the time required to complete the various tasks associated with
a project, and the interrelationship between these tasks. Risks and opportunities are identified for
each task and an analysis is performed to determine the total duration of the project and, usually,
the durations until specific milestones within the project are achieved. A schedule risk analysis is
generally more complex to perform than a cost risk analysis because the logical connections
between the tasks have to be modelled in order to determine the critical path.
Cost and duration are linked together
A project's cost and duration are, in reality, linked together. Tasks in a project are often
quantified by, among other things; the number of person weeks (amount of work) needed to
complete them. The duration of the task is then equal to the person weeks/people on the job and
the cost equals person weeks * labour rate. Costs and durations are also linked if the model
includes a penalty clause for exceeding a deadline.
Cost elements and, particularly, schedule durations are also oftencorrelated. Correlation, or
dependency, modelling is described in detail here. It is important to be aware that dependencies
often exist in a risk analysis model and failure to include them in an analysis will generally
underestimate the risk.
A project risk analysis is often completed after a more rudimentary (deterministic) analysis that
uses single-point estimates for each task duration and cost. A comparison of the results of this
deterministic analysis with those of the risk analysis, where distributions have been used to
model uncertainty components, often surprises people. Somehow, one expects that a
deterministic analysis based on values one thinks most likely to occur should produce results that
equate to the mode of the risk analysis output distribution.
In fact, it turns out that a risk analysis model will provide a mode and mean that is nearly
alwaysgreater than the deterministic model result. Sometimes the risk analysis output
distribution will not even include the deterministic result!

The main reason for this is that the distributions one assigns
assigns to uncertainty components are
nearly always right skewed, i.e. they have a longer tail to the right than to the left. This is
because there are many more things that can go wrong than go right, and because we are always
trying to place emphasis on doing the job as quickly and cheaply as possible. Thus the model
distributions nearly always have more probability to the right of the mode than to the left which
means that, in the aggregate, for most models one is much more likely to have a scenario that
exceeds
ds the deterministic scenario.
A schedule risk analysis will diverge evenmorefrom

even from its deterministic equivalent than a cost
model because any task whose commencement depends on the finish of two or more other tasks
begins at the maximum of the samples from the distributions of finish dates of the other tasks,
not the maximum of their modes.
A 5 step risk management model

‘Risk management is a systematic process of identifying, analysing and responding to project
risk.’ This may be broken down into a number of
o sub-processes
processes are used as the basis for the five
five-
stage model in this Kit:
1. Risk identification
2. Qualitative risk analysis
3. Quantitative risk assessment
4. Risk response planning
5. Risk monitoring and control
A precursor to all of this is risk management planning in which you identify the overall approach
to be taken to risk management. Where you have a developed project management framework
you may have an organisation-wide wide approach that is adapted as necessary for each project. An
excellent example of a risk management
agement plan is the one developed for NASA’s Project Zeus.
You can also view HEFCE’s approach to risk. risk
 Risk monitoring and control

Risk monitoring control is the process of keeping track of the identified risks,, monitoring
residual risks and identifying neww risks,, ensuring the execution of risk plans, and evaluating their
effectiveness in reducing risk. Risk monitoring and control records risk metrics that are
associated with implementing contingency plans. Risk monitoring and control is an ongoing
process for the life of the project. The risks change as the project matures, new risks develop, or
anticipated risks disappear.
Good risk monitoring and control processes provide information that assists with making
effective decisions in advance of the risk´s occurring.. Communication to all project stakeholders
is needed to assess periodically the acceptability of the level of risk on the project.
The purpose of risk monitoring is to determine if:
Risk responses have been implemented as planned.

Risk response actions are as effective as expected, or if new responses should be developed.

Project assumptions are still valid.
Risk exposure has changed from its prior state, with analysis of trends.
A risk trigger has occurred.
Proper policies
es and procedures are followed.
Risks have occurred or arisen that were not previously identified.
identi
Risk control may involve choosing alternative strategies, implementing a contingency plan,
taking corrective action, or re-planning
planning the project. The risk
risk response owner should report
periodically to the project manager and the risk team leader on the effectiveness of the plan, any
unanticipated effects, and any mid-course
mid correction needed to mitigate the risk.
Inputs Tools & Techniques

Outputs
.1 Risk management plan .1 Project risk response audits .1 Workaround plans
.2 Risk response plan .2 Periodic project risk .2 Corrective action
.3 Project communication reviews
.3 Project change requests
.4 Additional risk .3 Earned value analysis
.4 Updates to the risk
identification .4 Technical performance response plan
and analysis measurement
.5 Risk database
.5 Scope changes .5 Additional risk response
.6 Updates to risk
Oooooooooooooooooooooooooo planning
identification checklists
oooooooooooooooooooooooooo
oooooooooooooo oooooooooooooooooooooooooo
ooooooooooo oooooooooooooooooooooooooo
Inputs to Risk Monitoring and Control
1 Risk management plan. The risk management plan is described in Section 11.1.3 11.1.3.
2 Risk response plan. The risk response plan is described in Section 11.5.3.1
11.5.3.1.
3 Project communication. Work results and other project records described in provide
information about project performance and risks. Reports commonly used tomonitor and
control risks include Issues Logs, Action-Item
Action Item Lists, Jeopardy Warnings, or Escalation
Notices.
4 Additional risk k identification and analysis. As project performance is measured and
reported, potential risks not previously identified may surface. The cycle of the six risk
processes should be implemented for these risks.
5 Scope changes. Scope changes often require new risk analysis and response plans. Scope
changes are described in

Tools and Techniques for Risk Monitoring and Control
1 Project risk response audits. Risk auditors examine and document the effectiveness of
the risk response in avoiding, transferring, or mitigating risk occurrence as well as the
effectiveness of the risk owner. Risk audits are performed during the project life cycle to
control risk.
2 Periodic project risk reviews. Project risk reviews should be regularly scheduled.
Project risk should be an agenda item at all team meetings. Risk ratings and prioritization
may change during the life of the project. Any changes may require additional qualitative
or quantitative analysis.
3 Earned value analysis. Earned value is used for monitoring overall project performance
against a baseline plan. Results from an earned value analysis may indicate potential
deviation of the project atcompletion from cost and schedule targets. When a project
deviates significantly from the baseline, updated risk identification and analysis should be
performed. Earned value analysis is described in
4 Technical performance measurement. Technical performance measurement compares
technical accomplishments during project execution to the project plan´s schedule of
technical achievement. Deviation, such as not demonstrating functionality as planned at a
milestone, can imply a risk to achieving the project´s scope.
5 Additional risk response planning. If a risk emerges that was not anticipated in the risk
response plan, or its impact on objectives is greater than expected, the planned response
may not be adequate. It will be necessary to perform additional response planning to
control the risk.
Outputs from Risk Monitoring and Control
1 Workaround plans. Workarounds are unplanned responses to emerging risks that were
previously unidentified or accepted. Workarounds must be properly documented and
incorporated into the project plan and risk response plan.
2 Corrective actions. Corrective action consists of performing the contingency plan or
workaround.
3 Project change requests. Implementing contingency plan or workarounds frequently
results in a requirement to change the project plan to respond to risks. The result it
issuance of a change request that is managed by integrated change control, as described
in Section 4.3.
4 Updates to the risk response plan. Risks may occur or not. Risks that do occur should
be documented and evaluated. Implementation of risk controls may reduce the impact or
probability of probability of identified risks. Risk rankings must be reassessed so that
new, important risks may be properly controlled. Risks that do not occur should be
documented and close in the risk response plan.
5 Risk database. A repository that provides for collection, maintenance, and analysis of
data gathered and used in the risk management processes. Use of this database will assist
risk management throughout the organization and, over time, form the basis of a risk
lessons learned program.
6 Updates to risk identification checklists. Checklists updated from experience will help
risk management of future projects.

TOPIC 9
IS PROJECT PROCUREMENT MANAGEMENT
What is a Procurement Management Process?
A Procurement Management Process, or Procurement Process, is a method by which items are

purchased from external suppliers. The procurement management process involves managing the
ordering, receipt, review and approval of items from suppliers. A procurement process also
specifies how the supplier relationships will be managed, to ensure a high level of service is
received. This is a critical task in Procurement Management. In essence, the procurement process
helps you "get what you have paid for".
When do I use a Procurement Management Process?
You need to implement a Procurement Process any time you want to buy items from external
suppliers. By using Procurement Management Process, you can ensure that the items provided
meet your need. It also helps you manage the supplier relationship, ensuring that any issues are
resolved quickly. By implementing a Procurement Process, you can ensure you get the maximum
value from your supplier relationship.
The process for managing procurements in 5 steps
1 Specification
2 Selection
3 Contracting
4 Control
5 Measurement.
Managing project procurements and acquisitions requires the project manager to efficiently
collaborate with the purchasing department on the process of planning and managing
procurements. Project procurement management is a section of the Implementation Plan to
determine how “the ordered products necessary for producing deliverables can be delivered on
time and within the allocated budget”. Note that the “Procurement Management” section of the
Implementation Plan will be necessary only for projects that have to deal with substantial buy-in
of expertise or capital items. For any other projects where there is no high level of procurement
expenditure it is enough to include a procurement item list and a vendors list in the project
implementation plan.

Project Procurement Process
A Project Procurement Process [also called “Project Procurement Management Process”] is a

method for establishing relationships between an organization’s purchasing department and
external suppliers to order, receive, review and approve all the procurement items necessary for
project execution. The supplier relationships are managed on a contractual basis. The process
aims to ensure timely delivery of the purchased items which are selected and acquired according
to the specifications and requirements set up by the purchasing department and approved by the
project manager.
The procurement process includes five major steps, as follows:
 Specification. This step involves the purchasing department in communicating with the
project manager to develop and approve a list of procurement items necessary for project
implementation. The department must specify the approved items to external vendors.
 Selection. This step of the project procurement process requires the department to find
potential suppliers which can procure the necessary items, according to the specifications.
For this purpose the department needs to set vendor selection criteria, which may include
such measures as Delivery, Service Quality, Cost, and Part Performance.
 Contracting. The department must communicate with the suppliers on delivery dates and
payment conditions in order to ensure “on-time” delivery of the ordered items within the
stated project budget. All the conditions should be listed in a procurement contract. Also
a detailed delivery schedule should be negotiated with the procurers and approved by the
purchasing department.
 Control. Success of the procurement management process depends on how the

purchasing department controls the delivery and payment processes. Through arranging
regular meetings with the vendors, tracking delivery progress, reviewing the ordered
items against the approved product specifications, and making necessary changes to the
procurement contract, the department can control the process and ensure successful
accomplishment.
 Measurement. The final step of the project procurement management process refers to
using a system of performance indicators and measures for assessing the effectiveness
and success of the entire process. The project manager needs to set up such a system and
the purchasing department needs to use it in measuring the process. Special meetings and
workshops can be conducted to view KPIs, intermediate results of staged delivery,
performance of procurers, adherence to product specifications, communications with
suppliers, and the like. In case any deviations or gaps are revealed the department should
notify the project manager and make necessary changes to the procurement plan.

 The procurement planning process, tools and methods
Project Procurement Plan
Planning of project procurements is carried out within the procurement process and results in
developing a plan. A procurement plan is a convenient tool for organizing and managing
activities and tasks related to the procurement management process. A template of the plan is to
be designed by the purchasing department in cooperation with the project manager. A project
procurement plan should be reviewed and approved by the project manager before any supplier
relationships get started.
A project procurement plan template documents:
 Deliverables to be procured by proposed agreements/contracts.

 Effective resource management strategies for negotiating and managing the
agreements/contracts.
 The need for staged delivery and desirability of testing the procured items before
introducing them into the implementation process (this item is optional).
 The chosen procurement method (payments, expressions of interest, request for
price/quote, request for tender).
 Key stages of the process for selecting suppliers and vendors.
 The model of procurement funding.
 The sample of procurement contract/agreement.
 References to quality approvals, quality assurance and risk management.
Procurement tools and methods

To look for materials later
 Request for proposal and quotations
Request for proposal
A request for proposal (RFP) is a document that an organization posts to elicit bids from
potential vendors for a desired IT solution. The RFP specifies what the customer is looking for
and establishes evaluation criteria for assessing proposals.
An RFP generally includes background on the issuing organization and its lines of business, a set
of specifications that describe the sought-after solution, and evaluation criteria that disclose how
proposals will be graded. RFPs may also include a statement of work, which describes the tasks
to be performed by the winning bidder and a timeline for providing deliverables.
An RFP may be issued for a number of reasons. In some cases, the complexity of an IT project
calls for a formal RFP. An organization can benefit from multiple bidders and perspectives when

seeking an integrated solution calling for a mix of technologies, vendors and potential
configurations. A business moving from a paper-based system to a computer-based system, for
example, might request proposals for all the hardware, software, and user training required to
establish and integrate the new system into the organization. A simple hardware upgrade, in
contrast, may only involve issuing a request for quotation to a single vendor.
Some entities such as government agencies may be required to issue RFPs to provide full and
open competition. An organization may also release an RFP to boost competition to drive down
the cost of a solution. That said, a proposal accepted on the basis of being the most responsive to
an RFP’s specifications may not always be the lowest-priced bid.
Request for quotations
A request for quotation (RFQ) is a standard business process whose purpose is to invite
suppliers into a bidding process to bid on specific products or services. RFQ generally means the
same thing as IFB (Invitation For Bid).
An RFQ typically involves more than the price per item. Information like payment terms, quality
level per item or contract length are possible to be requested during the bidding process.
To receive correct quotes, RFQs often include the specifications of the items/services to make
sure all the suppliers are bidding on the same item/service. Logically, the more detailed the
specifications, the more accurate the quote will be and comparable to the other suppliers.Another
reason for being detailed in sending out an RFQ is that the specifications could be used as legal
binding documentation for the suppliers.
The suppliers have to return the bidding by a set date and time to be considered for an award.
Discussions may be held on the bids (often to clarify technical capabilities or to note errors in a
proposal). The bid does not have to mean the end of the bidding. Multiple rounds can follow or
even a reverse auction can follow to generate the best market price.
RFQs are best suited to products and services that are as standardized and as commoditized as
possible, as this makes each supplier's quote comparable. In practice, many businesses use an
RFQ where an RFT or RFI would be more appropriate.
An RFQ allows different contractors to provide a quotation, among which the best will be
selected. It also makes the potential for competitive bidding a lot higher, since the suppliers
could be quite certain that they are not the only ones bidding for the products.
Requests for quotations are most commonly used in the business environment but can also be
found being applied to domestic markets.
 Evaluation of proposals and quotations

 Contracting and contract administration
Contract management or contract administration is the management of contracts made with
customers, vendors, partners, or employees. The personnel involved in Contract Administration
required to negotiate, support and manage effective contracts are expensive to train and retain.
Contract management includes negotiating the terms and conditions in contracts and ensuring
compliance with the terms and conditions, as well as documenting and agreeing on any changes
or amendments that may arise during its implementation or execution. It can be summarized as
the process of systematically and efficiently managing contract creation, execution, and analysis
for the purpose of maximizing financial and operational performance and minimizing risk.
Common commercial contracts include employment letters, sales invoices, purchase orders, and
utility contracts. Complex contracts are often necessary for construction projects, goods or
services that are highly regulated, goods or services with detailed technical specifications,
intellectual property (IP) agreements, and international trade.
A study has found that for "42% of enterprises...the top driver for improvements in the
management of contracts are the pressure to better assess and mitigate risks" and
additionally,"nearly 65% of enterprises report that contract lifecycle management (CLM) has
improved exposure to financial and legal risk
Contracts
A contract is a written or oral legally-binding agreement between the parties identified in the
agreement to fulfill the terms and conditions outlined in the agreement. A prerequisite
requirement for the enforcement of a contract, amongst other things, is the condition that the
parties to the contract accept the terms of the claimed contract. Historically, this was most
commonly achieved through signature or performance, but in many jurisdictions - especially
with the advance of electronic commerce - the forms of acceptance have expanded to include
various forms of electronic signature.
Contracts can be of many types, e.g. sales contracts (including leases), purchasing contracts,
partnership agreements, trade agreements, and intellectual property agreements.
 A sales contract is a contract between a company (the seller) and a customer where the
company agrees to sell products and/or services and the customer in return is obligated to
pay for the product/services bought.
 A purchasing contract is a contract between a company (the buyer) and a supplier who is
promising to sell products and/or services within agreed terms and conditions. The
company (buyer) in return is obligated to acknowledge the goods / or service and pay for
liability created.
 A partnership agreement may be a contract which formally establishes the terms of a
partnership between two legal entities such that they regard each other as 'partners' in a
commercial arrangement. However, such expressions may also be merely a means to
reflect the desire of the contracting parties to act 'as if' both are in a partnership with
common goals. Therefore, it might not be the common law arrangement of a partnership
which by definition creates fiduciary duties and which also has 'joint and several'
liabilities.

Areas of Contract Management
The business-standard contract management model, as employed by many organizations in the
United States, typically exercises purview over the following business disciplines:
 Authoring and negotiation
 Baseline management
 Commitment management
 Communication management.
 Contract visibility and awareness
 Document management
 Growth (for Sales-side contracts)
Change management
There may be occasions where what is agreed in a contract needs to be changed later on. A
number of bases may be used to support a subsequent change, so that the whole contract remains
enforceable under the new arrangement.
A change may be based on:
 A mutual agreement of both parties to vary the contract, outside the framework of the
existing contract. This would be an independent basis for changing the contract.
 A unilateral decision to vary the contract contemplated and allowed for by the existing
contract. This would normally have notice periods for fairness and often the right of the
other, especially in consumer contracts, to cease the contractual relationship. Be careful
that any one-way imposition of change is contractually justified, otherwise it may be
interpreted as a repudiation of the original contract, enabling the other party to terminate
the contract and seek damages.
 A bilateral decision to vary the contracting, within the variation or change control process
outlined in the existing contract. These are often called change control provisions.
Phases of Contract Management

Contract Management can be divided into five phases namely
 pre- contract phase
 contract execution phase
 post award phase
Contract Compliance
During the post-award phase, it is important to ensure that contract conditions and terms are met,
but it is also critical to take a closer look for items such unrecorded liabilities, under-reported
revenue or overpayments. If these items are overlooked, margin may be negatively impacted. A
contract compliance audit will often commence with an opportunity review to identify the
highest risk areas. Having a dedicated contract compliance program in place has been shown to
result in a typical recovery of 2-4% and sometimes as high as 20%
 Using a software tool in project procurement management

TOPIC 10
IS PROJECT IMPLEMENTATION, COMPLETION AND EVALUATION
 Managing transition
Transition Methodology is the process of migrating knowledge, systems, and operating
capabilities between an outsourcingenvironment to an in-house staff.
Transition management starts with the preparation of the outsourced/offshore site to commence
client operations through documenting the processes, training process executives to execute the
processes, designing, procuring and deploying technology and bandwidth to access client
systems as required and finally fulfill the SLA and contact parameters. The overall success of the
outsourcing engagement is very much dependent on the effectiveness of the transition.
At an organizational level an outsourcing project would involve the tangible changes in structure,
processes, technology, culture that the organization would go through to go from the current state
to the desired future state. At the individual level, it would involve the process individuals to the
new way of working.
Transition Approach
Transition Methodology typical employs a four-to-five phased approach, with each phase
consisting of one or more tasks producing at least one deliverable and completion criteria that
must be met in order to progress to the next phase. The milestones and deliverables produced by
these tasks provide an ongoing quality review process that checks that the final product will meet
expectations.
1. Discovery/Assessment
2. Solution Design/Planning
3. Testing & Pilot
4. Service Assumption
5. Steady State Turnover/Implementation
The transition team executes a formal hand-off to the steady state PMO and confirms that the
service operations are stable and measure and report service performance. Ideally, the transition
team remains engaged through the actualization period when service has stabilized. Once in the
steady state, optimization efforts should commence to improve and adjust to changing business
drivers.

 Project evaluation
It’s a systematic and objective assessment of an ongoing or completed project. The aim is to
determine the relevance and level of achievement of project objectives, development
effectiveness, efficiency, impact and sustainability.
Program evaluation is a systematic method for collecting, analyzing, and using information to
answer questions about projects, policies and programs, particularly about their effectiveness and
efficiency. In both the public and private sectors, stakeholders often want to know whether the
programs they are funding, implementing, voting for, receiving or objecting to are producing the
intended effect. While program evaluation first focuses around this definition, important
considerations often include how much the program costs per participant, how the program could
be improved, whether the program is worthwhile, whether there are better alternatives, if there
are unintended outcomes, and whether the program goals are appropriate and useful.Evaluators
help to answer these questions, but the best way to answer the questions is for the evaluation to
be a joint project between evaluators and stakeholders.
The process of evaluation is considered to be a relatively recent phenomenon. However, planned

social evaluation has been documented as dating as far back as 2200 BC. Evaluation became
particularly relevant in the U.S. in the 1960s during the period of the Great Society social
programs associated with the Kennedy and Johnsonadministrations.Extraordinary sums were
invested in social programs, but the impacts of these investments were largely unknown.
Program evaluations can involve both quantitative and qualitative methods of social research.
People who do program evaluation come from many different backgrounds, such as sociology,
psychology, economics, social work, and public policy. Some graduate schools also have
specific training programs for program evaluation.
Doing an evaluation
Program evaluation may be conducted at several stages during a program's lifetime. Each of
these stages raises different questions to be answered by the evaluator, and correspondingly
different evaluation approaches are needed. Rossi, Lipsey and Freeman (2004) suggest the
following kinds of assessment, which may be appropriate at these different stages:
 Assessment of the need for the program

 Assessment of program design and logic/theory
 Assessment of how the program is being implemented (i.e., is it being implemented
according to plan? Are the program's processes maximizing possible outcomes?)
 Assessment of the program's outcome or impact (i.e., what it has actually achieved)
 Assessment of the program's cost and efficiency

Assessing needs
A needs assessment examines the population that the program intends to target, to see whether
the need as conceptualized in the program actually exists in the population; whether it is, in fact,
a problem; and if so, how it might best be dealt with. This includes identifying and diagnosing
the actual problem the program is trying to address, who or what is affected by the problem, how
widespread the problem is, and what are the measurable effects that are caused by the problem.
For example, for a housing program aimed at mitigating homelessness, a program evaluator may
want to find out how many people are homeless in a given geographic area and what their
demographics are. Rossi, Lipsey and Freeman (2004) caution against undertaking an intervention
without properly assessing the need for one, because this might result in a great deal of wasted
funds if the need did not exist or was misconceived.
Needs assessment involves the processes or methods used by evaluators to describe and diagnose
social needs. This is essential for evaluators because they need to identify whether programs are
effective and they cannot do this unless they have identified what the problem/need is. Programs
that do not do needs assessment can have the illusion that they have eradicated the problem/need
when in fact there was no need in the first place. Needs assessment involves research and regular
consultation with community stakeholders and with the people that will benefit from the project
before the program can be developed and implemented. Hence it should be a bottom-up
approach. In this way potential problems can be realized early because the process would have
involved the community in identifying the need and thereby allowed the opportunity to identify
potential barriers.
The important task of a program evaluator is thus to: First, construct a precise definition of what
the problem is. Evaluators need to first identify the problem/need. This is most effectively done
by collaboratively including all possible stakeholders, i.e., the community impacted by the
potential problem, the agents/actors working to address and resolve the problem, funders, etc.
Including buy-in early on in the process reduces potential for push-back, miscommunication, and
incomplete information later on.
Second, assess the extent of the problem. Having clearly identified what the problem is,
evaluators need to then assess the extent of the problem. They need to answer the ‘where’ and
‘how big’ questions. Evaluators need to work out where the problem is located and how big it is.
Pointing out that a problem exists is much easier than having to specify where it is located and
how rife it is. Rossi, Lipsey& Freeman (2004) gave an example that: a person identifying some
battered children may be enough evidence to persuade one that child abuse exists. But indicating
how many children it affects and where it is located geographically and socially would require
knowledge about abused children, the characteristics of perpetrators and the impact of the
problem throughout the political authority in question.
This can be difficult considering that child abuse is not a public behavior, also keeping in mind
that estimates of the rates on private behavior are usually not possible because of factors like
unreported cases. In this case evaluators would have to use data from several sources and apply
different approaches in order to estimate incidence rates. There are two more questions that need
to be answered: Evaluators need to also answer the ’how’ and ‘what’ questions The ‘how’

question requires that evaluators determine how the need will be addressed. Having identified the
need and having familiarized oneself with the community evaluators should conduct a
performance analysis to identify whether the proposed plan in the program will actually be able
to eliminate the need. The ‘what’ question requires that evaluators conduct a task analysis to find
out what the best way to perform would be. For example, whether the job performance standards
are set by an organization or whether some governmental rules need to be considered when
undertaking the task.
Third, define and identify the target of interventions and accurately describe the nature of the
service needs of that population It is important to know what/who the target population is/are – it
might be individuals, groups, communities, etc. There are three units of the population:
population at risk, population in need and population in demand.
 Population at risk: are people with a significant probability of developing the risk e.g. the
population at risk for birth control programs are women of child bearing age.
 Population in need: are people with the condition that the program seeks to address; e.g.
the population in need for a program that aims to provide ARV’s to HIV positive people
are people that are HIV positive.
 Population in demand: that part of the population in need that agrees to be having the
need and are willing to take part in what the program has to offer e.g. not all HIV positive
people will be willing to take ARV’s.
Being able to specify what/who the target is will assist in establishing appropriate boundaries, so
that interventions can correctly address the target population and be feasible to apply.
There are four steps in conducting a needs assessment:
1. Perform a ‘gap’ analyses
Evaluators need to compare current situation to the desired or necessary situation. The
difference or the gap between the two situations will help identify the need, purpose and
aims of the program.
2. Identify priorities and importance
In the first step above, evaluators would have identified a number of interventions that
could potentially address the need e.g. training and development, organization
development etc. These must now be examined in view of their significance to the
program’s goals and constraints. This must be done by considering the following factors:
cost effectiveness (considers the budget of the program, assess cost/benefit ratio),
executive pressure (whether top management expects a solution) and population (whether
many key people are involved).
3. Identify causes of performance problems and/or opportunities

When the needs have been prioritized the next step is to identify specific problem areas
within the need to be addressed. And to also assess the skills of the people that will be
carrying out the interventions.
4. Identify possible solutions and growth opportunities
Compare the consequences of the interventions if it was to be implemented or not.
Needs analysis is hence a very crucial step in evaluating programs because the effectiveness of a
program cannot be assessed unless we know what the problem was in the first place.
Assessing program theory
The program theory, also called a logic model or impact pathway, is an assumption, implicit in
the way the program is designed, about how the program's actions are supposed to achieve the
outcomes it intends. This 'logic model' is often not stated explicitly by people who run programs,
it is simply assumed, and so an evaluator will need to draw out from the program staff how
exactly the program is supposed to achieve its aims and assess whether this logic is plausible.
For example, in an HIV prevention program, it may be assumed that educating people about
HIV/AIDS transmission, risk and safe sex practices will result in safer sex being practiced.
However, research in South Africa increasingly shows that in spite of increased education and
knowledge, people still often do not practice safe sex. Therefore, the logic of a program which
relies on education as a means to get people to use condoms may be faulty. This is why it is
important to read research that has been done in the area. Explicating this logic can also reveal
unintended or unforeseen consequences of a program, both positive and negative. The program
theory drives the hypotheses to test for impact evaluation. Developing a logic model can also
build common understanding amongst program staff and stakeholders about what the program is
actually supposed to do and how it is supposed to do it, which is often lacking (see Participatory
impact pathways analysis). Of course, it is also possible that during the process of trying to elicit
the logic model behind a program the evaluators may discover that such a model is either
incompletely developed, internally contradictory, or (in worst cases) essentially nonexisistent.
This decidedly limits the effectiveness of the evaluation, although it does not necessarily reduce
or eliminate the program.
Creating a logic model is a wonderful way to help visualize important aspects of programs,
especially when preparing for an evaluation. An evaluator should create a logic model with input
from many different stake holders. Logic Models have 5 major components: Resources or Inputs,
Activities, Outputs, Short-term outcomes, and Long-term outcomes. Creating a logic model
helps articulate the problem, the resources and capacity that are currently being used to address
the problem, and the measurable outcomes from the program. Looking at the different
components of a program in relation to the overall short-term and long-term goals allows for
illumination of potential misalignments. Creating an actual logic model is particularly important
because it helps clarify for all stakeholders: the definition of the problem, the overarching goals,
and the capacity and outputs of the program.

Rossi, Lipsey& Freeman (2004) suggest four approaches and procedures that can be used to
assess the program theory. These approaches are discussed below.
 Assessment in relation to social needs
This entails assessing the program theory by relating it to the needs of the target population the
program is intended to serve. If the program theory fails to address the needs of the target
population it will be rendered ineffective even when if it is well implemented.
 Assessment of logic and plausibility
This form of assessment involves asking a panel of expert reviewers to critically review the logic
and plausibility of the assumptions and expectations inherent in the program's design. The
review process is unstructured and open ended so as to address certain issues on the program
design. Rutman (1980), Smith (1989), and Wholey (1994) suggested the questions listed below
to assist with the review process.
Are the program goals and objectives well defined?

Are the program goals and objectives feasible?
Is the change process presumed in the program theory feasible?
Are the procedures for identifying members of the target population, delivering service to
them, and sustaining that service through completion well defined and suffiient?
Are the constituent components, activities, and functions of the program well defined and
sufficient?
Are the resources allocated to the program and its various activities adequate?
 Assessment through comparison with research and practice
This form of assessment requires gaining information from research literature and existing
practices to assess various components of the program theory. The evaluator can assess whether
the program theory is congruent with research evidence and practical experiences of programs
with similar concepts.
 Assessment via preliminary observation
This approach involves incorporating firsthand observations into the assessment process as it
provides a reality check on the concordance between the program theory and the program itself.
The observations can focus on the attainability of the outcomes, circumstances of the target
population, and the plausibility of the program activities and the supporting resources.
These different forms of assessment of program theory can be conducted to ensure that the
program theory is sound.

Assessing implementation
Process analysis looks beyond the theory of what the program is supposed to do and instead
evaluates how the program is being implemented. This evaluation determines whether the
components identified as critical to the success of the program are being implemented. The
evaluation determines whether target populations are being reached, people are receiving the
intended services, staff are adequately qualified. Process evaluation is an ongoing process in
which repeated measures may be used to evaluate whether the program is being implemented
effectively. This problem is particularly critical because many innovations, particularly in areas
like education and public policy, consist of fairly complex chains of action. Many of which these
elements rely on the prior correct implementation of other elements, and will fail if the prior
implementation was not done correctly. This was conclusively demonstrated by Gene V. Glass
and many others during the 1980s. Since incorrect or ineffective implementation will produce the
same kind of neutral or negative results that would be produced by correct implementation of a
poor innovation, it is essential that evaluation research assess the implementation process itself.
Otherwise, a good innovative idea may be mistakenly characterized as ineffective, where in fact
it simply had never been implemented as designed.
Assessing the impact (effectiveness)
The impact evaluation determines the causal effects of the program. This involves trying to
measure if the program has achieved its intended outcomes, i.e. program outcomes.
Program Outcomes
An outcome is the state of the target population or the social conditions that a program is
expected to have changed. Program outcomes are the observed characteristics of the target
population or social conditions, not of the program. Thus the concept of an outcome does not
necessarily mean that the program targets have actually changed or that the program has caused
them to change in any way.
There are two kinds of outcomes, namely outcome level and outcome change, also associated
with program effect.
 Outcome level refers to the status of an outcome at some point in time.

 Outcome change refers to the difference between outcome levels at different points in
time.
 Program effect refers to that portion of an outcome change that can be attributed
uniquely to a program as opposed to the influence of some other factor.
Measuring Program Outcomes
Outcome measurement is a matter of representing the circumstances defined as the outcome by

means of observable indicators that vary systematically with changes or differences in those
circumstances. Outcome measurement is a systematic way to assess the extent to which a
program has achieved its intended outcomes. According to Mouton (2009) measuring the impact

of a program means demonstrating or estimating the accumulated differentiated proximate and
emergent effect, some of which might be unintended and therefore unforeseen.
Outcome measurement serves to help you understand whether the program is effective or not. It
further helps you to clarify your understanding of your program. But the most important reason
for undertaking the effort is to understand the impacts of your work on the people you serve.
With the information you collect, you can determine which activities to continue and build upon,
and which you need to change in order to improve the effectiveness of the program.
This can involve using sophisticated statistical techniques in order to measure the effect of the
program and to find causal relationship between the program and the various outcomes. More
information about impact evaluation is found under the heading 'Determining Causation'.
Assessing efficiency
Finally, cost-benefit or cost-effectiveness analysis assesses the efficiency of a program.

Evaluators outline the benefits and cost of the program for comparison. An efficient program has
a lower cost-benefit ratio.
Determining causation
Perhaps the most difficult part of evaluation is determining whether the program itself is causing
the changes that are observed in the population it was aimed at. Events or processes outside of
the program may be the real cause of the observed outcome (or the real prevention of the
anticipated outcome).
Causation is difficult to determine. One main reason for this is self-selection bias. People select
themselves to participate in a program. For example, in a job training program, some people
decide to participate and others do not. Those who do participate may differ from those who do
not in important ways. They may be more determined to find a job or have better support
resources. These characteristics may actually be causing the observed outcome of increased
employment, not the job training program.
Evaluations conducted with random assignment are able to make stronger inferences about
causation. Randomly assigning people to participate or to not participate in the program reduces
or eliminates self-selection bias. Thus, the group of people who participate would likely be more
comparable to the group who did not participate.
However, since most programs cannot use random assignment, causation cannot be determined.
Impact analysis can still provide useful information. For example, the outcomes of the program
can be described. Thus the evaluation can describe that people who participated in the program
were more likely to experience a given outcome than people who did not participate.
If the program is fairly large, and there are enough data, statistical analysis can be used to make a
reasonable case for the program by showing, for example, that other causes are unlikely.

Reliability, validity and sensitivity in program evaluation
It is important to ensure that the instruments (for example, tests, questionnaires, etc.) used in
program evaluation are as reliable, valid and sensitive as possible. According to Rossi et al.
(2004, p. 222), 'a measure that is poorly chosen or poorly conceived can completely undermine
the worth of an impact assessment by producing misleading estimates. Only if outcome measures
are valid, reliable and appropriately sensitive can impact assessments be regarded as credible'.
Reliability
The reliability of a measurement instrument is the 'extent to which the measure produces the
same results when used repeatedly to measure the same thing' (Rossi et al., 2004, p. 218). The
more reliable a measure is, the greater its statistical power and the more credible its findings. If a
measuring instrument is unreliable, it may dilute and obscure the real effects of a program, and
the program will 'appear to be less effective than it actually is' (Rossi et al., 2004, p. 219). Hence,
it is important to ensure the evaluation is as reliable as possible.
Validity
The validity of a measurement instrument is 'the extent to which it measures what it is intended
to measure' (Rossi et al., 2004, p. 219). This concept can be difficult to accurately measure: in
general use in evaluations, an instrument may be deemed valid if accepted as valid by the
stakeholders (stakeholders may include, for example, funders, program administrators, et cetera).
Sensitivity
The principal purpose of the evaluation process is to measure whether the program has an effect
on the social problem it seeks to redress; hence, the measurement instrument must be sensitive
enough to discern these potential changes (Rossi et al., 2004). A measurement instrument may be
insensitive if it contains items measuring outcomes which the program couldn't possibly effect,
or if the instrument was originally developed for applications to individuals (for example
standardized psychological measures) rather than to a group setting (Rossi et al., 2004). These
factors may result in 'noise' which may obscure any effect the program may have had.
Only measures which adequately achieve the benchmarks of reliability, validity and sensitivity
can be said to be credible evaluations. It is the duty of evaluators to produce credible evaluations,
as their findings may have far reaching effects. A discreditable evaluation which is unable to
show that a program is achieving its purpose when it is in fact creating positive change may
cause the program to lose its funding undeservedly.
Steps to Program Evaluation Framework
According to the Center for Disease Control (CDC) there are six steps to a complete program
evaluation. The steps described are: engage stakeholder, describe the program, focus the
evaluation design, gather credible evidence, justify conclusions, and ensure use and share lessons

learned. These steps can happen in a cycle framework to represent the continuing process of
evaluation.
Evaluating Collective Impact

Though program evaluation processes mentioned here are appropriate for most programs, highly
complex non-linear initiatives, such as those using the collective impact (CI) model, require a
dynamic approach to evaluation. Collective impact is "the commitment of a group of important
actors from different sectors to a common agenda for solving a specific social problem" and
typically involves three stages, each with a different recommended evaluation approach:
 Early phase: CI participants are exploring possible strategies and developing plans for
action. Characterized by uncertainty.
Recommended evaluation approach: Developmental evaluation to help CI partners understand

the context of the initiative and its development: "Developmental evaluation involves real time
feedback about what is emerging in complex dynamic systems as innovators seek to bring about
systems change."
 Middle phase: CI partners implement agreed upon strategies. Some outcomes become
easier to anticipate.
Recommended evaluation approach: Formative evaluation to refine and improve upon the
progress, as well as continued developmental evaluation to explore new elements as they
emerge. Formative evaluation involves "careful monitoring of processes in order to respond to
emergent properties and any unexpected outcomes."
 Later phase: Activities achieve stability and are no longer in formation. Experience
informs knowledge about which activities may be effective.
Recommended evaluation approach: Summative evaluation “uses both quantitative and

qualitative methods in order to get a better understanding of what [the] project has achieved, and
how or why this has occurred.”
Planning a program evaluation

Planning a program evaluation can be broken up into four parts: focusing the evaluation,
collecting the information, using the information, and managing the
evaluation.http://learningstore.uwex.edu/assets/pdfs/g3658-1.pdfProgram evaluation involves
reflecting on questions about evaluation purpose, what questions are necessary to ask, and what
will be done with information gathered. Critical questions for consideration include:
 What am I going to evaluate?

 What is the purpose of this evaluation?
 Who will use this evaluation? How will they use it?
 What questions is this evaluation seeking to answer?

 What information do I need to answer the questions?
 When is the evaluation needed? What resources do I need?
 How will I collect the data I need?
 How will data be analyzed?
 What is my implementation timeline?
Methodological constraints and challenges
The shoestring approach
The “shoestring evaluation approach” is designed to assist evaluators operating under limited
budget, limited access or availability of data and limited turnaround time, to conduct effective
evaluations that are methodologically rigorous(Bamberger, Rugh, Church & Fort, 2004). This
approach has responded to the continued greater need for evaluation processes that are more
rapid and economical under difficult circumstances of budget, time constraints and limited
availability of data. However, it is not always possible to design an evaluation to achieve the
highest standards available. Many programs do not build an evaluation procedure into their
design or budget. Hence, many evaluation processes do not begin until the program is already
underway, which can result in time, budget or data constraints for the evaluators, which in turn
can affect the reliability, validity or sensitivity of the evaluation. > The shoestring approach helps
to ensure that the maximum possible methodological rigor is achieved under these constraints.
Budget constraints
Frequently, programs are faced with budget constraints because most original projects do not
include a budget to conduct an evaluation (Bamberger et al., 2004). Therefore, this automatically
results in evaluations being allocated smaller budgets that are inadequate for a rigorous
evaluation. Due to the budget constraints it might be difficult to effectively apply the most
appropriate methodological instruments. These constraints may consequently affect the time
available in which to do the evaluation (Bamberger et al., 2004). Budget constraints may be
addressed by simplifying the evaluation design, revising the sample size, exploring economical
data collection methods (such as using volunteers to collect data, shortening surveys, or using
focus groups and key informants) or looking for reliable secondary data (Bamberger et al.,
2004).
Time constraints
The most time constraint that can be faced by an evaluator is when the evaluator is summoned to
conduct an evaluation when a project is already underway if they are given limited time to do the
evaluation compared to the life of the study, or if they are not given enough time for adequate
planning. Time constraints are particularly problematic when the evaluator is not familiar with
the area or country in which the program is situated (Bamberger et al., 2004). Time constraints
can be addressed by the methods listed under budget constraints as above, and also by careful
planning to ensure effective data collection and analysis within the limited time space.

Data constraints
If the evaluation is initiated late in the program, there may be no baseline data on the conditions
of the target group before the intervention began (Bamberger et al., 2004). Another possible
cause of data constraints is if the data have been collected by program staff and contain
systematic reporting biases or poor record keeping standards and is subsequently of little use
(Bamberger et al., 2004). Another source of data constraints may result if the target group are
difficult to reach to collect data from - for example homeless people, drug addicts, migrant
workers, et cetera (Bamberger et al., 2004). Data constraints can be addressed by reconstructing
baseline data from secondary data or through the use of multiple methods. Multiple methods,
such as the combination of qualitative and quantitative data can increase validity through
triangulation and save time and money. Additionally, these constraints may be dealt with through
careful planning and consultation with program stakeholders. By clearly identifying and
understanding client needs ahead of the evaluation, costs and time of the evaluative process can
be streamlined and reduced, while still maintaining credibility.
All in all, time, monetary and data constraints can have negative implications on the validity,
reliability and transferability of the evaluation. The shoestring approach has been created to
assist evaluators to correct the limitations identified above by identifying ways to reduce costs
and time, reconstruct baseline data and to ensure maximum quality under existing constraints
(Bamberger et al., 2004).
Five-tiered approach
The five-tiered approach to evaluation further develops the strategies that the shoestring
approach to evaluation is based upon. It was originally developed by Jacobs (1988) as an
alternative way to evaluate community-based programs and as such was applied to a statewide
child and family program in Massachusetts, U.S.A. The five-tiered approach is offered as a
conceptual framework for matching evaluations more precisely to the characteristics of the
programs themselves, and to the particular resources and constraints inherent in each evaluation
context. In other words, the five-tiered approach seeks to tailor the evaluation to the specific
needs of each evaluation context.
The earlier tiers (1-3) generate descriptive and process-oriented information while the later tiers
(4-5) determine both the short-term and the long-term effects of the program. The five levels are
organized as follows:
 Tier 1: needs assessment (sometimes referred to as pre-implementation)

 Tier 2: monitoring and accountability
 Tier 3: quality review and program clarification (sometimes referred to as understanding
and refining)
 Tier 4: achieving outcomes
 Tier 5: establishing impact
For each tier, purpose(s) are identified, along with corresponding tasks that enable the identified
purpose of the tier to be achieved. For example, the purpose of the first tier, Needs assessment,

would be to document a need for a program in a community. The task for that tier would be to
assess the community's needs and assets by working with all relevant stakeholders.
While the tiers are structured for consecutive use, meaning that information gathered in the
earlier tiers is required for tasks on higher tiers, it acknowledges the fluid nature of evaluation.
Therefore, it is possible to move from later tiers back to preceding ones, or even to work in two
tiers at the same time. It is important for program evaluators to note, however, that a program
must be evaluated at the appropriate level.
The five-tiered approach is said to be useful for family support programs which emphasise
community and participant empowerment. This is because it encourages a participatory approach
involving all stakeholders and it is through this process of reflection that empowerment is
achieved.
Methodological challenges presented by language and culture
The purpose of this section is to draw attention to some of the methodological challenges and
dilemmas evaluators are potentially faced with when conducting a program evaluation in a
developing country. In many developing countries the major sponsors of evaluation are donor
agencies from the developed world, and these agencies require regular evaluation reports in order
to maintain accountability and control of resources, as well as generate evidence for the
program’s success or failure. However, there are many hurdles and challenges which evaluators
face when attempting to implement an evaluation program which attempts to make use of
techniques and systems which are not developed within the context to which they are applied.
Some of the issues include differences in culture, attitudes, language and political process.
Culture is defined by Ebbutt (1998, p. 416) as a “constellation of both written and unwritten
expectations, values, norms, rules, laws, artifacts, rituals and behaviors that permeate a society
and influence how people behave socially”. Culture can influence many facets of the evaluation
process, including data collection, evaluation program implementation and the analysis and
understanding of the results of the evaluation. In particular, instruments which are traditionally
used to collect data such as questionnaires and semi-structured interviews need to be sensitive to
differences in culture, if they were originally developed in a different cultural context. The
understanding and meaning of constructs which the evaluator is attempting to measure may not
be shared between the evaluator and the sample population and thus the transference of concepts
is an important notion, as this will influence the quality of the data collection carried out by
evaluators as well as the analysis and results generated by the data.
Language also plays an important part in the evaluation process, as language is tied closely to
culture. Language can be a major barrier to communicating concepts which the evaluator is
trying to access, and translation is often required. There are a multitude of problems with
translation, including the loss of meaning as well as the exaggeration or enhancement of meaning
by translators. For example, terms which are contextually specific may not translate into another
language with the same weight or meaning. In particular, data collection instruments need to take
meaning into account as the subject matter may not be considered sensitive in a particular
context might prove to be sensitive in the context in which the evaluation is taking place. Thus,

evaluators need to take into account two important concepts when administering data collection
tools: lexical equivalence and conceptual equivalence. Lexical equivalence asks the question:
how does one phrase a question in two languages using the same words? This is a difficult task
to accomplish, and uses of techniques such as back-translation may aid the evaluator but may not
result in perfect transference of meaning. This leads to the next point, conceptual equivalence. It
is not a common occurrence for concepts to transfer unambiguously from one culture to another.
Data collection instruments which have not undergone adequate testing and piloting may
therefore render results which are not useful as the concepts which are measured by the
instrument may have taken on a different meaning and thus rendered the instrument unreliable
and invalid.
Thus, it can be seen that evaluators need to take into account the methodological challenges
created by differences in culture and language when attempting to conduct a program evaluation
in a developing country.
Utilization results
There are three conventional uses of evaluation results: persuasive utilization, direct
(instrumental) utilization, and conceptual utilization.
Persuasive utilization
Persuasive utilization is the enlistment of evaluation results in an effort to persuade an audience

to either support an agenda or to oppose it. Unless the 'persuader' is the same person that ran the
evaluation, this form of utilization is not of much interest to evaluators as they often cannot
foresee possible future efforts of persuasion.
Direct (instrumental) utilization
Evaluators often tailor their evaluations to produce results that can have a direct influence in the
improvement of the structure, or on the process, of a program. For example, the evaluation of a
novel educational intervention may produce results that indicate no improvement in students'
marks. This may be due to the intervention not having a sound theoretical background, or it may
be that the intervention is not conducted as originally intended. The results of the evaluation
would hopefully cause to the creators of the intervention to go back to the drawing board to re-
create the core structure of the intervention, or even change the implementation processes.
Conceptual utilization
But even if evaluation results do not have a direct influence in the re-shaping of a program, they
may still be used to make people aware of the issues the program is trying to address. Going
back to the example of an evaluation of a novel educational intervention, the results can also be
used to inform educators and students about the different barriers that may influence students'
learning difficulties. A number of studies on these barriers may then be initiated by this new
information.

Variables affecting utilization
There are five conditions that seem to affect the utility of evaluation results, namely relevance,
communication between the evaluators and the users of the results, information processing by
the users, the plausibility of the results, as well as the level of involvement or advocacy of the
users.
Guidelines for maximizing utilization
Quoted directly from Rossi et al. (2004, p. 416).
 Evaluators must understand the cognitive styles of decision makers

 Evaluation results must be timely and available when needed
 Evaluations must respect stakeholders' program commitments
 Utilization and dissemination plans should be part of the evaluation design
 Evaluations should include an assessment of utilization
Internal versus external program evaluators
The choice of the evaluator chosen to evaluate the program may be regarded as equally
important as the process of the evaluation. Evaluators may be internal (persons associated with
the program to be executed) or external (Persons not associated with any part of the
execution/implementation of the program). (Division for oversight services,2004). The following
provides a brief summary of the advantages and disadvantages of internal and external evaluators
adapted from the Division of oversight services (2004), for a more comprehensive list of
advantages and disadvantages of internal and external evaluators, see (Division of oversight
services, 2004).
Internal evaluators
Advantages
 May have better overall knowledge of the program and possess informal knowledge of
the program
 Less threatening as already familiar with staff
 Less costly
Disadvantages
 May be less objective

 May be more preoccupied with other activities of the program and not give the evaluation
complete attention
 May not be adequately trained as an evaluator.

External evaluators
Advantages
 More objective of the process, offers new perspectives, different angles to observe and
critique the process
 May be able to dedicate greater amount of time and attention to the evaluation
 May have greater expertise and evaluation brain
Disadvantages
 May be more costly and require more time for the contract, monitoring, negotiations etc.
 May be unfamiliar with program staff and create anxiety about being evaluated
 May be unfamiliar with organization policies, certain constraints affecting the program.
Three paradigms
Positivist
Potter (2006) identifies and describes three broad paradigms within program evaluation . The
first, and probably most common, is the positivist approach, in which evaluation can only occur
where there are “objective”, observable and measurable aspects of a program, requiring
predominantly quantitative evidence. The positivist approach includes evaluation dimensions
such as needs assessment, assessment of program theory, assessment of program process, impact
assessment and efficiency assessment (Rossi, Lipsey and Freeman, 2004). A detailed example of
the positivist approach is a study conducted by the Public Policy Institute of California report
titled "Evaluating Academic Programs in California's Community Colleges", in which the
evaluators examine measurable activities (i.e. enrollment data) and conduct quantitive
assessments like factor analysis.
Interpretive
The second paradigm identified by Potter (2006) is that of interpretive approaches, where it is
argued that it is essential that the evaluator develops an understanding of the perspective,
experiences and expectations of all stakeholders. This would lead to a better understanding of the
various meanings and needs held by stakeholders, which is crucial before one is able to make
judgments about the merit or value of a program. The evaluator’s contact with the program is
often over an extended period of time and, although there is no standardized method,
observation, interviews and focus groups are commonly used. A report commissioned by the
World Bank details 8 approaches in which qualitative and quantitative methods can be integrated
and perhaps yield insights not achievable through only one method.
Critical-emancipatory
Potter (2006) also identifies critical-emancipatory approaches to program evaluation, which are
largely based on action research for the purposes of social transformation. This type of approach
is much more ideological and often includes a greater degree of social activism on the part of the
evaluator. This approach would be appropriate for qualitative and participative evaluations.
Because of its critical focus on societal power structures and its emphasis on participation and
empowerment, Potter argues this type of evaluation can be particularly useful in developing
countries.
Despite the paradigm which is used in any program evaluation, whether it be positivist,
interpretive or critical-emancipatory, it is essential to acknowledge that evaluation takes place in
specific socio-political contexts. Evaluation does not exist in a vacuum and all evaluations,
whether they are aware of it or not, are influenced by socio-political factors. It is important to
recognize the evaluations and the findings which result from this kind of evaluation process can
be used in favour or against particular ideological, social and political agendas (Weiss, 1999).
This is especially true in an age when resources are limited and there is competition between
organizations for certain projects to be prioritized over others (Louw, 1999).
Empowerment evaluation
Empowerment evaluation makes use of evaluation concepts, techniques, and findings to foster
improvement and self-determination of a particular program aimed at a specific target
population/program participants. Empowerment evaluation is value oriented towards getting
program participants involved in bringing about change in the programs they are targeted for.
One of the main focuses in empowerment evaluation is to incorporate the program participants in
the conducting of the evaluation process. This process is then often followed by some sort of
critical reflection of the program. In such cases, an external/outsider evaluator serves as a
consultant/coach/facilitator to the program participants and seeks to understand the program
from the perspective of the participants. Once a clear understanding of the participants’
perspective has been gained appropriate steps and strategies can be devised (with the valuable
input of the participants) and implemented in order to reach desired outcomes.
According to Fetterman (2002) empowerment evaluation has three steps;
 Establishing a mission
 Taking stock
 Planning for the future
Establishing a mission
The first step involves evaluators asking the program participants and staff members (of the
program) to define the mission of the program. Evaluators may opt to carry this step out by
bringing such parties together and asking them to generate and discuss the mission of the
program. The logic behind this approach is to show each party that there may be divergent views
of what the program mission actually is.

Taking stock
Taking stock as the second step consists of two important tasks. The first task is concerned with
program participants and program staff generating a list of current key activities that are crucial
to the functioning of the program. The second task is concerned with rating the identified key
activities, also known as prioritization. For example, each party member may be asked to rate
each key activity on a scale from 1 to 10, where 10 is the most important and 1 the least
important. The role of the evaluator during this task is to facilitate interactive discussion amongst
members in an attempt to establish some baseline of shared meaning and understanding
pertaining to the key activities.In addition, relevant documentation (such as financial reports and
curriculum information) may be brought into the discussion when considering some of the key
activities.
Planning for the future
After prioritizing the key activities the next step is to plan for the future. Here the evaluator asks
program participants and program staff how they would like to improve the program in relation
to the key activities listed. The objective is to create a thread of coherence whereby the mission
generated (step 1) guides the stock take (step 2) which forms the basis for the plans for the future
(step 3). Thus, in planning for the future specific goals are aligned with relevant key activities. In
addition to this it is also important for program participants and program staff to identify possible
forms of evidence (measurable indicators) which can be used to monitor progress towards
specific goals. Goals must be related to the program's activities, talents, resources and scope of
capability- in short the goals formulated must be realistic.
These three steps of empowerment evaluation produce the potential for a program to run more
effectively and more in touch with the needs of the target population. Empowerment evaluation
as a process which is facilitated by a skilled evaluator equips as well as empowers participants by
providing them with a 'new' way of critically thinking and reflecting on programs. Furthermore,
it empowers program participants and staff to recognize their own capacity to bring about
program change through collective action.
Transformative Paradigm
The transformative paradigm is integral in incorporating social justice in evaluation. Donna
Mertens, primary researcher in this field, states that the transformative paradigm “focuses
primarily on viewpoints of marginalized groups and interrogating systemic power structures
through mixed methods to further social justice and human rights”. The transformative paradigm
arose after marginalized groups, who have historically been pushed to the side in evaluation,
began to collaborate with scholars to advocate for social justice and human rights in evaluation.
The transformative paradigm introduces many different paradigms and lenses to the evaluation
process, leading it to continually call into question the evaluation process.
Both the American Evaluation Association and National Association of Social Workers call
attention to the ethical duty to possess cultural competence when conducting evaluations.
Cultural competence in evaluation can be broadly defined as a systemic, response inquiry that is

actively cognizant, understanding, and appreciative of the cultural context in which the
evaluation takes place; that frames and articulates epistemology of the evaluation endeavor; that
employs culturally and contextually appropriate methodology; and that uses stakeholder-
generated, interpretive means to arrive at the results and further use of the findings. Many health
and evaluation leaders are careful to point out that cultural competence cannot be determined by
a simple checklist, but rather it is an attribute that develops over time. The root of cultural
competency in evaluation is a genuine respect for communities being studied and openness to
seek depth in understanding different cultural contexts, practices and paradigms of thinking. This
includes being creative and flexible to capture different cultural contexts, and heightened
awareness of power differentials that exist in an evaluation context. Important skills include:
ability to build rapport across difference, gain the trust of the community members, and self-
reflect and recognize one’s own biases.
Paradigms
The paradigms axiology, ontology, epistemology, and methodology are reflective of social
justice practice in evaluation. These examples focus on addressing inequalities and injustices in
society by promoting inclusion and equality in human rights.
Axiology (Values and Value Judgements)
The transformative paradigm’s axiological assumption rests on four primary principles:[43]
 The importance of being culturally respectful

 The promotion of social justice
 The furtherance of human rights
 Addressing inequities
Ontology (Reality)
Differences in perspectives on what is real are determined by diverse values and life experiences.
In turn these values and life experiences are often associated with differences in access to
privilege, based on such characteristics as disability, gender, sexual identity, religion,
race/ethnicity, national origins, political party, income level, are, language, and immigration or
refugee status.
Epistemology (Knowledge)
Knowledge is constructed within the context of power and privilege with consequences attached
to which version of knowledge is given privilege. “Knowledge is socially and historically located
within a complex cultural context”.
Methodology (Systematic Inquiry)
Methodological decisions are aimed at determining the approach that will best facilitate use of
the process and findings to enhance social justice; identify the systemic forces that support the

status quo and those that will allow change to happen; and acknowledge the need for a critical
and reflexive relationship between the evaluator and the stakeholders.
Lenses
While operating through social justice, it is imperative to be able to view the world through the
lens of those who experience injustices. Critical Race Theory, Feminist Theory, and
Queer/LGBTQ Theory are frameworks for how we think should think about providing justice for
marginalized groups. These lenses create opportunity to make each theory priority in addressing
inequality.
Critical Race Theory
Critical Race Theory(CRT)is an extension of critical theory that is focused in inequities based on
race and ethnicity. Daniel Solorzano describes the role of CRT as providing a framework to
investigate and make visible those systemic aspects of society that allow the discriminatory and
oppressive status quo of racism to continue.
Feminist Theory
The essence of feminist theories is to “expose the individual and institutional practices that have
denied access to women and other oppressed groups and have ignored or devalued women”
Queer/LGBTQ Theory
Queer/LGBTQ theorists question the heterosexist bias that pervades society in terms of power
over and discrimination toward sexual orientation minorities. Because of the sensitivity of issues
surrounding LGBTQ status, evaluators need to be aware of safe ways to protect such individuals’
identities and ensure that discriminatory practices are brought to light in order to bring about a
more just society.
Government requirements
Given the Federal budget deficit, the Obama Administration moved to apply an "evidence-based
approach" to government spending, including rigorous methods of program evaluation. The
President's 2011 Budget earmarked funding for 19 government program evaluations for agencies
such as the Department of Education and the United States Agency for International
Development (USAID). An inter-agency group delivers the goal of increasing transparency and
accountability by creating effective evaluation networks and drawing on best practices. A six-
step framework for conducting evaluation of public health programs, published by the Centers
for Disease Control and Prevention (CDC), initially increased the emphasis on program
evaluation of government programs in the US. The framework is as follows:
1. Engage stakeholders
2. Describe the program.
3. Focus the evaluation.

4. Gather credible evidence.
5. Justify conclusions.
6. Ensure use and share lessons learned.
CIPP Model of evaluation
History of the CIPP model
The CIPP model of evaluation was developed by Daniel Stufflebeam and colleagues in the
1960s.CIPP is an acronym for Context, Input, Process and Product. CIPP is an evaluation model
that requires the evaluation of context, input, process and product in judging a programme’s
value. CIPP is a decision-focused approach to evaluation and emphasises the systematic
provision of information for programme management and operation.
CIPP model
The CIPP framework was developed as a means of linking evaluation with programme decision-
making. It aims to provide an analytic and rational basis for programme decision-making, based
on a cycle of planning, structuring, implementing and reviewing and revising decisions, each
examined through a different aspect of evaluation –context, input, process and product
evaluation.
The CIPP model is an attempt to make evaluation directly relevant to the needs of decision-
makers during the phases and activities of a programme. Stufflebeam’s context, input, process,
and product (CIPP) evaluation model is recommended as a framework to systematically guide
the conception, design, implementation, and assessment of service-learning projects, and provide
feedback and judgment of the project’s effectiveness for continuous improvement.
Four aspects of CIPP evaluation
These aspects are context, inputs, process, and product. These four aspects of CIPP evaluation
assist a decision-maker to answer four basic questions:
 What should we do?
This involves collecting and analysing needs assessment data to determine goals, priorities and
objectives. For example, a context evaluation of a literacy program might involve an analysis of
the existing objectives of the literacy programme, literacy achievement test scores, staff concerns
(general and particular), literacy policies and plans and community concerns, perceptions or
attitudes and needs.
 How should we do it?
This involves the steps and resources needed to meet the new goals and objectives and might
include identifying successful external programs and materials as well as gathering information.

 Are we doing it as planned?
This provides decision-makers with information about how well the programme is being
implemented. By continuously monitoring the program, decision-makers learn such things as
how well it is following the plans and guidelines, conflicts arising, staff support and morale,
strengths and weaknesses of materials, delivery and budgeting problems.
 Did the programme work?
By measuring the actual outcomes and comparing them to the anticipated outcomes, decision-
makers are better able to decide if the program should be continued, modified, or dropped
altogether. This is the essence of product evaluation.
Using CIPP in the different stages of the evaluation
The CIPP model is unique as an evaluation guide as it allows evaluators to evaluate the program
at different stages, namely: before the program commences by helping evaluators to assess the
need and at the end of the program to assess whether or not the program had an effect.
CIPP model allows you to ask formative questions at the beginning of the program, then later
gives you a guide of how to evaluate the programs impact by allowing you to ask summative
questions on all aspects of the program.
 Context: What needs to be done? Vs. Were important needs addressed?

 Input: How should it be done? Vs. Was a defensible design employed?
 Process: Is it being done? Vs. Was the design well executed?
 Product: Is it succeeding? Vs. Did the effort succeed?
 Team evaluation
 Using a software tool to enhance project evaluation
17.11 Emerging issues and trends

Information Systems Project Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Systems Project Management

Uploaded by

Copyright:

Available Formats

PAPER NO.

1 www.someakenya.com Contact: 0707 737 890

2. Information systems project lifecycle

3. Project scope management

2 www.someakenya.com Contact: 0707 737 890

5. IS project resource management

6. IS project organizational structures

7. IS project communication management

8. IS project risk management

3 www.someakenya.com Contact: 0707 737 890

9. IS project procurement management

10. IS project implementation, completion and evaluation

11. Emerging issues and trends

Topic 1: Overview of an Information systems project ……………………………………….…..……5

4 www.someakenya.com Contact: 0707 737 890

OVERVIEW OF AN INFORMATION SYSTEMS PROJECT

Project management is the discipline of carefully projecting or planning, organizing,

The traditional approach

A traditional phased approach identifies a sequence of steps to be completed. In the "traditional

5 www.someakenya.com Contact: 0707 737 890

6 www.someakenya.com Contact: 0707 737 890

PRINCE2 is a structured approach to project management released in 1996 as a generic project

Critical chain project management

In multi-project environments, resource leveling should be performed across projects. However,

7 www.someakenya.com Contact: 0707 737 890

The incorporation of process-based

Agile project management

The iteration cycle in agile project management

Advocates of this technique claim that:

8 www.someakenya.com Contact: 0707 737 890

Lean project management

Extreme project management

9 www.someakenya.com Contact: 0707 737 890

Benefits realization management (BRM)

Benefits realization management (BRM) enhances normal project management techniques

The project development stages

10 www.someakenya.com Contact: 0707 737 890

Initiating process group processes

 analyzing the business needs/requirements in measurable goals

Project planning generally consists of

Executing process group processes

12 www.someakenya.com Contact: 0707 737 890

Monitoring and controlling process group processes

Monitoring and controlling includes:

 Measuring the ongoing project activities ('where we are');

Project maintenance is an ongoing process, and it includes:

1 Continuing support of end-users

13 www.someakenya.com Contact: 0707 737 890

3 Updates of the software over time

Monitoring and controlling cycle

In this stage, auditors should

14 www.someakenya.com Contact: 0707 737 890

Closing process group processes.

This phase consists of:

Project controlling and project control systems

Project controlling should be established as an independent function in project management. It

 A strategy to align development with the organization’s broader objectives

What is a Project? A project is a sequence of unique, complex, and connected activities

16 www.someakenya.com Contact: 0707 737 890

 Principle 2: Business Objectives

 Principle 3: Standards of Engagement

 Principle 4: Intervention & Execution Strategy

 Principle 5: Organizational Alignment

 Principle 6: Measurement & Accountability