Is IT a Profession or Bureaucracy?

Very interesting point of view but it's way to generalized to really amount to anything.

I've worked in IT over the past 14 years and a lot of what is mentioned here can be related to personality traits rather than performance. Ensuring you hire well rounded employees with other interests than just computers and video games and you might find some great individuals who are hard working, looking for a challange and not willing to back down from what is right.

The old GEEK factor assumption is prominent in our industry but there are some really great IT pros out there, too. Good leadership can always create good employees or weed out the bad ones.

Maybe some of us need some help with social skills in the work place but in my experience most of us want to do a good job when given the chance.

Good leadership is key. Get active, pay attention and most importantly listen to others. Team building, team work and group objectives are also very benificial.

It's always nice to hear one of our own waxing on about our lack of reliability, commitment, curiosity, integrity, intelligence, ability, work ethic, blah, blah, blah.

I suppose you could replace "IT" with just about any profession (accounting, medicine, plumbing, etc.) and find plenty of argument to justify the self-deprecation.

I would add two points to this excellent discussion.

IT organizations fear and loathing of metrics. This is particularly true when expressed as cost reductions or other quantifiable and measurable productivity improvements.

IT organizations find methodologies abhorrent. Why is the concept of a project plan or process analysis and managment so difficult to accept? As Six Sigma or similar methodologies proliferate IT will find itself left behind by their customers.

Very true. I've been saying this for years.

IT thinks it is the keeper of the gate, keeper of the keys to the technology.

The business side could care less what technology runs, as long as it does what it is supposed too when it is supposed to.

I disagree on one thing, when you say there are no high level platforms to develop new software in.

Visual Foxpro with a SQL Server or MySQL server backend is something that will develop every component necessary to run a company, but microsoft has phased it out in favor of their toy "Access" and IT has phased it out because they don't understand it.

Funny thing is, there are still ton's of critical applications running under foxpro DOS or windows.

You want to fix these types of problems, you get people like myself who understand the IT Side and the BUSINESS SIDE back to work and give us the ability to make the business goals our own goals and we will drive the changes that are necessary.

Problem is, I've been put out to pasture as have a lot of other good people who went directly into the military instead of college and we've been too busy acquiring actual skills and experience that lets us know what works and what doesn't to go to college full time.

One other thing you need to add to your list, is get the HR department out of the selection process and put them back to checking references, etc.

A good engineer or IT person can tell from talking to somebody if they are qualified or if they have the skills that you can build on.

Believe me, there is no shortage of IT people out there, but there are ton's of IT people like myself that are trying to reinvent themselves because we can't get jobs in the IT business because we can't get past the HR dept and whats worse is we have the skills to clean up the mess that has been invented by the MBA's with no experience and the bean counters who don't even realize that the reason they can't sell their products here in the states is because they're sending all of the money that could be utilized to purchase their products offshore to people who won't purchase their products...

Perfect! I am in IT for 20+ years, am a CxO. Some would say you have broad brushed, but that would be by those who were sucessful in IT careers.

I agree that these problems exist in far more abundance than is needed. However, the other side is infrustructure costs with training, constant upgrades to software because of poor programming by developers who already or should already know that a rush to market has caused this current state. Greed is costly!

What is needed is a standardized, centralized, constant that can adjust to upgrades in a lowest cost mentality. Profit making is the purpose of business; however, spending now appears to have the handle in driving up costs to the consumer, which in turn drives down the consumer will and profit margins to keep up with this IT mentality.

I have worked in IT for 25 years and disagree with many of the generalizations made. One thing I know for sure, I'm glad I don't work where Spano works ! Sounds like a stale team of pros.

IT is also a tyranny and sometimes not benign. IT managers seem to lack the ability manage a conversation between geeks. They have so little understanding of human nature that they allow disagreements to fester until they've drained all unity out of their teams. Because of the intellectual fear I've seen little or no innovation within a company in 13 years. And I've worked for some big companies too.

When people start their "careers" after college they usually have the mistaken belief that they are there to be a technologist. They want to apply their skills. It is so often not the case. In a business setting, trained CompSci types are completely over qualified for most of the jobs. A kid who once pulled all-nighters writing software, now pulls all-nighters watching files copy down to test from prod on a painfully slow network which no one has the budget to fix or even the desire undertake the pain if they did.

If it were me, I would advise any company to outsource and divest itself of as many IT personnel as possible. If business managers knew how much excess wasted capacity they have because the geeks can't/won't communicate with each other or are too scared they'd fire their CIOs.

There is no innovation in a tyranny.

Old timer with 26 years, just asked to resign by management in February. Now, still looking for employment. I call it the Microsoft attitude, most all business have adopted the MS software products which are always released full of known bugs, but have made the corporation profit.

All IT management are adapting the attitude to buy what is best marketed products rather than the products recommended by the old timers that perform without being rebooted every few hours. Even manufacturing companies are adopting the MS attitude, that a certain percentage of failures is acceptable as long as a profit is still being made.

No one seems to seek perfection or the best any more, instead it is the most profitable.

The Blog's Author Responds

Great dialogue. Based on reading the comments I feel compelled to offer one clarification. The observations I documented are based on an analysis of a large number of IT organizations.

While these traits are commonly found across a variety of organizations and technologies, they don't necessarily apply to all organizations and all IT professionals.

For those of you who take exception based on your individual circumstances, I say great. It is encouraging to read the positive observations that some of you are providing.

Wow. I'd say this pretty much hits the nail on the head. Especially in larger organizations you can witness all eight points first hand.

The point about older developers being considered obsolete is valid, but I would generalize it by saying that the IT industry is one that forgets. We forget the problems that were solved in the past and repeat them again and again. I just came across a new date field added with a 2-digit year!

I guess that programmer can count on being retired before it becomes a problem.

I would say that you find a few of these characteristics in most "experienced" CIOs today. I am in no way implying that all 50 years of age or older CIOs think this way; but let's face it.

Bureaucratic, backside-covering, non-commital thought processes don't cut it today. The successful leader is the one who challenges things that "have always been done that way," thinks outside the box and is willing to lay it on the line.

I witness a lot of posturing by "experienced" executives who either don't understand the technology nowadays or were promoted up from the hardware side and don't understand the value or necessity of partnering with the rest of the business. It is clear that some of this behavior is CYA and job protection; but increasingly, it appears to be a plain lack of knowledge of how to perform at the senior level.

Senior leaders need to be able to handle the political pressures at their level; but they also need to able to understand and promote the technology (software and hardware) within their organization.

I often see more emphasis on the political skills versus the technical prowess. And, let's be clear here, it is unreasonable to expect senior leaders to be low-level experts in technology; but it is reasonable to expect them to talk the talk at the 10,000- and even 5,000-foot level.

I have worked in IT for 16 years. In my 20s, I was consistently stifled due to my age. It just wasn't "right" for a 20-something to run a group or a department. Now, in my 30s, I am the leader or replacement for those who think that way.

As our profession continues to mature I hope to see more individuals with the right mindset moving up the ranks. I am optimistic that the people who demonstrate most of these characteristics are a dying breed in our profession because they are truly doing a disservice to the profession. Only then can IT be viewed as a business partner and leader instead of a cost center.

I agree these issues represent symptoms seen within many IT shops.

Having spent time on both the business side and IT side, I have seen these play out in many environments. My experience tends to indicate this occurs when there is lack of clairty within the organization as to the role IT is to play and a lack of alignment between an IT strategy and the organization's strategy. Consequently the maturity level in the IT function often fails to rise to the necessary level to support the organization's needs.

Most of today's IT shops began as data processing shops, where the role was more around automating manual accounting functions of some type. The goal for DP was throughput and efficiency. How many transactions can be throughput, how accurate were they and how cheaply can you do it?

Things like business intelligence, integration of systems and business processes, data quality and user friendly were not concerns of DP shops. From the business side, since business processes were not integrated into data processing there was little concern about understanding what was going on in the skunk-works of DP.

