This document discusses project management methodologies, specifically the Waterfall and Agile approaches. It defines a project as a task with a beginning and end that creates value or change. Project management involves planning, organizing, motivating and controlling resources to meet goals. The Waterfall model involves sequential phases of requirements, design, implementation, testing etc. It works well for small, defined projects but can fail for larger ones due to inflexibility. Agile methods allow for more flexibility and adaptation.

1. Project
Management
Methodologies:
According
to
the
book
“The
Definitive
Guide
to
Project
Management”
project
is
a
task
with
a
defined
beginning
and
end,
to
meet
unique
goals
and
objectives
that
will
bring
some
beneficial
change
or
added
value
to
something.
With
that,
the
definition
of
project
management
is
“the
discipline
of
planning,
organizing,
motivating
and
controlling
resources
to
achieve
specific
goals”1
.
There
are
many
challenges
in
the
project
management,
the
main
one
is
to
achieve
all
the
goals
dealing
with
the
restrictions:
scope,
time,
quality
and
budget.
This
is
called
the
Iron
Triangle
of
project
management
because
it
is
very
rare
to
change
one
constraint
(scope,
time
and
budget)
without
impacting
in
the
other
ones
and
the
quality
is
directly
affected
by
those
three
constraints.
Another
challenge
in
project
management
is
to
optimize
the
allocation
of
inputs
and
integrates
them
to
meet
the
objectives
and
goals
defined
in
the
beginning.
Every
project
is
different,
so
it
is
very
important
to
estimate
the
costs
correctly
in
the
beginning
and
keep
track
of
it
during
the
role
project.
Approaches:
There
are
several
approaches
to
managing
projects,
in
this
research
I
will
focus
in
two
of
them:
the
Waterfall
and
Agile.
Regardless
of
the
methodology
implemented,
all
of
them
must
consider
carefully
the
overall
project
objectives,
timeline,
cost
and
the
roles
and
responsibilities
of
the
participants
in
order
to
get
the
best
output.
The
Waterfall
approach:
Before
explain
the
Waterfall
approach
I
will
run
through
the
traditional
approach,
since
the
Waterfall
is
based
on
it.
In
the
traditional
approach
there
are
five
developmental
components,
it
is
a
sequence
of
steps
to
be
completed
during
the
project.
They
are:
1-­‐ Initiation
2-­‐ Planning
and
design
3-­‐ Execution
and
construction
4-­‐ Monitoring
and
controlling
systems
5-­‐ Completion
It
doesn’t
mean
that
every
project
should
have
every
stage.
Some
projects
terminated
before
they
reach
completion,
some
go
through
steps
2,
3
or
4
multiple
Figure
1
-­
The
Iron
Triangle
of
project
management

2. times.
Many
industries
use
variations
of
these
project
stages.
The
Waterfall
approach
is
one
of
those
variations,
when
series
of
tasks
are
implemented
in
a
linear
sequence.
It
has
7
steps:
1. Requirements
specification:
finding
what
customer
of
project
wants.
2. Design
3. Construction
(implementation
or
coding)
4. Integration:
integrate
the
design
and
construction
5. Testing
and
debugging:
ensuring
the
output
of
the
project
meets
the
agreed
requirements.
6. Installation
7. Maintenance:
getting
the
output
of
the
project
working
in
the
real
world.
It
differs
from
the
traditional
approach
because
in
the
Waterfall
model
it
is
implied
that
you
should
move
to
the
next
phase
only
when
the
preceding
phase
is
a
100%
completed
and
perfected.
For
example,
you
just
move
to
coding
after
the
design
is
100%
approved
at
tested.
It
is
usually
used
in
software
development
because
make
easier
for
the
team
that
is
working
since
you
won’t
have
to
change
problems
in
the
design
after
coding
and
will
have
to
do
the
coding
everything
again,
what
is
hard
and
takes
a
lot
of
time.
The
positive
point
about
this
approach
is
that
you
spend
time
early
making
the
requirements
specifications
at
the
phase
one
and
defining
the
tasks
for
each
step,
so
you
save
time
and
effort
latter
in
the
process
since
everything
is
well
defined.
This
model
works
well
for
small
and
well-­‐defined
projects
with
defined
budget,
but
often
fails
in
bigger
ones
because
of
the
undefined
nature
of
them
it
is
harder
to
plan
each
step
and
define
the
requirements
before
starts.
Because
the
problems
to
implement
it
in
some
cases
there
was
introduced
various
modified
Waterfall
models
that
Steve
McConnell
called
the
Rapid
Development
models2
.
The
pure
approach
requires
a
lot
of
testing
and
documents
after
each
step
leading
you
to
come
back
after
every
step
to
the
requirements
specifications.
The
Rapid
Development
models
allowed
you
to
overlap
each
phase
and
create
subprojects
in
one
project.
But
the
use
of
it,
as
in
the
pure
Waterfall
approach,
is
recommended
just
when
you
have
your
problem
well
framed
and
still
needs
all
the
requirements
defined
before
starting.
Weakness:
As
every
model,
the
Waterfall
has
your
weakness.
It
is
not
recommended
to
use
in
some
cases
when
clients
do
not
know
exactly
what
they
want,
what
makes
hard
to
do
the
first
requirements.
Sometimes
needs
and
limitations
appear
during
the
implementation
or
test
phase,
so
the
requirements
must
change,
changing
the
design
and
the
next
phases
as
well.
Other
case
that
Waterfall
methodology
is
not
a
good
choose
is
when
the
team
that
creates
or
design
the
software
do
not
know
the

