INTRODUCTION

1.1 Project management1

Project management is the discipline of planning, organizing, and managing resources
to bring about the successful completion of specific project goals and objectives. It is
often closely related to and sometimes conflated with program management.

A project is a temporary endeavor, having a defined beginning and end (usually

constrained by date, but can be by funding or deliverables, undertaken to meet particular
goals and objectives, usually to bring about beneficial change or added value. The
temporary nature of projects stands in contrast to business as usual (or operations), which
are repetitive, permanent or semi-permanent functional work to produce products or
services. In practice, the management of these two systems is often found to be quite
different, and as such requires the development of distinct technical skills and the
adoption of separate management.

The primary challenge of project management is to achieve all of the project goals and
objectives while honoring the preconceived project constraints. Typical constraints are
scope, time, and budget. The secondary and more ambitious challenge is to optimize the
allocation and integration of inputs necessary to meet pre-defined objectives.

1
http://en.wikipedia.org/wiki/Project_management
2
http://www.geology.cz/geocapacity/project/management/Organisation%20diagram2-red.jpg
1.2 History of Project Management3
Project management has been practiced since early civilization. Until 1900 civil
engineering projects were generally managed by creative architects and engineers
themselves, among those for example Vitruvius (1st century BC), Christopher Wren
(1632–1723) , Thomas Telford (1757-1834) and Isambard Kingdom Brunel (1806–1859)
It was in the 1950s that organizations started to systematically apply project management
tools and techniques to complex projects.

As a discipline, Project Management developed from several fields of application

including construction, engineering, and defense activity. Two forefathers of project
management are Henry Gantt, called the father of planning and control techniques, who
is famous for his use of the Gantt chart as a project management tool; and Henri Fayol for
his creation of the 5 management functions which form the foundation of the body of
knowledge associated with project and program management. Both Gantt and Fayol were
students of Frederick Winslow Taylor's theories of scientific management. His work is
the forerunner to modern project management tools including work breakdown structure
(WBS) and resource allocation.

The 1950s marked the beginning of the modern Project Management era. Project
management was formally recognized as a distinct discipline arising from the
management discipline. In the United States, prior to the 1950s, projects were managed
on an ad hoc basis using mostly Gantt Charts, and informal techniques and tools. At that
time, two mathematical project-scheduling models were developed. The "Critical Path
Method" (CPM) was developed as a joint venture between DuPont Corporation and
Remington Rand Corporation for managing plant maintenance projects. And the
"Program Evaluation and Review Technique" or PERT, was developed by Booz-Allen &
Hamilton as part of the United States Navy's (in conjunction with the Lockheed
Corporation) Polaris missile submarine program; These mathematical techniques quickly
spread into many private enterprises.

At the same time, as project-scheduling models were being developed, technology for
project cost estimating, cost management, and engineering economics was evolving, with
pioneering work by Hans Lang and others. In 1956, the American Association of Cost
Engineers (now AACE International; the Association for the Advancement of Cost
Engineering) was formed by early practitioners of project management and the associated
specialties of planning and scheduling, cost estimating, and cost/schedule control (project
control). AACE continued its pioneering work and in 2006 released the first integrated
process for portfolio, program and project management (Total Cost Management
Framework).

3
http://en.wikipedia.org/wiki/Project_management
1.3 Project management approaches4
There are a number of approaches to managing project activities including agile,
interactive, 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.

i) The traditional approach5

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

"traditional approach", we can distinguish 5 components of a project (4 stages plus
control) in the development of a project:

• Project initiation stage;

• Project planning or design stage;
• Project execution or production stage;
• Project monitoring and controlling systems;
• Project completion stage.

Not all the projects will visit every stage as projects can be terminated before they reach
completion. Some projects do not follow a structured planning and/or monitoring stages.
Some projects will go through steps 2, 3 and 4 multiple times.

Many industries use variations on 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."

4
http://en.wikipedia.org/wiki/Project_management
5
http://en.wikipedia.org/wiki/Project_management
ii) Critical Chain Project Management7

Critical Chain Project Management (CCPM) is a method of planning and managing

