eyetoit

Thinking about IT and the Board

The point of these writings, for the most part, is to offer some insight and observations that business managers, executives and directors of (primarily) non-technology companies to help better manage the role and function of IT within their organization. In October's Harvard Business Review, there is a quite good primer on board-level IT governance written by Richard Nolan and F. Warren McFarlan.

In "Information Technology and the Board of Directors" (p. 96 in print - subscribers can access here - non-subscribers can view an excerpt) Nolan and McFarlan lay out a succinct yet reasonably detailed framework for thinking about key issues of viewing IT as part of the corporate governance function, such as:

• What is the current role of the firm's IT operation - (Support, Factory, Turnaround or Strategic) -  I have always used somewhat different labels - Cost Leadership (Support), Operational Excellence (Factory) and Differentiation (Strategic). Also, I have always excluded "Turnaround" as a independent role because it should be getting turned around to something (i.e. one of the three other types) - but from a governance perspective, the key point is that board should expect to more thoroughly scrutinize relevant issues in a case of a turnaround.
• What sort of questions should the board ask for each type of IT operation?
• How often should they ask these questions?
• What is the role of a board IT expert? (see some of my comments in "IT Savvy Board Representation" from last year)
• How do you establish an IT governance committee on the board?

There are details within the article about which reasonable people can differ, but overall it is really quite a good piece and I would encourage any senior business manager or director to read it and discuss it with their other board members.

Why You Shouldn't Earmark Capital for IT

Bart Perkins of Leverage Partners has a short and sweet piece in ComputerWorld titled "A Separate IT Capital Pool Makes No Sense." While I have certainly argued in favor of valuing IT projects (and their too-common overruns) in the context of the impact they have on the business (cf "The $1.6 Billion Web Site"), Perkins does a good job of breaking out some clear reasons why firms should not provide an earmarked capital IT budget. Several of his reasons are the obvious ones, and most all cache out to the benefit of holding all capital spending to the same standard, but he also identifies out some organizational benefits that occur when IT investments must stand on their own merit.

Thinking About Offshoring As a Solution: What's The Unit of Measure?

I continue to be surprised at the continuing flight many firms are making to offshore development, even as many of the early adopters of offshoring are returning to domestic sourcing of more services (See "Return to Sender"). I think much of the pressure for offshoring comes from flawed assumptions and possibly flawed logic, both of which merit discussion.

Possibly the most pernicious situation with offshore development is the preordination or blanket directives for using offshore development. As an example, about three years ago I was in discussions with a global manufacturer about contracting with my firm to build a reasonably complex software application. I knew what the complexity of the system was because my firm had already built a very, very similar application. As we are able to do with most of our engagements, I suggested that we could do this for a fixed fee, and ballparked a fixed fee cost of approximately 1/2 of the next best (primarily offshore) development estimate they had on the table. Seems like a no-brainer, right?

Project Success Rates Drop in 2004 (And the hidden reasons why)

Frank Hayes wrote in ComputerWorld today about the preliminary results of the annual Standish Group study on IT project failure rates. They are actually up from last year. This year saw 28% of IT projects were entirely successful (delivered expected functionality within budget) and 18% were canceled before completion - complete failures. Last year's study had things at 34% - 18%. Apparently the numbers are not yet finished being tabulated and analyzed, but Hayes learned from Standish that there were a few things of note:

1) Projects are getting bigger again, and we know from experience that big projects are more likely to fail

2) Larger projects have meant a return to more traditional development schedules

3) Lack of user involvement has gone back into the #1 spot for project failure. (Last year's #1, lack of executive support is still running a tight second).

The obvious advice is to work to keep projects small. Hayes correctly identifies well-known reasons smaller projects are more likely to succeed: fewer people means less communication and management overhead; small projects can more easily be developed iteratively with a high degree of user involvement; finally, they avoid the corporate politics that can come to pass with large projects.

Infrastructure Complexity