3. capabilities
of
the
technology
that
will
be
implemented.
That
can
cause
important
changes
during
the
implementation
phase
in
order
to
adapt
the
idea
to
the
existent
technology.
This
last
case
was
a
key
point
in
my
last
project
at
Hyper
Island.
We
design
an
application
for
Facebook
and
Pinterest,
and
because
we
didn’t
know
the
limitations
of
the
second
one,
we
had
a
significant
delayed
on
the
implementation
phase
of
our
application,
since
we
had
to
change
all
the
idea,
what
made
impossible
to
deliver
by
the
deadline
of
the
project.
The
Waterfall
methodology
is
very
rigid
so
it
is
not
recommended
also
when
the
problem
constant
changes,
needing
to
reframe
the
phase
one
and
redoing
all
the
work
done
before.
The
Agile
approach:
The
Agile
approach
is
very
different
from
the
traditional
model.
More
focus
on
the
customers
need,
it
is
based
on
the
principles
of
human
interaction
and
human
collaboration.
It
is
a
very
flexible
and
interactive
technique
normally
used
to
manage
the
design
and
build
of
new
products
or
services
in
technology,
creative
and
marketing
industries.
In
this
methodology
the
project
is
divided
in
small
tasks
that
will
be
executed,
as
it
will
be
demanded.
It
is
not
a
pre-­‐planned
process
as
the
Waterfall
approach.
Each
small
task
is
part
of
a
delivery
cycle,
called
iteration
that
contains
a
plan,
a
small
deliverable,
test
and
feedback.
Because
of
this
frequent
prototypes
done
after
each
execution,
this
methodology
is
the
most
consistent
in
project
management,
since
it
gets
inputs
from
customers
and
individuals
from
the
industry
every
iteration.
Figure
2:
Agile
Project
Management
Iteration
This
approach
is
better
used
for
projects
that
are
too
complex
to
understand
as
a
role,
so
you
divide
it
in
small-­‐scale
projects
or
elements
to
understand
better
what