projects that puts the main emphasis on the resources required to execute project tasks. It
was developed by Eliyahu M. Goldratt. This is in contrast to the more traditional Critical
Path and PERT methods, which emphasize task order and rigid scheduling. A Critical
Chain project network will tend to keep the resources levelly loaded, but will require
them to be flexible in their start times and to quickly switch between tasks and task
chains to keep the whole project on schedule.

a. Origins8

Developed by Eliyahu M. Goldratt, Critical Chain Project Management is based on

methods and algorithms derived from his Theory of Constraints. The idea of CCPM was
introduced in 1997 in his book, Critical Chain. Application of CCPM has been credited
with achieving projects 10% to 50% faster and/or cheaper than the traditional methods
(ie. CPM, PERT, Gantt, etc.) developed from 1910 to 1950's.

From numerous studies by Standish Group and others as of 1998 for traditional project
management methods, only 44% of projects typically finish on time, projects usually
complete at 222% of the duration originally planned, 189% of the original budgeted cost,
70% of projects fall short of their planned scope (technical content delivered), and 30%
are cancelled before completion.

These traditional statistics are mostly avoided through CCPM. Typically, CCPM case
studies report 95% on-time and on-budget completion when CCPM is applied correctly.
Mabin and Balder stone in their meta-analysis of seventy-eight published case studies,
found that implementing Critical Chain resulted in mean reduction in lead-times of 69%,
mean reduction of cycle-times of 66%, mean improvement in due date performance of

6
http://en.wikipedia.org/wiki/File:Project_Management_(phases).png
7
http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
8
http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
60%, mean reduction in inventory levels of 50% and mean increases in revenue /
throughput of 68%.

b. Details9

With traditional project management methods, 30% of the lost time and resources are
typically consumed by wasteful techniques such as bad multi-tasking, Student syndrome,
In-box delays, and lack of prioritization.

In project management, the critical chain is the sequence of both precedence- and
resource-dependent terminal elements that prevents a project from being completed in a
shorter time, given finite resources. If resources are always available in unlimited
quantities, then a project's critical chain is identical to its critical path.

Critical chain is used as an alternative to critical path analysis. The main features that
distinguish the critical chain from the critical path are:

1. The use of (often implicit) resource dependencies. Implicit means that they are not
included in the project network but have to be identified by looking at the
resource requirements.
2. Lack of search for an optimum solution. This means that a "good enough"
solution is enough because:
1. As far as is known, there is no analytical method of finding an absolute
optimum (i.e. having the overall shortest critical chain).
2. The inherent uncertainty in estimates is much greater than the difference
between the optimum and near-optimum ("good enough" solutions).
3. The identification and insertion of buffers:

o project buffer
o feeding buffers
o resource buffers. (Most of time it is observed that companies are reluctant
to give more resources)
2. Monitoring project progress and health by monitoring the consumption rate of the
buffers rather than individual task performance to schedule.

CCPM aggregates the large amounts of safety time added to many subprojects in project
buffers to protect due-date performance, and to avoid wasting this safety time through
bad multitasking, student syndrome, Parkinson's Law and poorly synchronized
integration.

Critical chain project management uses buffer management instead of earned value
management to assess the performance of a project. Some project managers feel that the
earned value management technique is misleading, because it does not distinguish
progress on the project constraint (i.e. on the critical chain) from progress on non-

9
http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
constraints (i.e. on other paths). Event chain methodology can be used to determine a size
of project, feeding, and resource buffers.

c. Methodology10

Planning

A project plan is created in much the same fashion as with critical path. The plan is
worked backward from a completion date with each task starting as late as possible. Two
durations are entered for each task: a "best guess," or 50% probability duration, and a
"safe" duration, which should have higher probability of completion (perhaps 90% or
95%, depending on the amount of risk that the organization can accept).

Resources are then assigned to each task, and the plan is resource leveled using the 50%
estimates. The longest sequence of resource-leveled tasks that lead from beginning to end
of the project is then identified as the critical chain. The justification for using the 50%
estimates is that half of the tasks will finish early and half will finish late, so that the
variance over the course of the project should be zero.

