I.T.I.S. (It’s The Information, Stupid!)

by drjim on August 1, 2008

IT departments talk about technology and not about information systems

IT departments talk about technology and not about information systems

Q: What’s wrong with IT departments today?

A: They don’t look or act like any other department in the rest of the company.

One glaring example of this rears its ugly head when business users ask for company information and the IT team responds with a discussion about the technology that either interconnects it or simply collects it. It turns out that there is a big difference between information (a.k.a. knowledge) and data. IT departments do a great job of collecting a lot of data; however, that’s not what anyone wants. What everyone wants is information – what you get when you process data. Somehow we need to come up with a way to get IT departments to shift their focus from gathering more data to providing more information services that will help the business do better.

Three professors, Arik Ragowsky, Paul Licker, and David Gefen have spent some time studying this issue and asking question such as what is the real job of a CIO? It turns out that a CIO should be spending his/her time managing the information that the company depends on in order to be successful in its business. What this means is that CIOs have to find a way to change their thinking and move away from worrying about how to deliver more data and start to think about how to provide more information services.

How did IT end up being a plumber and not an architect? Back in the old days (1960’s), all computers were mainframes and business folks had no idea how they did what they did. However, they appreciated what the Information Systems (IS) department produced and were more than willing to pay for them to keep doing it. When PCs arrived in the early 80’s, suddenly everyone knew more about how computers worked. IS was renamed to Information Technology (IT) and the IT folks started to focus more on the technology and less on the information that the technology was delivering. Vendors helped things along by starting to sell directly to end users. This is when things got all messed up!

Who’s to blame for the current situation? Well, we IT departments have more than our fair share to bear. All too often we interact with business customers using technology terms. When we do this we are seen as the “geeks” that we really are instead of business partners. What we should be doing is talking business with the business folks and reserving our technology discussions for when we are back within the IT department and talking with our teammates.

Final thought: hide the technology and the data from the business customers. Instead, talk with them about information systems and the types of information that they need in order to help the company be successful.

Be Sociable, Share!

{ 10 comments… read them below or add one }

Louis D. August 3, 2008 at 9:38 am

Seems to me that the right tools that help process the data in to a BSM type view go a long way towards helping the IT department talk about things the right way. When we’re caught in the weeds because our tools put us there, it’s that much harder to get out.

Reply

Dr. Jim Anderson August 6, 2008 at 12:23 pm

Louis makes a good point that Business Service Management (BSM) tools can help the transformation of data into information. However, I personally have always been just a bit leery of the big SAP / Oracle software solutions – done the wrong way they’ll not only put us in the weeds, they’ll submerge the car!

I guess the right answer is to let the information drive the solution. If the internal customer can express what they want to see, the solution (off the shelf or homegrown) should be come self evident.

Reply

Jay August 21, 2008 at 3:15 pm

“If the internal customer can express what they want to see.” That’s like the donkey pulling the cart explaining to the carrot where they are going.

I would even exercise caution using the, ‘let the information drive the solution’ approach. I have seen too many instances where that approach was embraced at the expense of user requirements. When technology takes the dominant position in the level of importance, it is very easy to underestimate the importance of meeting user requirements and expectations.

A significant benefit to in-house solutions is the control over the SDLC. Inexperience with the different methodologies only compound the problems of delivering a viable solution on time, within budget, and other project-related constraints.

Traditional SDLC methodologies often appear unattractive due in large part to the excessive amounts of planning and documentation involved. Projects encounter many problems during the conversion phases where logic is transitioned into physical. Problems in architecture are difficult to identify early on and lead to scope creep in the construction phases.

RAD methods are faster and appear to hold the dominant position in preference because of the faster life cycle. You are dealing more with prototypes people can interact with and early problem detection is reduced.

Problems here are that prototypes cannot be readily transformed into documentation in the event contractual disagreements arise. RAD methods also reciprocate a ‘release-and-patch’ mentality. They can also give stakeholders a false impression that solutions are closer to release than they actually are. Scope creep is also a factor with RAD projects because people can easily request modifications to the prototype that were never in the original specification/expectation descriptions.

I think the best position for IT departments is to establish the proper framework around which their customers (internal/external) are able to communicate their needs. This requires understanding the firm’s present-state and aligning it with the desired future-state. Only then will they be able to recommend viable solutions to the firm’s strategic intent.

Just my thoughts…

Reply

Dr. Jim Anderson August 22, 2008 at 3:36 pm

Jay, I hear you but I basically disagree. When you start talking about SDLC/RAD, etc. you’re too far down the rabbit hole. What I was originally trying to get to is that I think that IT does a lousy job of providing the rest of the company with tools that allow it to boost profits. We twist ourselves up into Scrum knots and then congratulate ourselves when we deliver something – even if it doesn’t really help anyone.

The best requirements collection process/tool will miss the mark if the customer really doesn’t know what they are asking for.

