The document discusses several key challenges and considerations for projects, including: 1. Estimating timelines is difficult as the future is uncertain and many factors can impact schedules. Adding people to a late project can actually make it take longer due to coordination challenges. 2. Thorough documentation is important for defining objectives, specifications, timelines, budgets, and other key project details. Paper documentation is still valuable even for digital projects. 3. Testing and fixing errors is a major part of projects that is often overlooked. Simply restoring from backups should not be considered a normal way to address bugs. 4. Projects are rarely truly "finished" as enhancements, additions and ongoing fixes are usually needed after launch

1. Answer:
“Do I have to!”

2. Let’s consider this as an analogy

3. How long will it take?
Let’s consider this as an analogy

4. How long will it take?
How much will it cost?
Let’s consider this as an analogy

5. How long will it take?
How much will it cost?
Let’s consider this as an analogy

6. How long will it take?
How much will it cost?
Let’s consider this as an analogy
They have (inextricably) much in common

7. Well known sayings:

8. Well known sayings:
A project is where 90% of the planned time gets
blown on producing the specs

9. Well known sayings:
A project gets to be 90% complete and stays there
A project is where 90% of the planned time gets
blown on producing the specs

10. A common problem = timelines and time estimates

11. A common problem = timelines and time estimates
How long is a piece of string?
Answer:

12. A common problem = timelines and time estimates
How long is a piece of string?
Answer:
- it depends!

13. A common problem = timelines and time estimates
The future = a cone of uncertainty
How long is a piece of string?
Answer:
- it depends!
Future
2013

14. Excuse the misnomer

15. Excuse the misnomer
There are other costs

16. Excuse the misnomer
• Staff costs Staffcosts
There are other costs

17. Excuse the misnomer
• Staff costs
• Equipment
Staffcosts
There are other costs

18. Excuse the misnomer
• Staff costs
• Equipment
• Facilities
Staffcosts
There are other costs

19. Excuse the misnomer
• Staff costs
• Equipment
• Facilities
• Opportunity costs
Staffcosts
Opportunity costs
There are other costs

24. Hardware

25. Install
Hardware

26. Install
System
changes
Hardware

27. Install
System
changes
Op & other
systems
Hardware

28. Install
System
changes
Op & other
systems
Hardware
Testing

29. Install
Prep
System
changes
Op & other
systems
Hardware
Testing

30. Install
Prep
Train
System
changes
Op & other
systems
Hardware
Testing

31. Install
Prep
Train
System
changes
Op & other
systems
Hardware
Testing
Documentation

32. Install
Prep
Train
System
changes
Op & other
systems
Hardware
Testing
Documentation
It’s a bit crowded
here

35. 1. Start

36. 2. Next level
1. Start

37. 2. Next level
3. Repeat
1. Start

38. 2. Next level
3. Repeat
1. Start
4. Next level

39. 2. Next level
3. Repeat
1. Start
4. Next level
5. Repeat

40. 2. Next level
3. Repeat
1. Start
4. Next level
5. Repeat
n. Etcetera

42. Mature >> Been around for a bit
– means initial bugs are fixed?
- Service packs?

43. Mature >> Been around for a bit
– means initial bugs are fixed?
- Service packs?
Immature >> Unproven
– means initial bugs are not fixed?
- Service packs?

44. What can go wrong?

45. What can go wrong?
Murphy

46. What can go wrong?
Murphy
• is alive and well

47. What can go wrong?
Murphy
• is alive and well
• living in your project

48. What can go wrong?
Murphy
• is alive and well
• living in your project
• funded by your budget

49. Pregnancy?

50. Pregnancy?
The pregnancy myth:

51. Pregnancy?
The pregnancy myth:
If it takes 1 woman to produce 1 baby in 9
months

52. Pregnancy?
The pregnancy myth:
If it takes 1 woman to produce 1 baby in 9
months
How may women will it take to produce a
baby in 1 month

53. Pregnancy?
The pregnancy myth:
If it takes 1 woman to produce 1 baby in 9
months
How may women will it take to produce a
baby in 1 month
Hint: The answer is not = 9

54. Add more people = lengthen time

55. Add more people = lengthen time
Effort of coordination (see Airbus 380 & Boeing 787)
Number of Lines of communication increases effort

