This was a presentation I gave about the issues around RFP's and website creation for the Wellington egov barcamp

1. RFP vs. Website
A Love Story for the NZ egov barcamp

2. Attraction
• RFPs must represent interests of gov’t
• Websites must represent interests of...
government

3. Attraction
• RFPs must represent interests of gov’t
• Websites must represent interests of...
government
• Both sides want the same thing really bad
so what’s the issue?

4. Lust
• Government wants the best site it can get:
slick, feature-full, broad browser support,
etc.
• A web shop wants to deliver the best site
it can: slick, feature-full, broad browser
support, etc.

5. Courtship
• RFP’s are issued, vendors breathlessly
respond.
• “We can do that, no problem.”
• “It’s just a simple <insert feature here>.”
• The right questions are not being asked:
• how to prioritize? what user experience
are you aiming for?

6. Marriage
• The deal is signed and the relationship, um,
consummated.
• Now the fun begins...

7. Conflict
• What’s the most common source of
conflict in any loving relationship?

8. Conflict
• Breakdown of Communication:
• features not clearly elaborated (this does
not imply “create a thick spec doc”)
• misunderstandings based on inaccurate
perceptions
• commitments (drivers on both sides) not
understood
• wild-ass-umptions

9. Conflict Resolution
(Cover Your Ass)
• Try to place blame
• Work really long hours and possibly
succeed while definitely shortening your
lifespan

10. Dissolution or
Resentment
• Worst case things go really wrong and the
project dissolves, creating animosity all
around
• Next-worst case you struggle through,
resenting the other side while on Death
March to the finish line
• Better case: Both sides have conflicts but
communicate well and work through them

11. Good Divorce
• Eventually, some kind of finish line is
crossed and both sides go their separate
ways, usually.
• Ideally you want to be in a good place at
this point
• Only way to be in a good place is by
communicating well
• But how?

12. What went wrong?
• RFP not addressing fundamental needs
• Need to have accountability is in conflict
with how websites need to be developed
• Desire to over-specify on next project
• This is the intuitive response, and the
wrong one

13. How do other people
do it?
• Websites are software
• Example: US DoD MilStd 2167-A
• Dangerous trend toward the above
• How to avoid?

14. Answer: Agile
Techniques
• There is no Holy Grail
• Agile is better than other approaches
• risk management
• expectation management
• How to reconcile Agile with government
needs?

15. Tweak Government
• Government expectations rooted in
outdated needs and goals (from a software
perspective)
• A lot of what we’re talking about today is
how to get government to recognize it’s
2007
• So...?

16. Specifics (for both sides)
• Show the intent of what you’re trying to
achieve. Give usage scenarios.
• Ask questions.
• Provide examples of desired (or
mandatory) functionality.
• Say what’s out of scope.
• Recognize conflict. Allow for room to
resolve during the project.

17. Bend like a reed
• Both sides need to be flexible (and still
firm) to achieve a good outcome
• Frequent communication is critical
• Use tech to help communicate
• Skype, wiki, email
• Agree to intent and high-level only
• Finally...

18. Have fun
• Order icanhascheezburger shirts for the
team

19. Thank you
• Brian Calhoun
• brian@silverstripe.com
• 021 506 844