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

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