I think that it’s the job of IT to go out into the customer’s world and find out how we can help them – sorta like writing the requirements for them. They would then double check us and THEN we’re off and RADing to our hearts content.

What do you think?

Reply

Jay August 28, 2008 at 2:53 pm

Based on that perspective, I think it falls back on the middle and upper management to ‘educate’ their workforce on how to properly perform their related tasks, and what role those tasks play in the larger scheme of things.

This way, when the IT department is approached and asked to deliver some form of business process automation (BPA), business process improvement (BPI) or business process re-engineering (BPR) utility, they don’t get a room full of blank stares when they ask for requirements.

This isn’t to be confused with an employee needing to know how their process should be integrated or augmented with technology solutions… but at the very least, they should know their jobs inside and out.

I have seen a thousand projects where developers were ran through ‘crash course’ training to familiarize them with project-business dependencies in order for them to more affectively ‘assume’ requirements. It was usually very time-consuming with little or no return on investment.

It is really no different than when you lobby the upper management for support on continuity planning either. They don’t like pulling people away from their daily tasks to facilitate another project that has no immediate ROI. You often get mediocre or substandard task performers instead of the elite ones.

It begs the question… are these REALLY the people you want contributing to your next ‘profit boosting’ tool? Are these the most innovative skills sets the company has available?

If you don’t take the time to do it right the first time, what makes you think you find the time to do it right later? Yes, requirements are important, but certainly not the only critical component that decides project failure.

Reply

Dr. Jim Anderson September 1, 2008 at 8:56 pm

All good points; however, you missed the key one – just how to get the IT staff aware of how the business works? The trick here is that, as you said, you can't run them through a quick "here's how the business runs" course – they'll forget it before they walk out the door.

Rather, IT understanding of the complete business is something that has to happen constantly and over time. I'm a big booster of "lunch & learns" when the company pays for lunch. Having the business side of the house attend the project kick off is key and having them host a feedback session a month after the product is delivered can also be a big help.

No silver bullets here, just lots of small steps.

Reply

Jay September 10, 2008 at 2:12 pm

I agree with the IT department having a much better understanding of the business model within their organization. If for no other reason than innovation can take place ‘anywhere’ within the infrastructure. I learned the ‘crash course’ lessons the hard way, I built illustration systems for the Insurance Industry.

There was simply too much information for me to learn and model into the design within the project’s official time line. The course wasn’t organized very well, and the content had significant gaps between operational functions and industry/government regulations. It forced large blocks of scope creep into the project due to re-work required on core components of the system. Things that could – no, should have been avoided from the beginning.

I agree, firms must embrace methods of sharing knowledge across functional business units. I have participated in many ‘brown bag’ session similar to the one you identified as lunch & learns. It can be an effective tool for disseminating information, but how effective did you find it at actually ‘teaching’ participants?

Why lunch? After attending several of these events, I quickly picked up on new levels of resentment from the staff. Learning while eating or digesting your food can be a troublesome combination. Most of the staff wanted to do personal errands, take a break from work, or just socialize with other co-workers in an acceptable ‘off-duty’ format.

I still support it because it represents an effort to improve the knowledge base of the staff. I just wish management wouldn’t see it as the ‘only’ tool available. I prefer cross-functional team environments actively working projects. Select members from stakeholder departments, and drive early adoption through active participation.

I can’t tell you how many times a ‘key’ player was brought in too late. I realize it’s ‘never too late’. However, involving production engineers ‘after’ the planning stage is over is a clear mistake. I believe Steve Jobs, CEO of Apple, learned this valuable lesson when he designed the Macintosh before he consulted engineers only to find his design couldn’t ‘fit’ in the case itself. Another time, he pushed for Personal Computers ‘without’ fans because he believed noise reduction was an essential selling point.

Lol, this is where ‘chip creep’ enters the computer industry. Boards and sockets would expand and contract working the chips out of their sockets, breaking contact resulting in immediate shut downs. It was a disaster. Apple’s ‘suggested fix’ was to lift the front of the machine approximately 6 inches off of the desk and let it drop in the hopes that the chips would reseat themselves.

Agreed, no silver bullets. Effectively incorporating methods of educating the workforce should be a primary consideration for any firm interesting in institutionalizing competencies.

Reply

Dr. Jim Anderson September 10, 2008 at 2:39 pm

Jay: ouch! There’s nothing sadder than when a lunch & learn goes bad! It’s always been my thought that if having the info exchanged is important, then the company should pay for the food. It’s a cheap way to do knowledge transfer and everyone will come if only for the food!

Reply

Peony October 29, 2008 at 5:08 am

Good for people to know.

Reply

Production Planning December 10, 2009 at 5:14 am

This is one of the most useful posts I found. Thank You.

Reply

Leave a Comment

{ 1 trackback }

Previous post:

Next post: