Tag Archives: software

Does your MERL Tech effort need innovation or maintenance?

by Stacey Berlow, Managing Partner at Project Balance and Jana Melpolder, MERL Tech DC Volunteer and Communications Manager at Inveneo. Find Jana on Twitter:  @JanaMelpolder

At MERL Tech DC 2018, Project Balance’s Stacey Berlow led a session titled “Application Maintenance Isn’t Sexy, But Critical to Success.” In her session and presentation, she outlined several reasons why software maintenance planning and funding is essential to the sustainability of an M&E software solution.

The problems that arise with software or applications go well beyond day-to-day care and management. A foundational study on software maintenance by P. Lientz and E. Burton [1] looked at the activities of 487 IT orgs and found that maintenance activities can be broken down into four types:

  • Corrective (bug fixing),
  • Adaptive (impacts due to changes outside the system),
  • Perfective (enhancements), and
  • Preventive (monitoring and optimization)

The table below outlines the percentage of time IT departments spend on the different types of maintenance. Note that most of the time dedicated to maintenance is not defect fixing (corrective), but enhancing (perfecting) the tool or system.

Maintenance Type Effort Breakdown
Corrective (Total: 21.7%) Emergency fixes: 12.4% 

Routine debugging: 9.3%

Adaptive (Total: 23.6%) Changes to data inputs and files: 17.4%

Changes to hardware and system software: 6.2% 

Perfective (Total: 51.3%) Customer enhancements: 41.8% 

Improvements to documentation: 5.5% 

Optimization: 4.0%

Other (Total: 3.4%) Various: 3.4%

The study also pointed out some of the most common maintenance problems:

  • Poor quality application system documentation
  • Excessive demand from customers
  • Competing demands for maintenance personnel time
  • Inadequate training of user personnel
  • Turnover in the user organizations

Does Your Project Need Innovations or Just Maintenance?

Organizations often prioritize innovation over maintenance. They have a list of enhancing strategies or improvements they want to make, and they’ll start new projects when what they should really be focusing on is maintenance. International development organizations often want to develop new software with the latest technology — they want NEW software for their projects. In reality, what is usually needed is software maintenance and enhancement of an existing product.

Moreover, when an organization is considering adopting a new piece of software, it’s absolutely vital that it think about the cost of maintenance in addition to the cost of development. Experts estimate that the cost of maintenance can vary from 40%-90% of the original build cost [2]. Maintenance costs a lot more than many organizations realize.

It’s also not easy to know beforehand or to estimate what the actual cost of maintenance will be. Creating a Service Level Agreement (SLA), which specifies the time required to respond to issues or deploy enhancements as part of a maintenance contract, is vital to having a handle on the human resources, price levels and estimated costs of maintenance.

As Stacey emphasizes, “Open Source does not mean ‘free’. Updates to DHIS2 versions, Open MRS, Open HIE, Drupal, WordPress, and more WILL require maintenance to custom code.”

It’s All About the Teamwork

Another point to consider when it comes to the cost of maintenance for your app or software is the time and money spent on staff. Members of your team will not always be well-versed in a certain type of software. Also, when transferring a software asset to a funder or ministry/government entity, consider the skill level of the receiving team as well as the time availability of team members. Many software products cannot be well maintained by teams that not involved in developing them. As a result, they often fall into disrepair and become unusable. A software vendor may be better equipped to monitor and respond to issues than the team.

What Can You Do?

So what are effective ways to ensure the sustainability of software tools? There’s a few strategies you can use. First of all, ensure that your IT staff members are involved in the planning of your project or organization’s RFP process. They will give you valuable metrics on efforts and cost, right up front, so that you can secure funding. Second, scale down the size of your project so that your tool budget matches your funds. Consider what the minimum software functionality is that you need, and enhance the tools later. Third, invite the right stakeholders and IT staff members to meetings and conference calls as soon as the project begins. Having the right people on board early on will make a huge difference in how you manage and transition software to country stakeholders later at the end of the project!

The session at MERL Tech ended with a discussion of the incredible need and value of involving local skills and IT experts as part of the programming team. Local knowledge and IT expertise is one of the most important, if not the most important, pieces of the application maintenance puzzle. One of the key ideas I learned was that application maintenance should start at the local level and grow from there. Local IT personnel will be able to answer many technical questions and address many maintenance issues. Furthermore, IT staff members from international development agencies will be able to learn from local IT experts as well, giving a boost in the capacity of all staff members across the board.

