What your RMIS provider won’t tell you

I may singe a few bridges with this post, but here goes! Here are two things that typically drive clients nuts when it comes to their RMIS provider: 1) they won’t tell you no and 2) they won’t commit to an enhancement getting built or a defect getting fixed. Let’s tackle each one individually and talk about what you can do as the client to protect yourself.

1) they won’t tell you no

Your RMIS provider should probably tell you no more often that they do (if they ever do). So why wouldn’t they? Well for one, most people are hard wired to say yes. Deep down inside we are all people pleasers and don’t want to say no either because of the conflict involved or a deep psychological need to be liked. The second main reason is money. At this point, with the RMIS start-ups now more mature, you likely have a multi-contact service team and have an account manager. Their job is to get you to buy more – specifically more licenses (or anything with recurring revenue). So if you come to your account manager with a problem, as they listen to what you’re saying, in their mind they’re asking if this involves recurring money and is this something standard that can be deployed quickly. Your service team is also geared to say yes because they are rewarded on higher billable hours. As a solution architect I was guilty of saying yes a few times when I should have said no, just because I was intrigued by the business need. But I did say no to a several clients because as I phrased it ‘the juice isn’t worth the squeeze’. If something takes 2 hours each month, but could be done with automation, but the automation will take 100+ billable hours, perhaps you look at a better use of time. Jon Nichols, a RMIS veteran, is so brilliant in service and in operations management because he was always asking why. In one lovely example (true story that I’ve modified), a client was demanding that 10 reports had to be built and had to be printed and mailed out monthly. He kept on asking why? politely of course. Come to find out those hard copy reports were being sent to someone who wasn’t even looking at them. The recipient didn’t know why he got them, he just put them in a box each month and when the box was full, he sent it off to storage and got a new box.

To combat the ‘not saying no’ issue, you should always ask the why behind your business need internally. This introspective questioning will serve you well and save time as the project gets underway. Once you have your ducks in a row. Then and only then, go to your service team and get a level of effort and even ask for a proof of concept before committing. One of my clients prepared a five page specification with sample screen shots to me. This document aided me in creating a much more accurate level of effort and allowed me to ask more directed questions based on my review.

A mitigation effort you can take, if your RMIS provider has said yes but acknowledges it’s outside the ‘norm’ is to make the project time and material projects with caveats about hours reviews and overages. The onus is on you to review hours weekly, but that isn’t a bad thing (and likely should be done weekly or monthly anyway).

Your other mitigation tactic is to gently remind your RMIS vendor that you are partners. As such, you are expecting a no if it is 1) not feasible 2) not maintainable 3) in uncharted territory (something not in the RMIS provider’s wheelhouse).

2) they won’t commit to a enhancement getting built or a defect getting fixed

The why behind this annoyance is simple and yet complex. If a RMIS vendor has 800 clients, each client likely has their own set of enhancements and defects. Let’s argue each has 10 (likely more than that). So now you have 8,000 enhancements and defects for a development team before they’ve even reached for their morning coffee. I saw this personally when I began to implement and service clients that operated internationally where the software’s data model was decidedly not set up for global activities. If you’ve ever sat in a room with more than 2 international clients, you’ll know there is never consensus on what needs to happen first. Some people are concerned about languages, while others are concerned about currencies and others are concerned about how date-time stamps are stored (is it your end user’s computer time, US Central time, Greenwich time, where the server is housed?). On top of that are two layers: the vision for the company (Does the company have competing product prioritizations?) as well as what recent sales have contractual obligations (e.g., all of a sudden a business interruption module is moved up in the product timeline because a big deal is signed).

I am completely sympathetic to product and development because this is a major juggling act. but. BUT. BUT. there are typically something lovingly called ‘low hanging fruit’ – easy fixes or enhancements, that never get addressed because the focus is on these things called big rocks. If it were up to me, I’d have a team assigned to these low hanging fruits, let’s call them pebbles to stick with the stone analogy. Here’s why. Have you ever had a tiny pebble in your shoe? That pebble may start out as mildly annoying initially, then it becomes increasingly more irritating and may even cause an ugly blister if not addressed.

For this reason, I could see engaging a smaller start up RMIS provider, where you can be the big fish in the little pond and get the work done that you want done. But let’s presume you’re trapped in your contract. Or the bigger reality is you like most things about the software, but it is increasingly annoying that your pebble isn’t getting addressed. Your best tactic is to become the squeaky wheel by using one of these 3 tactics: 1) RMIS social media and 2) RMIS user conferences and 3) account manager engagement. Get out there and engage in public forums (client forums, industry forums, etc.). See if you can get other clients to agree with you on the issue (enhancement/defect). This does take some effort, but in general you should be talking on these forums anyway to hear about what others are doing in the system and cherrypick ideas to implement. The other squeaky wheel is to attend the RMIS’ user conference and attend the enhancement forum…and be vocal. You don’t have to be nasty – just state your case (quantify it – my team spends 30 hours each month doing x because y is broken). Become squeakier until you get heard. The third option may be your starting point. While your account manager’s job is to expand your engagement, they are also supposed to be your advocate and help you to escalate.

Finally, should your enhancement or fix get into the software, test it (because it doesn’t always work the first time) AND say thank you. Please and thank you go a long way!

I am sure there are other activities/actions (or non-actions) that frustrate (such as support team changes), but I have found these two are consistently the top annoyances. It’s important that you are aware of the why’s and have an action plan to address, so that your pebbles don’t drive you nuts. Remember it is a partnership that you’re served best by entering into with open eyes.