Needless to say, the world has changed. Unfortunately, many IT shops still have the financial and executive management support and culture that supports data processing and not what we call IT today. The failure to make the transition from DP to IT is what drives these issues. It is a leadership thing and a maturity thing.

As Stephen Covey said many years ago, every organization is perfectly aligned to get the results it gets. Many organizations are still aligned to do DP work, not the work that is required in today's IT environments. Many organizations still see IT as a cost to be minimized rather than a value enabler.

The failure to realign clearly falls in the laps of those in leadership of these organizations. This is the result of the business side failing to grow their knowledge of what the "techies" do and how those tools can be used to add value to the business, and the "techies" failing to grow their knowledge about what the business side does to keep the organization in business. Both sides tend to see the other as something they do not need to be concerned about. That is a major mistake.

Having worked in IT for more than 27 years, I would mostly agree with Spanos.

The problem as I see it is there is no way of assessing the value of what IT does. Yes, yes, we can look at up-time, redundancy and desaster recovery processes but there is no metrics for measuring value production.

When we implement Six Sigma, BPR, CRM, ERP and all the other TLA's you can think of, we never understand the totality of the impact IT changes are going both internally and from the customer's prospective.

IT needs to champion value production in the form of changing value steams and the potential value vs. harm. We need to look at the company behavior changes and uses of software and solutions and what they affect. We need to see how those behavior changes will improve the deliver of products and services.

Where to begin?

1. From the September 13 editorial IT's Bad Reputation by Eric Chabrow: "None other than Gary Hamel, arguably the world's preeminent authority of management strategy, cautions against turning to the IT department. 'When you want to run a quick experiment, I tell people don't go through the IT division because they are just going to tell you, no.'"

I thought that sentiment applied to the finance department, where if you can't assure a sufficient ROI, the project isn't considered.

IT doesn't have the authority to innovate. Marketing or sales might. Accounting might even get creative. But the business runs on IT as much as it runs on the telephone or the elevator where reliability is paramount. The IT vendors ought to innovate and corporations ought to implement proven technologies.

2. From the October 23 article Is IT a Profession or Bureaucracy? by Nicholas Spanos (see entry above): "Many IT pros react and want to be told exactly what to do. If they do not receive specific instructions, they either guess or they keep asking for a level of specificity the business is unable to provide."

IT projects generally starts with user requirements. Enough said?

Sure, an infrastructure is a prerequisite, but everyone except the start-up already has one. Want to re-platform? Forget about technological innovation. Where's the ROI?

3. Actually, the Spanos article appears to be an attempt to create controversy. Being so one-sided it's hard to take seriously.

Corporations face profitability pressure and budgetary constraints. IT would love to have a skunk works.

This is not really a problem. Sell more product at a higher price and you'll have the funds to invest in technological innovation, or to increase the rainy day fund or the stockholder dividend.

Some of Spanos' comments are way off the mark.

In the IT profession, experience is not a negative. As a CIO who is nearly always in hiring mode, I find experienced IT personnel far more valuable than someone who comes out of school with a fistful of certifications but not a clue as to 1) what the average user needs to do their job, 2) how the business uses IT resources from process-level perspective and 3) how enterprise-wide systems need to integrate.

Experienced IT staffers know how systems really work, rather than how the vendors would like us to believe they do.

Also, as far as his definition of a CIO as either a top geek or clueless C-level suit, I would suggest most are far more stategic in their thinking than Spanos gives them credit for. He must have worked with some really marginal CIOs.

For the most part, I think Mr. Spanos has some good points. One could even take the next step and say those individuals and IT organizations that foster behavior/norms/microcultures that acknowledge these obstacles while also making a consious effort to conquer these issues, will be a leg up on the competition, provide superior while producing quality product.

Unless IT, in all its facets (applications, network, services and management) become an intergal part of the Business Unit Model, there is a threat of items 1, 6, 7, & 8.

As far as the issue of career path, that is a personal obstacle. Very few people that know what they want to do, are not doing it. And, if they are not doing it, it is usually be due economic, familial, or social constraints.

The bigger problem is, the vast majority of Americans don't really know what they want to be when they grow up.

Even after they have grown up. We are living in a time when saying " I want to be a software developer" isn't enough. One needs vision, tenacity, commitment and, ultimately, a decision.

Our industry is changing. Ten years ago, it was thought technical skills were all one needs to excel in IT. That paradigm has changed. Communication skill, the ability to manage partners and vendors, a understanding of how the enterprise functions as well as how your role fits into the larger picture. How to effectively research and make decisions. How to adapt to the changing environs and continue to build skills as one gets older.

These have all become just as important as technical skills.

Just a few comments...

Reactive Profession: This is not exclusive to this profession but rather individuals or the leadership who governs what autonomy or forward thinking their subservient/support departments can operate with.

Lack of Career Path: This seems to be true in many subspecialty fields.

Rigidity: Absolutely agree.

Lack of Commitment: This is the way of the past. If you look at successful IT groups within sucessful companies, you will see that this is very much not the case.

Denial: This is prevelant in companies where leadership, accountability and sucess have a poor track record.

The comments have a grain of truth in them. The causes are not so clear.

As a lifetime entrepreneur and having spent just a couple of years leading application development in a financial services firm, I have a little different perspective. I was hired specifically because I would innovate, take risks and confront the status quo. It's really hard. Business moves fast. Business demands for IT come faster than IT can respond. IT budgets don't allow for R&D.

I think the only hope for IT to stay ahead of business is to adopt new methodologies and architectural practices. Agile can help. SOA can help.

I found that business leaders really liked agile--it was the old IT types who resisted. Agile does make commitments: but only about two weeks out. Anything more would be irresponsible. SOA is much much harder. But you need to grab little wins wherever you can find them and make incremental steps towards a more flexible software infrastructure.

I agree that IT is a bureaucracy. I work in a K-12 school system and his description is right on for each point.

* Reactive Profession
* Lack of Career Path
* Unreliable Technology
* Rigidity
* Leadership Void
* Lack of Curiosity
* Lack of Commitment
* Denial

Best yet, this department has created the ultimate blame it on the users plan: "site-based management."

Originally it was to be used by educators to tailor their school to fit their area demographics, allowing the principal to hire/fire staff. The IT management is using it to lay off all responsibility of a school's computer system to the local tech, usually a teacher, to figure out what they need and provides support in a very limited fashion.

Most techs do not know what to do and many are overwhelmed, exceptions exist, but the overall effect creates a patchwork quilt of applications, operating systems, hardware and every combination of a mess.

IT management usually over reacts to any change and throws money at vendors rather than trust their own staff to evaluate and determine a fix or change in method.
The vendors sell their solution to an problem, which usually doesn't exist, then management wonders why it failed. Then, they repeat the cycle with other vendors.

Also, the department is stuck in a "big iron" age where centralized systems meant control. It's an illusion and a day which will never return.

One of the readers accused me of being controversial. My response: He is absolutely correct.

Benign opinions do not generate a healthy debate. Ultimately, it doesn't matter whether the readers agree or disagree with my observations. The effectiveness of IT is an important topic that must be discussed and debated.

I would hope these discussions are continued within your own organizations. Important changes begin with a healthy debate on the nature of the problem and the possible solution options.

To all who have responded, thank you for your insights. In some cases, your responses help me to confirm my observations. Some of your comments have caused me to re-visit the topics from a different perspective.

I agree with the broad brush comments, and have observed all of these traits and behaviors in over 40 years in the IT business. Fortunately, I have always considered myself a business man that just happens to have the ability to bring technical solutions to business problems.

I find it interesting that no one has commented on the place that IT should truly have in the business. I am referring to a statement that I read recently that in my opinion sums up all of the issues that business has had with IT all these years. It goes something like; There are NO IT projects, only business projects enabled by technology.

Stop and think about it, the issues that Mr. Spanos is commenting on stem from the fact that IT, for the most part, has always been put in the position of being expected to lead business projects that have far reaching process and people implications beyond the technology solution. This is OK, as long as all the players understand that IT can facilitate a business solution as long as the SME's from each business unit are doing their part.

