This document provides 101 tips for getting the website you need while saving time and money. Some key tips include having clearly defined objectives focused on business goals and ROI, being open to vendor ideas, prioritizing quickly, and demanding accountability and demos from vendors. It also discusses using agile principles like valuing working software over documentation and responding quickly to changes. The overall message is to plan effectively, communicate constantly with vendors, and focus on business needs and outcomes above all else.

1. This has been agile 101
101 puppies and 101
other working titles

2. 101 Exciting Tips To
Get The Site You Need
While Saving Time And
Money
(And Get That Promotion You
Deserve In The Process)

3. Which is pretty much
the nonsense title
(or the hook)

4. I am

5. Andre Molnar

6. Drupal

7. Drupal
8.5 Years
(Has it really been that long? It really has)

8. Web Application
Developer

9. Web Application
Developer
13(ish) Years

10. First Web Page
1994

11. First Web Page
1994
18 Years Ago

12. 18

13. 18+13

14. 18+13+8

15. 18+13+8=101
years of experience

16. Freelancer

18. Currently at

20. They’re Pretty Cool

21. They’re Pretty Cool
A lot of talks here this year by smart myplanet folks!

22. Plug

23. Get Paid to Learn
Drupal
Myplanet Academy (see MPD table in the main room)

26. I’m talking from my
own experience

27. Tip #1

28. Always come to work
each day prepared to
be fired

29. Don’t *try* to get fired

30. Be willing to do things
differently

31. We’ll come back to
that

32. Getting the website
you need

33. Different from the
website you want

34. Answer this question

35. Answer this question
Over and over and over again

36. Why?

37. Why
are you building this site?

38. Why
do you want that feature?

39. Why
do you want it to be exactly the way you specified it?

40. What is the business
reason?

41. Good Reasons:

42. Good Reasons:
Increase sales

43. Good Reasons:
Comply with the law (e.g. accessibility)

44. Good Reasons:
Improve conversion of visitors to customers

45. Good Reasons:
Create awareness around “product X”

46. Good Reasons:
others?

47. Bad reasons:

48. Bad reasons:
ummm... I don’t know

49. Bad reasons:
we want to go viral

50. Bad reasons:
our competition has it we want it too

51. Bad reasons:
Drupal is supposed to solve all our problems

52. Drupal MIGHT solve
some of your problems

53. But you need to know
in detail which ones

54. More good reasons:

55. More good reasons:
Its too painful for our staff to use what we have

56. More good reasons:
Employee satisfaction

57. More good reasons:
Rebranding

58. More good reasons:
Rebranding (assuming there was a good reason
for that)

59. There are far too many
projects where the
reason or purpose is
far too vague

60. For each and every
feature answer this:

61. Which will provide the
highest ROI

62. Return on Investment

63. For every dollar we
spend

64. For every dollar we
spend
(Because your vendor doesn’t work for free)

65. how will the
functionality it buys get
us closer to achieving
our business goals?

66. If you can’t answer
these questions your
project is doomed

67. How many of your have
issued RFPs?

68. Responded to them?

69. Request for Proposal

70. Do:

71. Do:
Have your objectives clearly defined.

72. Do:
Be completely honest

73. Do:
Be completely transparent

74. Do:
Ask tough questions of potential vendors

75. Do:
Ask for examples of work

76. Do:
Ask questions about process

77. Do:
Ask questions about staff

78. Do:
Ask for references

79. Don’t

80. Don’t
treat it as a request for quote

81. Don’t
treat it as a request for quote
(if it is, issue a request for quotes)

82. Don’t
throw in every feature you ever imagined

83. Do
your homework

84. Do
find out if your vendor is capable of doing things

85. Do
find out if your vendor is capable of doing things
(even if you never ask them to do them)

86. Because you already
know all your ‘whys’
right?

87. You asked for a
proposal, right?

88. Accept proposals

89. Accept proposals
Be open to ideas

90. Don’t
use your RFP as a requirements document that is set in
stone

91. Accept that you don’t
have all the answers

92. Accept that you don’t
have all the answers
(yet)

93. Pick a project or
product owner

94. If you are that owner
see tip #1

95. And all the other tips

96. Give them the
authority

97. Give them the
authority
To make decisions

98. Give them the
authority
To provide answers

99. Give them the
resources (time)

100. Give them the
resources (time)
To work with your vendor

101. Give them the
resources (time)
To be available

102. Support them

103. Support them
By getting them answers they don’t have

104. Support them
By getting them resources they request (data, source
material etc.)

105. Maybe its more than
one person

106. BUT NEVER

107. EVER

108. Have a committee

109. They are too slow

110. Time is quite literally
money in web
development

111. Be Agile

112. Agility matters

113. I’m not necessarily
talking about Agile
Software Development
Methodology

114. Be quick

115. Adapt to change

116. Reprioritize on the fly

117. If a resource is delayed

118. have the next highest
priority item ready
to go

119. Be aware of Agile
Software Development

120. Educate yourself

121. Many of your vendors
will claim to be Agile

122. Know what it means

123. If you choose an Agile
vendor

124. Be prepared for the
process

125. NEWS FLASH

126. NEWS FLASH
That’s what I’ve been doing

127. NEWS FLASH
Preparing you for Agile vendors

128. But these tips are just
as valid for waterfall

129. Or other processes

130. But lets talk about Agile
for a moment

131. Agile Manifesto

132. ...we have come to
value:
Individuals and interactions over processes and tools

133. Don’t do anything for
the sake of sticking to
process

134. Don’t avoid things
because they don’t fit
your process

135. Your vendors/clients
are people too. Talk to
them.

136. ...we have come to
value:
Working software over comprehensive documentation

137. For you this is a ROI
question. documentation
How much value does comprehensive
give you?

138. Compare that to a
working website

139. ...we have come to
value:
Customer collaboration over contract negotiation

140. Work with your
vendor/client

141. Communicate

142. Communicate ALL THE
TIME

143. CYA, but only as much
as necessary

144. ...we have come to
value:
Responding to change, over following a plan

145. Not everything goes to
plan

146. Priorities change

147. Opportunities arise

148. Higher ROI items
present themselves

149. Be prepared to pivot
quickly

150. Other Random Tips

151. MoSCoW

152. Must Haves
Should Haves

153. Could Haves
Won’t Haves

154. Have good reasons

155. Be ready willing and
able to defend those
choices to your boss

156. and to demand them
from your vendor

157. Demand accountability

158. Demand demos

159. Regularly

160. See the progress

161. Don’t sweat it if design
is not pixel perfect in
demos

162. Don’t sweat it if design
is not pixel perfect in
demos like)
(I can tell you why if you

163. DO demand that
software defects are
fixed if present in demo

164. DO demand pixel
perfection for launch

165. Provide feedback often

166. Provide constructive
feedback often

167. Know the difference
between a defect

168. and something that isn’t
quite how you imagined
it

169. A defect is something
that doesn’t work

170. or does not meet the
required objective

171. or does not meet the
required objective
(you know, the ‘why the thing was being done in the
first place’)

172. If it works, and meets
the objective

173. but could be better...

174. Consider the ROI
before asking for the
change

175. Questions?

176. Horror Stories?

177. Oh wait...

178. Puppies

179. Inspirational Music

188. Thank You

189. This has been agile 101
101 puppies and 101
other working titles