RFP vs. WebsiteA Love Story for the NZ egov barcamp

Attraction

• RFPs must represent interests of gov’t

• Websites must represent interests of... government

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?

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.

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?

Marriage

• The deal is signed and the relationship, um, consummated.

• Now the fun begins...

Conflict

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

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

Conflict Resolution (Cover Your Ass)

• Try to place blame

• Work really long hours and possibly succeed while definitely shortening your lifespan

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

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?

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

How do other people do it?

• Websites are software

• Example: US DoD MilStd 2167-A

• Dangerous trend toward the above

• How to avoid?

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?

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...?

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.

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...

Have fun

• Order icanhascheezburger shirts for the team

Thank you

• Brian Calhoun

• brian@silverstripe.com

• 021 506 844