Professional Documents
Culture Documents
Information Systems Project Management
Information Systems Project Management
CT 62
SECTION 6
CERTIFIED
INFORMATION COMMUNICATION
TECHNOLOGISTS
(CICT)
INFORMATION
SYSTEM PROJECT MANAGEMENT
STUDY TEXT
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
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
CONTENT PAGE
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.
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
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 (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.
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
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.
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.
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 uses the principles from lean manufacturing to focus on delivering
value with less waste and reduced time.
Planning and feedback loops in Extreme programming (XP) with the time frames of the multiple
loops.
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.
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
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
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:
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.
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
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 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.
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.
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 includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned.
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.
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
15 www.someakenya.com Contact: 0707 737 890
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:
Definition of a project
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 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.
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.
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.
Projects differ, but they have some commonalities. Table 1.1 presents some characteristics of a
project.
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 owners might keep changing their minds about the components
and functionalities of the sales software.
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.
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
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
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
B. Bottom-Up Approach
• In this approach community/beneficiaries are encouraged to identify and plan the projects
themselves with or without outsiders.
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.
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 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.
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)
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.
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.
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.
30 www.someakenya.com Contact: 0707 737 890
Financial feasibility
In case of a new project, financial viability can be judged on the following parameters:
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.
The feasibility study outputs the feasibility study report, a report detailing the evaluation criteria,
the study findings, and the recommendations
Project selection
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.
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.
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,
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.
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?
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.
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.
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.
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.
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
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.
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
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
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,
Put another way, the physical portion of systems design can generally be broken down into three
sub-tasks:
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 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.
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
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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
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
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
Control Scope
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
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.
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
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.
• Organization by process
• Combination of two
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
• 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
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.
• If possible obtain estimates from several people and use the variance for risk assessment
• Use a separate risk assessment for estimating the effect of abnormal conditions and
contingencies.
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.
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.
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
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.
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
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 (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.
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.
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.
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.
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.
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.
This adds the Planned Task Relationships related list to the Project Task form. This
related list shows successor tasks.
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:
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.
Modifying Dependencies
To modify an existing dependency from the Gantt chart:
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.
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.
1. Double-click
click the relationship.
2. In the Planned Task Relationship form, click Delete.
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.
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.
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:
The same Project Task form appears for all tasks regardless of the parent
parent-child
relationship.
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.
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.
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.
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 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.
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"
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
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’.
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 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
Risk multipliers
This involves building in a time or resource contingency for tasks considered to be at high risk of
overrun.
• 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.
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.
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.
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
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.
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.
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.
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 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.
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.
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
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.
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
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
There are two broad categories of resource – consumable and re-usable. Scheduling these
resources ensures:
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.
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;
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.
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.
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.
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
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.
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
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.
Ready
Assigned
Terminated
Expired
Forwarded
Finished
Failed
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
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 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.
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.
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: 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.
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).
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.
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.
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
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.
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.
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.
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.
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
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
Team management
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:
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.
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
98 www.someakenya.com Contact: 0707 737 890
"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.
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
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
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:
Successful change management is more likely to occur if the following are included:
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.
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:
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:
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:
It is important to note what change management is and what change management is not, as
defined by the majority of research participants.
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.
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.
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.
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
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 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.
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.
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
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.
Training Rework
Equipment
Time To Do It Right
Testing Liabilities
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.
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
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.
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.
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.
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.
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.
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...
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.
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.
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.
Examples
Cause-and-effect
effect diagram
Check sheet
Histogram
Pareto chart
Scatter diagram
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:
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.
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.
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
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.
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.
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.
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.
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
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.
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
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:
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.
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.
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.
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
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:
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.
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
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
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
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.
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.
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 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)
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.
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:
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.
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.
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:
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.
Scope Risk
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 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:
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
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
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
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.
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.
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.
Kendrick highlights the common project level risks as (citing Capers Jones as the original
source):
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.
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:
Describe to all team members and stakeholders the change management process and how
it will be enforced
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.
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.
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.
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.
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 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.
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!
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.
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.
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.
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:
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.
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!
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 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.
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
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.
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.
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.
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.
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.
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.
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 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
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.
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.
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.
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.
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%
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.
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.
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:
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’
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 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
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.
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.
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
Early phase: CI participants are exploring possible strategies and developing plans for
action. Characterized by uncertainty.
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.
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.
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:
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,
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.
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,
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
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.
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.
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
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
174 www.someakenya.com Contact: 0707 737 890
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.
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 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.
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
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.
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”.
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
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(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.
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.
These aspects are context, inputs, process, and product. These four aspects of CIPP evaluation
assist a decision-maker to answer four basic questions:
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.
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.
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.
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.
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.
Team evaluation