4. you
have
to
do
and
gain
more
flexibility
to
change
things.
Since
you
have
smaller
tasks
to
achieve
(each
iteration),
this
methodology
is
more
dynamic
than
the
one
before,
enabling
the
user
to
refine
the
requirements
of
the
project
if
it
is
needed
without
loosing
much
time.
Because
of
this
dynamism,
the
Agile
approach
it
is
also
recommended
when
you
have
a
fast
moving
scenario,
unstable
situation
or
undefined
budget
or
final
product.
It
is
very
important
to
get
the
client
actively
involved
in
the
project
when
using
this
process,
so
you
can
develop
something
that
the
customers
wants
and
the
client
also,
but
it
demands
a
lot
of
time
of
the
client,
what
sometimes
is
hard.
Because
of
the
dynamism
of
this
methodology
and
the
constant
testing
with
the
customers,
the
end
product
can
be
very
different
from
the
one
that
was
planned
in
the
beginning.
It
is
very
important
during
this
process
to
up
date
the
team
and
the
client.
There
are
many
techniques
used
in
the
office
to
make
sure
that
everyone
is
updated,
the
Scrum
is
the
most
popular
one
in
creative
and
new
technologies
business.
The
Scrum:
The
Scrum
is
the
main
tool
used
at
the
Agile
project
management.
The
project
is
divided
in
sprints
–
2
to
4
weeks
phases
of
work
that
the
deliver
is
completed,
tested
and
documented.
The
sprints
should
be
planned
in
a
meeting
with
all
the
members
before
it
starts.
There
they
will
define
the
goal
and
assign
each
individual
responsibilities.
Everyday
there
will
be
a
15
minutes
meeting
to
report
the
progress,
discuss
what
will
be
done
today
and
what
is
needed
to
ensure
that
the
task
will
be
done.
Those
meeting
are
important
to
update
the
team
of
the
status
of
the
project
and
changes
that
occur.
Roles
of
the
team
members:
1-­‐
Product
owner:
the
expert
on
the
product
being
developed.
In
most
of
the
cases
is
the
direct
contact
between
the
client
and
the
company.
2-­‐
Scrum
master:
is
the
responsible
for
managing
the
process,
making
sure
that
everyone
is
updated
and
understanding
the
process.
This
person
is
also
responsible
to
reallocate
the
resources
and
help
everyone
complete
your
task.
Normally
is
the
project
manager
or
some
one
with
high
facilitation
skills.
3-­‐
Team:
the
people
working
on
the
project.
They
have
freedom
and
ownership
about
their
tasks
to
change
the
approach
when
needed.
When
the
sprint
is
over,
the
scrum
master
should
organize
a
retrospective
meeting
to
reflect
about
the
process
and
to
decide
what
need
to
be
improved
for
the
next
sprint.

5.
Figure
3:
Scrum
Other
tools
used
for
support
the
project
management:
As
the
Scrum,
there
are
several
tools
used
to
support
the
project
management
that
are
less
specific
for
the
approach
chose.
The
Scrum
is
very
specific
for
the
Agile
methodology,
but
there
are
other
tools
to
support
the
project
management.
The
importance
of
those
tools
is
to
keep
the
team
aligned
and
updated
about
every
step
of
the
process
and
help
the
project
manager
organize
the
scope,
time,
budget
and
quality.
There
are
several
softwares
that
help
that
process,
giving
tools
to
organize
the
tasks,
goals,
team,
emails,
finance
and
calendar,
as
Trello,
Lighhouse
and
Basecamp.
To
organize
the
testing
and
keep
track
of
bugs
when
you
are
developing
a
software
or
website,
there
are
programs
as
Jira
and
16bugs.
With
that
the
project
manager
has
a
historical
of
the
problems
and
how
it
was
solved.
It
is
important
to
document
every
step
of
the
process,
and
those
softwares
help
on
that.
For
meeting,
calls,
interviews
or
focus
groups
is
important
to
document
then
recording
and
writing
summaries
so
you
can
keep
track
of
the
evolution
of
the
project,
feedback
and
inputs.
To
share
those
documents
the
servidor
of
the
company,
Dropbox
or
Google
Drive
can
be
used
but
the
Google
Drive
is
more
efficient
since
you
can
see
the
changes
while
the
other
user
is
doing
it,
not
needed
to
update
every
change,
and
you
can
aces
remotely.
When
working
remotely,
to
communicate
between
the
members
of
the
team,
instant
messages
are
very
useful
because
speed
the
communication.
But
for
more
complicated
and
longer
topics
calls
and
emails
are
better.
Applications
as
Skype
and
Activecollab
enable
the
members
of
the
team
to
do
remotely
conferences
and
increase
the
collaboration
between
the
team.