Good subject for discussion and excellent reader comments. There are some fundamental issues with IT career management:

Many IT people get into the job for the wrong reasons. They do not understand what the job is about, how valuable their efforts can be to an organization and what an excellent IT profession looks like.

There is a poor balance of personalities and genders in the IT workforce. The profile is too focused on a small skillset. There is a lack of big picture vision.

Colleges to not qualify students adequately, neither do they weed out the the underachievers.

Employers often expect tech grads to be complete and qualified professionals, when in fact they are a work in progress that needs structure and mentoring.

(Editor: See 6 Key Skills CIOs Seek in Entry-Level Workers.)

Poorly performing IT people are frequently not recognized, not held to accountable standards of performance and are not given career paths suitable to their potential.

Alonsc, Foot Soldier and ricardo make excellent counter points to this rather feable attempt to discredit IT.

The value, efficiency and product that IT contributes to, given the almost unspeakable amount of variables in play with IT, is often understated or not considered at all.

Does accounting projects have any physical variables (like someone else's manufactured hardware, software and connectivity) as well as business and corporate culture variables. The answer is no. The hoops IT has to jump through and the balance IT has maintain is much more complex and difficult than many other fields of profession.

Accounting is accounting is accounting, etc. IT is ever changing and is different than even a few years ago. Given that IT is responsible for supporting the corporate infrastructure as well as contributing to the product, keeping up with the constant IT changes is a monumental task. You then ask for innovation with ROI parameters, well IT does it as good as they can, given the paramiters they work in, and often inspite of a lack of positive commitment.

Kudos to IT, the CIO's and the tech people who work very hard in thankless spotlights!!

While I do agree accounting has pretty much peaked as a technology, the innovations in the practice of accounting are just as spastic as the change curve in IT.

It is odd; some see this as an attempt to discredit IT while others see this as an honest dialogue and an honest attempt to intelligently discuss perceived negative aspects of IT, not all IT employees.

God Bless America!

I'm new to the CIO role and have found the greatest challenge to be the lack of comprehension and buy-in from other executives and their own teams. The CFO thinks IT should report to finance (apparently IT strategy is a cost centre) and pretty much every other executive thinks IT should just implement solutions without needing any collaboration from their team members. It seems every other team is too busy earning money for the company but IT just sits around all day waiting for helpdesk calls and costing money.

Despite this lack of collaboration IT is expected to then take ownership of all solutions and as a consequence carry the can when solutions don't properly fit with company strategy.

And, we should do all this at limited cost because apparently every IT professional is multi-skilled in programming, business analysis, project management and every other aspect of IT, so why should anyone need to pay for SLAs, consultants, project managers, etc., etc.? (And, of course, we should be accountants and engineers and sales managers too so then we wouldn't NEED other teams to collaborate.)

And, certainly IT personnel should never get training in business skills like supervision, management, budgeting. That should be left to the real professionals. Which kind of means to me that a lack of IT professionals skilled in business management is a self-fulfilling prophecy.

In my experience, companies SAY they want strategic inititatives from IT. But they don't want to participate, they don't want to pay and they don't understand that good strategic solutions happen when the whole company takes ownership.

In actual fact, other business units (and many IT professionals) don't understand that IT is NOT a service. IT is a valid, (in)valuable, indispensible contributor to company profitability, and I don't think the other business units like the idea that they can no longer do their jobs without us.

Nick makes some valid observations, but I do want to note that there are good and bad IT professionals, departments and CIO's out there.

I'm a project/program manager in a staff group at a major international corporation with a liaison role between the business and IT. We don't even have a CIO, so there's little if any accountability for the failures in our IT organization.

I have seen projects run like clockwork and others that have blown up like the Hindenburg. I've had more than my fair share of headaches dealing with non-responsive IT resources and lacking management over the past 10 years.

I have a saying I stole from someone else many years ago that I still tell my project teams on a fairly frequent basis - don't bring me problems, bring me solutions.

Outsourcing the knowledge-based positions has been the bane of my existence. Every time corporate demands cost reductions, IT sheds a percentage of its (typically co-located) resources and the business' projects come to a stand still. This is not because IT wants to reduce headcount, but because CxO's have no understanding of the value that IT really provides, IT has no good metrics to show its value, and they are traditionally viewed as nothing but overhead.

Even worse, IT management "professionals" decide to off-shore those positions under the pretense of achieving cost reductions through billing rates. But if it takes a "developer" in Bangalore 65 billable hours to do the same work I can have done in-house in 20 hours, the 60% rate decrease goes out the window. As does the project's schedule and the project manager's patience. The level of rework that has to be done, the redundant test cycles with each build and the level of detail required in the tech specs do not justify the move.

All this said, IT organizations as a whole need to develop and provide career paths for their staff, promote continuing education and personal development, open the doors to the business in support of honest collaboration, dedicate resources to pursue innovative solutions, and rationalize the platforms they will agree to support. And get away from the "Big Bang" release strategy; go Agile, it's faster, cheaper and much more effective.

If any CIOs are out there reading Nick's observations and have made it this far down the response chain, take the simple advice I share here, and you'll be able to change your team's reputation in very short order.

Nick, thanks for the discussion and putting it out there.

Disgruntled CIO Nails It!

Whenever a profession is compared to a bureaucracy with the listed items above, discredit is a fair assessment. The commitment to IT needs to be as positive as it is to any other group. As long as IT and other support areas are treated as second-class citizens, businesses with these "perceived" negative views of IT will continue to reap what they sow.

"But they don't want to participate, they don't want to pay and they don't understand that good strategic solutions happen when the whole company takes ownership."

The above quote says it all.

It took years for CEOs and other executives to admit IT to the board room and to give the field and its personnel its credence. And it was reluctant then, and to a large extent, still is today. Costs, Power struggles, turf battles, lack of support, and a reluctant acknowledgement of IT, the profession and its personnel, all have contributed to these "perceived" negative views and have hindered this field almost since its inception. Many of the items listed above are legacy issues that have grown from the negative reception IT received in the beginning. And it all stemmed from this "IT" eating into the bottom line.

And in spite all of these hindrances, all the successes of businesses around the world are in part because IT works hard through these many obstacles, changes, and negative perceptions bestowed upon it.

By comparison, IT is a field in its infancy and will continue to evolve in the business world. But a change in how it is embraced by management deserves a fair review. When positive commitment comes, and when a company does share in the responsibility of IT succeeding, and takes whole ownership, truly great things can happen.

But while it still gets banged around by management and personnel, IT will still continue to support, contribute and innovate like no other group.

This "is" a great discussion on the perceived negatives in IT.

And nothing comes close to the change curve in IT. So much for the intelligent discussion.

God Bless America!

I happen to largely agree with Nick. I am a 32-year veteran who has taken on many of the challenges faced above. I would say the lack of professionalism is rampant in our industry and frequently masked by processes designed to offset or obscure incompetence.

Twenty years ago we were having the same debates. But again smart young grads with good hair and MBAs tried to enforce change by layering ever increasing processes that overly complicated the relationship with the true customers of IT. Many corporations today work from a premise of paternalism or even outright ineptitude to avoid dealing with individuals who have massively failed to deliver but somehow are never held accountable.

The fiascos in IT today parallel those of many corporate blunders of the past, and yet in an attempt to shield share prices and prevent accountability for hitting truly where it belongs, these items are glossed over.

If this were the medical profession, the number of dead patients would bankrupt many an insurance corporation and bring the masses yelling to ask if possibly "leeching really were not more effective".

Again on the point of experience. Everything that is old is new again, and many of the most experienced and absolutely qualified professionals are again largely ignored for young MBA's who somehow by reasoning of this relatively finite and pointless degree are deemed at 30 to be the quintessential saviors of IT, only to fade into the mass of middle and project managers who produce marginal results at best; and a worse total destroy the effectiveness of dedicated individuals trying to make a difference.

On the point of languages... this is where I disagree. There is a trade off, and any one who truly knows languages would have to admit that JAVA and C++ are anything but close to Assembly. In fact the difference is like similar to that of addition tables to integral mathematics. The power of these languages is in that so much can be done with so little. While there are better languages on the market, they have been marginalized by the big commercial engines of industry in enigmatic collaboration of higher learning institutions.

Only when our organization is not held as a group but the various disciplines within it (such as architecture) are raised to a professional level and held accountable for their failures in the same way bar associations manage lawyers, or accounting associations hold sway of accountants will our profession truly progress. Even in medicine there are numerous disciplines with various governance bodies. Also only once governance is externalized from corporate organization, will true accountability and then professionalism truly infuse itself with our industry.

Even though some things in this article may hit close to the mark - they are very one sided and sort of hit a nerve.

1. Reactive Profession. How about dumped on profession? No offense but most IT groups I have been involved with are so over worked they don't have time to do anything but react. Companies don't want to invest in the additional labor.

Not only that but more to the point in the list - it is a communication problem. IT wants to know what the end goal of something is and the "customer" doesn't even know that. Add in the fact that not only does the business not know what they want in the first place and can not articulate it, they change their mind 20 times during the process. So in the end, you have a hodgepodge that doesn't work. So yes, IT wants to be told what exactly to do BUT you better know how to ask for what you want.

2. Lack of Career path. Very true; is it any different then business in general though?

3. Don't blame it on the "unreliable" technology. This goes back to my answer to number 1. In all honesty most of the "new" program languages are just there because of media hype caught the attention of an executive who then demanded them. Most of them are not scalable or very poor performance wise and too vulnerable to other changes in a PC. I think just the opposite is true of what was said.

4. Partially true. We are going through this. The problem here is that there is no such thing as a one size fit's all ERP package. Yes they are fairly rigid - no 2 companies do much the same and to build total flexibility in is 20-30 years away if it is possible.. And often there is VERY good reason for some of the rigidity. But who will, in this day and age, pay and wait to have a system developed just for them? Even though in the end they may as well have because it will cost the same and take just as long to develop. It is again poor business management practices rearing their head. I see way to much media influence and the they are doing it so we should mentality in management.

5. And isn't it the same on the business side? Totally.

6. Mostly BS. It is not due to a lack of curiosity it is more about lack of time and resources. I have seen some of the methods that are applied. If you can not fix a computer in 5 minutes then image it in a total of 10 more and you are off to your next problem. You don't waste the employee's time or your own chasing down a small problem. It is simply economics for the most part. When something is down, the business will not let you take the time to figure out why; it is fix it now!

7. Again BS. If the business would not make constant changes commitments become doable. IT management can not stand up to "business" management and expect to be around long. So they let the dates, budgets etc. slide. It's about politics of survival. It is next to impossible to hit a target that is constantly changing.

8. Biggest BS of all. You are right IT, like any other business unit survives on bureaucracy - if you don't can't play the game you won't be around. That is the no brainer here. It is just another business unit. So many of the other posters are right on. IT has no real power. I have seen it in Big and Small business. Fortune 250 and 20 people organizations. I am the head of IT at my present employer. I am fed up with this blame IT for everything BS. I took this job because I knew I could tell the truth and stand up to business. You know what? It doesn't matter!!!! Business doesn't want to give IT any time to come up with a solution. They want, no, demand it now. They can have a problem for a year and IT is oblivious to it because business didn't bother to let them know they had a need it doesn't matter. IT can NOT be omniscient.

IMHO there are a 3 main reasons for all the above.

1. Communication. Communication! Communication! Communication! It is a 2 way street and most IT units are no better then the business units at it.

2. Company Politics. Don't even pretend that isn't one of the most important reasons for company problems. Big cheese sees this, doesn't know anything about it except the media says it's "hot!" and won't listen to reason... Is that classic or what? SOA anyone?

3. Staffing. If all a company wants to do is cut IT budget and outsource, what exactly do you expect? No outsourcing company will support you like an in house staff. An over worked staff will just keep it's head above water...

Don't get me wrong - some of the comments do ring true. It takes a certain rather rare kind of mind to be good in any IT field and it takes an even more rare mind to understand IT and manage it.

It does sound like the article was wrote by what I call a business dummy who blames all the woes of the organization on IT. Well I have to tell you having just gone through two years of ERP implementation. I did my best to get the business to where they needed to be. They laughed it off until it was too late and they seen I was 100% correct in what I was telling them all along. Management had no idea what the actual processes were in their organizations, so how can IT? Not to mention they did not want to document any of their own processes because it was IT's job since it had anything to do with touching a computer!

Do I sound frustrated? I was. Now they are. But I have a CYA file the size of a filing cabinet that shows them I probably communicated every issue they refused to address at least six times and usually 12 to them and in different ways when possible. Maybe it is a little childish--but it is a good feeling--I wasn't crying wolf. I unfortunately am putting in 12-to-14-hour days just too keep them functioning because of their lack of vision so the business does not suffer. But I have plenty of ammo to mow down any complaints that their fixes are not coming fast enough or that there are problems; I was very busy doing both of our jobs before.

Wonderful dialogue.

For those of you who are taking exception to my observations and speculating about my background and my motivation, let me end the speculation.

I started my career as an assembler programmer. I have held various positions including technical analyst, business analyst, support and development manager and IT executive. I have been in IT for 30 years and my experience spans the mainframe and the current object and web technologies.

In my current role, I manage a group that delivers management consulting services to clients. One of my specialty areas is the assessment of IT process and organizational effectiveness. I examine IT organizations, identify their strengths and weaknesses and submit recommendations to IT executive management.

Working in the IT profession today is stressful with very little job security for most people. Yes, the business is the source of much stress. As professionals, we can either be reactive or proactive in our response to the challenges. As stated in my article, I find that most IT organizations are reactive.

I also tell my staff, don't identify problems unless you have considered potential solutions. My intent was to begin a dialogue on the problems before I publish my solution ideas.

Once again, thanks to all for your participation in this great dialogue.

With 30 years of experience in IT, I have to agree with Nicholas' assessment.

Although he has broken things down into eight factors I believe they can all be boiled down to two things: (1) Poor leadership/management and (2) a fear of losing control.

My experience is that poor leadership is almost always influenced by the need to maintain one's authority. The result is that when an IT employee tries to be innovative and bring valuable ideas to the table they receive a bloody nose at best. This type of poor leadership/management creates a culture of fear and repression. In other words an employee comes to understand it is not worth the beating they will receive for trying to do the right thing. The outcome is that those in authority get to maintain control of their kingdom and their subordinates remain submissive. There is an old expression, "like pushing a rope uphill", that really says it all.

The only way out of the mess IT has created is to see a radical culture change take place. Hopefully, with process driven practices like Six Sigma, ISO, ITIL and business continuity, IT may be able to move into the realm of reality. There may be hope yet.

C Christesen said: "There are no IT projects, only business projects enabled by technology."

I agree with this and will take it a step further. There is no place for IT within a business, period.

A business that sells clothing or soft drinks has no need of a professional technology bureaucracy. These individuals offer no value to the business. They take vital resources away from the business. The geeks are seldom interested in the company. Since they don't really understand the business and truly don't care they focus only on technology for technology's sake. Why should a bunch of sullen introverted technologists take the place of vibrant motivated business innovators?

IT is a service, companies should specialize in providing this service for a fee. Let the service provider take the hit on the excess capacity, not the business.

Truly, I have systems right now running at under 20 percent utilization, and paranoid IT managers steadfastly refuse to live in shared environments and insist on isolation rather than consolidate.

This is just the tip of the iceberg too. Spanos is correct. He stated the problem, I've seen it from my first hour in IT. Nothing has changed with respect to Spanos's analysis in 13 years across the several companies I worked for. You can't teach an old dog new tricks, so I recommend that companies completely divest themselves of IT departments.

Get rid of it all. Great work Nick!

"Working in the IT profession today is stressful with very little job security for most people. Yes, the business is the source of much stress."

Tell me about it, having had a few positions disappear on me over the decades. The thing is, I don't know what other career I would have taken on if IT didn't exist (my dad would have been a great programmer, just born a generation too early). When the environment is at least bearable, and the project is interesting and challenging, all the rest of the crap is worth it.

There is a new book out that starts with a good description of how we got into this mess,
The Technology Garden: Cultivating Sustainable IT-Business Alignment
by Jon Collins, Neil Macehiter, Dale Vile and Neil Ward-Dutton

Also check out Smart (Enough) Systems by James Taylor and Neil Raden.

Good article; it motivates me to put my two-cents worth.

I have been in IT for over 40 years and I have seen it all. In my days, one went to a four-year course at a university to get a degree in computer Sciences. During this time, you were taught all aspects of computing and I think this is where today's IT people are different.

Yes, technology changes daily, we have better solutions today; yesterday, we chiseled every application with rudimentary tools but our systems were sound. Today we have embedded systems that do this much faster and here is where the deficiencies start to appear. One, IT people are too specialized forgoing the basic science of planning and designing. Today, it is too easy to pose a problem and immediately have a solution using software 'A;' there is no design or planning, just the solution. Here is where hackers feed on because we don't have the discipline to prevent violations or failures. If anything fails, we patch it and put it back into production but we disregard documentation, redesign or adhering to any if there is one.

Take, for example, what Virgil Bierschwale says, a lot of whining and immediately is talking software talk, this product here, this product there. We lack organizational skills, we are too focused in solutions and we negate engineering which is our demise as professionals. we have lost the prestige in favor of comfort, left the professionalism status for an exchange in freedom of attire and office setting. To me it is difficult to distinguish a bum from an IT professional and when we whine like Virgil, we have no grounds for being in this business.

I agree with JGeek about how business and IT generally interact.

I worked for many years as an IT solutions provider for employers and clients who had no metrics at all in their business models. They didn't know how much they spent to get new clients or to revitalize old clients, so it was flat impossible for them to tell if their Web solution de jour was working. They tended to wipe everything out and put in something new every two or three years, based on God-knows-what.

The idea of an IT-outsourced/marketing company is looking better and better to me these days. I want to be able to suggest the idea of testing the business cases and applying IT to the results of the tests. Get the IT company interested in the business's success by giving them a percentage of the increased profits. The people getting a percentage of increased profit will definitely be able to develop a metric to track that. IT-indeterminacy gone!

In an IT career of 21 years, I think the biggest issue I ever had with employers HR was that I am a generalist, and have done lots of different things, from running cable to writing books about network security. I have been owner of seven businesses and CIO/COO of a start-up. I have never had a job where I did only one thing, or one class of things. HR only uses search capability to go through a resume. If you don't have technology A on your page, but do have E through Z, HR is not equipped to say whether you could use technology A. So your resume hits the trash. You may even have to specify that you could use Excel for a Linux engineering job.

The fact IT has the reputation it does is reason enough for concern and action. Sticking your head in the sand and blaming everyone from end users to administration won't change the bad rap, whether it is deserved or not.

Working in healthcare IT, I can say with certainty IT deserves the reputation is has with its end users and administration. Rarely do IT projects deliver on their promises in healthcare. While IT has their heads burried in the bits and bytes the solutions they doll out do little to improve the workflow for clinicians.

Most healthcare organizations that have the least usable systems are the ones that have IT leading the way. These organizations suffer one failed project after another. Sure the system is up all the time, is more secure than Fort Knox and has redundancy built in, but the application doesn't fit the workflow. So what good is it? The focus is all wrong.

IT people are most interested in building great IT systems. End users could care less. What they want are tools that solve their problems and applications that improve their ability to provide care. It takes a great deal of effort on IT's part to understand a clinicians workflow and what solutions would work for them.

What I typically see is an organization that exists to support IT. I think if you want to shake the bad rap IT should exist to support the organization.

I am not convinced that Mr. Spanos should be considered a veteran in the IT industry. His viewpoints are shallow and seem like they are derived from a few experiences instead of years of various experience.

Come on, lack of career path? What has he worked with monkeys? There are so many different options in the IT field. There is always room for improvement and new opportunities develop continuously due to new technology and new business needs. Plus, technology cuts across every industry which creates development opportunity.

I read the first few items in Mr. Spanos list, then called it quits; this guys has no clue what he is talking about. The unreliable technology item had me double checking the date of the article. Do you even know what .Net is?

Visual Studio is doing wonders cutting down on development time and the future looks bright in this arena, allowing multiple development shops (Java, C++, C#, Perl, Visual Basic, .NET, etc.) to work together on the same projects. And, Web services? Come on man. This guy really has no clue.

IT has not been defined itself as a profession. Skills, levels, and objectives are ad hoc at best. A mechanical engineer gets a degree in ME and may often have to pass professional exams to be considered an engineer, a dentist must have a DDS and pass the boards, and even a master electrician has better defined professional qualifications than IT.

Joe who used to load tapes and read a book, Sally who was good at Excel, and Ted who took some programming classes at a community college are often the sorts of people who have ended up in IT. Professional degrees, exams, etc., mean very little to people hiring IT services when it comes to doing the day to day work of IT. Anyone who has the right buzz words on a resume and some references to match is considered qualified.

There are very specific roles in IT with different skill sets. For example, project management, infrastructure support, database administration, programming, and effort estimation require very different skills. However, IT people freely move between disciplines without any checks on skills or ability in a specific area.

Of course, the elephant in the room is that most IT work is drudgery. Most business applications are boring, simple, and trivial to implement by skilled staff. However, when Mary from HR puts her Access database on the company's shared drive to manage vacation time, this is an IT disaster waiting to happen. Unfortunately, most companies have very time specific needs for IT, and between these episodes any monkey can load the tapes and check the back up logs.

Organizations need to reassess their IT needs, looking for external services. $250/hr paid out in chunks of $2,000 a month for a professional services company is much cheaper than $40,000 a year plus benefits for a staff person who doesn't maintain their skills and can't be kept busy.

IT needs to be thinned, redefined and made a true profession with skills, roles, and certifications. Until IT is made a real profession, it will continue to languish as a pseudo-profession rife with failure and cost overruns.

I'm a 25-year IT veteran and overall I think that Nick Spanos misses a few critical points:

1) Experience is expensive - I figure a baseline of about $50K + $5K per year of real world (post college experience) is a pretty good rule of thumb for IT professionals, though it flattens out somewhat near the upper range of that.

An experienced person (10+ years in the field) may bring a wealth of knowledge and expertise in with them compared to a just graduated college student, but in general the technologies themselves are sufficiently complex to non-technology professionals that the distinction between someone with two years and someone with ten years of experience in a field is meaningless to the bean counters or HR.

This means in general that most IT departments are filled with people who have (at best) a four year theoretical understanding of programming, but that have comparatively little real world experience to be able to know what works and what doesn't. Having taught IT students, I was always shocked at how few other teachers actually covered the day-to-day roles of developers and sys admins (perhaps because they hadn't gained this experience themselves).

In business, you'd be foolish to hire a manager with only a little real world experience for anything other than a low level position, as an apprenticeship. The mentoring aspect of agile is intended to foster that apprenticeship for IT workers in principle, but in practice, such mentoring is typically done by someone only slightly more seasoned than the one being mentored.

Because of the age bias within IT (which in my experience is very real) and the pervasive perception of IT as a youth culture, what ends up happening is that senior IT people are often either forced into management (where they are typically fairly inept), forced into a consultative role, or forced out of IT altogether.

This brain drain is exacerbated by the constant churn of new technologies and languages, most adopted not because of inherent advantages in the languages themselves, but because such tools are either "upgraded" to insure sales of new software or are languages that gain street cred in a bubble technology niche. You may have twenty years of experience working with C++, but if you have only six months working with Ruby the you're seen as being no better a programmer than someone who's spent a year working with Ruby after having just graduated.

2) There are no standardized titles within IT, so you tend to get title inflation. In my own hiring, I differentiate an architect from a developer largely on the basis of experience - if you haven't spent at least ten years solving real world problems across a wide variety of technologies, I'll tend to look dubiously at claims to being an architect on your resume. If you don't have a blog that I can scrutinize, I will question your ability to communicate.