Application maintenance may not be the most interesting part of an international development project, but it is certainly one of the most vital to help ensure the project’s success and ongoing sustainability.

Check out this great Software Maintenance/Monitoring Checklist to ensure you’ve considered everything you need when planning your next MERL Tech (or other) effort!

[1] P. Lientz, E. Burton, Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations, Addison-Wesley (August 1, 1980)

[2] Reference: Jeff Hanby, Software Maintenance: Understanding and Estimating Costs, https://bit.ly/2Ob3iOn

How to buy M&E software and not get bamboozled

by Josh Mandell, a Director at DevResults where he leads strategy and business development. Josh can be reached at josh@devresults.com.

While there is no way to guarantee that M&E software will solve all of your problems or make all of your colleagues happy, there absolutely are things you can do during the discovery, procurement, and contracts stages to mitigate against the risk of getting bamboozled.

#1 – Trust no one. Test everything.

Most development practitioners I speak with are balancing a heavy load of client work, internal programmatic and BD support, and other organization initiatives. I can appreciate that time is scarce and testing software you may not buy could feel like a giant waste of time.

However, when it comes to reducing uncertainty and building confidence in your decision, the single most productive use of your time is spent testing. When you don’t test, what evidence do you have to base your decision on? The vendor’s marketing and proposal materials. Don’t take the BD guy’s word for it and whatever you do, don’t trust screenshots, brochures, or proposals. Like a well-curated social media profile, marketing collateral gives you a sense for what’s possible, but probably isn’t the most accurate reflection of reality. If you really want to understand usability, performance, and culture fit, you simply need to see for yourself.

We have found that the organizations that take the time to identify and test what they’ll actually be doing in DevResults are much better off than those who buy based on what they see in documentation and presentations, or based on someone else’s recommendation.

And it makes our lives easier too! We may have to spend a little more time upfront in the discovery and procurement phases, but by properly setting expectations early on, we have to provide far less support over the long-term. This makes for smoother, lower-cost implementations and happier customers.

#2 – Document what success looks like in plain language.

We obviously need contracts for defining the scope of work, payment terms, SLA, and other legalese, but the reality is that the people leading procurement and contracts are often not the people leading the day to day data operations.

Contracts are also typically dense and hard to use as a point of reference for frequent, human communication. So, it’s incredibly important that the implementation leads themselves define what success looks like in their own words and that is what drives the implementation.

It took us years to figure this out, but we’ve taken the lesson to heart. What we do now with each of our engagements is create an Implementation Charter that documents, in the words of the implementation leads, things like a summary baseline, roles and responsibilities, and a list of desired outcomes, i.e. ‘what success looks like.’ We then use the charter as the primary point of reference for determining whether or not we’re doing a good job and we evaluate ourselves against the charter quarterly.

Similar to the point about testing above, we have found this practice to dramatically increase transparency, properly set expectations, and establish more effective channels for communication, all of which are crucial in enterprise software implementations.

#3 – Plan for the long-haul and create the right financial incentives. Spread out the payments.

Whether at the project or organizational levels, M&E software implementations are long-term efforts. Unlike custom, external-facing websites where the bulk of work is done up front and the rest is mostly maintenance, enterprise software is constantly evolving. Rapidly changing technology and industry trends, shifting user requirements, and quality user experience all require persistent attention and ongoing development.

Your contract and payment structure should reflect that reality.

The easiest way to achieve this alignment is to spread the payments out over time. I’m not going to get into the merits of a software as a service (SaaS) business model here (we’ll be putting another post out on that in the coming weeks), but suffice to say that you get better service when your technology partner needs to continuously earn your money month after month and year after year.

This not only shifts the focus from checking boxes in a contract to delivering actual utility for users over the long-term, but it also hedges against the prospect of paying for unused software (or even paying for vaporware, as in the case of the BMGF case against Saama).

We know from experience that shifting to a new way of doing things can be difficult. We used to be a custom-web development shop and we did pretty well in that old model. The transition to a SaaS offering was painful because we had to work harder to earn our money and expectations went up dramatically. Nonetheless, we know the pain has been worth it because our customers are holding us to a different standard and it’s forcing us to deliver the best product we’re capable of. As a result, we’ll not only have happier customers, but a stronger, more sustainable business doing what we love.

Stop the bamboozling.

If you have any tips or recommendations for buying software, please share those in the comments below, or feel free to reach out to me directly. We’re always looking to share what we know and learn from others. Good luck!

MERL Tech London is coming up on March 20-21, 2018 — Submit your session ideas or register to attend!