By Today’s post starts with a quote from a deliciously dark Stephen King mini-series from years ago, Storm of the Century
The Mary summary (condensed/abridged to fit this blog post) – a stranger comes to town and keeps repeating the line ‘Give me what I want and I’ll go away’. The town decides to do so because they think it’s a good idea but…in the end it really isn’t…which launches me into my blog (and my return to RMIS as a topic).
On most of your RMIS projects you’ll have a project team that includes a solution architect who is charged with designing the best solution for you. What I see is a solution architect, with good intentions, delivers a solution, but it is not sustainable. By that I mean it hasn’t been engineered with ongoing needs in mind. So is it really the best solution? In my career, I’ve seen more overly complex, over-engineered solutions that I’m told the client had to have because that was their need. I would argue that was what they wanted…but not at all what they needed. Over-engineering and overly complex custom solutions are not your friends. Going outside the box is fun, but does not guarantee long term success. The best solution is one that is designed to meet your current and future needs. And one of those future needs should be easy maintenance. One of the best architects I ever worked with was Tom Lill, who designed solutions using as much standard software as possible.
How does this benefit the client? Less customization = less opportunity for things to break; less risk of lost knowledge when transitioning to the ongoing support team; less use of hours because you’re in a simpler model, more long term flexibility.
Don’t get me wrong – There is a time and a place for complex solutions. But it should be your last resort, not your first option. A highly customized solution is a solution that you may think you want. Long term it is not the solution you need. It won’t grow as your company evolves…or as the product evolves. And then stagnation occurs, followed by frustration. Never a good thing.
How can you avoid? I’m glad you asked.
First – start with your end goal – know what reports you need or what your anticipated workflow improvements will be. Then, with every question, recommendation, development ask yourself if those end goals are being met.
Second – Tell your solution architect you want the solution to be as standard as possible. When they propose a solution dig in – and ask how standard it is. Push them and your team to stay within the box.
Third – ask yourself if the juice is worth the squeeze. If a report takes you 1 hour each month to create and the solution is 40 hours of development time…then I’d question the investment.