Of course, the fact that IT covers a large rubric makes it difficult to formulate such titles, both because the responsibilities and definitions of what those titles mean changes as the technology changes and because it is notoriously difficult to provide a quantitative scale of competency when it's difficult to create tests that themselves become obsolete.

That's why I find that informally it is useful to think of programmers as being similar to craftsmen in a guild system - while it is difficult to provide a quantifiable number indicating the competency of a given individual, most seasoned developers can generally gauge whether a programmer is an apprentice, a journeyman or a master, with these ranks having little to do with management experience and everything to do with competency in one's field.

In general I find that when a company has problems delivering, it's because it lacks a good balance of journeymen to apprentice developers. You need both. You need the journeymen to do the bulk of the innovative development, to handle the software design and architecture and to help steer the apprentices. You need the apprentices because a lot of programming really is scut-work, because such apprentices will be your future cadre of journeymen and because such apprentices usually challenge the existing order in non-disruptive ways.

Masters, on the other hand, should be used sparingly. They are the ones that shape the direction of the technology often at an inter-company level, they are the ones that establish best practices and that write the books and articles introducing people to the technology. They frequently end up in an R&D role, becomes standards advocates, speak regularly at conferences and symposia or become professors after spending several years within the profession (as opposed to the Bachelor to PostDoc eternal student).

