Page Comparison

Discussion the risks identified by committee members

Risk #2. Are we building the right product for our target environment?

• What do we do about it if we build the right product? If we go to a country, and it doesn't meet the needs.  We course correct. Hopefully we the right architecture in place to support extension.
• We want to find the common feature set for OpenLMIS

Risk #11. Too many new country requests / distractions / demands of project teams (scope creep)

• Chris George (Unlicensed) noted this is important for the committee to set expectations
• Current strategies will need to be monitored over time and adjusted as needed

Risk #3. Solution too complex for end users

• Ashraf Islam (Unlicensed): Dealing with integrations with ERPs can be complicated
• Danni Yu (Unlicensed): Trainings will be required.  Should aim to keep OpenLMIS complexity at the same level. Users are can be overwhelmed.
• Kevin Cussen (Deactivated): we will continue to receive feedback on an ongoing basis
• Ashraf Islam (Unlicensed): balance what is required and what is not

Other risks will be addressed on an on needed basis. slot time for each call.

• Risk #1. New deployments that are needed before 3.0 is done
• 
  Risk #7. OpenLMIS community stays dependent on centralized funding from 1-2 primary sources and fails to diversify and encompass open source development principles
• Risk #6. OpenLMIS community fails to grow. Stays small and driven by self-interest
• Risk #5. Perception of code review as an acceptance of the story. The role of code review.
• New risk identified by Lakshmi: Countries do not migrate to 3.0.

Follow up: present the new feature verification process diagram

• Chris George (Unlicensed): Someone from the implementor team engage with the product committee.
• Kevin Cussen (Deactivated): we need to encourage implementors to engage as early as possible