Gap Project Governance

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.

Page Contents

Gap Project Governance Members


  • 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.


The Interface workstream LOE may increase as we decide on the approach. In the month of August the Reporting workstream may increase the scope. The above does not include the non-prioritized scope which counts for an estimated 33.4 additional epic points.  

Sprint Reports:

Version 3.4 (2018 May - August)

Version 3.5 (2018 August -December)

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.

RiskDiscussionStatusApproach to Mitigate
1Sustainability 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 

2Metric 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?

We are planning to have an in-person meeting to discuss reports and metric. Potentially we could invite members of our community who have experience with SCOR or other supply chain best practices to help inform how our metrics could be improved or fit within.


 Brandon: let's get some face-to-face time in September alongside the OpenLMIS community meeting.

Matt: we could do some prep work around this prior to the meeting to ensure good conversation. Perhaps we could ask folks prior to the meeting to provide feedback. What are the key things which drive their decision making.

Edward: Let's make sure not redo what we've already done and be specific around the request.

Mary Jo: what do they actually use and how to use it.

3Lack 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 with the whole group.

Edward: what additional input is needed? 

Mary Jo: we wanted to note this as a risk because TZ and Zambia said all features were

4Alignment on the strategy for interoperability.Currently the Team Leads, Product Manager, Governance Committee and Architect are not aligned on the approach to implement/support interoperability.Note yet discussed with the whole group.Josh Zamor has incorporated feedback from the team and held a meeting to go over the approach. Please outline if there is need for further discussion.

Travel Budget

Important : All international plane tickets must comply with the US Airways limitation. For details, please reference the individual contracts and this online cheat sheet. In addition, when requesting travel please fill out the following form and submit to Mary Jo Kochendorfer (Deactivated).

Name of Personnel
Purpose of Assignment
Period of Performance
Travel Route

Total Cost Estimate

  • RT airfare
  • Per diem
  • Ground transport

Meeting notes

Meetings will be held at the end of the month, prior to the check in with PATH.

OpenLMIS: the global initiative for powerful LMIS software