the little book of
ProjectMethodologies
2.
Why read this book?You know there are a lot of different ways to do projects and you want
to know more about them
You’ve always done projects one way but now everyone seems to
be changing things around
You’re a master of waterfall, agile and lean and looking for a simple tool to explain them to your team
Welcometo our little book on the big subject ofProjectMethodologies
4.
1. What is a project methodology? 8
2. An introduction to waterfall 24
3. An introduction to agile 40
4. The best of the rest! 60
5. Mixing and matching 86
6. Choosing the right methodology 108
7. Glossary 126
8. Useful resources 130
9. About NineFeetTall 134
Contents
6.
Be stubborn about your goals…
...�and�flexible� about your methods.
Anon
8.
What is a project methodology?1 C
lose
Monitor Initiate
Plan
Execute
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
10.
What is a methodology?A system of broad principles�or�rules...�
businessdictionary.com
...from�which�specific�methods�or�procedures�may�be�derived�to�interpret�or�solve�different�problems�within�the�scope�of�a�particular�discipline.�
It�is�not�a�formula�but� a�set�of�practices.
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
12.
What is project management?
Project management is the application of processes, methods, knowledge, skills and experience to achieve project objectives.
Association for Project Management
A project is a unique, transient endeavor, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes, or benefits.
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
14.
Why use a project management methodology?
A good methodology…
1. Provides direction
2. Saves time
3. Increases productivity
4. Improves quality
5. Generates efficiencies
6. Delivers consistent results
7. Clarifies expectations
8. Encourages continuous improvement
9. Increases chances of success
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
16.
If you can’t describe what you are doing as a process,
W. Edwards Deming
you don’t know what you’re doing.
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
18.
The project management methodology used by a large organisation is typically defined by the business’s project management office or PMO.
In smaller organisations, individual project managers may work to their own preferred methodology or select the most appropriate approach to every new project.
Where possible, applying a consistent methodology to all projects usually delivers most benefits.
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
20.
What does a methodology include? These tools provide the know-how
to manage the project:
» Documentation
» Business involvement
» Communication
» Risk and issue management
» Change control
» Reporting
» Team management
» Project lifecycle
» Team structure
» Samples
» Templates
» Instructions
» Process workflows
» Aids
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
22.
Remember… A project team also needs to be equipped with knowledge, skills, resources, experience, leadership, and a healthy dose of common sense.
A methodology alone will not deliver projects or
guarantee success.
24.
An introduction to waterfall2
2. A
n in
trodu
ctio
n to
wat
erfa
ll
26
The waterfall methodology originates from the construction industry in the 1970s, where structured, physical environments made late changes prohibitively expensive.
Because of this, it’s a methodology geared toward minimising changes to requirements.
Waterfall methodology
2. A
n in
trodu
ctio
n to
wat
erfa
ll
28
Waterfall methodology is driven by the delivery of a plan.
It works on the basis that requirements defined by the business are fixed.
A project is able to flex resources and time available in order to deliver these requirements.
Requirements
Resources Time
2. A
n in
trodu
ctio
n to
wat
erfa
ll
30
FIRST, have a definite, clear practical ideal; a goal, an objective. THIRD, adjust
all your means to that end.
Aristotle
SECOND, have the necessary means to achieve your ends; wisdom, money, materials, and methods.
2. A
n in
trodu
ctio
n to
wat
erfa
ll
32
The fundamentals Solutions are developed in a sequential
process: scope, plan, launch, monitor, close.
» Formal review and approval is required to proceed from one stage to the next.
» All requirements are determined upfront and remain unchanged.
» Extensive documentation is created for each and every stage.
» Business involvement is limited to requirements definition and testing.
» Tasks are assigned to team members by the project manager.
2. A
n in
trodu
ctio
n to
wat
erfa
ll
34
The waterfall lifecycleEvolve an
idea into a vision, scope and benefits aligned with the business strategy.
Create plan and work packages, and secure budget and resources.
Define detailed requirements, design a solution, build, test, train the business and deploy.
Monitor over time to measure benefits and embed change.
Conduct lessons learnt and handover to BAU.
SCOPE
PLAN
LAUNCH
MONITOR
CLOSE
2. A
n in
trodu
ctio
n to
wat
erfa
ll
36
Why do waterfall?
…is simple to understand and use
… ensure regular quality and business case reviews
… focus the team on clear goals and ways of working
… optimises system architecture and business process
… aids knowledge transfer for large or geographically dispersed teams
» A clear and rigid lifecycle structure…
» Stage-by-stage checkpoints…
» Specific deliverables and formal processes…
» Requirements analysis and design of full solution upfront…
» Accurate and thorough documentation…
2. A
n in
trodu
ctio
n to
wat
erfa
ll
38
As long as information is retained in someone’s head, it is vulnerable to loss.
If�it�is�not�documented,� it�doesn’t�exist…�
Louis Fried
40.
An introduction to agile3
3. A
n in
trodu
ctio
n to
agi
le
42.
Agile manifestoThe foundations of agile are based on a manifesto produced in 2001.
A group of bright minds got together and considered what they felt could make projects more successful.
» Individuals and interactions over processes and tools
» Working software over comprehensive documentation
» Responding to change over following a plan
» Customer collaboration over contract negotiation
They adopted a new set of values:
3. A
n in
trodu
ctio
n to
agi
le
44.
Agile is a methodology driven by delivering value to the customer.
It works on the basis that the resources and time available to the business are fixed.
Within these limitations, a project aims to deliver as many of the prioritised features as possible.
Features
ResourcesTime
3. A
n in
trodu
ctio
n to
agi
le
46.
Think about it…
Would a business rather have…
100% of features, 80% complete?
Or…
80% of features, 100% complete?
3. A
n in
trodu
ctio
n to
agi
le
48.
Agile is underpinned by 12 principles:1. Customer satisfaction – by rapid
delivery of useful software
2. Changing requirements – always welcomed, even late in development
3. Frequent delivery – of working software
4. Daily cooperation – between business people and developers
5. Motivated individuals – trusted to progress the project
6. Face-to-face conversation – is the best form of communication with co-located teams
7. Clear progress measurement – in terms of working software
8. Sustainable development – able to maintain a constant pace
9. Technical excellence – and good design continuously strived towards
10. Simplicity – to reduce waste and maximise the amount of work not done
11. Self-organizing teams – for generating the best quality outputs
12. Regular reflection and adaptation – to become more effective
3. A
n in
trodu
ctio
n to
agi
le
50.
Pareto and the 80/20 ruleA man named Pareto first made this observation of uneven distribution, seen throughout the natural world.
Agile favours the idea that…
…delivery of the most important 20% of new product features usually delivers around 80% of the benefits.
Did you know…
» 20% of the global population control 80% of its wealth
» 20% of a company’s products generate 80% of its income
» 20% of software bugs generate 80% of software failures
3. A
n in
trodu
ctio
n to
agi
le
52.
So what’s new?Agile Traditional
Management
Facilitates and ensures collaboration
Directs work and issues tasks
Features
Facilitates and ensures collaboration
Requirements fixed up front
Planning
Developers plan detail
Project manager plans detail
Agile Traditional
Changes
Add changes to features backlog
Pass requests through change control process
Lifecycle
Iterations, phases and releases
Sequential stages lead to go live
Reporting
Iterations, phases and releases
Record activities completed against Gantt chart
3. A
n in
trodu
ctio
n to
agi
le
54.
The agile lifecycle
Pre-Project Phase
FeasibilityConfirm business case, outline possible approaches and define project team, timescale and costs.
FoundationsGather high level requirements and outline business, management and solution foundations.
ExplorationIteratively and incrementally explore business requirements and demo models and prototypes to business.
EngineeringEvolve preliminary solutions iteratively into fully functional business solutions.
DeploymentBring the product release into use and close the project after the final release.
Repe
at fo
r eac
h re
lease
1
2
3
4
5
3. A
n in
trodu
ctio
n to
agi
le
56.
Why do agile?… combat the ‘don’t know what they
want’ problem
… builds acceptance of final products and ensures fit to business needs
… delivers a simple, quality product more quickly and removes upfront overheads
…empowers and motivates developers
… are easy for everyone to communicate
and understand
» Prototypes, demos and flexible requirements...
» Continuous business collaboration…
» The iterative approach…
» Self-organisation and customer interaction…
» Simple progress measures…
3. A
n in
trodu
ctio
n to
agi
le
58.
We don’t need an accurate document.
Jeff Patton
We need a shared understanding.
60.
The best of the rest!4
4. T
he b
est o
f the
rest
!
62.
The restWaterfall and agile are the champions of methodology, but there are lots of other contenders and conspirators too.
Some hone in on specific methodology components – lifecycle, team interactions or development – or represent a specific core value.
Lets take a whistle stop tour through…
» DSDM
» Scrum
» Extreme Programming
» Lean Development
» Spiral
» Critical Chain
4. T
he b
est o
f the
rest
!
64.
Dynamic Systems Development ModelDSDM is the most fully defined agile framework – a project lifecycle, team management approach and development methodology neatly wrapped into one package.
It is guided by similar principles to agile…
» focus on business need
» deliver on time
» collaborate
» never compromise on quality
» build incrementally
» develop iteratively
» communicate continuously
» demonstrate control
…and follows an iterative and incremental lifecycle, just like agile.
4. T
he b
est o
f the
rest
!
66.
Technique Spotlight:
What?Breaking up time into short periods during which a team works towards a goal.
How?Requirements of different priorities are assigned to a timebox for investigation and development. Low priority requirements act as contingency because they can be dropped if necessary to protect a deadline.
Why?Timeboxing focusses a team on specific short-term objectives and values delivery on time, every time.
Timeboxing
4. T
he b
est o
f the
rest
!
68.
Nothing is particularly hard if you divide it into small jobs.
Henry Ford
4. T
he b
est o
f the
rest
!
70.
ScrumThis is an iterative, incremental framework focused on cross-functional teams, a bit like rugby teams.
It embraces agile values and an experiential learning cycle:
Rules of the game
» A prioritised product backlog is the full list of requirements.
» A sprint is an agreed amount of time to complete some work (e.g. two weeks).
» A scrum team skims the top layer from the backlog to create a sprint backlog.
» The team holds a daily scrum or meeting to assess progress.
» The team delivers the features in the sprint backlog by the end of the sprint.
» The team reviews the sprint and begins the next.
Plan
Execute
Conclude
Review
4. T
he b
est o
f the
rest
!
72.
FEED
BACK
Extreme Programming (XP)A software development methodology that prizes customer satisfaction, aiming to deliver simple solutions as they are needed.
XP uses the timeboxing technique to break down work into small parts. A self-organising development team select tasks to each work on.
XP is all about continuously receiving feedback and responding to it quickly.
Pair programming, unit testing and daily stand up meetings act as particularly immediate feedback loops.
Release plan
Code
FEEDBACK
FEEDBACK
FEEDBACK
FEEDBACK
FEEDBACK
FEEDBACK
Iteration plan
Acceptance test
Stand up meeting
Pair negotiation
Unit test
Pair programming
4. T
he b
est o
f the
rest
!
74.
...is like measuring aircraft building progress by weight.
Measuring programming progress by lines of code...
Bill Gates
4. T
he b
est o
f the
rest
!
76.
Lean Software DevelopmentLean methodology was born out of Toyota manufacturing plants in Japan.It is all about eliminating waste.
The basics of lean philosophy are…
1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole
What does project waste look like?
Waste is anything that does not create value for the customer.
» Unnecessary code and functionality
» Time delays
» Unclear requirements
» Insufficient testing
» Bureaucracy
» Slow communications
4. T
he b
est o
f the
rest
!
78.
Technique Spotlight:
Kanban
Kanban is a technique for visualizing the software production line.
Use sticky notes to make a Kanban board that shows what different resources are working on.
Can you see the bottleneck in this Kanban board? If so, you can add resources to increase the flow of production.
Analyse Develop Test
4. T
he b
est o
f the
rest
!
80.
SpiralThe spiral methodology is a lifecycle framework for incremental software development.
It places emphasis on understanding and eliminating risks.
A project kicks off with the first spiral, and each spiral represents an iteration.
Planning
Evaluation
Risk Analysis
Engineering
1 2
34
gather requirements
evaluate with business
test solution
write code
identify solution risks
build prototypes
4. T
he b
est o
f the
rest
!
82.
Critical chainThis approach is about acknowledging and addressing the fact that project resources are only human.
It argues 30% of lost time on projects is typically due to wasteful behaviours:
» poor multitasking
» student syndrome (procrastinating)
» lack of prioritisation
Critical chain plans tasks with ambitious time estimates, and with no contingency.
It collects the would-be contingency for each task into a buffer zone at the end of the project, or stages of the project.
Traditional project plan:Task Task TaskBuffer Buffer Buffer
Critical chain project plan:Task Task Task Buffer
A lack of slack drives people to complete and hand off tasks as soon as possible, like a relay race… no multitasking, no procrastinating, no prioritising!
4. T
he b
est o
f the
rest
!
84.
Don’t let the want for perfection become procrastination. Every masterpiece that’s ever been done, it could have been better.
Danielle LaPorte
Just�launch�and learn.
86.
Mixing and matching5
88. 5. M
ixin
g an
d m
atch
ing
Many organisations choose to define their own methodology tailored to their business, rather than just take one off the shelf.
This way they can combine the best bits of different methodologies and reject the bits that don’t work for them.
There are huge benefits to creating a methodology that is ‘just right’, so it’s an activity worth investing in.
Did you know…NASA defines its own project management methodologies and continuously looks for new ideas in the field that could increase its success in space.
In 2003 it even set up the Center for Project Management Research to build learnings into its methodologies.
90. 5. M
ixin
g an
d m
atch
ing
Warning! Mixing and matching is not without its dangers:
» can strain interactions between teams using different methods
» can create confusion over deadlines, deliverables and expectations
» can exclude the use of project management software
» can generate manual project information management work
» can be difficult to report consistent or conventional metrics to senior stakeholders.
92. 5. M
ixin
g an
d m
atch
ing
But keep breaking traditions, I beg you.
Create your own method. Don’t depend slavishly on mine. Make up something that will work for you!
Constantin Stanislavski
94. 5. M
ixin
g an
d m
atch
ing
So what are the options?Where�to�begin!
The possibilities really are endless, and this is only a little book, so here’s the low down on some popular pick-and-mixes.
96. 5. M
ixin
g an
d m
atch
ing
Agile + waterfallAlthough agile and waterfall are always fundamentally different and sometimes actually polar opposites, mixing them isn’t necessarily a definite no-go.
Taking the strongest components of both methodologies can resolve common problems experienced on projects, for example…
ProblemUsing agile for large solutions risks overlooking the design of system architecture, data and user experience at the outset and creates a messy landscape later on.
SolutionApplying some of the structure of waterfall can clarify the architecture upfront, while the agile approach to development gives the benefit of rapid business feedback and early feature delivery.
98. 5. M
ixin
g an
d m
atch
ing
In a recent survey of 150 agile adopters, 54% said they were using waterfall methods as well.
Applications developed with a combination of agile and waterfall methods scored higher on robustness,�security� and�changeability than those developed using agile alone, 75% of the time.
Forrester Research
25% 75%
Agile Agile + Waterfall
100. 5. M
ixin
g an
d m
atch
ing
Waterfall + leanThe ‘just-in-time’ philosophy of lean and the ‘plan and control’ foundations of waterfall might not initially strike you as candidates for a long and happy marriage.
But what if one’s strengths could cover the other’s weakness spots?
ProblemDifferent resource types feel the heat at different stages of the project – e.g. scope, design, build… which can create bottlenecks and delays.
SolutionUse a Kanban to track workflows within each stage to understand how resource shifts could speed up that sign off. If business analyst resource is under pressure, ask what the development team could do to help.
102. 5. M
ixin
g an
d m
atch
ing
Thomas A. Edison
— we’re trying to accomplish something.
Hell, there are no rules here
104. 5. M
ixin
g an
d m
atch
ing
Agile + XPXP and agile aren’t so different, both believing in the value of iterative development and rapid feedback.
ProblemXP methodology builds in multiple feedback loops to developers, to make sure the solution is of the highest quality for the customer. But why not try to get it right first time?
SolutionWrite requirements as user stories described from the customer’s perspective, to empower developers with an understanding of why features are needed so they can build the best solution.
106. 5. M
ixin
g an
d m
atch
ing
Waterfall + scrumScrum focusses on people and interactions.
Waterfall focusses on process and documentation.
Combining elements of the two can be a great and easy-to-implement way to make your project an all-rounder.
ProblemPeople are great communicators but unreliable. Documents are reliable but poor communicators.
SolutionMaintain formal project documents to manage project and solution knowledge and hold a daily scrum (15 minute stand up meeting) among key stakeholders focussed on the here and now:
» What did they do yesterday? » What will they do today? » What is impeding their
progress?
108.
Choosing the right methodology
6
110 6. C
hoos
ing
the
right
met
hodo
logy
So�you’re�all� clued�up�on� methodologies�now… …�but�what’s�the�
right�choice�for� your�organisation?
112
There are a variety of factors to consider… Resource skills
Project management maturity
Culture
Organisational structure
Business sector
Project type
6. C
hoos
ing
the
right
met
hodo
logy
114
But�even�once� you’ve�accounted� for�the�characteristics�of�your�organisation… …�don’t�underestimate�
the�benefits�to�be�achieved�by�choosing�the�right�approach�for�each�individual�project.
6. C
hoos
ing
the
right
met
hodo
logy
116
When does agile suit my project?
In projects involving…
Software development New product development
Vague requirements at outset Frequent requirements changes
A short timeline (< 1 year)
Gradually enhanced features able to be used by the business
A small team able to communicate face-to-face
6. C
hoos
ing
the
right
met
hodo
logy
118
When should I avoid using agile?
Typically not best-suited in cases of…
Construction development Systems infrastructure change
Clear requirements at outset Requirements unlikely to change
A long timeline (> 1 year)
The business able to use only the final end product
A large or departmentalised team facing a communications burden.
6. C
hoos
ing
the
right
met
hodo
logy
120
Colin Powell
The situation dictates which approach best accomplishes the team’s mission.
Fit no stereotypes. Don’t chase the latest management fads.
6. C
hoos
ing
the
right
met
hodo
logy
122
And, what about waterfall?
An immature project management function can follow a simple plan
Clear and fixed requirements with no ambiguity
Resources likely to change and necessitate knowledge transfer
A well-established core solution and implementation expertise
Business resource only able to offer limited time
A mature project management function can apply flexibility to deliver more efficiently
Unclear requirements at the outset
Consistent resources committed for the full lifecycle
A creative, exploratory or industry-first solution
Business resource available for active involvement and input
6. C
hoos
ing
the
right
met
hodo
logy
124
So, what’s�the�most popular methodology�in�the�business?
A blended method (incorporating some waterfall and some agile) is the most frequently chosen across all types of businesses, with:
43% saying it’s the right choice for them.
Hammond J (2010)
6. C
hoos
ing
the
right
met
hodo
logy
126.
Glossary7
128. 7. G
loss
ary
GlossaryPRODUCT OWNERA business representative responsible for communicating the business vision and for defining and prioritizing the project backlog
SPRINTA term used in scrum methodology to describe a time box of usually up to 30 days during which certain backlog items will be developed
STAGE GATEA review and decision point in a project lifecycle triggered by time or completion of a set of tasks, which marks the end of one stage and the beginning of another
BURNDOWN CHARTA type of line graph that illustrates a project schedule by plotting work left to do on the vertical axis and time on the horizontal
GANTT CHARTA type of bar chart that illustrates a project schedule by plotting start dates and finish dates of individual tasks
SCRUM MASTERA facilitator for a project team, responsible for guiding the team to agreements, removing obstacles, and protecting the team from distractions – but NOT responsible for outcomes achieved or decisions made
130.
8Useful resources
132. 8. U
sefu
l res
ourc
es
Useful resourcesWEBSITES
» www.ninefeettall.com
BOOKS
» Carroll J (2012) Agile Project Management In Easy Steps, In Easy Steps Ltd
» Davis B (2012) Agile Practices For Waterfall Projects, J Ross Publishing
» Newton R (2007) Project Management Step By Step, Pearson Busine
BLOGS
» www.ninefeettall.com/blog
» https://www.apm.org.uk/blog
BEST PRACTICE
» PRINCE2 www.apmg-international.com/en/qualifications/prince2/prince2.aspx
» Agile PM www.apmg-international.com/en/qualifications/agile-pm/agile-pm.aspx
134.
About9
136.
About
are experts in business transformation
with proven experience of delivering
complex change projects across
multiple industries and sectors.
Each member of the team has a broad range of skills and
knowledge brought together with a conviction and energy to deliver
measurable results for our clients.
9. A
bout
Nin
eFee
tTal
l
1. W
hat i
s a
proj
ect m
etho
dolo
gy?
138.
Contact usWe hope you have enjoyed our little book on this big subject.
If you would like to discuss your project management requirements, please get in touch:
CALL 01225 904 630
EMAIL [email protected]
WEB www.ninefeettall.com
Don’t forget we have other books in the series. Get in touch to receive your copy!
140.www.ninefeettall.com
Top Related