IT Transformation with SOA

Defining the Project’s Scope and Requirements

The Strategy and Planning for the IT Transformation effort must emanate from the definition of scope and the understanding of the requirements that will be targeted by the initiative. Many compromises must be made in the process, and these compromises become both cause and effect of the ultimate strategic direction.

The compromises deal with the interplay of these parameters for each requirement:

§ Quality: The solidity of the deliverable

§ Cost: The amount of money available for delivery

§ Schedule: The expected delivery timelines

§ Scope: The functionality that is being delivered

These variables are known as QCSS attributes, taken from the initials of each. The business requirements can only reasonably specify three of these factors. The fourth factor will be a result of the project’s dynamics. For example, if the business wants a project done within certain cost restraints, under a specific timeline, and with a specific scope, the quality of the project will be in question.

In this diagram, Functionality is represented by the surface area of the square. The Cost used to meet the Functionality is shown in light grey, and the Schedule (timeline) is in dark grey. Quality is the percentage of the Functionality surface that is being covered by the Cost and Schedule squares. The diagram shows that if the Functionality scope is increased (larger surface), you will either have to increase the Cost, the Schedule, or both to match the new requirements; if not, Quality will suffer.

This “law” applies to all projects and to any combination of attributes. Furthermore, imagine the QCSS variables as knobs on a control panel, each influencing the other[1]. The more money available for a given project, the more potential resources that can be committed; thereby enabling faster delivery and/or more extended functionality. With less funding, chances are the scope will need to be reduced if timelines are to be maintained.

Managing the project budget and the timelines is a straightforward project management function. Project Management disciplines to effectively do this have been developed and can be applied in a systemic way. But truth be said, the most complicated challenge during this stage is to properly manage the amount of requirements you are likely to receive from the business. Let’s face it, this is an IT Transformation project that, most likely, has been sold as the mother-of-all-solutions and that will, no doubt, have the business salivating like a kid in a candy store with all the potential for functions that they have for so many years been deprived of.

However, the fact is that the requirements values tend to follow Pareto’s 80-20 rule. That is, typically 20% of the requirements represent 80% of the solution value, and the other 80% the remaining 20%. Now please don’t go to the business and tell then you will cover 20% of their requirements. Not a good idea. First, the Pareto principle is just that—a principle; not a law. It might be that in your case 40% of your requirements represent 70% of the value. Secondly, that little extra business value that can be attained by covering a few additional requirements might mean the difference between having a highly competitive solution or an also-ran.

What you first need to do is identify the 20% to 40% of the requirements that everyone agrees are a must, and then proceed to carefully analyze and prioritize the remaining requirements in light of their diminishing returns. My own philosophy is to do as much as possible with the money and time allocated (in essence, establish first the cost and schedule surfaces) and then draw a line in terms of what requirements are to be met during that first phase. You can place the unfulfilled requirements in a subsequent phase that might or might not be funded on its merits. If you can do so without eliciting the wrath of the business team, then you have succeeded!

As you can see, managing the overall scope is an activity best handled by the project leader and not to be delegated to line project managers. It requires finesse and political skills in dealing with business customers.

A second dimension that is often left unexamined during the requirements phase is the need to assess the project complexity and define the strategy of how this complexity will be managed. By this, I mean the determination of the strategy balancing the target automation complexity versus the reliance on manual processes. This is the subject of my next blog.

Till then.

Labels: Business Case, Complexity, Functionality, IT, Management, PM, Project, Requirements, Scheuled, Scope, Time

posted by IT Transformation with SOA @ 8:31 AM

Assessing Your Organization’s View of Technology

Some people view their automobile merely as a utility—a means of transportation to get them safely from point A to point B. Others view it as a strategic enabler: “This Porsche is sure to get me more dates!” A corporations’ view of technology is no different. The trick is to find out whether your company views IT as a dependable truck or a sports car.

First, let’s agree there are two types of information system technologies: those needed to support the running of your business, and those that are core to the business. The former include applications such as accounting and payroll systems as well as Intranets. Indeed, the patterns associated with these services have made it easier for major vendors to offer customizable packages under the umbrella of ERP (Enterprise Resource Planning) that can be configured to meet a company’s specific business needs. The latter usually consists of applications and systems formed under more proprietary circumstances and that support the actual business operations: point of sale, promotions, customer relationship management, guest facing sales and marketing (including Web portals and campaign management), product distribution and tracking, reservation systems (such as those used by airlines and hotels), etc.

