1. Generally,
in
large
organization
various
project
management
activities
are
carried
out
approximately
at
the
same
time.
There
are
thousands
of
products.
There
are
also
geographical,
language,
custom
and
many
more
issues
to
take
into
account.
In
such
an
environment
each
project
will
make
different
demands
on
management:
for
example,
“
some
might
be
more
technically
challenging,
might
affect
particularly
critical
areas
of
the
business
or
might
involve
larger
numbers
of
different
types
of
users
”[1].
So
it
is
evident
that
if
the
procedures
by
which
each
project
is
run
are
standardized
rather
than
having
to
be
continually
reinvented
it
would
be
much
more
helpful
for
the
organizations.
In
this
regard
PRINCE
(PRojects
IN
Controlled
Environments)
was
first
developed
by
CCTA,
now
part
of
OGC,
in
1989
as
a
UK
Government
standard
for
IT
project
management.
Although,
initially
developed
only
for
the
need
of
IT
projects,
the
latest
version,
PRINCE2,
which
was
released
in
1996,
is
a
generic
project
management
method.
An
overview:
“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
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”[2].
A
PRINCE2
project
is
divided
into
a
number
of
Management
Stages,
each
forming
a
distinct
unit
for
management
purposes.
Like
the
project,
a
Stage
is
driven
by
a
series
of
Processes,
has
a
defined
set
of
products
and
activities,
a
finite
life-‐span,
control
elements,
and
an
organisational
structure.
It
identifies
roles
rather
than
jobs.
Depending
on
the
circumstances,
a
role
could,
in
fact,
be
carried
out
by
more
than
one
person,
or
a
single
person
could
assume
more
than
one
role.
The
PRINCE2
methodology
applies
three
key
elements
to
each
project
and
to
the
Management
Stages
within
a
project.
The
three
elements
can
be
the
Processes
which
drive
the
project
management,
Components
and
Techniques,
which
are
used
by
each
of
the
Processes
to
effect
the
management
of
the
project.
“PRINCE2
defines
45
separate
sub-‐processes
and
organizes
these
into
eight
processes
as
follows:
”
[2]
Starting
Up
A
Project
(SU)
-‐
Establishes
the
Objectives
and
Approach
to
the
Project;
Sets
up
the
Project
Management
Team;
Plans
for
the
Initiation
Process.
This
is
a
pre-‐project
Process,
which
looks
to
answer
the
question
“do
we
have
a
worthwhile
and
viable
project?”
before
asking
for
commitment
of
resources
to
set
up
a
project
environment.
Initiating
A
Project
(IP)
-‐
Plans
the
whole
Project
in
terms
of
its
Products,
Activities,
Resource
Usage
and
Quality;
Sets
the
baseline
for
the
Business
Benefits
&
Risks.
Directing
A
Project
(DP)
-‐
Provides
authorisation
for
work
to
be
carried
out
and
Resources
to
be
committed.
Authorisation
for
Project
Initiation
and
Project
Closure
and,
in
some
cases,
2. its
premature
termination.
The
Process
is
“owned”
by
the
Project
Board
–
the
overall
authority
for
the
Project
–
the
Executive
member
is
accountable
for
the
overall
business
success
of
the
project.
Controlling
A
Stage
(CS)
-‐
The
basic
day-‐to-‐day
project
management
Process
-‐
authorising
work
to
create
or
change
Products,
collecting
and
reflecting
actual,
assessing
progress
and
reporting
to
senior
management.
Capturing
proposed
changes
and
errors
and
escalating
these,
where
appropriate
to
the
Project
Board.
Managing
Product
Delivery
(MP)
-‐
The
main
“workshop”
for
the
project
where
the
majority
of
resources
are
consumed.
This
Process
is
where
the
Products
of
the
Project
are
created.
Progress
reports
(Checkpoint
Reports)
are
provided
to
the
Project
Manager.
Quality
Review
and
Delivery
of
Products
occurs
here.
Managing
Stage
Boundaries
(SB)
-‐
Reporting
on
the
achievements
of
the
Current
Management
Stage
and
the
impact
on
the
overall
Project
Plan
and
Business
Case.
Planning
the
Next
Stage
(Products,
Activities,
Resource
Usage).
Putting
together
Exception
Plans
when
the
Management
Stage
has
suffered
a
significant
departure
from
its
approved
plan.
Planning
(PL)
–
“
PRINCE2
advocates
product
based
planning
which
means
that
the
first
task
when
planning
is
to
identify
and
analyze
products.
Once
the
activities
required
to
create
these
products
are
identified
then
it
is
possible
to
estimate
the
effort
required
for
each
and
then
schedule
activities
into
a
plan.
There
is
always
risk
associated
with
any
work
and
this
must
be
analyzed.
Finally,
this
process
suggests
how
the
format
of
plans
can
be
agreed
and
ensures
that
plans
are
completed
to
such
a
format.
”
PL1
Design
a
Plan
PL2
Define
and
analyze
products
PL3
Identify
activities
and
their
dependencies
PL4
Estimate
effort
and
each
activity
PL5
Schedule
PL6
Analyze
risk
PL7
Complete
plan
Figure
1.1:
Diagram
showing
PRINCE2
processes.
The
arrows
represent
flows
of
information.[2]
3. Closing
A
Project
(CP)
-‐
Preparation
for
closing
the
Project
in
an
orderly
way.
Customer
sign-‐
off,
preparation
of
an
End-‐
Project
Report
and
identification
of
Lessons
Learned
and
Follow-‐
on
Recommendations.
Planning
for
a
Post-‐Project
Review.
In
PRINCE2
methodology
these
following
Components
are
used
which
are
as
follows:
Organisation
-‐
Organisation
Structure
+
Role
Descriptions.
Predominantly
used
in
the
“Starting
Up
A
Project”
Process
where
the
Executive
and
Project
Manager
are
appointed
in
the
first
Process,
and
the
Project
Management
Team
is
designed
and
appointed.
The
Project
Management
Team
is
reviewed
at
the
end
of
each
Management
Stage
within
“Managing
Stage
Boundaries”.
Plans
-‐
All
Processes
use
the
Plans
Component.
The
Initiation
of
the
project
is
planned
during
“Starting
Up
A
Project”;
the
project
itself
is
planned
in
“Initiating
A
Project”;
Stage
plans
are
prepared
in
“Managing
Stage
Boundaries”;
and
Product
planning
is
carried
out
in
“Controlling
A
Stage”
and
“Managing
Product
Delivery”.
Follow-‐on
actions,
including
preparation
of
a
Post-‐Project
Review
Plan
are
put
together
in
“Closing
A
Project”.
“Directing
A
Project”
uses
the
approved
plans
throughout
to
confirm
the
required
progress.
Controls
-‐
All
the
Processes
use
the
Controls
Component.
The
“control”
Processes
which
make
particular
use
of
this
Component
are
“Initiating
A
Project”(which
sets
up
the
overall
project
control
structure);
“Controlling
A
Stage”
(which
uses
Checkpoint
Reports
to
capture
progress,
and
records
actual
usage
of
resources.
Highlight
Reports
are
used
to
inform
the
Project
Board
of
progress);
“Managing
Product
Delivery”
generates
Checkpoint
Reports
for
control
purposes.
Stage
approval
is
handled
by
“Managing
Stage
Boundaries”
where
Management
Stages
are
approved
via
End
Stage
Assessments.
This
Process
also
uses
Exception
Reporting
and
Planning
to
control
significant
departures
from
plan.
“Directing
A
Project”
is
the
Process
within
which
overall
authorisations
are
made;
this
Process
uses
the
key
controls
of
End
Stage
Assessment,
Exceptions
Assessments,
Tolerance,
Project
Initiation
and
Project
Closure.
Business
Case
-‐
The
Business
Case
is
viewed
as
the
“driving
force”
of
any
PRINCE2
project.
The
Business
Benefits
are
measured
by
the
Business
Case
which
is
outlined
in
“Starting
Up
A
Project”
and
formally
recorded
in
“Initiating
A
Project”
where
it
forms
an
important
part
of
the
Project
Initiation
Document
(PID).
The
Business
Case
is
up-‐dated
at
least
during
“Managing
Stage
Boundaries”
when
the
End-‐Stage
Report
is
created
–
more
often
if
appropriate.
When
Project
Issues
are
being
analysed
the
impact
on
the
Business
case
will
be
reviewed.
During
“Closing
A
Project”
the
Business
Case
will
be
used
in
preparing
the
Post
Project
Review
Plan.
The
Business
Case
has
close
ties
with
the
Management
of
Risk
Component
and
the
two
elements
are
usually
treated
in
unison.
Management
of
Risk
-‐
Risk
analysis
is
carried
out
initially
in
“Starting
Up
A
Project”
when
the
Project
Brief
is
created
and
a
Risk
Log
established.
The
initially
identified
risks
are
refined
in
“Initiating
A
Project”
where
the
Business
Case
for
the
project
is
established.
The
risk
analysis
is
updated
during
“Managing
Stage
Boundaries”
to
provide
the
basis
for
decision
support
for
the
Project
Board
when
they
review
the
project
at
the
End
Stage
Assessment
in
“Directing
A
Project”.
“No
specific
risk
analysis
tools
or
techniques
are
4. recommended.
Management
of
risk
has
close
ties
with
the
Business
Benefits
which
are
measured
and
presented
as
the
Business
case
for
the
project.”[3]
Quality
In
A
Project
Environment
-‐
The
Customer’s
Quality
Expectations
are
first
identified
in
“Starting
Up
A
Project”
and
quality
aspects
are
planned
in
“Initiating
A
Project”.
When
the
project
is
approved,
“Controlling
A
Stage”
and
“Managing
Product
Delivery”
enable
specific
Quality
Criteria
to
be
set
for
each
Product
(or
Deliverable)
via
Product
Descriptions
described
in
the
“Planning”
Process.
Configuration
Management
-‐
Configuration
Management
is
not
optional
in
PRINCE2.
This
Component
addresses
the
proper
safeguarding
and
management
of
Products
or
Deliverables
and
their
associated
documentation.
“Initiating
A
Project”
sets
up
the
Project
Files
and
“Controlling
A
Stage”
and
“Managing
Product
Delivery”
executes
the
Configuration
Management
arrangements.
Project
Files
are
archived
in
“Closing
A
Project”
mainly
for
audit
purposes.
Change
Control
-‐
Managing
proposals
for
change
is
an
important
aspect
of
project
management
and
the
Process
“Controlling
A
Stage”
is
where
such
proposals
are
captured,
evaluated
and
actions
decided
upon.
PRINCE2
project
organization
“
PRINCE2
identifies
roles
rather
than
jobs
”[1].
Every
PRINCE2
project
will
have
a
Project
Board
appointed.
The
Project
Board
is
the
overall
authority
for
the
project
and
is
normally
appointed
by
Corporate
or
Programme
Management
to
take
overall
responsibility
and
control
of
a
PRINCE2
project.
The
Project
Board
consists
of
three
senior
management
roles,
each
representing
major
project
interests.
1. Executive
2. User
3. Supplier
“The
senior
staff
carrying
out
the
respective
roles
will
be
responsible
officers
within
their
respective
organizations
and
the
oversight
of
the
project
will
probably
by
only
one
of
many
responsibilities.
Hence,
the
task
of
managing
the
project
on
a
day-‐
to
–
day
basis
will
be
delegated
by
the
Project
Board
to
a
Project
Manager.
On
a
large
project
it
could
be
necessary
for
the
Project
Manager
to
delegate
the
managing
of
certain
aspects
of
the
project
to
specialist
Team
Managers.
”
[1]
Similarity
of
PRINCE
2
with
Waterfall
Model
:
The
traditional
waterfall
model
gives
a
high-‐
level
view
of
the
software
life
cycle.
At
its
most
basic
it
is
effectively
the
tried
and
tested
problem
solving
paradigm:
• Decide
what
to
do
• Decide
how
to
do
it
• Do
it
• Test
it
• Use
it
5. The
phases
in
the
waterfall
model
are
represented
a
as
a
cascade.
The
outputs
from
one
phase
become
the
inputs
to
the
next.
Figure
2.1
shows
the
unmodified
waterfall
Model[4]
“The
waterfall
model
is
a
sequential
software
development
model
(a
process
for
the
creation
of
software)
in
which
development
is
seen
as
flowing
steadily
downwards
(like
a
waterfall)
through
the
phases
of
requirements
analysis,
design,
implementation,
testing
(validation),
integration,
and
maintenance.
”[4]
Communication
Project
initiation
Requirement
gathering
Planning
estimating
scheduling
Modelling
tracking
Construction
analysis
design
code
Deployment
test
delivery
support
feedback
Figure
2.2
[7]
Now,
if
we
watch
closely
from
this
above
figure
2.2
it
is
evident
that
when
used
for
software
projects
how
PRINCE2
maintain
close
similarity
with
Waterfall
Model.
We
can
see
the
similarities
between
stages
“Communication”
with
PRINCE2’s
Starting
up
a
Project(SU),
“Planning”
with
PRINCE2’s
Planning(PL),Controlling
a
Stage(CS),
“Modelling
and
Construction”
with
PRINCE2’s
Initiating
a
Project(IP),
Directing(DP),
Managing
Product
Delivery(MP),
Managing
Stage
Boundaries(SB)
and
“Deployment”
with
PRINCE2’s
Closing
a
Project(CP).
Considering
all
these
facts
and
figures
I
can
define
PRINCE2
is
another
version
of
the
waterfall
model
for
project
managers
when
used
for
software
projects.
References:
1.
Software
Project
Management
-‐
Bob
Hughes
&
Mike
Cotterell
2.
http://en.wikipedia.org/wiki/PRINCE2
3.
Google
Books:
Managing
Successful
Projects
with
PRINCE2
4.
http://en.wikipedia.org/wiki/Waterfall_model
5.
Google
Books:
PRINCE2:
A
'No
Nonsense'
Management
Guide
6.
Software
Engineering
-‐
Ian
Sommerville
(Fourth
Edition)
7.
Software
Engineering
-‐
A
Practitioner's
Approach
-‐
Roger
S.
Pressman
(Sixth
Edition)