RFP vs. Website: A Love Story


Published on

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

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

RFP vs. Website: A Love Story

  1. 1. RFP vs. Website A Love Story for the NZ egov barcamp
  2. 2. Attraction • RFPs must represent interests of gov’t • Websites must represent interests of... government
  3. 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. 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. 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. 6. Marriage • The deal is signed and the relationship, um, consummated. • Now the fun begins...
  7. 7. Conflict • What’s the most common source of conflict in any loving relationship?
  8. 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. 9. Conflict Resolution (Cover Your Ass) • Try to place blame • Work really long hours and possibly succeed while definitely shortening your lifespan
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. Have fun • Order icanhascheezburger shirts for the team
  19. 19. Thank you • Brian Calhoun • brian@silverstripe.com • 021 506 844