Difference between revisions of "The MoveOn Process for Translating Technology Visions to Reality"
Jump to navigation
Jump to search
m (1 revision imported) |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
* Grassroots | * Grassroots | ||
| − | + | ||
| − | Look at what has been effective | + | '''START WITH A CONCEPT''' |
| + | |||
| + | '''Look at what has been effective''' | ||
| + | |||
* Studies | * Studies | ||
* Stories | * Stories | ||
* Historically | * Historically | ||
| − | + | ||
| − | Nail down the plan first | + | '''Nail down the plan first''' |
| + | |||
* What is your output? | * What is your output? | ||
* How do you want the campaign to work | * How do you want the campaign to work | ||
* Before you do specs/coding | * Before you do specs/coding | ||
| − | Outline | + | '''Outline''' |
| + | |||
* One sentence about each of the features you want in the tool | * 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) | * Enables you to go to your programmers to get feedback (yes/no/need more specs) | ||
| − | Plan | + | |
| + | '''Plan''' | ||
| + | |||
* What should the tool be able to do/what should users be able to do with the tool? | * What should the tool be able to do/what should users be able to do with the tool? | ||
* Timeline | * Timeline | ||
| Line 33: | Line 40: | ||
* Specifications | * Specifications | ||
* Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.) | * Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.) | ||
| − | Test and test and test again | + | |
| + | '''Test and test and test again''' | ||
| + | |||
* Don’t roll something out that hasn’t gone through several iterations of testing | * 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 | * Programmers are good to ask in terms of where it’s likely to fail | ||
| Line 39: | Line 48: | ||
* Lots of different testing groups means coming across lots of different use scenarios | * Lots of different testing groups means coming across lots of different use scenarios | ||
| − | Other issues | + | '''Other issues''' |
| + | |||
* Paranoia team | * Paranoia team | ||
* Think of how people might try to misuse the tool | * Think of how people might try to misuse the tool | ||
| Line 47: | Line 57: | ||
<br> | <br> | ||
| − | How to manage these projects remotely? | + | '''How to manage these projects remotely?''' |
| + | |||
* Collaboration can be difficult 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 | + | * 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 |
| − | + | *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> | |
| − | 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> | ||
Latest revision as of 19:52, 15 January 2016
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
Assumptions:
- Volunteer-based
- Grassroots
START WITH A CONCEPT
Look at what has been effective
- 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
- Create a paper trail for every stage of the process
- Have a bucket/list for ideas you can’t use (Tanya calls it “Tier 6”)