This page is an effort to track the project governance items in a transparent way so the whole team has access to the open discussion around project performance (burn-down and costs) opportunities (for conference attendance and travel) and overall project risks. Please feel free to leave comments (either to page or inline) and ask questions.
Background: See Gap Analysis Development Project for details on the scope of the project, timeline, team structure and more.
Gap Project Governance Members
- JSI representative: Edward Wilson (stand in: Ashraf)
- Ona representative: Matt Berg (Unlicensed) (stand in: Craig Appl (Unlicensed))
- VillageReach representative: Brandon Bowersox-Johnson (stand in: Sam Im (Deactivated))
Roles:
- Mary Jo Kochendorfer (Deactivated) will be held accountable for updating this page with monthly information from the team.
- Team Leads are responsible for raising risks or questions for the Gap Project Governance team.
- Members are responsible for reviewing and weighing in on any open questions.
Scope of Governance
- Review Roadmap Burn down and Team velocity
- Identify and mitigate risks
- Oversee travel budget and allocations
- OpenLMIS conference attendance
- In-person meetings
- Trips for team members
- Monitor opportunities for funding more gap work
Roadmap Burn Down
The burn-down of how many epics still remain in the entire gap scope and links to team velocity.
<insert burn down chart>
<links will be inserted for each sprint>
Open Question: Kaleb mentioned wanting to see costs alongside the burn-down. I would like to hear the input from the team on if and how we'd like to address that request.
Risk Mitigation
All Gap Project team members are responsible for flagging risks and adding them to the table below. The Gap Governance Team is responsible for reviewing the list and coming up with mitigations when possible.
| Risk | Discussion | Status | Approach to Mitigate | |
|---|---|---|---|---|
| 1 | Sustainability of the codebase if developer community is fragmented in knowledge | Raised by Ashraf and Craig Appl (Unlicensed). Important to consider the trade-off between velocity and cross-functional work. One team focused on component/area will achieve more than one team constantly shifting components/areas of focus. However, if the teams do not work across components we run the risk of no developers (or one team/org) understanding how to support or build on the entire OpenLMIS code base. | as of it is proposed agenda item for the first meeting | |
| 2 | Metric definition. Right now there are a ton of "Reports" with varying degree of complexity. We do not have a clear set of key metrics and why they are the key ones. | How do we get the OpenLMIS community opinionated about which metrics are priority across implementations with varying practices? Which metrics will help our implementers and drive new adoption? How do we learn from each country and organization's experiences? | Note yet discussed. | |
| 3 | Lack of input form Tanzania and Zambia stakeholders. Specifically on what scope of features are most important and WHY. | We understand the decision to actually upgrade is unique process/decision for each country. However, we need input from the implementations on priorities and why certain features are useful (or potentially should be redesigned). | Note yet discussed. |
Travel Budget
Meeting notes
Meetings will be held at the end of the month, prior to the check in with PATH.