• Working with a Mifos Specialist
• Creating a Network of Specialists
• Choosing a Mifos Specialist
• Managing Software Development Projects
• Contracting with a Specialist

Working with a Mifos Specialist

MFIs intending to deploy Mifos will want to work with professionals who are specialists in the Mifos product. Even though Mifos is built on open source code, is well-documented, and well-supported, the installation and implementation processes are not trivial and should be managed by IT professionals. You’ll need the following types of expertise:

• Someone to implement the software. In addition to setting up the system and configuring it for your organization, this person or technology firm will need to manage the migration of data from your old system, as well as train your staff in using Mifos.

• If you’ve determined that you need to add to or tweak features in the core software, you’ll want to select a software developer to write the code.

• Once the software is deployed, you’ll need someone to act as a Mifos system administrator and provide ongoing technical support.

It’s possible that IT personnel within your organization can fulfill one or more of these roles, or that the same vendor can fulfill more than one role.

Creating a Network of Specialists

One of the goals of the Mifos initiative is to build a network of Mifos Specialists who possess the skills needed to deploy and customize Mifos for your organization. We encourage MFIs, IT professionals, and the community at large to help build this network by identifying companies with the required skills.

Choosing a Mifos Deployment Specialist

Although the skills and experience you require in a Mifos Specialist will vary depending on the skills already available in-house, consider the following skill sets when hiring the Specialist.

Project Management. The Specialist you select needs to understand the challenges of working on site. They should be able to manage project schedules, including assigning tasks and deliverables and setting milestones. They should be able to provide examples of their experience in setting roles and defining responsibilities for a project team, including identifying the relevant stakeholders, reviewing the skill sets of stakeholders, and assessing other responsibilities and workloads. Specialists should be able to give examples of challenges and success stories in balancing vendor needs with client needs, and IT/MIS team needs with operations and senior management needs. They should have experience in understanding and balancing the communication needs and styles of different stakeholders.

Domain Experience. Specialists should understand microfinance policies, processes and workflows, and be able to use the tools for mapping those workflows. They need to understand and help define reporting requirements, taking regulatory and donor requirements into consideration. They need to understand the data needs of microfinance and be able to help MFIs prioritize those needs. They need prior experience in recommending process change. For example, they need to be able to describe how they have dealt with common process issues such as determining acceptable workarounds, how they have gotten management to buy into IT-driven process change, and how they have driven process change across an organization.

Systems Migration. Specialists should have previous experience in managing system migration, including data mapping from one database to another and from a manual to an automated database. They should be able to give examples of conversion tools they’ve used, both manual and automated. They should have experience in developing user and administrator training. They should also be experienced in communicating organizational change, including managing client expectations and communicating change beyond the project team across the organization. They should provide examples of successful roll-outs, including timing and success factors. They should have experience in collecting and reporting bugs and other types of feedback.

System Administration and Technical Support. Specialists should have experience in developing hosting strategies, including defining and testing connectivity requirements, identifying hosting options, and implementing data backup and archiving processes. They should be able to configure systems and be familiar with various report writing tools.

Open Source Community. Lastly, Specialists should understand open source processes and comply with open source protocols. They should be willing to actively participate in the listserv and publish process and planning documents for public access.

Managing Software Development Projects

To be updated

Contract with a 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.

Managing Costs

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 java.net issue tracker to enter all bugs/issues found in the software. Contact the Mifos-developer mailing list if you want a bug category created specific to your deployment
• Use the wiki and folders/file section of the java.net site for all functional requirements.
• Make sure they do NOT fork code and work extensively in a local version. Changes should be made directly to SVN repository. Code changes should be checked-in at least daily, although more frequent check-ins are encouraged. All code check-ins must include the corresponding junit test (i.e., these tests should not be all written at the very end of the project).
• Agree that no check-in will cause new or existing unit tests to fail. [what does this mean?] The system should also be working at a user level. For example, a feature which is not yet completed should only be accessible by typing a special URL or through some other mechanism, and should not be visible to everyone by default.
• 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. These iterations should be posted to the Mifos test server (test.mifos.org), and you should try out the code on the test server.
• 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.

Miscellaneous Items

• Acceptance criteria:
  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.

See also

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