(It's also been my experience that masters tend to be extraordinarily disruptive to most companies or organizations, are not that useful at day to day programming because they become far too fascinated in the intricacies of the process rather than in achieving a demonstrable goal, and often intimidate both non-IT and IT managers alike.)

3) My experience differs from Spanos' lack of curiosity. Most developers WANT to innovate - the profession is fundamentally one that attracts innovators and inventors. In general, most businesses tend to stifle curiosity and exploration, because non-IT managers tend to view the role of a programmer as a manufacturer of a specific widget or process within very narrow constraints, usually designed and created by marketers who see developers as the people who realize THEIR visions.

I'd also contend that organizations tend to expel truly innovative people because such people tend to be disruptive, do not fit well within corporate cultures, do not respect established chains of authority and can come across as abrasive, eccentric, or arrogant. What are left are often mediocre programmers who have learned not to make waves, who value job security over being innovative, and who really see comparatively little advantage to completing a known job in order to revamp when that job is over with.

3) About lack of commitment. Programming is invention on demand. Chances are, if there was a product out there that did what was needed, it is in general far less costly to purchase that product. This means that every web developer is essentially trying to invent something that doesn't already exist, often on questionable technology with unpredictable APIs working across heterogeneous computers and operating systems.

This differs from very nearly all other professions - a manager needs to plan strategies and allocate resources, but in general the problem domains are known and can be reasonably predicted. Marketers similarly need to get a reasonably comprehensive analysis of their positions, but their work is similarly well known.