Recognizing that tasks are more likely to take more rather than less time due to
Parkinson's law, Student syndrome, or other reasons, "buffers" are used to establish dates
for deliverables and for monitoring project schedule and financial performance. The
"extra" duration of each task on the critical chain—the difference between the "safe"
durations and the 50% durations—is gathered together in a buffer at the end of the
project. In the same way, buffers are gathered at the end of each sequence of tasks that
feed into the critical chain.

Finally, a baseline is established, which enables financial monitoring of the project.

Alternatively, the project manager can use probability-based quantification of duration

using Monte Carlo simulation. In 1999, a researcher applied simulation to assess the
impact of risks associated with each component of project work breakdown strucure on
project duration, cost and performance. Using Monte Carlo simulation, the project
manager can apply different probabilities for various risk factors that affect a project
component. The probability of occurrence can vary from 0% to 100% chance of
occurrence. The impact of risk is entered into the simulation model along with the
probability of occurrence. The Monte Carlo simulation runs over 10,000 iterations and
provides a density graph illustrating the overall probability of risk impact on project
outcome.

10
http://en.wikipedia.org/wiki/Critical_Chain_Project_Management
Execution

When the plan is complete and the project ready to kick off, the project network is fixed
and the buffers size is "locked" (i.e. their planned duration may not be altered during the
project), because they are used to monitor project schedule and financial performance.

With no slack in the duration of individual tasks, the resources on the critical chain are
exploited by ensuring that they work on the critical chain task and nothing else; bad
multitasking is eliminated. An analogy is drawn in the literature with a relay race. The
critical chain is the race, and the resources on the critical chain are the runners. When
they are running their "leg" of the project, they should be focused on completing the
assigned task as quickly as possible, with no distractions or multitasking. In some case
studies, actual batons are reportedly hung by the desks of people when they are working
on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome
the tendency to delay work or to do extra work when there seems to be time.

Because task durations have been planned at the 50% probability duration, there is
pressure on the resources to complete critical chain tasks as quickly as possible,
overcoming student's syndrome and Parkinson's Law.

Monitoring

Monitoring is, in some ways, the greatest advantage of the Critical Chain method.
Because individual tasks will vary in duration from the 50% estimate, there is no point in
trying to force every task to complete "on time;" estimates can never be perfect. Instead,
we monitor the buffers that were created during the planning stage. A fever chart or
similar graph can be easily created and posted to show the consumption of buffer as a
function of project completion. If the rate of buffer consumption is low, the project is on
target. If the rate of consumption is such that there is likely to be little or no buffer at the
end of the project, then corrective actions or recovery plans must be developed to recover
the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate
where all of the buffer may be expected to be consumed before the end of the project,
resulting in late completion), then those alternative plans need to be implemented.
11
http://www.advanced-projects.com
iii) Event chain methodology12

Event chain methodology is an uncertainty modeling and schedule network analysis

technique that is focused on identifying and managing events and event chains that affect
project schedules. Event chain methodology is the next advance beyond critical path
method and critical chain project management.

Event chain methodology helps to mitigate effect motivational and cognitive biases in
estimating and scheduling. In many cases, project managers intentionally or
unintentionally create project schedules that are impossible to implement. The
methodology also simplifies the process of defining risks and uncertainties in project
schedules, particularly by improving the ability to provide reality checks and to visualize
multiple events. Event chain methodology is used to perform more accurate quantitative
analysis while taking into account such factors as relationships between different events
and actual moments of the events.

a. Event Chain Methodology Principles13

Moment of risk and state of activity

An activity (task) in most real life processes is not a continuous uniform procedure. Tasks
are affected by external events, which transform an activity from one state to another.

One of the important properties of an event is the moment when an event occurs during
the course of an activity. This moment, when an event occurs, in most cases is
probabilistic and can be defined using statistical distribution.

Event Chains

Events can cause other events, which will create event chains. These event chains can
significantly affect the course of the project. For example, requirement changes can cause
an activity to be delayed. To accelerate the activity, the project manager allocates a
resource from another activity, which then leads to a missed deadline. Eventually, this
can lead to the failure of the project.

