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 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 can you 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. It's someone's very best foot forward. 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 and making sure we're the right tool for the job, users are more successful 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. That vision should be what drives the implementation.
It took us years to figure this out, but we’ve taken the lesson to heart. Now, with each of our engagements, we create an Implementation Charter that lets our clients' implementation leads document 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.
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 shifts the focus away from checking boxes in a contract to instead 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 higher 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!
This post was first delivered as a lightning talk at MERL/Tech 2017 in Washington DC and later published on the MERL/Tech blog at http://merltech.org/how-to-buy-merl-software-and-not-get-bamboozled/.