Here are some of the problems in the U.S. IT space today...

1. New programs, new buzzwords, new approaches that cause org overhauls every stinking year... Transformation is the slogan de jour... Enough already...

2. Let's call transformation what it is -- cost cutting. Enough with the window dressing.

3. A central problem with captive IT dev shops is they are viewed by the business leaders of the firm as a cost center vs. profit center. Take away IT and you are left to fill your demand curves (product and/or service models) with labor, labor, labor vs. capital (yes, software, once complete, is capital). Run some pro forma's without products that IT has built and see what your EBITDA looks like! You're out of business, period.

4. The problem with IT costs (since this is the primary focus in the way CEOs/business leaders think) does not lie with IT development; it lies with the business constituency, which cannot or will not articulate what should be built! Why? Because they don't know! They don't invest the funds to develop process, methods, research capabilities to identify what is important in their respective market (unless they are P&G or UPS, who are world-famous for their capability in this space), let alone have the ability to articulate that to the IT community. If you've worked in IT for a long period of time as a PM, you've experienced the numereous "cherry pickings" of a requirement vs. its cost to develop it as the biz community trys to leverage annual budgets to build " more things" vs. building the "right things." What is the product that you need to be competive in space X, and return Y ROI to the firm? That's the question to answer, period. Then define it and build it. Incessant change requests, etc., ergo, "we the biz have no idea what we want, but we'll know it when we see it,", blows the ROIs out of the water. This is why the systems community attempted to alter development methodologies towards an agile model -- to help business get out of its own way!

5. Code from India is usually "less than desirable"... Once again, senior biz leaders get suckered into thinking you get something for nothing. They don't put any systems or analysis in to determine the true costs of India coding. Ask an executive what is "per-unit cost and code yield when comparing India vs. U.S. constructed code," and their eyes glaze over. What I've witnessed is it's 3:1 yield-on-man effort (typically takes 3.0 India code engineers to 1 U.S. code engineer ) -- so if you are paying the India engineer 60% less than a U.S. engineer, you're final product is coming in above the cost of the U.S. engineer, and that's before re-work costs to correct the 4:1 defects that originate from India code vs. U.S. code, they're typically 25% to 35% of India turnover ratios, etc. Bottom line, the true costs of India development, when properly calibrated and accounted for, actually exceed the U.S. costs of development on a per-unit basis.

So, do biz execs turn a deaf ear? No. They hear everything, but they just don't get it or choose not to, don't address the correct issues, and also don't know how to solve them. Their only answer -- what is the cheapest short-term cost we can incur? One of the reasons the economy is in such dire straits is based on following the short-term solutions. The motive for this approach regarding implementation of short term at any cost is based on CEO comp, ie., "How does it impact my bonus and share-options pricing?" Get rid of these programs and these types of CEOs (and all their cronies), and you can eventually correct these issues. Maybe what IT transformation should be is figuring out a way to get rid of blotted CEOs budgeted positions, and their underlying, non- contributing support base. Cutting 20% of staff from the top down probably yields a 60% to 70% savings to the firms overall labor costs. As a long-term shareholder of a corporate stock, I think I would find that value appreciation of my holdings most appealing...

Transformation is in the eye of the beholder. While it is safe to say that it is both a goal AND a journey, the transformation itself is based on the needs of the organization. Trying to define such a broad topic in a universal, narrow-scope, all-inclusive manner is like jousting a windmill -- failure is practically guaranteed, and success borders on meaninglessness.

Transformation, regardless of the specific desired outcome, will inevitably include:

1. An examination and, hopefully, a streamlining of processes, with a focus on value-add components

2. The redefinition of particular roles, and potentially headcount, within an organization

3. The implementation of a technology to enable this transformation, ideally one that is intuitive, easy to use and maintain

4. The change management components required to support this change, including training, redistribution of team members, and realignment of goals

5. And finally, the appropriate metrics needed to measure the (hopefully successful) outcome desired, with the implication being that results should be examined to ensure the intended value is being delivered

