Interesting views on IT development and why it goes wrong

Book Summary from CIOZone, about Robert Lewis’s book “Keep the Joint Running: A Manifesto for 21st Century IT. 


Main point: IT needs to be competent before any other improvement is possible.  If IT is not competent first, then metrics will only multiply by zero.  IT as order takers results in long, expensive failures, with no innovation.


Interesting notes:

·         it doesn’t pay to focus your time and energy on aligning IT with the business if you haven’t already demonstrated basic competence

·         The BIG PROJECT: "Projects tend to fail, enhancements always succeed."

o   Why enhancing existing systems succeed, where BIG PROJECTS fail:  “ they are simple, developers and end-users communicate directly, and they are short”

·         Internal users are NOT customers  “These people are consumers and not customers, he says. "IT needs to focus on exactly the same customer as everyone else in the enterprise: The real, paying, external customers," he adds.

o   Treating consumers like customers is BAD, because: “it reduces IT’s job to responding to internal requests. The business figures out what technology meets its needs and IT delivers it. That doesn’t allow IT to take a leadership role when it comes to identifying new technologies that can solve business problems.”

·         (it is) IT’s role is to ask: How do you want your operation to run differently and better? IT should not be asking what business users want the software to do.


About paulscho36

I like to simplify software. I love people who actually deliver software.
This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to Interesting views on IT development and why it goes wrong

  1. Jack says:

    Interesting thoughts Paul, I agree with this author and find it reassuring that the statement is really about the age old \’KISS\’ principle. When I joined my current company they had over 100 year long projects running. A large percentage of them were failing for a myriad of reasons… bottom line we are now running with quarterly client input meetings and monthly releases that stress simple enhancements. This of course serves two purposes, we can tailor our software and the client web experience specifically and we can control costs by lower resource commitment. If an enhancement goes wrong it only cost us 1/12 of what it used to and we can start work on a better solution right away not 12 months later. Clients are happy, Management is happy and the team is happy. Shorter deadlines for QA & UAT are tough but it also forces us to keep our foot on the gas. The Client\’s input has also been transformational for several of our other Clients and they have seen improved business process and revenue as a result… Thanks for sharing this insight.

  2. Ben says:

    I have to concur as well. It\’s critical for any solution provider in the organization (whether they are called IT or something else) to prove themselves competent. I\’ve seen the business rely on IT to deliver expecting them to be choosing the right tech etc but then IT fails to clearly understand what the business is actually saying they need when the ask for xyz. This results in the business having little confidence in the solution provider and starting to over function into choosing tech solutions. The business doesn\’t always say what they really need but they always say what they want. Solution providers have to get better at helping the business articulate what they need to accomplish and then provide a solution. I don\’t want an order taker because that doesn\’t require any thought. But i also think it\’s a problem to have 7different solution providers when it\’s unclear they talk to each other or are aware of what each is doing. Sometimes it feels like a competition and frankly I\’m not sure i want solution providers competing on the same solution. I do want them competing showing how well they can deliver but i don\’t want to see three groups seeming to overlap in solutions. That just makes me think they are broken and running with blinders on not concerned with what the business really needs.

  3. Hubert says:

    Yep I buy Lewis view that big projects should not be undertaken … instead turning big projects into more digestible and easily achievable enhancements, using adaptive methodologies, with high interactivity between developers and business users. In my professional life I have been involved in the deployment of six variations of a customer management and incident tracking system – and I have not even seen all of them. Every time we heard those big bold promises of how much brighter the world would be after we were on the new system. We have not talked about how much time and effort it takes to do the basics every time nor have we talked about the cost of changing the entire eco system around those core systems. Maybe it was good we were so busy doing the deployments that we could keep our eyes closed in front of all the things that we have missed: neither do we know our customers any better today, are our process fundamentally more automated or have we improved overall efficiency of the users we serve. But – and I am not sure if it is a “but” or a confirmation of Lewis’s views – we have not had a sound IT department either. One where I had the feeling they are sitting firmly in the saddle. Yes we always enjoyed blaming IT for our own shortcomings and IT ducked under our blames and every time we thought things are getting any better than the whole shop was reorganized to keep them busy for a good while with themselves. In our company nobody has ever asked “do you want Exchange, SendMail or Lotus Notes”. That discussion never happened, not even for a minute. When it comes to customer data we still tend to accept every department need to store, manager and retrieve their own customer data – no matter how little of the entire customer interaction that department really covers. We have chosen as a company that a Chief Architect and a strong IT department was a waste of money, we love to moan about the fact that multiple mail systems cost more money than one and that we do not have a seamless interaction between multiple mail systems (hope you get my twist here). From a technology perspective every one of the six systems I have experienced would have been capable of staying in place, be migrated bit by bit to a new platform: for a couple of cycles we twist the frontend, then do a couple of cycles changing the backend and when it needs to be put in a few cycles to introduce an effective middleware. Staying the pace and thinking long-term is what was missing in our world. Too much power in the business and too little in the IT world likely contributed to it as well. These kind of discussions remind me of the day when I walked thru Karnack temple in Egypt: the guide told us it took the ancient Egyptians 120 years to build that temple. Lay stone by stone, fill it up with sand and lay the next round. Then finish off the stone as they worked their way down again. The first thought in my mind was they probably did not change their management team every 18 months or if they did, then it could not have changed the direction every time. Realizing this thought was 4000 years old I got really impressed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s