Monte Carlo Simulations

Once events and event chains are defined, quantitative analysis using Monte Carlo
simulation can be performed to quantify the cumulative effect of the events. Probabilities
and effects of risks are used as input data for Monte Carlo simulation of the project
schedule. In most real life projects, it is necessary to supplement the information
regarding the uncertainties expressed as an event, with distributions related to duration,
start time, cost, and other parameters.

12
http://en.wikipedia.org/wiki/Event_chain_methodology
13
http://en.wikipedia.org/wiki/Event_chain_methodology
Critical Event Chains

The single events or the event chains that have the most potential to affect the projects are
the “critical events” or “critical chains of events.” By identifying critical events or critical
chains of events, we can mitigate their negative effects. These critical chains of events
can be identified by analyzing the correlations between the main project parameters, such
as project duration or cost, and the event chains.

Performance Tracking with Event Chains

Monitoring the activity's progress ensures that updated information is used to perform the
analysis. During the course of the project, the probability and time of the events can be
recalculated based on actual data. The main issue with performance tracking is
forecasting an activity’s duration and cost if an activity is partially completed and certain
events are assigned to the activity. The simple heuristic approach to this problem is to
analyze the moment of risk, which is defined as one of the event parameters. Advanced
analysis can be performed using a Bayesian approach.

Event Chain Diagrams

Event Chain Diagrams are visualizations that show the relationships between events and
tasks and how the events affect each other. The simplest way to represent these chains is
to depict them as arrows associated with certain tasks or time intervals on the Gantt chart.
Different events and event chains can be displayed using different colors. Events can be
global (for all tasks in the project) and local (for a particular task). By using Event Chain
Diagrams to visualize events and event chains, the modelling and analysis of risks and
uncertainties can be significantly simplified.

b. Event Chain Methodology Phenomena14

Repeated Activities

Sometimes events can cause the start of an activity that has already been completed. This
is a very common scenario for real life projects; sometimes a previous activity must be
repeated based on the results of a succeeding activity. Modeling of these scenarios using
event chain methodology is simple. The original project schedule does not need to be
updated, as all that is required is to define the event and assign it to an activity that points
to the previous activity. In addition, a limit to the number of times an activity can be
repeated needs to be defined.

Event Chains and Risk Mitigation

If event or event chain occurs during the course of a project, it may require some
mitigation effort. In some cases, mitigation plans can be generated. Mitigation plans are

14
http://en.wikipedia.org/wiki/Event_chain_methodology
an activity or group of activities (small schedule) that augment the project schedule if a
certain event occurs. The solution is to assign the mitigation plan to an event or event
chain. These small schedules will be triggered when an event chain occurs. The same
mitigation plan can be used for different events.

Resource Allocation Based on Events

One potential event is the reassignment of a resource from one activity to another, which
can occur under certain conditions. For example, if an activity requires more resources to
complete it within a fixed period, this will trigger an event to reallocate the resource from
another activity. Reallocation of resources can also occur when activity duration reaches
a certain deadline or the cost exceeds a certain value. Events can be used to model
different situations with resources, e.g. temporary leave, illness, vacations, etc.

15
http://www.cairngormdocs.org/bjorn_schultheiss/eventChaining/EventChainDiagramBlue.jpg
iv) PRINCE216

Projects IN Controlled Environments (PRINCE) is a project management method. It

covers the management, control and organization of a project. "PRINCE2" refers to the
second major version of this method and is a registered trademark of the Office of
Government Commerce (OGC), an independent office of HM Treasury of the United
Kingdom.

a. History17

PRINCE2 is derived from an earlier method called PROMPT, and from PRINCE project
management method, which was initially developed in 1989 by the Central Computer and
Telecommunications Agency (CCTA) as a UK Government standard for information
systems (IT) project management; however, it soon became regularly applied outside the
purely IT environment. PRINCE2 was released in 1996 as a generic project management
method. PRINCE2 has become increasingly popular and is now a de facto standard for
project management in the UK. Its use has spread beyond the UK to more than 50 other
countries.