This sounds relatively intuitive, however, all five steps must be executed at both the 'business logic' and 'infrastructure support' levels, where the actual steps used to support business processes, as well as the interfacing system impact, must be considered. While this is hardly a roadmap for successful execution, it speaks directly to the high-level steps to support a transformation effort.

What remains is the definition of the intended goal, the acquisition of executive sponsorship for the transformation, the access to the subject matter experts required, and the tempered execution of the plan itself. And, as I often warn people, though, this is more easily discussed than realized.

Transformation is nothing more than a term invented by the big consultancy firms in order to generate more business.

Seriously, no one in IT really uses the term.

1. I agree with Jon. No one at the operational level uses the term transformation/transformational. This is more a strategic/corporate-level term.
2. Franklin explains this from a corporate/executive level and Woodrow's points further illustrate that transformation, while entirely strategic in focus, lacks adequate planning and coordination by the CIO and COO down to the operational sectors of the organization.
3. What I view as the central point of failure in realizing a transformed organization is not realizing the connection between the strategic and operational minds in the organization.
4. Transformation is driven by the environment. Listen to what the operators on the ground are telling you. The environmental sensors only tell you from a snapshot in time. It's the operators in the environment that will guide you best. Let them guide your strategy.

In my view there are 2 types of projects – systems engineering and business transformation. The distinction is critical as each has a much different risk profile.

A systems engineering project, within the IT domain, takes an existing set of processes and automates them. The premise is that the processes are defined, robust and industrial-strength. The point of automation is to “speed” them up, provide scalability and reliability, improve accuracy and responsiveness, etc.

In contrast, a business transformation project seeks to change the behavior of people. Folks – employees, agents, vendors, clients -- are told to follow a new set of business processes. Those new business processes may be defined and only partially tested – in time and in real time. The point here is that changing the behavior of people is a very significant effort – one that invariably is underestimated.

I offer the following observation in terms of project costs over a 5-year span:
 1/3 of project is for platform – hardware, software, pipeware
 1/3 of project is for project setup – the application development
 1/3 of project is ongoing operations – care and feeding, enhancements, etc
 1/3 of project is for business transformation – process redesign, change management, etc.

That of course explains why many, if not most, business transformation projects are late and over budget.

Jon and Mario,

You both bring up valid points. Transformation is one of those buzzwords that gets execs excited and drives operations people crazy.

The single most profound thing I can say is that Mario nailed it in his third point. If the real system users do not feel a profound and positive impact, the "transformation" is a failure. It's also pretty obvious that you have been victims of "transformation" before.

In very plain language, making changes to an organization or system for any reason other than improving performance is misguided at best and destructive at worst.

IT transformation is what we at IAITAM call IT Asset Management. We've been teaching organizations around the world how to bring value to IT and doing it for the fraction of the cost of a full-blown consulting project. Over the 6 years (almost 7 now) we've been in business we have collected, observed and created best practices around IT asset management. We've also discovered that organizations are primarily focused on 1 of 3 business drivers: risk, efficiency or financial. In today's climate I bet you can guess which one is the most popular.

IT Asset Management (or ITAM) is about understanding the needs of all the functional groups within your organization and making sure those needs are met. Our members, over 6,000 strong, have been very successful implementing these best practices.

Twenty years ago we put together a consulting practice to "transform" IT organizations. After a year of trying to sell the concept, we learned that IT organizations don't want to be "transformed." Instead, they would love to be more effective, add more value to the business, retain and recruit the best people, be respected in the corporation, etc. It's kind of like going to a "shrink" who says that you need to be transformed. The first thing you would do is to find the door out of there.

It seems to me that the fundamental shift that IT must make is from a pure producer role to a stewardship role. In this stewardship role IT would serve as the expert managers of IT services and advisors to management.

Building a transparent financial structure where all the IT services and sub-services are defined, each running "like a business," can be done within a year.

The IT demand management organization -- the customer-facing or "sales" role within IT -- can then work with customer businesses to develop reasoned make/buy decisions for sub-services. IT would produce what it can economically and coordinate buying sub-services from others where economical. In essence, IT would act as prime contractor and sub-contractor where economical.

