Notes from Rebecca below on managing nonprofit technology projects

http://aspirationtech.org/events/mntp-sf http://mntp.aspirationtech.org/index.php/Event_Agenda

…maybe I’ll clean this up someday.

—- !!!Basic Stages of a Project

  1. Initiate * define project * talk about start and end points, budget, participants/roles, timeline
  2. Plan * defining scope, requirements, use cases

  3. Implement

  4. Monitor

  5. Close *how do you know when you’re done with the project you’re working on?

*upkeep/maintenance phase?

*in “waterfall” style projects, there is just one of each step *in “agile” style projects, the plan -> implement -> monitor cycle repeats *know which style project it is at the beginning!

!!!Content inventories For redesign processes, figure out what content and navigation is currently present and how it’s organized. Include things like creation dates and web statistics; talk about the value of old content to users. This can affect how much of the content is migrated, and can give organizations insight into how they intend to communicate vs. how they’re actually communicating. For example, one PM working on the ACLU site inventoried 15,000 pages; the ACLU decided to migrate 8,000 of those, and rethought their style of technical & legal language to a more personal approach.

!!!Scope Creep *postpone things to phase 2 *define project endpoints in the “initiate” phase *specifications that include what ‘‘won’t’’ be included *review scope and recently developed features regularly *revisit goals to regain focus as scope creep starts to take over *saying no: make sure that people are aware of the depth of their requests, especially if they’re out of scope. inform people about research or dev time required just to estimate cost for a feature.

!!!Recognizing Impending Doom *chunking projects: dividing projects into smaller chunks will make overages more obvious. *development time = developer + QA + PM + client + risk + padding. *define checkin points in the web plan *be upfront/honest/immediate when you’re feeling uncomfortable *be proactive about input–consider what input people will have before you ask them for it *one attendee mentioned that they “had been trying to stay with this FOSS community which was politically important, but they were making incredibly bad engineering decisions” and they eventually had to break with the FOSS group. *beware of working with volunteers who aren’t web professionals *notice the point where transparency starts to drop

!!!Client Panic *lack of communication: presenting a product that the client hasn’t seen before and they aren’t happy *role changes on either the client or dev side can trigger less dialouge *when you’re behind, don’t just work harder: restructure dev roles, reopen lines of communication with client *sign of panic: abusive emails. one dev mentioned having a “2 strike rule” for abusive communication; he immediately calls higher-ups re: lack of tolerance for abusive/blame email/interaction *learn how to identify ‘‘good’’ things about a client relationship

’'’recovery stragegy’’’: regaining trust is remotely is difficult. Highly structured communication can help; for example, frequent meeting at consistent times with a repeated agenda.

#highly structured communication #revisit goals #talk to other members of the client org #re-structure the project #fire the client

!!!Turning a Project into a Product *forces you into more standardization *documentation becomes exponentially more important *languages & international users: translators can be your most active outside contributors

!!!Other *build test cases alongside app development *involve real-life people–external stakeholders–in the process *make sure there is someone within the nonprofit who can maintain the solution *can you narrow your website’s focus? working with the client to focus the project; can be used to reduce the feature set and budget, AND/OR to clarify the client’s communication strategy. *get clients to take notes at meetings and send them to you so that you know what they’re taking away/expecting *discussions about “which tools?” can obscure discussions of needs *blog or message board for a project: for both issues and for cheerleading *“the smallest organizations need the most hand-holding” —- EOF