Perhaps the closest profession I can think of to programming is writing a book, and it is another profession where it is notoriously difficult to make reasonable estimates on time because there can be comparatively few metrics for innovation. The less of the unknown there is in completing a software product or project, the more reliable the estimate, but this also means that the likelihood that the problem domain can be resolved with an existing product goes up as the degree of the unknown goes down.

There's an additional factor at work there as well. Most good programmers see the world as a continuum of probabilities - when asked whether something is doable, most programmers will think about the problem and try to resolve mentally whether THEY could do it, and will usually factor in the probabilities that they can do it with a variety of other responsibilities on their plates as well. They can offer up a variety of solutions with associated costs, benefits, and risks, and typically they can see how solution x will have a benefit for customer a, solution y will have a benefit for customer b and so forth.

The manager, on the other hand, is looking for THE solution - they are being pressured by their own superiors to provide a date, a budget, and a commitment that the project can be reached by this date and budget. They in general are not wanting to take the time to analyze the solutions offered up by their programmer, they want a commitment to a solution. In other words, they want the developer to decide for them.

Now, the primary role of a manager is to make decisions. That is what they get paid for - they are not otherwise adding significantly to the bottom line of the organization. The programmer makes plenty of decisions - use this particular tool or that one, use this set of libraries or that one, each of which turns a completely abstract potential product into a completely constrained actual one - but in general these are decisions that do not (and should not) factor in the business environment in which they are working.

The indecisiveness that Spanos refers to generally comes about when a manager asks IT to do his job for him, and consequently to become a scapegoat should the decision prove to be the wrong one while in general reaping no benefit if it proves to be the right one. Not surprisingly, a good IT manager is not going to get into this kind of pissing match.

4) Defining professionalism. Different professions define professionalism differently, sometimes significantly so, and this can be seen especially in comparing programmers to the business definition of professionalism.

Developers put great store in competence and intellectual elegance, respect people with a broad focus of interests and those that are creative, and have a grudging admiration for those people who are brave enough to be non-conformant. They value intellectual achievements - creating a new programming language or establishing a countervailing methodology, for instance.

They tend to be uncomfortable around people that they can't communicate with, and even among other developers they handled enforced proximity badly after a period of time. Most programmers are precise, both because their work requires that they be precise and because they understand the power of words (it's their stock in trade, if you will).

They tend to be either Ayn Rand libertarians (if conservative) or civil libertarians (if progressive), and in either case place a large degree of responsibility upon the individual. Most tend to have an instinctive mistrust of corporations, usually with good reason.

Thus, professionalism among programmers usually tends to stress these traits -
1) a professional spends a significant amount of his or her time educating others,
2) does not take credit for other people's work,
3) shares knowledge, code, advice and associations
4) attempts to perform to the best of his or her ability in creating code,
5) only promotes those things that he or she believes in (the programmer's definition of integrity)
6) and respects the authority of those who are more competent than he or she is while at the same time helping to instill competency in those who are still learning.

The above code of ethics is not dissimilar from that of academics, though in the latter case the competency is generally more clearly delineated.

On the other hand, these do not in general correspond that closely with the code of ethics of a given business professional. Professionalism there is usually defined as:

1) Present a respectful appearance in the face of superiors, associates and underlings within the corporate structure.
2) Respect the authority of those you work for, and respect the rights and opinions of those that work for you.
3) Make decisions that best reflect the values and interests of the company, your superiors, and yourself in that order.
4) Never deprecate the company in the presence of current or potential customers or competitors.
5) Respect the value of the assets that the company has, and do not reveal the intellectual assets to competitors.
6) Mentor your potential successors. Do not back-stab your mentor.
7) Do the work that you have been assigned with speed and efficiency, but it is considered bad form to do work that you have not been assigned.
8) Do not steal from the company.
9) Do not promise that which you have no control over or that you cannot otherwise keep, and keep your promises (the manager's definition of integrity)
10) Contribute back to your community, both because it keeps you well rounded and it helps to promote the company.

There may be a wee bit of caricature in the latter list, but overall I think it sums up the distinctions pretty clearly. IT people clearly have different definitions of integrity, of personal responsibility, and of the notion of authority than managers do, even at the level of ethics, so I daresay that from a programmer's standpoint, most managers behave in a very unethical fashion and as such seem to be the ones who lack professionalism.

I think that there are a lot of places where criticism of the IT community is valid, but I don't necessarily see it in the commentary thus posed.

Wondering Aimlessly

You are expressing the typical technologist mindset. Mr. Spanos has accurately defined the current challenge for our IT bureaucracy. (I won't call it an industry) If you are working for Microsoft, Oracle, HP, Sun, SAP or some other hardware/software development company you have then missed the context of Spanos's article. We are talking about development in companies like Pfizer, PepsiCo, UPS, US Steel, APL, Stanford University, Hughes, PacBell, etc. etc. etc.) What does a PepsiCo's CEO care about Web services for? How are you going to explain to PacBell's CEO the importance of .Net to the their shareholders. Shareholders, we are making plenty of new development opportunities for our IT professionals to engage on. They're making software so complex and brilliant that we might have to hire even more geeks to manage it all.

