View source for WestCoast2008:The MoveOn Process for Translating Technology Visions to Reality

Like many organizations, MoveOn needs to translate the technology needs and desires expressed by their staff in the field into practical and implementable designs for software and websites.  MoveOn project manager Tanya Africa will talk through their process and lead a discussion about techniques and tips to understand and document technology needs so all involved can participate in the process.

Notetaker: Tanya

05/20/08<br>


'''Assumptions:'''

* Volunteer-based
* Grassroots

Start with a concept<br>
Look at what has been effective<br>
* Studies 
* Stories
* Historically


'''Nail down the plan first'''
* What is your output?
* How do you want the campaign to work
* Before you do specs/coding

'''Outline'''
* One sentence about each of the features you want in the tool
* Enables you to go to your programmers to get feedback (yes/no/need more specs)

'''Plan'''
* What should the tool be able to do/what should users be able to do with the tool?
* Timeline
* Budget
* Prioritizing functions, enforce discipline from the organizing side
   * Everything that is a priority one pushes down another priority
   * No features are free; each great feature means you don’t get something else
   * This is one of the hardest things to do, to get people to understand trade-offs

'''Specifications'''

   * Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.)

'''Test and test and test again'''

* Don't roll something out that hasn’t gone through several iterations of testing
* Programmers are good to ask in terms of where it’s likely to fail
   * Sometimes these things can’t be predicted; there will always be bugs
   * Lots of different testing groups means coming across lots of different use scenarios

'''Other issues'''

* Paranoia team
   * Think of how people might try to misuse the tool
   * Security issues
   * What needs to be protected (privacy issues, etc.)
* Define policies ahead of time, think through how people might misuse the tools

'''How to manage these projects remotely?'''

* Collaboration can be difficult remotely
* Define what your collaborators are comfortable with (tech-wise) and then tailor your use of tools to help fit that, and plan for training on those tools<br>
*Create a paper trail for every stage of the process<br>
*Have a bucket/list for ideas you can’t use (Tanya calls it “Tier 6”)<br>