In principle, ERP systems are needed by all industries, but transformational projects for back office systems can only be truly justified when there’s a need to respond to a big business event such as a merger or an acquisition. Also, ERP investments are rarely justifiable on the basis of competitive advantage—argumentations for cost saving or administrative agility advantages notwithstanding. Instead, large ERP projects are usually approved because they tend to serve the operational governance of the CFO, who ultimately is the person with the budgetary approval power.

Justifying technology transformation projects intended to deliver a direct business benefit is another matter. Their value is often not appreciated because of the high costs. Ironically, because ERP projects typically require proprietary vendor architectures and high-consulting support to customize the solution, they often end up costing much more than IT projects intended to directly deliver competitive features. That’s why there’s always a question as of how to position these core projects in light of the company’s view of technology as a competitive weapon.

Given that IT systems designed to support the core business usually require some costly proprietary development, it has long been a chimera of some businesses to make their core support systems behave the way ERP is viewed today—as a commodity. This view reveals technology as not being a strategic asset, but a utility that’s needed to “get-the-work-done”. Basically, this view of IT is akin to the way most of us view sewage services or electricity—stuff we can’t live without, but that we always expect to work.

Organizations that view IT technology needed for the core business as if it were just a utility are also typically the same organizations whose culture is not predisposed to change. You’ll recognize them when you hear statements such as, “Sure, the business could use this new function but we don’t want to bother with changing things when we can just patch a quick solution for now,” or: “Yes, this new technology will solve many issues, but we can save money by hanging on to we have for a little longer,” or my favorite, overhead from a particularly out-of-touch CEO in the midst of the dot-com explosion of the late nineties: “Nah, if it grows like a weed, it must be a weed. This Internet thing is nothing but a fad!”

Let’s face it. To the executives with that limited perspective, IT is just the geeky intern that shows up whenever there’s a need to “fix” the laptop or “get email going”. This is a view predicated on a strict utilitarian view of IT as a service organization, and nothing more. In this case, your first challenge is to educate the executive brass about the true extent and governance of the IT organization. However, even with all the education in the world, if your company is in an industry that traditionally does not rely on, or get obvious benefits from modern technology, chances are that your attempt to justify that big transformation project is going to fall on deaf ears unless you position your message in line with the company’s culture.

Then there are those companies that consider technology to be a strategic asset . . . Sometimes far too strategic. Frankly, these companies may also suffer from an equally insidious problem of overusing technology. They cling to the belief that technology and only technology will pull the company out of the ditch and increase profitability. I would suggest that a large percentage of the failed IT projects that provided fodder for the Harvard Review’s case studies come from extremely high expectations as to what the ROI mega-technology projects were expected to deliver.

So, there you have it. Understanding the view of technology within your company and your industry is a good starting point in the understanding of the feasibility, scope, and value of your IT transformation effort. What are the considerations for assessing your company’s positioning vis-à-vis technology?