The customers can "buy" the resultant high-level services from the IT department knowing that they're getting a good price for the quality delivered.

The customers can "buy" what they can afford -- knowing the price of the services. IT moves away from the fixed-price, unlimited-demand model that it finds itself in today.

I find it’s useful to give business leaders a way of looking at the mission of IT that reflects and balances both day-to-day and transformative roles. I like to say that the mission of IT is “RSVP":

R = Reliability -- Make sure the technology works.

S = Security -- Protect systems and data (from accidents and malicious intent).

V = Value Added -- Discover and deploy technology that adds value compared to existing systems and competition (looking outside the organization for new approaches is essential).

P = Productivity – Introduce technology that increases productivity (looking inside and understanding the organization's functioning is essential).

I tell them that that Reliability and Security roles apply to all IT organizations, but Value Added and Productivity roles for IT depend on each organization’s unique mission, customers, products, suppliers, channels, regulations, structure, maturity, etc.

I feel that IT's impact on Value Added and Productivity areas requires detailed business knowledge, partnering with business leaders, interpersonal and political skill and organizational support and funding. These roles for IT also produce the most significant benefits to organizations.

From Webster: transform = 1 a: to change in composition or structure; b: to change the outward form or appearance of; c: to change in character or condition : convert.

So what does that really mean? Ask 20 CEOs and you'll get 20 answers. It has nothing to do with some so-called consultant saying IT doesn't know or can't verbalize it -- it has to do with the fact that it means different things to different people.

Ask yourself this question: if CEOs were so smart, how come so many of them are getting burned by the bad economy right now? Many CEOs are good at what they do, which is run their particular business. Not all businesses are making or selling technology; thus they have CIOs and other have help running the business. They have CFOs, marketing teams, sales teams, back office support teams and so on. If they want financial information, they go to a CFO and heed that advice, most times. So why is it that many CEOs don't heed the advice of CIOs? Some say they don't know or understand the business. Well, in my short 35 years, CFOs don't know their businesses any better (didn't mean to pick on CFOs). A large group of consultants and some of the media have convinced CEOs that IT is stupid. Look at all the books that proclaim how IT is really bad, wrong or just useless. If that's true, I would like to see all these businesses and consultants turn off all the technology in their company for just one week.

The problem is largely that we as humans change constantly. Although most people will tell you they hate change, they really thrive on it. Just think if everything stayed the same all the time...pretty dull! Since change is constant and someone wants technology to address that change, you have created a very complex set of rules to follow. Which then creates a complex solution.

Use technology as a tool. It's not a solution to every problem. Here is my favorite example. I need to dig a hole, so I go to the store and buy a shovel. I dig my hole and I am happy. The next day, I need to change the flat tire on the car. I get out my shovel and get mad after 3-4 hours of trying to change it with the shovel. I go to the store and give them a piece of my mind that the shovel didn't help me change my tire. The person at the store says, well, of course, sir, you cannot change a tire with that you need a tire iron. I get mad and storm out because I think the tool I bought is defective. Now the maker of the shovel didn't say specifically that the shovel would not change tires -- I just thought it would.

So is it IT's fault that the tool built to the business needs and requirements won't do everything, especially those things not ask for? You decide.

So as my grandfather once said, you are either part of the problem or the solution. Which one are you?

Without doubt, the involvement in IT in the overall business process of any organization, including the manufacturing process, is a relatively new idea.

I appreciated Alex's comment about the last 1/3 of a project -- the unbudgeted portion of the project -- as 1/3 business transformation.

I prefer the terms used throughout these posts such as solution, resolution, even the word simply "change," as it is a more truthful expression of what needs to happen. Wherever the word transformation began to evolve as a different buzzword in the IT world -- I find it makes promises that I doubt it can truly deliver. It may, however, have the advantage of making a point that that 4th third of the project definitely has costs associated with it and that without that 4th third the project has no hopes of meeting the requirements for which it was proposed. But I may be oversimplifying this.