6. Reflections:
From
my
previous
experience
in
workplace
and
Hyper
Island
it
is
very
hard
to
use
one
methodology
as
it
was
developed.
It
is
needed
to
make
arrangements
so
it
will
make
your
work
more
efficient.
During
Hyper
Island,
since
the
communication
with
the
client
was
limited,
the
Waterfall
approach
was
used
in
most
of
the
projects
since
the
problem
was
previous
framed
and
defined,
this
approach
was
more
efficient
to
define
the
tasks
for
each
member
of
the
group
and
it
was
reduced
in
just
the
first
four
steps.
Not
having
a
final
product
in
most
of
the
cases
made
easier
to
implement
this
methodology
since
there
was
no
testing,
so
was
rare
the
cases
that
we
had
to
came
back
to
the
first
phase
and
redefine
requirements,
goals
and
objectives.
It
was
just
needed
if
someone
from
the
group
pointed
some
problem
during
the
design
or
implementing
phase.
In
the
order
hand,
it
is
impossible
to
know,
besides
by
the
feedback
gave
from
the
industry
leaders,
if
our
solution
will
work
if
installed.
For
the
Run
a
Creative
Business
module
was
the
first
time
that
we
tried
to
implement
the
Agile
methodology.
Since
it
was
a
bigger
group
and
more
tasks
than
the
normal,
was
important
to
implement
a
methodology
that
allowed
us
to
keep
track
of
the
role
of
each
member
and
someone
to
facilitate
the
needs
of
the
team.
We
had
to
adapt
the
methodology
because
there
was
more
than
one
project
for
the
team,
and
we
had
to
do
smaller
sprints
since
we
had
just
4
weeks
to
do
the
project.
The
Scrum
meetings
were
essential
for
us,
being
the
only
time
that
the
entire
group
was
together,
so
we
could
up
date
everyone
and
manage
the
sources
to
make
sure
that
all
the
tasks
were
done
by
the
deadline.
The
meeting
with
all
members
took
a
long
time,
so
we
restructured
and
the
meetings
to
plan
the
sprint
were
done
just
with
one
member
of
each
project,
keeping
the
reflections
and
daily
meetings
with
everyone.
The
experience
in
the
last
module,
Showcase,
was
different.
We
decided
to
keep
the
Waterfall
methodology,
since
we
were
a
small
group
with
a
very
clear
goal
and
objective,
but
the
lack
of
knowledge
from
us
about
the
technology
that
we
wanted
to
develop
reflected
in
delays
in
our
project.
Because
since
the
beginning
for
all
of
us
was
very
important
to
delivery
something
done
and
tested
in
the
market,
we
had
to
change
our
idea
and
start
everything
again.
For
that,
we
decided
to
implement
the
Agile
methodology,
again
with
shorter
sprints,
so
every
member
of
the
team
would
have
a
clear
task
and
Scrum
meeting
were
done
everyday,
to
force
us
to
delivery
results
faster
than
in
the
other
approach.
In
that
case,
was
very
important
the
flexibility
gave
by
the
Agile
methodology
and
the
meeting
were
very
useful
to
update
and
reallocate
the
member
of
the
group.
In
the
end,
was
very
positive
the
change,
and
we
were
able
to
delivery
two
final
products.
I
believe
that
was
possible
because
when
you
have
clear
tasks
divided
you
create
an
ownership
for
that
task,
what
encourages
you
to
work
harder
to
see
the
final
product.
Conclusion:
The
two
main
keys
to
a
project
to
success
are
good
people
and
good
planning.
To
meet
all
the
goals
of
the
project
it
is
important
that
the
project
manager
keeps

7. everyone
that
is
working
motivated
and
interested
and
simultaneously
keeps
the
customer
satisfied.
Because
of
this
last
experience,
I
believe
that
when
planning
digital
projects
the
Agile
methodology
can
be
the
best
way
to
manage
your
project.
The
Scrum
meeting
are
very
useful
to
make
the
team
aligned
and
the
ownership
created
by
dividing
the
tasks
is
very
important
to
make
everyone
motivated.
The
only
occasion
that
I
fell
that
the
Waterfall
process
can
be
better
is
when
you
have
a
small
project,
with
the
problem
and
final
product
already
defined.
Using
the
Agile
in
that
case
can
make
the
team
waste
time
and
go
though
processes
that
is
not
needed.
But
it
is
rare
the
projects
that
have
everything
defined,
most
of
then
change
a
lot
during
the
time,
and
you
find
out
more
about
the
customer’s
needs
during
the
testing.
About
the
tools,
I
believe
that
the
Scrum
is
essential
when
using
the
Agile
methodology,
but
adaptations
should
be
done
depending
of
the
project,
company
or
people
involved.
A
place
to
store
the
data,
as
Google
Drive,
is
important
as
well,
but
other
tools
I
believe
that
you
should
test
and
see
if
the
team
adapts
to
then.
To
organize
the
tasks
of
the
project,
from
my
experience,
Trello
is
the
software
with
the
better
user
experience
and
more
intuitive
to
learn
how
to
use.

