Innovation through Nonprofit Software Development

10:45-12:15

How have nonprofits developed and adapted software tools to meet their needs? This session will focus on discussing 3-6 case studies of nonprofit software initiatives which involve: single organizations and collaboration between organizations details on what worked and what didn't relating to technical staff and managing limited or extensive levels of participation elements of open source and closed source projects and how nonprofits addressed gaps between their skills and managing technology projects. Suggestions on future practices will also be offered.

Takeaways

-some good stories of pitfalls and ways to avoid them
-advantages and disadvantages of various approaches

Panelists: Sara Schnadt Office of Cultural Planning at Department of Cultural Affairs,  Phil Klein www.penpixel.com , Katrin Verclas on FOSS solutions.

Format:

* Intro/goals -- 5 min 10:45-10:50
*  who's here... npo
* Polls/audience interaction - 10 min 10:50-11:00

         have you done a software project
         experience -- good, bad, ugly, mixed
         points of pain
         innovated?  if not why not?

(maybe we can do a spectrogram)

Sessions: 15 min each 
-Sara Schnadt --til 11:15
-Phil Klein --til 11:30
-Katrin Verclas --til 11:45

* discussion/Q&A 30 mins 11:45-12:15

Phil’s 15 minutes:

It all comes down to working wisely, working with the right other people and organizations, in good and viable ways, and working well together -- in a few words, good project management and collaboration.

• Distribute cost, risk, participation and benefits as widely as possible.

• Run your software on the web to open your organization & world to others.

• If your building only for your single organization; the costs will seem high and real benefits hard to gain—get over the myth of your absolute uniqueness (when it comes to your software needs) and get the benefits of tools build for 2 or more, or a network of organizations like yours.

• If you do Build for your org exclusively, share results and code with others.

• Build collaboratively with other orgs, and share the benefits

• Build tools that enable the work of others to benefit your org or project.

• Use tools built by others in new ways to benefit your org & reach your goals.

• Build your tools to be useful in ways you can’t predict -- design to open up, not close off, user possibilities (and possible users). 

Beware! There are lots of disincentives to collaborate – it’s a minefield. NPODevelopers, NPOSandbox, Social Source, some attempts to get funders to consider how projects could yield benefits beyond a narrow scope, are all examples of failed efforts at collaboration.  

Some common problems with Collaboration

• inadequate incentives for participation by all key participants

• the added cost and energy need to communicate between organizations can be high.

• lack of trust or resources can keep project goals out of reach.  

• risk of designing for an abstracted or generalized user rather than for real users that you know

• ownership poorly defined can detract from accountability and make ongoing support challenging.

Models for collaboration on software tools

Partnerships between organizations

• establish partnerships between organizations & participants

• compare project goals

• identify shared vision

• build trust and strong communication channels, shared ground rules

• identify & allocate resources 

• coordinate timeline

• define and set project roles and responsibilities, and ownership terms clearly

• agree on your exit strategies

Involve Volunteers in your project

• Use a funded project manager who knows how to manage software projects, and who delegates tasks to paid and/or volunteer project team members.

• This can be done in an open source manner or not.

• Select tasks for volunteers that match their ability and commitment

• Package the tasks (as small as possible) to make participation most feasible.

• Volunteers can do much work, but can have limits to their expertise, ability to do complex or extensive work, and are usually less reliable that paid project participants.

•  See Johnathan Peizer's papers, especially http://www2.soros.org/internet/ideology.htm  http://www2.soros.org/internet/ 

Open Source projects

• Use some combination of the following (more is better as these components enhance the benefit of each other) open source project management tools

• a code repository

• recruit a development team. Choose a development leader

• Make sure that user input is thoroughly included, and that project management include non-technical issues as well as technical issues. 

• Make sure you address your user interface needs carefully

• Research any existing projects you want to build upon carefully.

• Good suggestions at: http://www.omidyar.net/group/issues-tech/news/7/ 
  from Zach Rosen: snip: 

Case Studies 

Suggestions:

• Explore your project vision thoroughly before beginning work
  • Dream wildly and be inventive (across boundaries and beyond past history. Envision your tools beyond the scope of your project; abstract to a higher level. Set aside time for this and don’t jump straight to building what you think you need – muddle it over first. Encourage questioning. Don’t look only within your organization, but consider who could contribute and where valuable nexus may be.)
• Do your research (verify stability and viability of technology, seek out similar  projects or visions, and build connections with people using and working on the technologies now. Study other thinkers and dreamers – Knowledge Management, Communities of Practice, Sustainable Innovation, Network centric thinking all have good books that discuss ideas that can transform how work is envisioned. See Movement as Network by Gideon Rosenblatt, read Valdis Krebs' Papers http://www.orgnet.com , and for advocacy projects read Mary Kearns.)
• Have rigorous standards for viability, sustainability and maintainability, and meet them. Estimate targets for each of these. (Good business sense rocks).
• For larger projects, consider doing a pilot first. Include a few go/no-go points in the project so you can cut losses if you have to.) 
• Open your processes (to stakeholders, peer organizations, and users. Provide opportunities and use tools that let people participate as they meet their own needs too. Use open source licensing and tools when it makes sense. Packetize opportunities to participate appropriately.) Get on appropriate email lists such as http://npogroups.org/lists/info/riders-tech  NPO Techies, www.nten.org , find more links at http://mist146.drizzle.com/bookmarknpotools.htm 
• Share your work when it makes sense, and involve the smartest people you can find, wherever they are.
• Honestly consider how unique your project needs and users are -- if they are truly unique, design to address these unique needs. 
• Manage projects with diligence (using a sound and appropriately flexible project management philosophy. See http://www.stevemcconnell.com/sg.htm and http://www.extremeprogramming.org/ .)
• Emphasize and speak openly about the risks and potential benefits of the project.
• Keep a risks list, weekly. Sample .