The most current revision was released in 2009 as part of the Prince2:2009 refresh project
by the Office of Government Commerce.

PRINCE2:2009 Refresh: Since 2006, the method has been revised and launched as
"PRINCE2:2009 Refresh" on June 16th, 2009. The name "PRINCE2" (instead of
"PRINCE3" or similar) is kept to demonstrate that the method remains faithful to its
principles. Nevertheless, it is a fundamental revision of the method from 1996 to adapt it
to the changed business environment, to make the method simpler and "lighter", to
address current weaknesses or misunderstandings, and to better integrate it with other
OGC methods (ITIL, P3O, P3M3, MSP, M_o_R etc.). The main difference between the
2009 version and earlier versions is that there will be two manuals: 'Managing Projects
Using PRINCE2' and 'Directing Projects Using PRINCE2'. Both the Foundation and
Practitioner Examinations will be based on the new 'Managing Projects' manual and will
not include material from the new 'Directing Projects' book. The pass mark for the
Foundation exam will remain unchanged but the pass mark for the Practitioner exam will
increase from the current 50% to 55%. The Practitioner exam will also shorten in length
from 3 hours to 2.5 hours. Further info about the refresh is available here.

b. Advantages18

PRINCE2 is a structured approach to project management. It provides a method for

managing projects within a clearly defined framework. PRINCE2 describes procedures to
coordinate people and activities in a project, how to design and supervise the project, and
what to do if the project has to be adjusted if it doesn’t develop as planned. In the method
16
http://en.wikipedia.org/wiki/PRINCE2
17
http://en.wikipedia.org/wiki/PRINCE2
18
http://en.wikipedia.org/wiki/PRINCE2
each process is specified with its key inputs and outputs and with specific goals and
activities to be carried out, which gives an automatic control of any deviations from the
plan. Divided into manageable stages, the method enables an efficient control of
resources. On the basis of close monitoring the project can be carried out in a controlled
and organized way. Being a structured method widely recognized and understood
PRINCE2 provides a common language for all participants in the project. The various
management roles and responsibilities involved in a project are fully described and are
adaptable to suit the complexity of the project and skills of the organization.

c. Pitfalls19

PRINCE2 is sometimes incorrectly considered inappropriate for very small projects, due
to the work required in creating and maintaining documents, logs and lists. However, this
may often be because of a misunderstanding about which parts of PRINCE2 to apply:
PRINCE2 is fully scalable.

d. Overview of the method20

PRINCE2 is a process-driven project management method which contrasts with

reactive/adaptive methods such as Scrum. PRINCE2 2009 defines 40 separate activities
and organizes these into seven processes:

Starting up a project

In this process the project team is appointed and a project brief (describing, in outline,
what the project is attempting to achieve and the business justification for doing so) is
prepared. In addition the overall approach to be taken is decided and the next stage of the
project is planned. Once this work is done, the project board is asked to authorize the next
stage, that of initiating the project.

Key activities include: appointing an executive and a project manager; designing and
appointing a project management team; preparing a project brief; defining the project
approach; and planning the next stage (initiation).

Initiating a project

This process builds on the work of the start up process, and the project brief is augmented
to form a Business case. The approach taken to ensure quality on the project is agreed
together with the overall approach to controlling the project itself (project controls).
Project files are also created as is an overall plan for the project. A plan for the next stage
of the project is also created. The resultant information can be put before the project
board for them to authorize the project itself.

19
http://en.wikipedia.org/wiki/PRINCE2
20
http://en.wikipedia.org/wiki/PRINCE2
Key activities include: planning quality; planning a project; refining the business case and
risks; setting up project controls; setting up project files; and assembling a Project
Initiation Document.

Directing a project

This process dictates how the Project Board (which comprises such roles as the executive
sponsor or project sponsor) should control the overall project. As mentioned above, the
project board can authorize an initiation stage and can also authorize a project. Directing
a Project also dictates how the project board should authorize a stage plan, including any
stage plan that replaces an existing stage plan due to slippage or other unforeseen
circumstances. Also covered is the way in which the board can give ad hoc direction to a
project and the way in which a project should be closed down.