56. Add more people = lengthen time
Effort of coordination (see Airbus 380 & Boeing 787)
Number of Lines of communication increases effort
Formula: (n is # workers)
Lines of communication = n(n-1)/2

57. Add more people = lengthen time
Effort of coordination (see Airbus 380 & Boeing 787)
Number of Lines of communication increases effort
3 workers require 3 x as much pairwise
communication as 2: 3(3-1)/2 = 3
Formula: (n is # workers)
Lines of communication = n(n-1)/2
1 2
3

58. Add more people = lengthen time
Effort of coordination (see Airbus 380 & Boeing 787)
Number of Lines of communication increases effort
3 workers require 3 x as much pairwise
communication as 2: 3(3-1)/2 = 3
Formula: (n is # workers)
Lines of communication = n(n-1)/2
4 workers require 6 x as much pairwise
communication as 2 4(4-1)/2 = 6
1 2
3
1 2
3 4

59. Brooks Laws -

60. Brooks Laws -
Adding manpower to a late software project
makes it later

61. Brooks Laws -
Adding manpower to a late software project
makes it later
Difference in productivity between a high and
low performer is an order of magnitude

62. Brooks Laws -
Adding manpower to a late software project
makes it later
Difference in productivity between a high and
low performer is an order of magnitude
No correlation between years of experience
and performance

63. Consequences -
What does the system allow you to omit
and what are the adverse consequences?

64. Consequences -
What does the system allow you to omit
and what are the adverse consequences?
If adverse consequences could be foreseen
they would be avoided in the 1st place

65. How to correct errors
When developing software, correction of errors has to
be considered. This is often left out.
It’s not can go wrong
Its something goes wrong, how can it be fixed
what
when

66. How to correct errors
When developing software, correction of errors has to
be considered. This is often left out.
It’s not can go wrong
Its something goes wrong, how can it be fixed
what
when
Most famous last words: I’ve just fixed the last bug

67. Correcting errors

68. Correcting errors
Restoring from backup
- should not be considered an acceptable
‘normal’ procedure

69. Correcting errors
Restoring from backup
- should not be considered an acceptable
‘normal’ procedure
Bug fixes:
- the number of fixes means NOTHING

70. Weaknesses in the procedures?
When developing software:
- the new system should include internal
controls
- designed to facilitate checking and
reconciliations
Examples:
subledger balances
external accounts

71. Adding people to the project?

72. Adding people to the project?
The Hit-the-ground-running myth

73. Adding people to the project?
A management technique that does not work!
The Hit-the-ground-running myth

74. Multi-tasking

75. Multi-tasking
Another myth!

76. Multi-tasking
Another myth!
Focus on the project
– concentration
– that is what works!

77. Documentation (for users)
– you have to seed - it does not yet exist
– is an integral part of development
– Counter argument = Microsoft ‘help’ files are no
longer very good (they rely on the iNet)
– is it any good? – customers (this means your users)
want/need it

78. Beware Paperless ! ! !

79. Beware Paperless ! ! !
Dangers of paperless

80. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:

81. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:
 Objectives & Policies

82. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:
 Objectives & Policies
 Specifications / Define the product

83. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:
 Objectives & Policies
 Specifications / Define the product
 Schedule / Timeline

84. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:
 Objectives & Policies
 Specifications / Define the product
 Schedule / Timeline
 Budget / Cash flow projection / Forecast

85. Beware Paperless ! ! !
Dangers of paperless
Without paper to help a project you still need:
 Objectives & Policies
 Specifications / Define the product
 Schedule / Timeline
 Budget / Cash flow projection / Forecast
 Org chart

86. Decisions

87. Decisions
Meetings decide -

88. Decisions
Meetings decide -
Records of decisions are needed:

89. Decisions
Meetings decide -
Records of decisions are needed:
 What

90. Decisions
Meetings decide -
Records of decisions are needed:
 What
 When

91. Decisions
Meetings decide -
Records of decisions are needed:
 What
 When
 How

92. Decisions
Meetings decide -
Records of decisions are needed:
 What
 When
 How
 Where

93. Decisions
Meetings decide -
Records of decisions are needed:
 What
 When
 How
 Where
 Why

94. Why document (may be electronically)
Writing down encourages:

95. Why document (may be electronically)
Writing down encourages:
 Expression Frame  Structure  Complete

96. Why document (may be electronically)
Writing down encourages:
 Expression
 Clarity Policy
 Frame  Structure  Complete

97. Why document (may be electronically)
Writing down encourages:
 Expression
 Clarity
 Motivate  Communicate
 Policy
 Frame  Structure  Complete

98. Why document (may be electronically)
Writing down encourages:
 Expression
 Clarity
 Motivate
 Coordinate
 Communicate
 Policy
 Frame  Structure  Complete

99. Why document (may be electronically)
Writing down encourages:
 Expression
 Clarity
 Motivate
 Coordinate
 Direct Review  Control
 Communicate
 Policy
 Frame  Structure  Complete

100. Ask:

101. – is it an integral part of development
– when will a project be effectively complete?
– Note: you don’t get a warranty
Ask:

102. – is it an integral part of development
– when will a project be effectively complete?
– Note: you don’t get a warranty
PS - you also have to fix your own bugs
Ask:

104. Typically 40% of cost is incurred after RTM

105. Typically 40% of cost is incurred after RTM
New bugs are discovered as users ‘push’ the
boundaries of the product

106. Typically 40% of cost is incurred after RTM
Every ‘fix’ is an opportunity for a new bug
New bugs are discovered as users ‘push’ the
boundaries of the product

107. Typically 40% of cost is incurred after RTM
Every ‘fix’ is an opportunity for a new bug
New bugs are discovered as users ‘push’ the
boundaries of the product
Bug fixes are typically not performed by the
development team

108. Typically 40% of cost is incurred after RTM
Every ‘fix’ is an opportunity for a new bug
New bugs are discovered as users ‘push’ the
boundaries of the product
Bug fixes are typically not performed by the
development team
Bug fix testing is not usually comprehensive

109. Enhancements and Add-ons

110. Enhancements and Add-ons
Are we
finished
yet?
– is an ongoing process

111. Enhancements and Add-ons
Are we
finished
yet?
– is an ongoing process
– when is a project complete >> decision EG RTM

112. Enhancements and Add-ons
– After RTM >>
service packs, bug fixes and revisions
Are we
finished
yet?
– is an ongoing process
– when is a project complete >> decision EG RTM

113. Redesign becomes necessary – when?

114. Redesign becomes necessary
– worn out as a basis for progress
– out-of-date architecture needs a restart
– more features = more opportunities for bugs

115. Redesign becomes necessary
New technology = new opportunity for excellence
– worn out as a basis for progress
– out-of-date architecture needs a restart
– more features = more opportunities for bugs

116. Redesign becomes necessary
New technology = new opportunity for excellence
– worn out as a basis for progress
– out-of-date architecture needs a restart
– more features = more opportunities for bugs
You can only exploit the life-cycle for so long then
you need to start over

117. Redesign becomes necessary
New technology = new opportunity for excellence
– worn out as a basis for progress
– out-of-date architecture needs a restart
– more features = more opportunities for bugs
You can end up with a 1 size fits all but fits no one
eg Tablets, Laptops and PDAs
You can only exploit the life-cycle for so long then
you need to start over

118. C. S. Lewis – the key to history
“The idea is excellent,
energy brings success,
then some fatal flaw comes to the top
and things start to go wrong
and breaks down”
“Then is the time for a redesign & restart”

119. Building vs Maintaining
Building reduces disorder (entropy)
Maintaining increases disorder (entropy)
entropy >> disorder
metastable >> dependent on stable conditions
A system is only metastable – it will survive only
as long as the context or environment

120. All systems have a life span

121. All systems have a life span
Engine type Water, Oil, Electric

122. All systems have a life span
Engine type
War type Vietnam, Iraq
Water, Oil, Electric

123. All systems have a life span
Engine type
War type
Books Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

124. All systems have a life span
Engine type
War type
Books
Travel methods Road, Rail, Plane, Rocket
Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

125. All systems have a life span
Engine type
War type
Books
Travel methods
Education methods Schools, Books, Internet
Road, Rail, Plane, Rocket
Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

126. All systems have a life span
Engine type
War type
Books
Travel methods
Education methods
Growing food Farming, Manufacture
Schools, Books, Internet
Road, Rail, Plane, Rocket
Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

127. All systems have a life span
Engine type
War type
Books
Travel methods
Education methods
Growing food
Medical methods Pills, Robotic surgery
Farming, Manufacture
Schools, Books, Internet
Road, Rail, Plane, Rocket
Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

128. All systems have a life span
Engine type
War type
Books
Travel methods
Education methods
Growing food
Medical methods
Entertainment Movies, DVD, VHS
Pills, Robotic surgery
Farming, Manufacture
Schools, Books, Internet
Road, Rail, Plane, Rocket
Paper, Electronic
Vietnam, Iraq
Water, Oil, Electric

129. Environment (PETS)

130. Environment (PETS)
Political
China needs to change its politics

131. Environment (PETS)
Political
Economic
China needs to change its politics
The economy brings opportunity for reverse mortgages

132. Environment (PETS)
Political
Economic
Technical
China needs to change its politics
Apple, PC, PDA, Cellphones
The economy brings opportunity for reverse mortgages

133. Environment (PETS)
Political
Economic
Technical
Social
Social progress means Women CPAs
China needs to change its politics
Apple, PC, PDA, Cellphones
The economy brings opportunity for reverse mortgages

134. Environment (PETS)
Political
Economic
Technical
Social
Social progress means Women CPAs
You cannot change these
– you have to adapt
– or die!
China needs to change its politics
Apple, PC, PDA, Cellphones
The economy brings opportunity for reverse mortgages

135. Environment (PETS)
Political
Economic
Technical
Social
Social progress means Women CPAs
You cannot change these
– you have to adapt
– or die!
Are you old enough to
remember
when a 45 was not a gun?
China needs to change its politics
Apple, PC, PDA, Cellphones
The economy brings opportunity for reverse mortgages

136. In sync with other systems
Note: ETL is a new buzzword for Extract, Transform, Load &
is a formal name for synch’ing data (+ loading)
The law of unexpected
consequences
Remember the
law of
unexpected
consequences
Expect the
unexpected
The law of unexpected
consequences
Get
real
Be careful what
you wish for
– Some caveats >>

137. Complexity
Reference:
Evolution of a programming systems product - Alan Brooks
Complexity tends to
increase by the
‘square’ of the
increase

138. Complexity
Reference: Evolution of a programmingsystems product-Alan Brooks
Complexity tends to increase by the
‘square’ of the increase # layers
Double
Double again
= now quadrupled
The law of
unexpected
consequence
s
One Task
The law of
unexpected
consequence
s
Task
The law of
unexpected
consequence
s
Task
The law of
unexpected
consequence
s
One Task
The law of
unexpected
consequence
s
One Task
The law of
unexpected
consequence
s
One Task
The law of
unexpected
consequence
s
Task

139. Dangers + Significance
of potential errors

140. Dangers + Significance
of potential errors
– what have I got to lose?

141. Dangers + Significance
of potential errors
– so what?
– what have I got to lose?

142. Dangers + Significance
of potential errors
– so what?
– what have I got to lose?

143. Expertise required (resources)

144. Expertise required (resources)
– stick to the middle of the road

145. Expertise required (resources)
– pioneers live in tents
– stick to the middle of the road

146. Expertise required (resources)
– continuity - how easy is it to change
– pioneers live in tents
– stick to the middle of the road

147. Expertise required (resources)
– availability
– continuity - how easy is it to change
– pioneers live in tents
– stick to the middle of the road

148. Statistics of success
Although there is no ‘normal statistic, the % of
project failure is very big

149. Statistics of success
Although there is no ‘normal statistic, the % of
project failure is very big
Example: Paper entitled
“101 Common Cause of Project Failure”

150. Statistics of success
Although there is no ‘normal statistic, the % of
project failure is very big
Example: Paper entitled
“101 Common Cause of Project Failure”

151. Examples of Failed Projects (1)
Boeing 787
Reason:
Budget:
Time:

152. Examples of Failed Projects (1)
Boeing 787
3 years late
Reason:
Budget:
Time:

153. Examples of Failed Projects (1)
Boeing 787
3 years late
Reason:
Budget:
Time:
$12b ---> $18b

154. Examples of Failed Projects (1)
Boeing 787
3 years late
Reason:
Budget:
Time:
$12b ---> $18b
Complexity due to Outsourcing

155. Examples of Failed Projects (1)
Boeing 787
3 years late
Reason:
Budget:
Time:
$12b ---> $18b
Complexity due to Outsourcing

156. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:

157. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
2 years late

158. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
2 years late
$6b over

159. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
1. 16 design centers
2 years late
$6b over

160. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
1. 16 design centers
2. CAD drawings resulted in short cables (3”)
2 years late
$6b over

161. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
1. 16 design centers
3. German vs French management
2. CAD drawings resulted in short cables (3”)
2 years late
$6b over

162. Examples of Failed Projects (2)
Time:
Airbus 380
Budget:
Reason for Failure:
1. 16 design centers
3. German vs French management
2. CAD drawings resulted in short cables (3”)
2 years late
$6b over

163. Examples of Failed Projects (3)
California State Payroll System

164. Examples of Failed Projects (3)
California State Payroll System
Budget = $250million

165. Examples of Failed Projects (3)
California State Payroll System
Budget = $250million
Project abandoned Feb 2013

166. Examples of Failed Projects (3)
California State Payroll System
Budget = $250million
Project abandoned Feb 2013
Reason for Failure = Don’t know (FUBAR?)

167. Examples of Failed Projects (4)
Project started 2005
Reasons for Failure =
US Airforce: Oracle:
ECSS (US Airforce Oracle ERP system)
Budget =

168. Examples of Failed Projects (4)
Project started 2005
Reasons for Failure =
US Airforce: Oracle:
ECSS (US Airforce Oracle ERP system)
Abandoned Nov 2012
Budget =

169. Examples of Failed Projects (4)
Project started 2005
Reasons for Failure =
US Airforce: Oracle:
ECSS (US Airforce Oracle ERP system)
Don’t know but $1b spent
Abandoned Nov 2012
Budget =

170. Examples of Failed Projects (4)
Project started 2005
Reasons for Failure =
US Airforce: Oracle:
 Lack of: Planning
 Acquisition Strategy
 Infrastructure
ECSS (US Airforce Oracle ERP system)
Don’t know but $1b spent
Abandoned Nov 2012
Budget =

171. Examples of Failed Projects (4)
Project started 2005
Reasons for Failure =
US Airforce: Oracle:
 Lack of: Planning
 Acquisition Strategy
 Infrastructure
 Over 2000 design flaws
 below requirements
ECSS (US Airforce Oracle ERP system)
Don’t know but $1b spent
Abandoned Nov 2012
Budget =

172. Strategy for success
Some things to consider

173. Strategy for success
 Be realistic

174. Strategy for success
 Be realistic – use common sense

175. Strategy for success
 Be realistic
 Define and Set achievable goals, milestones, measure and
assess progress
– use common sense

176. Strategy for success
 Be realistic
 Define and Set achievable goals, milestones, measure and
assess progress – make it happen!
– use common sense

177. Strategy for success
 Be realistic
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress – make it happen!
– use common sense

178. Strategy for success
 Be realistic
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– make it happen!
– use common sense

179. Strategy for success
 Be realistic
 Structure your effort
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– make it happen!
– use common sense

180. Strategy for success
 Be realistic
 Structure your effort
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– beware the complex!
– make it happen!
– use common sense

181. Strategy for success
 Don’t bite off more than you can chew or you will choke
 Be realistic
 Structure your effort
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– beware the complex!
– make it happen!
– use common sense

182. Strategy for success
 Don’t bite off more than you can chew or you will choke
 Be realistic
 Structure your effort
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– beware the complex!
– make it happen!
– use common sense
– low hanging fruit first

183. Strategy for success
 Don’t bite off more than you can chew or you will choke
 Be realistic
 Structure your effort
 Plan, Motivate, Coordinate, Control
 Define and Set achievable goals, milestones, measure and
assess progress
- John Wayne was NOT a manager
– beware the complex!
– make it happen!
– use common sense
– low hanging fruit first
– divide and conquer

184. Questions?

185. So - on to some humor?

186. So - on to some humor?
Is it comedy or tradgedy?

187. Fun-rules of Project management

188. Fun-rules of Project management
 Nothing is impossible – for the person who doesn’t have to do it

189. Fun-rules of Project management
 Nothing is impossible – for the person who doesn’t have to do it
 A problem shared is the buck passed

190. Fun-rules of Project management
 Nothing is impossible – for the person who doesn’t have to do it
 The bitterness of poor quality outlasts
the sweetness of meeting the deadline
 A problem shared is the buck passed

191. Fun-rules of Project management
 Nothing is impossible – for the person who doesn’t have to do it
 There are no good project managers – only lucky ones
 The bitterness of poor quality outlasts
the sweetness of meeting the deadline
 A problem shared is the buck passed

192. Fun-rules of Project management
 Everyone requests a strong leader
– when they get one they don’t want him
 Nothing is impossible – for the person who doesn’t have to do it
 There are no good project managers – only lucky ones
 The bitterness of poor quality outlasts
the sweetness of meeting the deadline
 A problem shared is the buck passed

193. Fun-rules of Project management
 Everyone requests a strong leader
– when they get one they don’t want him
 Nothing is impossible – for the person who doesn’t have to do it
 There are no good project managers – only lucky ones
 The bitterness of poor quality outlasts
the sweetness of meeting the deadline
 A problem shared is the buck passed
 Projects would not started if
the truth had been told about time and cost

194. Fun-rules of Project management (2)
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected

195. Fun-rules of Project management (2)
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 If nothing can possible go wrong – it will

196. Fun-rules of Project management (2)
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 Future dates on a calendar are closer then they appear to be
 If nothing can possible go wrong – it will

197. Fun-rules of Project management (2)
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 Activity is not achievement
 Future dates on a calendar are closer then they appear to be
 If nothing can possible go wrong – it will

198. Fun-rules of Project management (2)
 The person who says it will take the longest and cost the most is the
only one who knows what he is talking about but he will not be chosen
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 Activity is not achievement
 Future dates on a calendar are closer then they appear to be
 If nothing can possible go wrong – it will

199. Fun-rules of Project management (2)
 The person who says it will take the longest and cost the most is the
only one who knows what he is talking about but he will not be chosen
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 Activity is not achievement
 Future dates on a calendar are closer then they appear to be
 If nothing can possible go wrong – it will
 The best thing about not planning is that failure comes as a surprise

200. Fun-rules of Project management (2)
 The person who says it will take the longest and cost the most is the
only one who knows what he is talking about but he will not be chosen
 Bad planning, project time = 3x expected
Good planning, project time = 2x expected
 Activity is not achievement
 Future dates on a calendar are closer then they appear to be
 If nothing can possible go wrong – it will
 The best thing about not planning is that failure comes as a surprise
 If project scope is allowed to change – the rate of change will
exceed the rate of progress

201. 7 phases of a Project

202. 7 phases of a Project
1. Enthusiasm

203. 7 phases of a Project
1. Enthusiasm
2. Disillusionment

204. 7 phases of a Project
1. Enthusiasm
3. Confusion
2. Disillusionment

205. 7 phases of a Project
4. Panic
1. Enthusiasm
3. Confusion
2. Disillusionment

206. 7 phases of a Project
4. Panic
1. Enthusiasm
3. Confusion
2. Disillusionment
5. Search for the guilty

207. 7 phases of a Project
4. Panic
1. Enthusiasm
3. Confusion
2. Disillusionment
6. Punish the innocent
5. Search for the guilty

208. 7 phases of a Project
4. Panic
1. Enthusiasm
3. Confusion
2. Disillusionment
6. Punish the innocent
5. Search for the guilty
7. Promote the non-participants

209. Last ( I promise)
– here is an old favorite

210. Views of a Project
1. How the Customer explained it

211. Views of a Project
2. How the Project Manager
understood it

212. Views of a Project
3. How the Analyst designed it

213. Views of a Project
4. How the Customer explained it

214. Views of a Project
5. How the Consultant described it

215. Views of a Project
6. The documentation

216. Views of a Project
7. How operations installed it

217. Views of a Project
8. How it was billed

218. Views of a Project
9. How it was supported

219. Views of a Project
10. What they wanted

220. CliffB
Marketing Pitch
So if you have a project and would like to
speak with me
Call (949) 813-1349 or
cliffbeacham@Hotmail.com