In the diagram above, I give a general assessment of how various well-know companies might value technology. (Note: my sample assessment is completely conceptual, and you have every right to disagree on the manner in which I’ve positioned some of these companies.. More importantly, I suggest you do the exercise of placing your own company in the diagram. The vertical axis represents the typical level of IT investment in relation to the company’s revenue (companies the view technology as a tactical enabler usually allocate 2-5% of their gross revenue to IT; companies that view technology as a core component invest more on it) , while the horizontal axis shows the real or self-perceived value of technology by the company. For example, a company that views itself as one whose actual product is technology related but has a low percentage of investment in IT would fall in the under-investment zone in the bottom right. Your case for transformation should be easier in this case. The upper-left shows technology over-investments. GM (who is o the verge of bankruptcy as I write this) was typically a heavy investor in technology, even though it did not traditionally position itself as a technology company, but rather as a car company—a big car company (Hummer or Yukon, anyone?). In fact, EDS was spun off from GM after some executive concluded that providing DP services was not a business GM should be in.

The two sample brands to the left are representative companies that might well see technology as a utility. They do depend on technology, mind you, but chances are they want it as cheaply as possible, so they can focus on their actual lines of business: selling food products. Some companies see technology only as a tactical enabler. Here I’m thinking of manufacturing and retail that tend to view technology as something better than a utility but still not core to their business. Still, just because a company requires technology only as a tactical enabler does not mean that IT can’t be leveraged against the competition. Even in this scenario there might be IT contributions to the core business (e.g. automated ordering kiosks in retail, use of loyalty systems and CRM.)

In the middle of the horizontal axis, there lies the Twilight Zone of technology funding. Technology becomes truly strategic when the end product would not exist if technology did not operate with excellence and efficiency. In this area you’ll find companies that have typically leveraged the power of technology to their competitive advantage. Two examples are Sabre, with its powerful computer reservations environments for the airlines, and the financial institution, Merrill Lynch[1], leveraging on-line financial services.

To the upper right of the chart are those companies whose life blood depends on maintaining a leading hand in technology. Further to the right you can find companies whose technology is the actual product. Even though in these companies it might be easier to make the case for technology, don’t be surprised if you get push-back resulting from stale thinking or stunted vision. “Why should we invest in that Internet thing?” someone at Novell might have asked back in the late eighties or, “Why do we need those PCs?” from DEC’s Olsen. Still, there can be no question that the further to the right you find a company, the easier it should be to make a case for technology transformation, if needed. However, in this scenario the execution of technology transformation can be the hardest because in doing so, you are dealing with the lifeblood of the business!

Labels: IT, IT Transformation Defined, Justification, Manufacturing, retail, Technology, Utility, Vision

posted by IT Transformation with SOA @ 1:56 PM

Musings about Innovation

Thus far I have focused primarily on aspects related to the corporate culture, the business requirements, and the funding considerations that serve as a foundation for an IT Transformation initiative. Soon I will be delving into the more technically focused steps required to provide the strategic technology framework for this transformation, such as the gathering of specific requirements, setting the program scope, and defining the high level architecture and technology transformation tenets. However, before I proceed with this technical nitty-gritty, I wanted to highlight one important element that I believe must be at the core of any IT transformation initiative: innovation.

Surely, one of the sweetest and most rewarding outcomes of a true renovation program is the introduction of truly innovative features, technologies, and processes. A transformation program that results in more of the same tired old solutions, except for the “we’re now running a more modern platform,” is bound to excite no one and is less likely to meet emerging requirements. Without Innovation, IT Transformation would be like pimping a Ford Pinto with velvet seats and a “La Cucaracha” horn.

Innovation can and should take place at each step of the transformation, from the identification of business processes suitable for improvement, to the manner in which you lay down the technology strategy, to the methods and processes you follow, and certainly to the specific elements and inventions of the solution.

Then again, this may be easier said than done. The creation of innovation is not the sort of thing that can be scheduled in a plan. Innovation is about the “how” we solve problems and not about the “what”. There are plenty of white papers attempting to formalize innovation processes as if innovation were something that can be created by simply following predefined methodologies: “Put processes here, structure this, add water, and bingo! Invention will happen!” Forgive my skepticism. It just doesn’t work that way.

After all, the genesis of innovation is perhaps one of the most intriguing aspects of all human endeavors, and its appearance can often only be explained as the result of the combination of the right circumstances and a little bit of luck. Innovation is more about atmospherics than about process. Why? I don’t believe an innovation process can be formalized with the kind of structure and targeted predictability that is applied to other methodology-rich disciplines such as auditing or quality assurance.

The truth of the matter is that the one proven way to foster innovation is to secure resources with the smarts and ability to generate ideas, all the while ensuring they enjoy an environment that supports and encourages the emergence of their ideas. Even then, new ideas may or may not occur, depending upon the presence or absence of a third element: serendipity.

Serendipity matters. Think of the invention and use of the wheel. Depictions of Sumerians carriages pulled by horses confirm that the wheel was first invented at least 5,000 years ago. On the other hand, look at the Americas. The Aztecs never used the wheel for transportation, even though they had invented it and used it in children toys. Why? The most common explanation is that the wheel was impractical to them because they lacked horses, oxen, or any other animal capable of pulling a carriage. Fair enough, as far as explanations go this is not a bad one. It’s just that I don’t buy it. Even though the Aztecs did not have horses or oxen, they did have access to readily available beasts of burden: enemy prisoners and slaves. Given that human rights was not high on that society’s agenda, one would imagine that instead of extracting the hearts of thousands-upon-thousands of their war prisoners, the Aztecs could have put some of those folks to a more practical use by having them pull wheeled carriages. No, a simpler explanation is this: the idea to use carts with wheels as a form of transportation simply did not occur to them! In fact, it’s just possible that the one individual that might have come up with the revolutionary idea to use the wheel for transportation was one of the unlucky fellows whose heart was pulled out for the benefit of the gods! With their pervasive human-sacrifice program, the Aztecs definitely failed to provide the right innovation-fostering environment.

Now, before you begin to argue that perhaps the Aztecs were just not all that smart, think of wheeled-luggage. Why wasn’t the idea to attach wheels to luggage invented much sooner?

I’m amused every time I view a fifties movie classics with people carrying immense traveling trunks. Most of us old enough to have used vinyl records had to go around airports, train stations, and bus stations hauling heavy luggage. And yet something so seemly obvious and technologically viable, such as attaching wheels to luggage, did not occur until very recently!

Again, why is this?

It wasn’t that the technology to attach wheels to luggage didn’t exist, or that train stations lacked even terrain, or that travelers of yore had bigger muscles, but quite simply the idea had not occurred to anyone!

A caveat regarding innovation is this: beware of the gimmick. Gimmicks are to innovation what margarine is to butter. They only give the appearance of innovation but fail to provide real value and benefits. They shimmer with the glow of vanity that hides their ultimate banality, and quickly become anchors that usually add cost and obfuscation to the deliverables. Remember that annoying Windows paper clip “assistant”? Gimmicks often occur when there is an artificial pressure to innovate; to come up with “new stuff” no matter what. The potential for their embarrassing existence is another good reason to avoid the establishment of inane innovation quotas.

You don’t need gimmicks. Perhaps it is true that the best ideas are often the simplest ones—like the wheel. However, if you plan to develop a new system that includes a fair share of innovation, you could do more than simply hope for the best. A good environment for innovation is made of constructing appropriate facilities (offices, labs, and equipment), providing individual and team recognition, establishing open communications, instigating flexibility and, most importantly, ensuring the team is fully aware of the shared objectives and passionately committed to success.

Then again, a little bit of luck doesn’t ever hurt.

Serendipity awaits.

Labels: Aztecs, Gimmicks, Innovation, Pinto, Serendipity, Strategy, Sumerians, Technology, Windows

posted by IT Transformation with SOA @ 4:44 PM

Justifying the Technology Transformation

This is the recipe: slice and dice your company’s view of technology, add a pinch of prognostication, sweeten the core issues faced by your legacy technology; then heat in the oven the mixture your business requirements represent. You can then serve up a fully baked, warmly prepared technology strategy.

Clearly, the key ingredient missing in this recipe is your actual budget. Even if there is a commitment to invest in IT, you should prove that it is worth the investment to undertake a transformation project rather than simply riding the legacy platform bandwagon for a little longer. If you decide on the latter approach, you might want to put this blog on the shelf for now and revisit it later, but if you want to show the need for investment, you’ll have to figure out how to go about convincing the CEO, and the CFO, and any other executive holding the purse strings, to open the company’s wallet.

All this is just my roundabout way of saying that, no-matter-what, you are going to need to develop a business case that shows the benefits of transformation in terms of dollars and cents; not just in qualitatively ethereal terms. You should be able to determine the benefits on the return of investment that the transformed IT will support.

In addition to the identified direct returns from the business team requesting the functionality, this ROI should include the monetized benefits derived from future time to market opportunities, reduced operational expenses (including cost avoidance), and if possible, estimated additional revenue resulting from functionality and features that would otherwise not be feasible with the legacy system.

How do you go about doing a business-oriented justification? Studies show that, in a typical IT budget, 80% is spent on system maintenance and the remainder 20% on strategic efforts[1] Indeed, there is little room for further maneuvering as IT budgets suffer from pressures caused by the global economic meltdown and you’re faced to allocate ever diminishing monies to “keep-the-doors-open” maintenance of systems that definitely must remain operational.

Ultimately, funding a transformation initiative can only come from a mixture of savings on day-to-day maintenance costs, supplemented with the injection of capital from business-driven initiatives. In the end, the business case should be framed with a combination of these benefits:

· Future cost savings due to the avoidance of maintenance expenses resulting from the use of newer technology. These savings can come from leveraging external operation services, removing dependencies on single vendors, opening the door to competitive pricing, and using lower cost commodity hardware and open source code. (Caveat emptor: Open Systems are usually cheaper, but not always! Check the fine print in those support license agreements.)

· Incremental revenues due to the higher effectiveness of the new technology. For example, fewer customer losses due to better service, better accounting and auditing information, reduction or elimination of maintenance outage windows, better business intelligence, and so on. For good measure you should also include estimated development cost savings associated with use of modern technologies and functionality enhancements.

· Added revenue generated by new business opportunities or competitive advantage enabled or supported by the new technology. The ability for the business to quickly implement a new promotion, or to define dynamic pricing based on more sophisticated customer intelligence or more targeted and flexible up-sell and cross-sell capabilities, scaling up to rapidly adsorb an acquisition, the ability to quickly connect to new partners via B2B services, are among the types of benefits you will need to quantify and elaborate upon.

You can try to reduce current operational and maintenance costs to help fund the initial investment for IT transformation but, needless to say, this might be extremely tricky to accomplish. Ironically, were you to accomplish this feat, you would also be playing with a doubled-edged sword. as you might be asked why there is even the need to proceed with a technology transformation, when the company can simply pocket the recouped funds.

Obviously, if there is money to be saved from conventional cost saving measures (renegotiating maintenance fees, reducing marginal staff, deferring expenses, etc.) you should do these as a matter of normal business. However, you will especially do well to identify those short-term savings resulting from the commitment to a strategic transformation direction. For instance, if the company commits to the technology transformation effort, you might be able to nominally reduce service-level agreements for non-critical parts of the current environment, but with the expectation that such an SLA reduction is a short term risk to be remediated by the earlier new project deliverables. Additionally, you might be in a better position to re-negotiate deals with your current vendors with the promise that they will be considered as potential suppliers for future strategic work. As part of the short term cost reduction, you might plan the short-term outsourcing of legacy operations, especially if your long term plan is to also outsource operations of the strategic system.

Be aware of that it is at this early stage of justification that the seeds of large project failures are often buried. The challenge always comes to this: if one is careful to include all possible costs and risks in the request for funding, you risk scaring away the support for the project. After all, executives are almost by nature risk-averse and afraid to accept cost estimates that while realistic, may suggest a grand level of investment.

The temptation then is to sugar-coat the request for investment by presenting best-case diminished cost estimates and over-promising on results.

Please don’t do that.

A better approach is to present a request that clearly delineates the benefits and costs for a series of deliverable phases so that the executive decision-makers can make informed strategic decisions on the level of investment they are willing to commit to. This way you will be able to limit the scope of what’s being promised in order to lower the initial funding request, while still announcing that you expect to come back in the future for additional funding as the project succeeds and proves it worth. Ideally, you will be able to define a first phase that produces benefits, but also points to subsequent phases that provide increasing returns with less and less additional investment. However, never propose a phase that consists simply of “infrastructure” positioning and therefore lacks a clear business case (see my rant below about the idea of business-justifying SOA on its own).

Most importantly, be wary of over-promising results in order to secure support for the new project. Remember, you are going to have to deliver on that promise! In the end, over-promising will only come back to haunt you and is not a worthwhile strategy. Seek at all times to follow this one wise dictum: Under-promise and Over-deliver.

(Rant)

Given that you will likely use a Service Oriented Architecture (SOA) as the backbone for IT transformation (more on this in followings sections), you might feel tempted to justify the endeavor on this basis alone. Don’t. There is no way you can make a business case for SOA. SOA is part of IT strategy; not a business strategy. SOA is all about “how” you will implement technology transformation and not at all about the “why”.

Developing a business case to justify SOA and then getting your CEO to sign a multi-million dollar check to implement it is not doable. Believe me; I’ve tried this! I once made a presentation to the CEO of my company naively asking for a gazillion dollars to implement this thing called SOA. He was a great CEO, he treated me with respect and he was so extremely gracious that he didn’t kick me out of the room when he found out there was no business case for it. Instead, he politely asked me to go back and make a business case for my proposal. Good luck doing that! It doesn’t matter that SOA just happens to be the most exciting thing to come out of IT since the invention of the one hour pizza delivery, or that it truly empowers a business by aligning its IT structure to business processes and goals, or that it does all this with potential cost-saving, open-source technology that can freely inter-operate via services, or that (write in-your-promise-here). What does matter is that your company will only fund initiatives that are framed around business benefits, and these initiatives are those that deal with “why”, and not “how”, the company does things. Yes, once the project has been approved and the process begun, SOA can and should become the solution’s backbone.

Labels: Business Case, IT, IT Transformation Defined, Justification, Requirements, ROI, SOA, Technology

posted by IT Transformation with SOA @ 10:02 AM

Envisioning the Business Impact of Technology

"This 'telephone' has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us."

Western Union internal memo, 1876

It happens all the time. . . Too often, the industry leader invariably misses the chance to grab onto an emerging business. Wells Fargo failed to get into the railway business, Western Union did not get into the telephone industry, and the Rail Companies, lords of transportation in the nineteen century, missed out on the chance to capture the automobile industry.

One can prognosticate the future of technology with techniques that suggest the importance of maintaining a proactive effort in monitoring new developments coming out from the world’s R&D labs, but the challenge is to understand the transformative impact these technologies can have on the business. The problem is that figuring out the future of business will always be more of a divination-based exercise.

Even today, it’s difficult to predict, let alone prognosticate, the ultimate future business impact that the emergence of Web 2.0 services such as Youtube.com, Facebook.com, or Twitter.com represents. This is not to say that techniques used to prognosticate technology cannot also help in imagining “what-if” scenarios for business, but the ability to prognosticate with sound information and well-founded assumptions is at the core of what it means to be a true visionary. After all, most resumes today include some form of “I am a visionary” claim rather than that of “I am a prognosticator”, which would not sound as legit.

Envisioning the future of business is as intriguingly fun as it is difficult. If it weren’t so, there would be far more billionaires roaming the face of the earth these days. Look at how Amazon has transformed the book industry (and continues to do with devices like the Kindle), or the way Apple took the music industry by storm when it properly combined a number of differing technologies and created a viable online music distribution business model (a business that no one from the traditional music industry had the foresight to invent, perhaps because they were focusing too much of their energy fighting Napster rather than riding the winds of change!).

Granted, although the Virtual Presence example may be a bit obvious, there can be no question that a formally established Virtual Presence would seriously impact the travel and hospitality businesses; not to mention the possible impact on industries such as entertainment, education, and healthcare.

True, worrying about this impact might be, well . . . a bit premature, but nevertheless, visualizing possible outcomes can help to position your business as a leading entrant. It can’t hurt to be prepared should something develop more quickly than expected.

We can envision that the initial versions of Virtual Presence will be so expensive that its use will have to be leased from large, well-established Virtual Presence providers. This service can be viewed as the start for a potential transformative development in the future but still unclear is whether hotels will be the natural focus centers for these types of services.

As the cost of technology drops, its availability becomes the realm of opportunistic service providers. Witness the emergence of Internet Cafes; still popular in countries where Internet access is not prevalent, and I still remember that as a child I had to pay twenty cents to watch TV episodes of The Lone Ranger at my neighbors.

Once the technology cost becomes affordable by individuals, you begin to see a gradual segmentation of services based on quality of service. Most of us can use Internet based video-conferencing using “free” tools like Skype, but for more professional Videoconferencing, you would utilize professional office support businesses such as those from Kinko’s. Also, for large employee teleconferencing gatherings, you could lease the services of movie theater operators who advertise this service.

From my previous blog example, if you are trying to understand the implications of Virtual Presence to your hospitality business, you would do well to evaluate whether there is a business model that combines a future Virtual Presence capability with meeting room facilities. For example, you could estimate additional food and beverage revenues, plus sleeping room accommodations for people arriving from regional distances to attend this Virtual Presence event.

Then again, although Virtual Presence technology does not yet exist, this should not stop you from imagining its eventual advent and deciding whether it makes sense to position your system by entering the present Teleconference business. For example, notice today’s placement of high-end Telepresence services like Marriott’s and HP’s announcement[1] to enable the use of HP’s Halo Telepresence Technology from Marriott’s conference room facilities. Clearly, Marriot is looking ahead in this area.

In any case, as much as this prognostication/envisioning exercise showcased the importance of continuous technology monitoring, defining your very own R&D roadmap, and assessing the impact technology can have on the business. While you should avoid becoming an order-taker when it comes to articulating the IT Transformation plans, you should never forget that ultimately everything revolves around the business.

At the core of any prognostication and envisioning exercise is how to match your transformation direction with the business strategy. If your hotel company (in this example) is typically focused on leisure travel, for example, then the idea to push for investments in Telepresence technology will likely not to be well received. That is, unless you find an angle that leverages the use of teleconferencing by vacationing guests, in which case you might end up with a powerful competitive differentiator.

In the end, no matter what, you will need to business-justify the investment on technology transformation, if you are to get it done. This is the subject of my next blog!

Labels: Business Impact, HP, IT Transformation Defined, Marriott, Skype, T, Telepresence, Videoconferencing, Virtual Presence, Vision, Web 2.0, Westen Union

posted by IT Transformation with SOA @ 1:57 PM