Key activities include: authorizing initiation; authorizing a project; authorizing a stage or

exception plan; giving ad-hoc direction; and confirming project closure.

Controlling a stage

PRINCE2 suggests that projects should be broken down into stages and these sub-
processes dictate how each individual stage should be controlled. Most fundamentally
this includes the way in which work packages are authorized and received. It also
specifies the way in which progress should be monitored and how the highlights of the
progress should be reported to the project board. A means for capturing and assessing
project issues is suggested together with the way in which corrective action should be
taken. It also lays down the method by which certain project issues should be escalated to
the project board.

Key activities include: authorizing work package; assessing progress; capturing and
examining project issues; reviewing stage status; reporting highlights; taking corrective
action; escalating project issues; and receiving a completed work package.

Managing stage boundaries

The Controlling a Stage process dictates what should be done within a stage, Managing
Stage Boundaries (SB) dictates what should be done towards the end of a stage. Most
obviously, the next stage should be planned and the overall project plan, risk log and
business case amended as necessary. The process also covers what should be done for a
stage that has gone outside its tolerance levels. Finally, the process dictates how the end
of the stage should be reported.

Key activities include: planning a stage; updating a project plan; updating a project
business case; updating the risk log; reporting stage end; and producing an exception
plan.
Closing a project

This covers the things that should be done at the end of a project. The project should be
formally de-commissioned (and resources freed up for allocation to other activities),
follow on actions should be identified and the project itself be formally evaluated.

Key activities include: decommissioning a project; identifying follow-on actions; and

project evaluation review.
v) Process-based management21

Process-based management is a management approach that governs the mindset and

actions in an organization. It is a philosophy of how an organization manages its
operations, aligned with and supported by the vision, mission and values of the
organization. The process is the basis on which decisions are made and actions are taken.
It is oriented toward achieving a vision rather than targeting specific activities and tasks
of individual functions.

The general process is that the vision determines the necessary strategy, structure and
human resource requirements for the organization. It can also be used on the project
management level in that a clear vision of a project defines the strategy, structure and
resources required to achieve success. The project process continues with the
implementation of the tasks and activities required to achieve the vision.

Most companies are focused around organizational performance such as budgets,

incentives, costs, and skill development. Process Based Management adds these
performance measures but in an operational way that adds to the organizational measures.
Over time, the process measures take a stronger role. The "Order to Cash" process for
instance is what brings revenue into a company, but often, conventional companies are so
focused on their individual departments that the cross functional process is an
afterthought. Performance suffers because of this. CAM-I is currently performing
research on this concept.

22

21
http://en.wikipedia.org/wiki/Process-based_management
22
http://www.bpminstitute.org/images/contributors/Dowdle_Fig2_0509.jpg
 2. PROJECT DEVELOPMENT STAGES

2.1 PROJECT ORIGINATION23

Purpose

The purpose of Project Origination is to evaluate projects pro-posed for the next planning
cycle and to reach a consensus on the projects to be selected. During this phase, the strength
of a project’s Business Case is tested, and the viability of the Proposed Solution is explored.
A determination is made as to whether the project is consistent with the agency’s strategic
plan and affordable within budget guidelines.

The Project Proposal process may actually be part of the budget cycle, serving as the
justification for budget requests. In this case, Project Proposals may need to be created a full
budget cycle prior to the project’s anticipated initiation.

Other factors that impact Project Origination include statutory requirements, regulations,
legislative restrictions, and civil service rules.

Each organization has its own approach to green-lighting desired projects. The approach
outlined below is only one of many possible variations of the evaluation and selection pro-
cess. There are some general principles, however, that apply to any effective evaluation and
selection process:
⇒ The deciding body must have enough information about the merits of the project’s
Business Case and the viability of its Proposed Solution to make a meaningful
evaluation;
⇒ The competing projects’ merits must be evaluated and compared using a
consistently applied methodology;

⇒ The selection process must take into consideration the project’s fit with the
organizational mission and strategic plan.