Swapnil Shah has an "opinion" piece in Computerworld this week on the challenges of complexity in corporate computing infrastructures, "Defying the IT 'Butterfly Effect.'" I put the scare quotes around "opinion" because in all fairness, Shah is the CEO of mValent, a company that, not surprisingly, has tools for managing complex corporate computing infrastructures (imagine that!).

However, Shah's economic interest in solving the problem doesn't diminish the truth of much that he writes, and it is good food for thought when thinking about the real cost of excessively complex architectures. And while Shah focuses on the value of tools from vendors such as mValent for solving some of the problems this complexity creates, it is also worth considering the long-term savings that can result from rationalizing a complex architecture, as I wrote about some weeks ago in "ROI and IT Architecture"

The CFO of IT (versus an IT Controller)

Computerworld has a number of interesting articles on an increasingly popular role, "The CFO of IT," leading with "The Number Crunchers" and a too-short sidebar interview with the University of Miami's former IT finance guy.

Setting aside the fact that I really dislike grand titles, I'm not sure exactly how much I like the concept of the role that such a title implies, although certainly I think a lack of finance-minded folk in IT is a problem. I think the main issue I have with the concept is what exactly the function entails, and why companies may seek the role. For example, the CFO of AIG's IT group (which in AIG's case is admittedly a separate entity) defines his role as: ""to determine and explain to senior management what AIG is spending on IT and to provide reasonable assurance that expectations are being met."

Is this an important function? Yes. My question is: why wouldn't this be part of the CIO's job?

Should You Kill That Project?

If you sponsor enough IT projects, it is likely you will most likely be faced with the decision of whether or not to kill a project. The decision is almost invariably a difficult one, with a desire to see the solution achieved vying with a realistic assessment of the project actually achieving the desired outcome. Emotional factors such as corporate face-saving and an the irrational value typically assigned to sunk costs complicate the intellectually challenging task of accurately predicting the final cost and final success of the project. In this installment, I hope to provide sponsors with some thoughts about making that difficult decision as to whether or not a project should be terminated.

Also, be aware that all of these points will also have merit in keeping an eye on projects to see if they are on track or starting to tempt fate. Many projects that ultimately need to be killed either shouldn't have even started or could have been saved had people caught the warning signs earlier.

One of the first things to realize is that, unfortunately, IT project failures are not uncommon. If you are in a large organization, it is a virtual certainty that projects have failed, even if those projects were not killed outright, or labelled as failures, Many projects actually seem to take former Senator George Aitken's advice about Vietnam, namely to "declare victory and go home." The point is: do not make the mistake of thinking that the project failure is truly unique, do not let the fear of being "the only one" to have a failed project prevent making the right decision.

Things to Think About With Integration Projects

Computerworld reported in July about a new industry group, the Integration Consortium, that aims to make systems integration projects less expensive and more successful for its members. It is a very ambitious aim, and some of their goals are of a "boil the ocean" magnitude. While we're waiting for the ocean to heat up, a better understanding of integration from a business standpoint should actually help improve an organization's integration project outcomes in the near term.

It is a good bet that systems integration, in one form or another, will continue to drive a good chunk of IT value in many enterprises. Integration is what allows more parts of the enterprise (and the extended enterprise of suppliers and customers) work together with less and less human intervention.

At the very basic end of integration is simply getting system A to send data to system B (e.g. sending filled orders to the AR system for invoicing). More advanced integration has systems A & B sending data back and forth (an inventory and order management system communicating, for example). Progressively more advanced integration projects tie together multiple disparate systems and may start to incorporate aspects of Business Process Management (BPM) such that workflows and business rules are applied to the data moving from system to system (for example, managing the return process from the customer service rep issuing an RMA to the warehouse receiving the return and all the way to accounting for credit).

According to the Computerworld piece, The Standish Group estimates 95% of all integration projects fail, that is, overrun their schedules or budgets and/or underdeliver on their goals. Now, this is one of those stats that begs a number of questions, however, even the base number indicates something is wrong with these projects. The Computerworld piece also says industry studies peg integraton costs at 35% of total IT project costs for the average company. No matter how you slice it, this is a big impact issue.

Since I think the Integration Consortium's dreams are a long way from being realized but recognize that integration should continue to be a business technology objective, here are some things the business should think about when it comes to integration in the enterprise:

ROI and IT Architecture

I was a little alarmed to see an article on gantthead written by Vijay Sankaran titled "Down With ROI!" Gantthead is aimed at IT project managers and all I am thinking is IT people reading this and adopting this line of thinking in dealing with their organization. Progress for the sale of progress! Onward techie soldiers! My concern was heightened as Sankaran writes, "While I completely concur with the necessity of a business case, I wonder about the great endeavors that mankind may not have pursued if stringent ROI rules had been imposed."

Vijay, we are talking enterprise architecture, not putting a man on the moon! Is the complexity comparable when you look at the IT infrastructures of the world's largest companies? Yes, it is. But nobody is sitting around Citigroup's Network Operations Center saying "One small ATM withdrawl for man, one giant overnight loan for mankind." While the global financial system (and even Citigroup's role in it) is of significant social consequence, it lacks the historical consequence of his cited "great endeavors".

Sankaran's thesis is that when considering migrating an enterprise to a "simplified application and architecture information technology environment...ROI is not the best measure of value-justification." What is? "A systems-based approach [in which] you consider all the externalities of a particular component in a system to evaluate its effect on the overall system."

Despite Sankaran's anti-ROI rhetoric, his basic claim is simpy that one must appropriately expand the scope and the time horizon of an enterprise architecture project's ROI assessment. I think the most fair interpretation of Sankaran's real argument is that enterprise architecture projects should not be held to the same payback schedule as might be required of a more focused initiative.

With that, I can certainly agree. The value of modernizing enterprise architectures has a variety of payback parameters that companies should take into consideration, such as:

Enterprise Software Negotiation

This week AMR Research produced a note on negotiating with SAP. They focused on SAP because the company is doing very well despite AMR's view of the sector being weak. This idea of the Enterprise Applications (EA) sector (ERP, CRM, SCM, etc.) being generally weak does not resonate with my current experience. I am seeing a significant number of non-SAP (mostly Oracle) ERP implementations in the local market, although Oracle has a historically strong footing in these parts. I think part of the sector weakness right now may be caused by Oracle's continuing, and possibly Quixotic, designs on acquiring PeopleSoft as well some uncertainty among current JD Edwards customer caused by PeopleSoft's acquisition of JDE.

Getting back to the issue of enterprise software negotiation, it is important to recognize that incumbent package vendors have some significant advantages when they come to the negotiating table (beyond the obvious issues of frequently negotiating EA deals and having a more intimate understanding of their licensing models). Enterprise applications are expensive to implement and relatively painful to change, especially if moving to a new packaged application that would possibly need to be customized or involve substantial process change or retraining. This creates enormous switching costs, a software vendor's most significant advantage. Vendor lock-in is even more significant now as companies are further hesitant to switch because of their recent efforts in process control and documentation activities driven by Sarbanes-Oxley compliance initiatives. Does anyone really want to go through that right now?

Now, of course single-sourcing isn't all bad. The common architectural platform of a full-line vendor such as Oracle 11i or SAP R/3 (and to a lesser extent Peoplesoft) means easy integration among a wide variety of applications. Integrating disparate packaged applications proves to be a challenge (or at least surprisingly costly) for many organizations. This is the sort of thing that seems like it should be easy until you really get into the nuts and bolts of it.

However, the price paid for this ease of integration is the possible need to compromise on functionality in certain application areas. In this case, my typical advice (and what I have seen work well) is to select the suite that best meets the broad requirements and then implement custom solutions in those areas where the suite vendor doesn't have a module or where the module does not meet a defined threshold of fit for the company. This is a larger topic and one I will explore more deeply in a future post.

Now, almost all the major IT research firms (AMR, Gartner, Giga, etc.) offer consulting services to help negotiate with vendors. If your company is already a client of one of these firms, it's worth reading their vendor-specific advice. If you're not a client, or you just want a negotiating primer, here is a quick rundown of generic strategies you should consider the next time you need to negotiate with your EA vendor.