March 15, 2016

Product Priorities

Karl - Question about VIMS code being incorporated. Curious if there is another customer who wants it at this time. Doesn't make sense to bring it in unless there is another customer who needs that specific VIMS functionality.

Response: If there was another country that wanted to do a similar project and thought that modifying the VIMS code base was the way to go then that would be a strong rationale.

Marasi - Say Kenya comes on tomorrow and wants to take 2.0 and integrate VIMS code base, what is the timeline for that? The foundation has made it clear to us that they want this to be readily available to countries. The timeframe to provide that could be a stumbling block. What is the timeframe to integrate the VIMS code base into 2.0.

Response: Don't have an exact estimate. Not a trivial amount of time, so need to decide if there is a customer for it. Gates understand the timing and reasoning for why we had to move forward with 2.0

Legacy Implementations

Ashraf - When you say that individual countries have their own version of OpenLMIS. At least for JSI's implementation, they're all in the same code base. Not different between countries - same code base.

Response: Important to note, especially for the ROI for that work. Same for Mozambique and Benin as well.

Karl: May be worth scoping out the building of migration scrips in the "ask," countries that were on the eLMIS implementation. We want to get them off the fork and back into the scope.

Response: That could make sense, but need to be transparent with donors that migration scripts aren't the only costs. Would love to get some indication from USAID that they see for existing implementations going forward is that they get handled as country-specific implementations, or if they get pulled into 3.0. Sounded like funding was limited, but unclear if that was at the country level, etc.

Ashraf: USAID is dealing with other issues. One approach is that we can scope the different work that would be needed, as well as for the overall rearchitecture and come up with a joint proposal? Individual organizational partners might have their part of the ask, as part of the overall package. This is my piece of work, this is the funding that I ask for. If it comes through, that funding would be made available to that organization.

Response: It would be good to have them on board conceptually. How to move forward with the various donors. If we think the right thing to do is to bring these implementation to 3.0. Cote d'Ivoire has a standard OpenLMIS implementation with a small level of customization on top of it. It would be a relatively modest ask to bring them up to 3.0. For Tanzania, with the VIMS customization, etc., and replicating that with module-based functionality, would be a much bigger scope. Frankly, the ask for Tanzania in particular may be high. The recommendation that we come to as a group is for them to stay on their country implementation for a time, and then revisit in a few years. That's looking at it from an ROI and timing perspective.

Ashraf: The more we wait, the more effort it will take to bring them together.

Mattias: We're still talking about the idea of going dark and really separating from the current implementations, versus the incremental approach where we coudl potentially take the countries that already have a nationwide implementation and could test it out while it's being developed so we don't orphan those countries, and also have something that's proven to work in a country. Able to say, this is the actual implementation available in X number of countries which we could put in your country. As opposed to a completely rewritten piece that may be less feature-rich with no existing implementations. Why don't we look more seriously at the idea of incremental architecture?

Marasi - In Tanzania, we've had multiple countries visit, or when GF or USAID has visited, the selling point on the tool is that it's already implemented. Every country wants to see the proof that it works. We're likely to get more traction by showcasing a version of it that's implemented in one of the pathfinder countries.

Response: Echo your comments about the value of having the software implemented and ensuring that it works. You can take the same kind of project approach regardless of whether its a rewrite or incremental. Is there a country you'd recommend?

Marasi: Tanzania? Strategically using Zambia would be a better bet given that there is continuity with the team that implemented the work. Zambia, given the fact that they are still doing a national rollout, they have a pipeline that could be leveraged for this purpose. By virtue of going with Zambia, then Tanzania benefits.

Wendy - We would really need to know exactly what that would entail. We'd need to know what the upgrade would be.

Response: Those are questions that need to be answered. This is at the initial visioning phases. One question would be, does the UI stay the same? If so, the training burden would be pretty minimal. Have had some conversations otherwise. For this Zambia piece, I propose that we set up a follow on conversation to scope this piece of work as part of the proposal. Does that sound like it would work? We should have a more detailed proposal in the next four weeks, and will decide on what to scope.

Mattias - Do we need to re-think what it is as a community that we need to do? Work together on a proposal? Would it be helpful for us to think through this and put forth a joint proposal? If each partner has some sort of expertise to bring or ideas on how to implement, we can come together on a joint proposal like with VAN, these are the pieces that each organization can contribute to it. It seems like Gates and others would look favorably on that sort of collaboration.

Response: What do other people think about that question?

Brian - Is this to get countries onto that code? Or get the code migrated to get them ready for implementation? What would it cost to migrate the code from Zambia (pretty close to that because of 2.0 happening in December), and then the data migration and training of users on a national scale in Zambia.

Karl - Need to figure out where the actual business value is in migrating? If it's a feature-by-feature replacement, there's not much of a point to migrate. The point of doing the re-architecture in my mind is so that forking no longer happens, and customization and modularization a the country level can happen without forking. Legacy and existing implementations should stay on their legacy version, adn we should make sure we can provide support and bug fixes for that version. A year or year and a half from now when 3.0 starts adding features, it might make sense to consider migrating them. You'd have to demonstrate the value of doing a big migration.

Brian - Any time that users make a change from software to the next, there needs to be value on their end. Not a lot of value for the end user.

Ashraf - Strongly disagree with that. It's more realistic to upgrade. If you're not really validating your work against an actual country and doing your upgrades, you're working on a theoretical basis. But if you're facing an actual country, challenges and requirements, then your product will be much more grounded in reality.

Brian - For developers (JSI) I can agree with that. For a Ministry, having to re-train all users in a new interface, I think we'd need to do some work to prove that.

Mattias - Aren't we talking about essentially keeping the same interface? Wouldn't be the same interface. Really this is not as much for the benefit of Zambia, but for the benefit of OpenLMIS. Validating changes in real time that what you've created is usable in a country that has done a nationwide implementation.

Karl - You should not do the re-architecture in a bubble, have a use case in mind. Doesn't need to be a country with a nationwide implementation. Unless you can demonstrate that there's actual value for the country. In the short term, it may be smarted to upgrade until there are 4-5 features in OpenLMIS 3.0 that they could use, then consider upgrading. You need a new architecture working in a country first so you can polish it, and then apply to an existing implementation with a lot of customization.

Sarah - Doesn't sound like we'll have concensus as a group, and ultimately it's the donors that need to be convinced. If we're saying that the primary value is to the OpenLMIS community and not to the country, then we have a bit of a concern.

Ashraf - This is where we run the risk of fracturing the community. If our perspectives aren't taken into account then we may not continue with the community.

Brian - Speaking to Sarah's point, if we can get the countries advocating for it, getting Zambia's ministry of Health to say that they want it, it would go a long ways to get sponsorship.

Wendy - One more question: If, hypothetically saying, we're not ready for an upgrade now, how seamless would an upgrade be a year from now?

Karl - We have to figure out how to move the data, but also need to talk about moving the functionality. Would mean reimplementing all those customizations in the new version. The reason the re-architecture is being done is to make sure that forking doesn't happen.

Sarah - Still makes sense to have a follow on conversation about the Zambia piece. Would be interesting to hear from JSI what indications you've gotten from Gates. We've gotten the impression that they are disinclined to fund country implementation projects right now. Doesn't mean they wouldn't want to, investigate further, provide more information to Wendy, and get information from the MOH in Zambia. Only a benefit to have more conversations with the Zambia team.

Action Items

• All, read through remainder of Feedback page. Comments? Send to Governance mailing list. Or send questions for discussion to the Governance committee list.
• Mattias Wiklund (Unlicensed) to coordinate scheduling call on Zambia proposal