In my previous article, I referred to the theory of Schumpeter and described how growing organisations can become “dinosaurs” that seem unable to respond to market needs. In this article, I am going to describe one specific cause of this paralysis – IT.
Some organisations find themselves unable to move quickly because their IT systems just aren’t up to scratch. This has always seemed ironic to me… IT is supposed to be an enabler yet it stops some organisations from seizing strong and strategic opportunities. Perhaps their IT estate has evolved through knee-jerk decisions rather than design, leaving them with a rich cornucopia of conflicting systems. In a worst case, these disparate and unconnected systems may appear to be held together with string, staples and sticky-tape. A situation best avoided!
I firmly believe that organisations of all size can avoid this issue by carefully considering whether they need new IT systems, and by understanding their business and user requirements. 7 of the most important questions that any organisation should ask are listed below.
- What problem am I trying to solve? Before buying IT software or hardware, it is essential to take a step back and focus on the business problem or opportunity that is being addressed. Organisations all over the world have fallen into the trap of the “solution illusion”; where they end up building or buying something that they don’t need and doesn’t meet their needs. Once they have implemented it they may find themselves “stuck” – it is too expensive to replace, and the system inhibits them or slows them down.
- What would success look like? After knowing what problem or opportunity you’re addressing, make sure you define some success criteria. Will you have more spare time (because the IT system is going to automate your invoicing?). Will it save you money? Define these success metrics up front, and you’ll have a much better chance of selecting a solution that helps you meet them.
- What requirements must be met to solve that problem? In order to choose the right solution, you’ll need to understand your businesses and your users’ requirements. What does the system need to do in order to solve your problem or meet your opportunity? What conditions need to be met?
- Which requirements are most important? When buying anything, it’s important to focus on the “killer requirements” that meet your real needs. This applies just as much at home as at work. Even when buying something as “simple” as a washing machine, it’s tempting to get caught up in all the advanced features. But how many of those 150 wash programmes will you really need? Probably less than 10%. Focus on your core needs, whilst paying attention to how your needs might change in future. (If you were buying a washing machine, you may have additional requirements if you have a baby on the way – perhaps a larger drum size!). A similar thought process should be applied to purchasing software. How might your business plan and business strategy change over the coming years?
- What solutions are available? It’s easy to be drawn in by a well articulated pitch by a charismatic vendor. However, I would always recommend carrying out due diligence by considering a number of solutions or vendors. A few hours of Internet research, finding vendors websites and white papers is time well spent.
- Which solution is most appropriate? Having come up with a list of solutions, you’ll need to whittle it down to the most appropriate options. Refer back to your original requirements – how well does each solution meet them? Are there any gaps? If so, how will these gaps be filled? How does the licencing model work – how much will the solution cost you (in terms of hardware, software, development, support and training?). For large and strategic solutions you might want to issue a formal Request for Information (RFI)/Request for Proposal (RFP) (You can find more information about the RFI and RFP process here)
- How will it integrate with my existing systems and processes? Before choosing a solution, it is well worth considering how the new system will integrate with your existing IT systems and business processes.
- Will you need to customize/extend the package so that it works with your business process
- Or will you adapt your business processes so that they work with the out-of-the box package?
- What data does the new system need? How will it get there? What interfaces does it need to maintain?
By focussing on the problem that you are trying to solve, understanding your requirements you will find a solution that best fits your needs. IT is an investment. Avoid knee jerk reactions, and invest wisely. Good luck!
I hope you have found this article useful. How does your organisation select and buy IT? What are your experiences of “dinosaur” companies who have been paralysed by their legacy IT issues? I’d love to hear from you – please add a comment below.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet.
var sc_project=7776643;
var sc_invisible=1;
var sc_security="4f8cf775";
Great article Adrian! I could not agree more with your comments. I have also seen many of the unfortunate results that you predicted for organizations that don’t take the time to align their business and IT.
I have seen the company that has multiple systems that are not working together. I have seen the organizations that never design their systems to meet their needs and pay later.
I wrote an article about the same topic at http://ftpinc.ca/news/bid/123294/Aligning-IT-with-Business-Needs
Jonathan, thanks, I’m glad you enjoyed the article. Misalignment of business and IT seems to be all too common a problem — but what is frustrating is that it’s totally possible to avoid it. It seems that some organisations *don’t* have the time to do things properly (e.g. they jump on a solution without upfront analysis) … which means they’ll *have* to make time to do it twice! Untangling the spaghetti of silo-systems, processes (with some good-old-fashioned “end user computing” thrown in for good measure) can take much longer than implementing something of value in the first place. There’s some irony in there somewhere!!!
Thanks again for your comment.
Adrian.
PS – I read your article, and I really liked it. The embedded presentation is really powerful, thanks for sharing!