You say ". . .new opportunities develop continuously due to new technology and new business needs. Plus, technology cuts across every industry which creates development opportunity."

Why would any CEO care about the ability to "develop continuously"? What should any CEO, and the shareholders for that matter, even care? Your mindset typifies why IT as currently exists is failing miserably.

Spano's article claims that IT is not meeting the current needs of the business, what makes you think that experienced business managers would even look to their poor performing IT shops to deliver solutions for "new business needs" any more? If there is new business, then how about a radically new business model that leaves fulltime geeks out of the picture?

You wrote only of opportunities to develop solutions, you said nothing of the business. This mindset assumes that there will be new business needs. Don't assume. If I owned a business, I would use zoho (or some like application) for my office productivity software. Salesforce.com for my CRM. I would outsource every piece of IT I could, and let those companies deal with the "politics of IT" and its day-to-day operations. The days of professional on-site IT staffs are over. And it's not inept business managers and their lack of technology savvy that is to blame. It is the systemic arrogance and insufferable sense of entitlement that geeks have allowed into the culture that is the cause of our demise.

In my opinion, IT has a bad rap because time and time again it gets a bloody nose from the business despite doing its utmost to partner and collaborate.

Business will never accept that IT could know its business better than it knows it itself, however business frequently doesn't know how it runs itself. IT is better positioned to understand how the business is run and the interdependencies of business units and processes.

Business unwillingly accepts IT as a partner and a peer when it suits it and treats it as a serf when IT pushes back on initiatives that are underdeveloped concepts or for which there are multiple external dependencies in downstream integrated application scenarios.

IT carries the multifaceted mantle of business operations supporter and business innovation facilitator. These two roles are often at odds with one another especially if stability and business continuity is valued more highly than innovation or new development. IT cannot perform good operational stewardship if it randomly and haphazardly tackles all and any projects at the whim of business managers and their desire to implement pet projects.

Whilst IT often carries a high monetary price tag, the budget allocated to operational excellence and quality systems is frequently inadequate and not considered critical to ensuring timely and sustainable solutions. In manufacturing for example, a factory would far rather spend more money on a new piece of plant or machinery than on new IT technology that will provide faster system performance, effectiveness and response times. The only exception is if the IT is needed to run the plant and machinery and then it is often considered NOT IT but a part of the manufacturing system(s).

Change the view you have of IT and where it actually fits into your organization, be more inclusive of IT, inform them early on of your plans, strategy and initiatives and be more open with IT and its leadership and you're likely to see better service, support and innovation.

Nick, et. al.

I've been thinking this through and reading the discourse now for a couple of days. But I have one question that no one seems to have asked.

Could someone please tell me of the business or group that clearly meets all 10 "failures" of IT? Where is this utopian group of people? Every deficiency I read above I could easily replace the letters IT with: Lawyers, Doctors, Accountants, Businesspeople, etc.

Our biggest problem hasn't been our lack of success but more to the point the exact opposite. IT became too important - too fast. Core competencies have been lost back in the 1990s.

When there is easy money there's going to be a great deal of "easy" people. We have tolerated far too many "almost good enough" to work in IT, folks in the field for far too long.

Ever notice when you see two techs, who have never meet. Generally, the conversation starts off like a job interview. Each side thinking: so, do you really know what your talking about or are you going to waste my time like the last three folks I talked to? I am guilty of teaching everyone out as well. Meet just a few too many well meaning people working in the industry with too little knowledge to bother with having to explain what should be more obvious.

--An IT veteran of 28 years in November '07

Jgeek, if we use your same argument, shouldn't purchasing, accounting, manufacturing, and in fact every single department of most businesses be good choices to outsource? Why deal with the politics of purchasing? The beancounters certainly take up a significant portion of the company revenue. Manufacturing can be done much more cheaply using child labor in a third world country. Why should any CEO care about those departments?

I think the biggest problem with IT is that too often we are not persuasive enough when we talk to management. We can demonstrate by the numbers that there will be adverse actions if management makes a certain decision and tell them what will be the result, yet we are the bad guys when what we told them would happen does in fact happen. That is exactly the situation we are facing right now in my company.

For all the comments ... I'm a non techie...

What does IT do? I know what shipping does, accounting and sales... what does IT do?

All that leveraging and collaborating and all that... except run the help desk and install... stuff.

How many IT folks see users as a barrier to "me running MY project", or blame the users when goofy software acts goofy.

How many promises have not been met, how many projects have costs more than originally estimated because IT wants the customer to pay for IT's toys.

Why must we have Oracle when dBase will do...because the IT staff likes Oracle and wants someone to fund their toys and training...

It can blackmail the organization with "if you don't buy exactly what I tell you, I will get amnesia about anything you ask me for".

How many IT folks can say "hello" without users piling firewood at their feet.

Most important, how are IT folks trained? Is the training only about the clicks or what the clicks can do for customers?

I've been developing software for 30+ years. From the day programming separated from the business it has been going downhill. The amount of documentation needed before development can even start has skyrocketed. 95 percent of it is solely to protect user management and IT management from the inevitable failure of the software to do what the users need and the resulting finger pointing battle.

The way to solve this mess is to get rid of IT management and have developers report directly to business management working directly with the users who will use the software. That will never be done of course. The end will come when computers start programming themselves, which, dear friends in IT, is coming.

Another IT professional

"...shouldn't purchasing, accounting, manufacturing, and in fact every single department of most businesses be good choices to outsource?"

Let's also include HR. I think all that you mention I've seen outsourced to some degree or the other, except purchasing. I've never seen purchasing outsourced, but I suppose there is some critical core skill in purchasing that might be necessary to a company.

I think that a lot of the current Boeing project has outsourced a great deal of their manufacturing. The supply chain is global.

Of all the groups you mentioned I think IT is the most useless to a corporation. I work right in the middle of it. We make the business purchase millions upon millions of dollars of software, but use it so poorly. If accounting did as poorly as we did someone would go to jail, if purchasing did as poorly as we did the company would lose money.

We fail all the time. If a purchasing dept overbought, their mistakes would quickly be revealed with bloated warehouses and poor cash flow. If HR over hired or over paid same thing. If sales over-promised their lies would soon be revealed. If marketing and advertising spent millions and millions on failed campaigns they would shortly be proven as frauds. We do this every year and deliver nothing by way of value. The vast majority of our work can be done better by companies whose sole purpose is to manage the technology infrastructure of their customers.

We on the other hand over purchase to the point of being criminally negligent. I would even say fraudulent. I wonder how much excess capacity just sits there in every company not utilized. Then we ask for more. The only thing that saves us is users are ignorant of what they don't know.

Again you've given no examples of the value of how an entrenched IT Bureaucracy delivers value to the business. You know Lord of the Rings? We are like the Grima Wormtongue's to the business.

I'm really biased on this in a lot of ways, not the least of which is because I'm currently reading "Freedomnomics" by John Lott. At the risk of being accused of threadjacking, I highly recommend it.

But it isn't a threadjack at all, because from reading through the comments here and looking back on my own two decades in IT, this is the root of the problem: Information Technology tends to fail to function as an agent for transferring economic forces and pressures from one enclave to another. Instead it acts as an insulator.

What are consumers of information technology missing? Sam (10/25-12:18 p.m.) nailed it. Focus is in high supply, but the demand rises only so far as it's needed to make something work. Econ 101 says, as a commodity it should lose value. But it gains value over time. I have strong doubts that I'm the only one with personal experience in this; I'm looking up, and I'm seeing folks have 28, 35, 40 years of experience in IT. Time comes to look for a job, the "smart money" says to take this ten years or that twelve years, and HIDE them...customize the resume to whatever position is being filled. The "Jack of all trades" is thought to be a master of none.

