Val tweeted this and I kind of took exception to it as no where in the linked marketing fluff does it actually say that NetApp enabled Guitar Hero to beat Rockband to market. But it lead me to thinking about something; can a change in technology really lead to this kind of advantage?
I don't think that the answer is all that clear cut, a change in technology can be the catalyst which enables a change in process; this can lead to an advantage. But is that change in technology actually necessary to enable to the change in process? And does the investment in new technology really pay off and how do you know?
Marketing fluff is not a good place to start in evaluating whether new technology will actually pay off for you.
No CIO is going to get up and say to his boss, 'You know that new technology that we bought, well it's a piece of crap! I was totally lead astray by the shiny-shiny lights and boy do I have egg on my face now!'
Equally no CIO is going to get up and say to his boss, 'That new technology that we bought well it's excellent and it has completely changed the way we work! But you know what, we didn't need to change the technology really, we could have just changed the way we work!'
So what happens is a jolly little cosey-up; a nice deal is cut, a bit of marketing fluff is sometimes agreed as exchange for a really great deal on price and everyone's happy.
Cynical? Yes very! Does it happen? Sure it does, all the time. Whenever I see a press-release or a case-study, I always ask myself what deal was done to enable this; free services, an extra couple of points of discount?
Sometimes, I think that we fail to see the wood for the trees in IT. If we want to institute major change; we change everything, whether we need to or not. How often do we see the tag-line 'This Changes Everything!'? How often does the question get asked whether everything needs to be changed as opposed to just changing something? As technologists, we look to change technology first and process second.
All the changes that Chuck et all are talking about, evangelising about are completely worthless without process change but many of the benefits can be felt with a process change. You do not need a technology change to achieve many of the benefits or if you do; it does not need to be a huge technology change.
Actually if you try to do this without a huge technology change; you may reap more benefits. The problem with large technology changes is that you often fail to do anything with the legacy tail; you simply deploy new stuff onto the new technology. The legacy just sits and moulders, costing money to maintain and manage. Of course you could simply just decide not to maintain the legacy, which will save you money in the short-term but when it breaks, you could find yourself spend even more money trying to fix a system which no-one really understands. If you try to change the process before rolling in the new technology, you will probably stand a greater chance of dealing with the legacy tail.
So don't expect miracles from a change in technology!
Without process change, technology changes are probably just cost!
People Trump Processes Trump Technology
Don't simply accept a vendor's claim that the only way to change your processes is to change to their technology!
When caught up in the new, don't forget the stuff your business runs on today!
Marketing folks even lie in their sleep, their dreams are the lies they plan to tell you tomorrow!
Martin
Love the bit about “marketing people lie in their sleep …” I actually had to ponder that one for a moment.
The point about “people trump process trump technology” cannot be overstated, so thanks. I end up spending most of my time with customers talking about the “3Ps” — people, process and politics.
The good news is that it’s now far more common to meet a senior IT leader who thinks in terms of organizational change first, technology change second.
Indeed, I wrote a post about “lighthouse projects” being justified solely on their ability to accelerate this sort of change.
Part of the equation, I believe, is to be very clear with people around what sorts of opportunities they will have post-change. Won’t solve the problem, but it’ll help.
Thanks again for a thoughtful post.
— Chuck
I saw the post where you talk about ‘Lighthouse Projects’ and they concern me. I think that we have to be very careful that everyone does not just turn to where the light is and focus on that; there is a huge legacy tail out there which will also need dealing with.
It’s very easy to deploy new stuff onto new stuff, it is harder to take that old stuff and move it onto new stuff and deal with new realities. For example, lots of corporates still have Mainframes and the whole support infrastructure which goes a long with that. There are two reasons for this
1) The mainframe is still the right place for the application
2) No-one has a clue how it works and have no idea how to get off it.
Now 1) may ultimately lead to 2); the mainframe was the right place for the application, so it got left there but it is no longer the right place for the application but so much time has passed that 2) is now the reality.
The same thing will happen with legacy Unix systems; replatforming would probably be the right thing to do but the pay-off on the investment of replatforming could be two-three years hence. The tenure of most senior IT managers means that this is not worth doing because it does not contribute to this year’s bonus.
IT suffers from a lot of tactical thinking with very little strategic positioning. Arguably things change so fast that this is often inevitable. But let me give you an example where this is not really inevitable but enforced by the behaviours of another factor.
IT Suppliers like to shuffle the deck on their sales-teams; it appears from looking outside that once a sales-person has got to know an account well, knows the customer’s business well and can add value; they are shuffled. All that knowledge, all the good relationships and trust which has built up is gone. So sales-teams are almost conditioned to think short-term and not strategically. Why invest time in what might be an 18-24 month process doing what is right for the customer? You could be moved off that account and loose all that investment of time and energy.
From a customer point of view, this is incredibly frustrating; especially when you are working on long term, multi-dimensional projects.
One of the first lessons I learned after graduating was the mantra “simplify, integrate, automate”. Toyota’s most efficient engine plant in the 1980s had no robots at all, technology should only ever be an enabler to efficient processes. Far too often we are seduced into buying technological panacea solutions to what are, in the end, organisationsl problems – and then we wonder why the ROI does not stack up.
A challenge: next time you put forward a proposal based on an ROI prediction, build into the project a way of measuring the actual ROI. This is deeply scary but we should do it anyway.