Contracting with a Mifos Specialist
Disclaimer: The following is not legal advice. Please consult legal counsel in your country to ensure that you are following local regulations.
We recommend that MFIs include the following items in a development contract . While these were written specifically for deployments that require software development work, many of these items are "best practices" and would be helpful to include in any Mifos Specialist contract.
MFIs should be very conservative when budgeting for their Mifos development work, since it is very easy for development projects to run over schedule and budget. To prevent budget overruns:
- Scale back development efforts at the start by building in a buffer of at least 20% to cover any budget run-overs. For example, if your development budget is $10,000, scale back the effort so that the original Statement of Work is for no more than $8,000.
- Be prepared to adjust the amount of work to be done. Make sure the must-have items are ready to deploy before moving on to the lower priority items.
- Be extremely vigilant about managing, on an ongoing basis, how much money has been spent and how much of the work is done.
Statement of Work
Use a statement of work to specify the work that is going to be done. Prioritizing items well is essential for spending development money on the work that provides the most value. Whether you update the statement of work every week or every few months, you should agree on what you will be spending money on before the money gets spent. You’ll also need to track larger tasks, such as those that need to be done before Mifos can replace your current system.
Because needs are usually not fully understood up-front, it is best to outline the needs as you understand them in a draft statement of work. Include a preliminary scope and price, and expect to revise the statement as the gap analysis proceeds.
You’ll need to address:
- Work that will be undertaken
- Mifos Specialist resources assigned (role, skill level and time allocation)
- MFI resources assigned to support Mifos specialist (role, skill level and time allocation)
- Clear guidelines for how scope changes (such as additional features) will be handled and how impact to pricing will be determined
- Communication and escalation plans
Language of Deliverables
Because the Mifos community conducts its communications primarily in English, it is important for the Mifos Specialist to be able to provide information to that community in written English. The contract should specify that deliverables such as functional requirements, technical designs, and code comments for new code should be provided to the community in English. In addition, it may be important for the Specialist to provide deliverables and solicit feedback from the MFI staff in the local or regional language, to ensure that Mifos meets expectations.
Software Development Methodology
Because Mifos is an open source product, it is critical that your Mifos Specialist participate deeply in the Mifos community, use the tools and infrastructure provided by the community, and commit code back into Mifos' central code base. The items below stipulate the tools, processes and procedures that the MFI should require the Mifos Specialist to use or adhere to, in order to contribute code back to the community.
The Mifos Development Specialist should:
- Use JIRA issue tracker on MifosForge to enter all bugs/issues found in the software. Search through the existing issues in the issue tracker or discuss the possible bug on the mailing lists, if you're unsure whether or not it's a bug.
- Follow our guide and templates for writing out and discussing functional requirements. Follow all guidelines of our code submission process so the changes you make can be successfully integrated back in the codebase and shared and maintained by our community.
- Make sure they do NOT fork code and work extensively in a local version that is running the most recent build of Mifos. Code should be written according to the best practices we state on our site. All code should contain and successfully past its current unit test.
- Schedule and arrange your work in meaningful iterations (no longer than two-week increments) so that your MFI is able to review progress as it is made.
- Maintain two-way communication with the Mifos-developer mailing list so that technical and functional decisions are communicated as they are made. This will ensure that code is accepted in a timely fashion.
Licensing & Copyright of Code
It is very important that all code developed for your organization be contributed back to the community. By contributing it back, you ensure that all future features and enhancements built into Mifos are backwards compatible with your software. Your contract should stipulate that all code is released under the Apache 2.0 license.
A contract usually stipulates that an acceptance criteria document, mutually agreed to by both parties, will be created at a point later in the development process. This document typically includes definitions of P1-P4 bugs and states that the code will not contain P1 and P2 bugs. It identifies the documents/code/functionality that will be delivered, and defines how much time a client has to review the deliverables and "accept" them.
Hardware and software requirements:
Clarify that your Mifos Specialist is responsible for any hardware and software that they require to complete the work. Because this is an open source project, it’s unlikely that they’ll require additional software, but it's best to state this in the contract.
Changes to project team:
It's usually best for both the MFI and the Mifos Specialist to minimize changes to the project team. However, when changes are necessary, the contract should stipulate that either party should provide 15 or 30 days notice.
- Martin Fowler's writing on agile processes, for example FivePoundBag, PleasingTheCustomer, CustomerAffinity, or The New Methodology. Although written primarily for developers and others with software project management experience, there is still much of interest to the MFI.
- Sources such as The One-Page Guide to Agility Although this is far lengthier than a one-page "how to," it does summarize the issues involved in contracting for and managing projects.