One of the most respected I.T. columnists for the last 25 years or more points out some of the latest failings at IBM in his most recent article here, entitled "Fulfilling customer requirements is a weapon at IBM"

Cringely has made a solid career and reputation by listening to what insiders at a company say about it. He's done it so long, that his channels for information are probably as good as those of the NSA or Volker Weber. A sure sign he's on the right track, is the report that "there is now a filter on the IBM corporate e-mail system that flags any messages that contain the word Cringely."

Cringely has been highly critical of IBM for several years - particularly since the company began a relentless campaign to reach $20 per share by 2015 no matter what it costs the company. Since that goal was announced, IBM has focused it's earnings per share efforts largely on cost cutting through employee reductions, transitioning as many remaining jobs to overseas data centers, and by spending as little as possible on current product lines. This last reminds me of what Computer Associates used to be famous for. They would buy a successful product, brand their name on it and continue to sell it on its reputation while spending as little as possible keeping it up to date and competitive, milking the revenue until the product became irrelevant.

Some of the latest bits include the following reports:

• The state of Pennsylvania cancelled an unemployment compensation system contract that was 42 months behind and $60 million over budget.
   
  
• IBM has been banned from the Australian state of Queensland after botching a $6.9 million SAP project that will now reportedly cost the people of Queensland $A1.2 billion to fix.
   
  
• Credit Suisse analyst Kulbinder Garcha says IBM has a cash flow problem and downgraded the stock.
   
  
• IBM’s Systems & Technology Group gave employees a mandary one week furlough at the end of August or beginning of September.
  

Good outsourcing vs. Bad outsourcing

The first two on that list strike me as emblematic of picking the wrong outsourcing partner. Cringlely's article talks about this in different terms, but for me the subject is quite personal. Over the years I've had discussions with clients many times who want me to compare my rates with what they can get by outsourcing to IT development centers overseas. What I usually tell them is that I'm not interested in competing at that price, but if their new relationship doesn't work out, I'll be here for them with no hard feelings. There's no point in arguing that the outsourcing vendor isn't capable -- because that's not really the problem.

The problem is that those kinds of vendors deliver exactly what you ask for without any analysis, discussion, or counter proposal. I've run into very few corporate project owners who don't think this is exactly what they want, and I've run into very few who can manage that kind of relationship as successfully as they think. They need an outsource partner who can help them get what they need, rather than just what they're asking for. You can't explain this successfully to a customer who hasn't experienced the project failures yet that result when they hire people who just do what they're asked and never raise questions.

It's the difference between a contractor and consultant. The IBM of the past was good at it. Today's IBM is not.

When I'm brought in to work on a significant development project as the lead, the first step is to sit down with the client and understand not just the requirements, but the goals behind the requirements and how the work they're asking for will impact the people using system. My job, at this stage is to use my experience to anticipate the unseen requirements, the potential problems, and the unintended consequences of the changes they're requesting. I do this through asking questions and getting them to walk me through both the current process and the updated process. If we have the right people in the room -- not just the project managers but also representatives of people who use the systems daily -- then during this phase they realize how the real world use differs from the project plan paperwork. We're able to adapt the plan and build what they need. Spending the right money up front on this kind of analysis prevents the kinds of disasters Cringley is pointing out.

IBM used to be the company you turned to when you had some massive technical job to do and no idea how to do it. They brought in teams of people who would help you get your hands around the project, then design a solution using whatever systems and processes it needed. The work of implementing was the tail end of the real project, and often wouldn't even be the part IBM did. Sadly, that's not the IBM of today, as the people of Queensland have learned when their failed project cost them 174 times the estimated cost. Today if you bring IBM in to solve that massive problem, you'd better already have your solution planned because IBM will give you just exactly what you ask for. If you don't ask for the right things and it fails, that's your own fault. If you do ask them to design your solution, you can bet it will be based as much on what IBM wants to sell as it will be based on what would actually be the best solution.

IBM will probably make a come back some day, when the people who have been there too long have retired and the right management team steps up. They've done it before, coming back from the dark days of antitrust, for example. It's going to be a long and painful process though.