Where Sam is right, is in noting the soundness of systems that are designed and implemented with the overall machinery, stock barrel & all between, in mind. This has been shown to be true time and time again. Again, this should diminish the value of focus and specialization as a commodity. Systems break down and need much higher levels of day-to-day maintenance as a direct consequence of too much focus.

He's wrong to look at computer science degrees as the curative agents, though. The certification industry--and I freely confess, I'm personally biased in saying this--is causing the problem. It has exploded at the very same time IT's reputation has been on a steep decline. It is...in all the ways that matter...a parasite.

We have all these training programs we didn't have six or seven years ago. If they work, they are recognized and they make money. And once that happens...things don't stay still. The certification "splits." If you were certified as X, now you can become a X-1 or X-2 or XXX or XYZ. And why would you not? Why would such a specialization not be offered? It's a win-win for the trainer and the trainee, both of whom are now about to solidify a transaction that has already worked for them in the past.

And so over time, professionals become more specialized. The result is that to bring on one guy with expert knowledge, or even just sufficient knowledge to achieve command of a given problem, in all the areas that matter--this becomes difficult to impossible. You've got to hire a team of specialists.

It's a lack of economic communication, pure and simple. The consumer wants pretty much the same swimming pool everybody else wants, something he can dive into -- he must acquire twenty swimming pools, each one a foot wide and a mile deep. Whether he even gets the mile of depth, is up to the HR department. Aside from being purely non-technical, I notice HR has emerged in this thread as a clear villain; haven't seen anything good said about them here. Yet, still, they make all the decisions, everywhere. Virgil calls out the problem, Sam calls him a "whiner." This, again, is another failure to transfer economic forces and pressures. Things that are not in genuine demand, are made artificially precious.

I agree fully with Chris and Michael has a point, and I'm glad Morgan agrees with me in something.

College degrees are just a piece of paper that you can plaster on a wall with pride, the only thing it proves is that you took the time to reach a goal; I know this because I have them hanging on a wall in my house far removed from sight. But these programs teach you the proper use of tools of the trade when they are necessary. These practices have been forgotten today the new instructions don't focus on discipline. I'm not championing for everybody to have degrees but if a doctor has one, they are accredited to practice their practice; so, why not make IT a profession? These days you don't have to have an HS diploma but you can go to a two-week course and you are accredited to set a Web site or write a program. When you see a bad driver on the road you are compelled to yell "where did you get your license?" Sears?

The same thing, these two-bit technicians become proficient in time but they leave a trail of disasters behind. I'm in charge of several staff and I'm appalled to their shortcomings in knowing the process methodology of computer design, zilch!

It is my experience dealing with today's technology that the strategic and tactical elements of running and IT organization are gone which does not give IT the rightful credentials of a white-collar profession; mechanics is a blue-collar profession, today's IT is the operational branch of yesterday caught in the middle of these professions.

It is a shame.

1) The issue is not that IT is reactive, it is that there are too many cooks in the kitchen. The best software is always produced by small teams, and software is the key to adding business value. However, good developers (those who can translate a business need into a solution and anticipate likely future needs) are pushed out of development if they want to earn anything. As a result, all sorts of unnecessary software and infrastructure is required to support mediocre development teams and software solutions. Further, few quality IT folks want to learn about and become an expert in non-differentiating business software (e.g., SAP.) There is little long-term career benefit of being an ABAP or SAP Payroll expert, even if you can generate substantial income for a few years.

2) Agree completely. The career path is to get out of IT or become a CIO at one of the very, very few firms that really value a broad-based IT background, then move to the business side of the enterprise before you are terminated. Those who do not believe this have never had the job.

3) Software engineering is the greatest disappointment of the entire computer era. However, the language is just a piece of the puzzle. There is nothing inherently wrong with any computer language just as there is nothing wrong with any spoken language. On the other hand, at some point, creating more languages is just an exercise is self-importance (which is a common trait in IT.)

4) A program is a set of steps (or procedure) codified in software. By definition, the more variability in the steps, the less predictable the outcomes. People always want infinite flexibility at zero cost, but this is unrealistic. Further, COTS solutions are inherently non-differentiating and will not positively impact most businesses.

5) Leadership has too many potential definitions to respond on that basis. However, there is no practical way for a CIO to understand all the business applications that support an enterprise. The key issue is that money is not changing hands. If people continue to pay for a service that adds no value, why should that be a failing of the CIO? If IT is a tax, then the tax should be cut each and every year until critical services start to fail. If IT charges for services that people pay for and do not use, good for them. Have you ever heard of a health club? Are you going to blame Bally's for members who pay but do not exercise?

6) Why do people keep blaming the service provider for providing service? There is a strong possibility that most IT investments have negative return. But to blame the vendors and service providers as the accountable parties for people overpaying and making poor business decisions is ludicrous. People buy Porches in Chicago - why? You cannot drive fast anywhere and the low profile wheels easily bend when roads are rough. Should we call Germany and tell them to change the engine dynamics and the wheels?

7) People/vendors who service the IT industry get away with what they can. If the customer tolerates poor planning, late delivery, excessive costs, and low quality, what incentive is there to do better? How long did it take for the US auto industry to see the light? Is it the fault of the auto makers for producing cars that people continue to buy?

8) IT is a bureaucracy. So what?

All that said, the opportunity for IT to positively impact business is great. Why? Because many businesses still rely on too many people to manage around problems. These problems occur because people do not plan. Better planning is required to improve execution. Unfortunately, planning is a core skill that is lacking in the general marketplace. Many firms do not reward good planning and the associated execution, they rewards long hours and fire drills. IT people are trained to be beaten, and so they are.

1. Reactive Profession

"IT should also solicit and understand business requirements and design an appropriate solution. Instead, T requires the business to provide very detailed design specifications which delays projects and causes confusion."

The IT community has a role already defined for soliciting requirements and defining a solution approach, the business analyst. Any shop without such people, get some; see IIBA.com for what you need to know about the role...and remember you don't always need to design a solution; re-use or buy are real options.

2. Lack of Career Path
All major IT roles have certifications associated with, from PMI to IIBA's CBAP.; membership in a certifying body should be the minimum you look for in IT people.
"Experience is a negative"? Experience in anything that is not being used anymore is a negative. It behooves all professions to stay current, including more traditional jobs like lawyers, doctors and engineers. On the other hand, having experience in something old but is still needed can be a boon.

3. Unreliable Technology
Languages becoming too low-level? Need a whiz-bang development language? Wrong solution; we should be generating code from models like data models, process maps and UML.

4. Rigidity
Old problem; look at packages from Kronos or IDS or other domain vendors; they are all configurable, process and rule-driven. Monolithic software like old ERPs are of the past.

5. Leadership Void
Any leader that does not know what the hell is going on in their organization should indeed be fired, that's any department, not just IT.

6. Lack of Curiosity
"IT doesn't ask why." get your Business Analysts involved, that's what they do. Besides, anyone asking for an IT service should know why they want it, enough to define dollar benefits that can be combined with estimated IT costs do get the ROI. No company has unlimited resources, so don't waste them.
And applications belong to the business that uses them, not IT. While wary of analogies, think of an app as a car; business owns the car, while IT services it. IT may well suggest some fixes or say its time for a new car, but it's the owner's choice to do it or not.

7. Lack of Commitment
"IT does not make commitments. And, even if it does, IT does not believe it has an obligation to meet the commitments (dates, costs, scope)." Not where I work, or where I have ever worked. Find me the IT department is still getting away with this, I want to go there.

8. Denial.
"It's the biggest problem of all. By blaming the business for the issues, IT avoids internal continuous improvement. It is common practice to dismiss or punish the people who are willing to offer innovative ideas. The staff eventually learns to avoid innovation." ...see my answer to 6. IT is not innovative? I still remember trying to get business departments to consider online over their batch processing. BPM, SOA, Business Rules and EDM, that's innovation.

The sad truth is that this is also true for some software companies. They dictate when problems will be fixed, if ever, instead of working with the client to work around the problem can be address in a meaningful manner.

To a degr