Request Management System for World Food Programme

History:

• 29 January 2300 UTC - Edgardo Yu of WFP responds e-mail of Sahana chair Brent Woodworth - requesting Sahana to provide simple request management system to help manage requests for food aid and distribution for the health cluster.
• 30 January 0030 UTC - Brent Woodworth responds that Sahana response would require funding/support and are eager to discuss
• 30 January 1600 UTC - Edgardo Yu of WFP requests cell number so he can call Brent
• 30 January 2100 UTC - Edgardo Yu repeats request and asked to be called
• 30 January 2115 UTC - Mark Prutsalis and Edgardo Yu briefly discuss requirements by phone - still need to bring Brent into conversation to sort out funding vehicle.
  

Requirements: excerpts from e-mails and discussion with WFP

• WFP manages the Food Cluster of the UN. As such they accept requests for food aid and distribution, and have these delivered by the Logistics Cluster, also managed by WFP.
• They want to know if it is possible to customize Sahana's request management module to fit the attributes requested by the cluster.
• WFP has met with the cluster coordinator and they think it is a good idea to capture requests and food needs and display them on a map.
• They have access to 8cm imagery (as do we through the world bank flyovers - something we can configure with openlayers) that they want to have as an overlay.
• They have developers who can assist with the mapping components.
• I think it is the simple RMS that they are after here... as a front end to collect data... fulfil requests, and report on status.
• Requests could be "downloaded" and "validated", and the status manually updated.
• They have looked at our Haiti.SF.org site and say that all the elements and functionality is there.
• They need to customize the fields of data to be collected.
• Obviously the locations that are generating requests are not hospitals - so we would have to add all the locations that concern them.
• They will need to specify reports that need to be generated.
• They want to be able to integrate the request module with their internal workflow system (yet to be designed) and provide the aid requesters with status updates automatically, e.g. if their request is in planning, under provisioning, under delivery or closed.
• They want to be able to integrate with their institutional supply chain management system but have not identified the exact requirements for this yet; they have looked at how we handle aid and think it basically lines up, but the challenge is a lot of supplies come from internal sources (already tracking within their systems).
  
• They need the service to be operational within one week (all except the backend integration with their systems).
  

Deployment Vision and Questions for Developers (from Mark):

• A separate instance of SahanaPy stood up - hosted by us or them? Or do we build on the same prod data?
  • Fran would love to see this running within same Dev->UAT->Prod instance. We can provide separate security roles, if required.
• We need to budget operating and support costs in near-term and long term.
• All code via trunk... no forks.... no conflicts with HMS, R-HMS, or RMS.
  • Fran: RMS will be merged with Trunk in a slightly more generic form...ideally the WFP customidsations can fit within that, otherwise we /can/ simply create a new module...although I'm reluctant
• Is there a need to have a developer in Rome to coordinate on data structures and requirements with WFP?
  • Fran: Whilst that could be nice, having good remote access should work for this part too...the personal touch is mostly useful to get agrrement on the higher-level aspects...if this is in-place then the more detailed parts don't require as much F2F
• We only do this if funded. We can't do a project for WFP without dedicated assets that are paid to deliver on the project.
  • Fran: I'd happily do this free, however the timetable is very tight & we're committed on many fronts currently.
• Those who will be paid to work this out will have to commit to a time schedule and availability that makes sense for the project. All personal and professional time commitments must be noted.
• Long term support - the change requirements sound minimal - so standing up a system within a week should not be difficult if we have dedicated assets to do this. Need thoughts for proposing long-term support plan: a combination of having support team available to support the product once stood up for 3 or 6 months, or do we rapidly train and handover?
• How does this impact our ability to continue to support HMS system?