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 are three 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 business development 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 salesperson’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 don’t need to support them as much 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, service level agreements, 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 you define what success looks like in your own words and have that drive 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 from both organizations, 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 remaining work is mostly maintenance, enterprise software is constantly evolving and needs long-term support. 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, 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 worse, paying for vaporware. Both is more common that anyone would like, just ask the Gates Foundation.
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 SaaS 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. We’re always looking to share what we know and learn from others. Good luck!
Josh Mandell is a Director at DevResults. This was his lightening talk at MERL Tech DC 2017
Sorry, the comment form is closed at this time.