8. References:
Figure
1:
Mindtools.com.
2012.
Iron
Triangle
of
Project
Management
-­‐
PM
Tools
from
MindTools.com.
[online]
Available
at:
http://www.mindtools.com/pages/article/newPPM_54.htm
[Accessed:
20
Aug
2013].
Figure
2:
http://en.wikipedia.org/wiki/File:Agile_Project_Management_by_Planbox.png
Figure
3:
Anderson,
A.
2013.
Untitled
paper,
paper
presented
at
A
little
bit
about
agile
&
scrum,
Hyper
Island,
Manchester,
UK,
July,
4.
Other
references:
AgileConnection.
2013.
AgileConnection.
[online]
Available
at:
http://www.agileconnection.com/
[Accessed:
20
Aug
2013].
Anderson,
A.
2013.
Untitled
paper,
paper
presented
at
A
little
bit
about
agile
&
scrum,
Hyper
Island,
Manchester,
UK,
July,
4.
Articles.techrepublic.com.com.
n.d..
techrepublic.com.com.
[online]
Available
at:
http://articles.techrepublic.com.com/5100-­‐10878_11-­‐
6118423.html?part=rss&tag=feed&subj=tr
[Accessed:
20
Aug
2013].
Brown,
W.,
Mccormick,
H.
and
Thomas,
S.
2000.
AntiPatterns
in
project
management.
New
York:
Wiley.
Chapman,
C.
2008.
15
Useful
Project
Management
Tools
|
Smashing
Magazine.
[online]
Available
at:
http://www.smashingmagazine.com/2008/11/13/15-­‐useful-­‐project-­‐management-­‐tools/
[Accessed:
20
Aug
2013].
Cleland,
D.
and
Ireland,
L.
2006.
Project
management
:
strategic
design
and
implementation.
New
York:
McGraw-­‐Hill.
D.
BENINGTON,
H.
2011.
Production
of
Large
Computer
Programs.
p.
350–361.
Highsmith,
J.
2010.
Agile
project
management.
Upper
Saddle
River,
NJ:
Addison-­‐Wesley.
Macconnell,
S.
1996.
Rapid
development.
Redmon:
Microsoft
Press.
Mindtools.com.
2012.
Project
Management
Tools
from
MindTools.com.
[online]
Available
at:
http://www.mindtools.com/pages/main/newMN_PPM.htm
[Accessed:
20
Aug
2013].
Mindtools.com.
2012.
Iron
Triangle
of
Project
Management
-­
PM
Tools
from
MindTools.com.
[online]
Available
at:
http://www.mindtools.com/pages/article/newPPM_54.htm
[Accessed:
20
Aug
2013].
Mindtools.com.
2012.
Agile
Project
Management
-­
Project
Management
Tools
From
MindTools.com.
[online]
Available
at:
http://www.mindtools.com/pages/article/agile-­‐project-­‐management.htm
[Accessed:
20
Aug
2013].
Nokes,
S.
and
Kelly,
S.
2007.
The
definitive
guide
to
project
management.
Harlow:
Financial
Times
Prentice
Hall.
Scrumalliance.org.
2013.
Scrum
Alliance:
Transforming
the
World
of
Work
-­
Scrum
Alliance.
[online]
Available
at:
http://www.scrumalliance.org/
[Accessed:
20
Aug
2013].

9. Syque.com.
2002.
Project
Management.
[online]
Available
at:
http://www.syque.com/improvement/Project%20Management.htm
[Accessed:
20
Aug
2013].
Trello.com.
n.d..
Trello.
[online]
Available
at:
http://trello.com
[Accessed:
20
Aug
2013].
Wysocki,
R.
and
Mcgary,
R.
2003.
Effective
Project
Management.
New
York:
Wiley.