List of P r o c e s s e s

The three major processes in this phase of the project management lifecycle are:

⇒ Project Proposal, where the initial Business Case is made, and initial project
parameters are defined;
⇒ Evaluate Project Proposals, where cost/benefit analysis is performed, and
the projects are evaluated against a set of specific business criteria; and

23
http://www.oft.state.ny.us/pmmp/guidebook2/index.htm
⇒ Select Projects, where a consensus is reached on the project’s feasibility and
relative importance in comparison to other proposed projects, and a decision is formally
made regarding the Project Proposal.

The following roles are involved in carrying out the processes of this
phase. The detailed descriptions of these roles can be found in the Section
I Introduction.
� Project Sponsor
� Project Proposal Team
� Project Selection Committee

Since a Project Manager is not usually assigned to the project at this

time, members of the Performing Organization Management prepare and
review Project Origination deliverables.

2.2 DEVELOP PROJECT PROPOSAL24

Before a project can be selected for initiation, a persuasive case must

be made for its viability given current organization-al priorities. In
D e v e l o p P r o j e c t P r o p o s a l , the initial Business Case for the
project is formulated, and all information required for project selection
is formalized in the Proposed Solution. A proposal for a project may
come from any place in the Performing Organization, but someone
must be identified as the “owner” of the proposal, and must serve as
Project Sponsor, at least through the evaluation and selection process.
The Project Sponsor may be in executive management, in a specific
functional program area, or a representative of the Customers or the
Consumers within the Performing.

24
http://www.oft.state.ny.us/pmmp/guidebook2/index.htm
2 PROJECT INITIATION

Purpose

The purpose of Project Initiation is to begin to define the over-all

parameters of a project and establish the appropriate project
management and quality environment required to complete the project.

Development of the Project Charter is a pivotal starting point for the

project, establishing the project definition that will serve as the
foundation for all future efforts. The completion of this process is
marked by the Project Kick-off Meeting, in which the Project Manager
presents the Project Charter.

Successful projects begin with a detailed project definition that is

u n d e r s t o o d a n d a c c e p t e d by Stakeholders. Putting everything down in
writing helps ensure a commitment among Project Team members and
between the team and the Stakeholders. As part of Project Initiation, an
initial Project Plan is developed, which comprises the Project Charter,
Cost/Scope/Schedule/ Quality (CSSQ) documents, and preliminary risk
identification list. These documents, once approved, ensure a consistent
understanding of the project, help to set expectations, and identify
resources necessary to move the project to the next level of detailed
planning. Potential problems are identified so that they can be addressed
early in the project.

Also during Project Initiation, a high-level Project Schedule is

developed as the roadmap to more detailed Project Planning and Project
Execution and Control. This high-level schedule will be refined over
time, and will serve as the primary source of information regarding
project status and progress. An accurate, realistic, and complete
schedule, rigorously maintained, is essential to the success of a project.

Sponsorship of the project must be confirmed or gained during Project

Initiation. Having a Project Sponsor, and securing approval early in the
project management lifecycle, helps to ensure a commitment to the
project.
 List of Processes

This phase consists of the following processes:

� Prepare for the Project, where the Project Sponsor and initial
Project Team are identified and work with the Project Manager to create the Project
Charter.
� Define Cost/Scope/Schedule/Quality (CSSQ), where the Project
Manager, along with the Project Team define the scope of the project and identify the
preliminary budget, high-level schedule and quality standards to complete the project.
� Perform Risk Identification, where the Project Manager and
Project Team begin to identify and document any risks associated with the project.
� Develop Initial Project Plan, where the Project Manager and
Project Team identify all Stakeholders and document their
involvement in the project, develop means of communicating with
them, and compile all documentation created during Project
Initiation to produce the Initial Project Plan.
� Confirm Approval to Proceed to Next Phase, where the Project
Manager reviews and refines the Business Case, secures resources required for Project
Planning and pre-pares the formal acceptance package for review and approval by the
Project Sponsor.

The following chart illustrates all of the processes and deliverables of

this phase in the context of the project management lifecycle.