Good, Cheap, Fast - Pick Two

By: Chris Gegenheimer (Chemonics) and Leslie Sage (DevResults)

Back in September, Chemonics and DevResults spoke at MERL Tech DC about the inherent compromise involved when purchasing enterprise software. In short, if you want good software that does everything you want exactly the way you want it, cheap software that is affordable and sustainable, and fast software that is available immediately and responsive to emerging needs, you may have to relax one of those requirements. In other words: "good, cheap, fast - pick two!"

Of course, no buyer or vendor would ever completely neglect any one of those dimensions to maximize the other two; instead, we all try to balance these competing priorities as best we can as our circumstances will allow. It's not an "all or nothing" compromise. It's not even a monolithic compromise: both buyer and vendor can choose which services and domains will prioritize quality and speed over affordability, or affordability and quality over speed, or affordability and speed over quality (although that last one does sometimes come back to bite).

Chemonics and DevResults have been working together to support Chemonics' projects and its monitoring and evaluation (M&E) needs since 2014, and we've had to learn from each other how best to achieve the mythical balance of quality, affordability, and speed. We haven't always gotten it right, but we do have a few suggestions on how technological partnerships can ensure long-term success.

Observations from an implementer

As a development implementer, Chemonics recognizes that technology advances development outcomes and enables us to do our work faster and more efficiently. While we work in varied contexts, we generally don’t have time to reinvent technology solutions for each project. Vendors bring value when they can supply configurable products that meet our needs in the real world faster and cheaper than building something custom. Beyond the core product functionality, vendors offer utility with staff who maintain the IT infrastructure, continually upgrade product features, and ensure compliance with standards, such as the General Data Protection Regulation or the International Aid Transparency Initiative. Not every context is right for off-the-shelf solutions. Just because a product exists, it doesn’t mean the collaboration with a software vendor will be successful. But, from an implementer’s perspective, here are a few key factors for success:

Aligned incentives

Vendors should have a keen interest in ensuring that their product meets your requirements. When they are primarily interested in your success in delivering your core product or service — and not just selling you a product — the relationship is off to a good start. If the vendor does not understand or have a fundamental interest in your core business, this can lead to diverging paths, both in features and in long-term support. In some cases, fresh perspectives from non-development outsiders are constructive, but being the outlier client can contribute to project failure.

Inclusion in roadmap

Assuming the vendor’s incentives are aligned with your own, it should be interested in your feedback and responsive to making changes, even to some core features. As our staff puts systems through their paces, we regularly come up with feature requests, user interface improvements, and other feedback. We realize that not every feature request will make it into code, but behind every request is a genuine need, and vendors should be willing to talk through each need to figure out how to address it.

Straight talk

There's a tendency for tech vendors, especially sales teams, to have a generous interpretation of system capabilities. Unmet expectations can result from a client’s imprecise requirements or a vendor’s excessive zeal, which leads to disappointment when you get what you asked for, but not what you wanted. A good vendor will clearly state up front what its product can do, cannot do, and will not ever do. In return, implementers have a responsibility to make their technical requirements as specific, well-scoped, and operational as possible.

Establish support liaisons

Many vendors offer training, help articles, on-demand support, and various other resources for turning new users into power users, but relying on the vendor to shoulder this burden serves no one. By establishing a solid internal front-line support system, you can act as intermediaries and translators between end users and the software vendor. Doing so has meant that our users don't have to be conversant in developer-speak or technical language, nor does our technology partner have to field requests coming from every corner of our organization.

Observations from a tech vendor

DevResults’ software is used to manage international development data in 145 countries, and we support M&E projects around the world. We’ve identified three commonalities among organizations that implement our software most effectively: 1) the person who does the most work has the authority to make decisions, 2) the person with the most responsibility has technical aptitude and a whatever-it-takes attitude, and 3) breadth of adoption is achieved when the right responsibilities are delegated to the project staff, building capacity and creating buy-in.

Organizational structure

We've identified two key factors that predict organizational success: dedicated staff resources and their level of authority. Most of our clients are implementing a global M&E system for the first time, so the responsibility for managing the rollout is often added to someone's already full list of duties, which is a recipe for burnout. Even if a "system owner" is established and space is made in their job description, if they don't have the authority to request resources or make decisions, it restricts their ability to do their job well. Technology projects are regularly entrusted to younger, more junior employees, who are often fast technical learners, but their effectiveness is hindered by having to constantly appeal to their boss' boss' boss about every fork in the road. Middle-sized organizations are typically advantaged here because they have enough staff to dedicate to managing the rollout, yet few enough layers of bureaucracy that such a person can act with authority.

Staffing

Technical expertise is critical when it comes to managing software implementations. Too often, technical duties are foisted upon under-prepared (or less-than-willing) staffers. This may be a reality in an era of constrained budgets, but asking experts in one thing to operate outside of their wheelhouse is another recipe for burnout. In the software industry, we conduct technical exams for all new hires. We would be thrilled to see the practice extended across the ICT4D space, even for roles that don’t involve programming but do involve managing technical products. Even so, there's a certain aspect of the ideal implementation lead that comes down to personality and resourcefulness. The most successful teams we work with have at least one person who has the willingness and the ability to do whatever it takes to make a new system work. Call it 'ownership,' call it a 'can-do' attitude, but whatever it is, it works!

Timing and resource allocation

Change management is hard, and introducing a new system requires a lot of work up front. There's a lot that headquarters personnel can do to unburden project staff (configuring the system, developing internal guidance and policies, etc.), but sometimes it’s better to involve project staff directly and early. When project staff are involved in the system configuration and decision-making process, we've seen them demonstrate more ownership of the system and less resentment of "another thing coming down from headquarters." System setup and configuration can also be a training opportunity, further developing internal capacity across the organization. Changing systems requires conversations across the entire org chart; well-designed software can facilitate those conversations. But even when implementers do everything right, they should always expect challenges, plan for change management, and adopt an agile approach to managing a system rollout.

Good, cheap, fast: pick THREE!

As we said, there are ways to balance these three dimensions. We've managed to strike a successful balance in this partnership because we understand the incentives, constraints, and priorities of our counterpart. The software as a service (SaaS) model is instrumental here because it ensures software is well-suited to multiple clients across the industry (good), more affordable than custom builds (cheap), and immediately available on day one (fast). The implicit tradeoff is that no one client can control the product roadmap, but when each and every customer has a say, the end product represents the collective wisdom, best practice, and feedback of everyone. It may not be perfectly tailored to each and every client's preferences, but in the end, that's usually a good thing.

Chris Gegenheimer is the Director of Monitoring, Evaluating and Learning Technology at Chemonics International. Leslie Sage is the Director of Data Science at DevResults.