eyetoit

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.

Accenture on Transforming the IT Workforce

Stephen D. Page and Susan R. Pearson of Accenture have an article on "Transforming the IT Workforce." [PDF Link] It describes a framework for changing the orientation of the IT organization. The article is aimed at CIOs or those wanting to explore and understand ways of modelling the IT workforce. However, the material presented focuses more on the strategies for framing the IT organization that encourage business alignment, rather than providing recommendations on how it should be organized, per se. I recommend it to non-IT readers because the business has a fundamental responsibility in defining the goals and roles of the IT organization.

Although Accenture derives significant revenue from outsourcing, this article is not about doing more outsourcing of IT functions.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

Bain on IT: Enabler or Impediment?

David Shpilberg and Steve Berez of Bain have released the research findings from a survey "Is IT a Bottleneck to Growth?" [press release and highlights]. Some key highlights:

• Companies who view IT as a key enabler spend an average if 7.4% of revenue on IT, compared to 4.7% for those which do not.
• Fully 60% of those surveyed viewed IT as an inhibitor to growth.
• Two-thirds of senior business executives felt there was poor IT alignment with the business.
• Two-thirds of all respondents felt IT didn't deliver on it's promises, or maybe even its full capability.
• One-third of respondents felt there were a lack IT skills, whether internal or in vendor selection.
• Half the respondents felt that their current legacy systems were adequate to stay current with business needs.

Read the full release, for some observations about where IT delivers value to organizations.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

McKinsey on Changing IT Spending

Ken Davis, Brian Scanlon and Anna Rath of McKinsey & Company have new research on IT spending in the 2004 special edition issue of The McKinsey Quarterly (page 58 in the print magazine or online). The article is short but very information-packed, as is most of McKinsey's research. I'm pulling out some highlights worth mentioning, but I would recommend reading the full article.
They found that due to a combination of factors, IT spending is on the rise (I have certainly noticed this myself). The primary drivers are:

• Capital expenditures from 2000 and before are rolling off the books, meaning lower depreciation expenditures in the budgets, leaving more money available for new capital projects.
• Pent-up demand to replace older infrastructure, due to deferred investment over the past few years. This ranges from garden-variety PC purchasing to security upgrades.

Something else interesting about this, and mirroring a trend I am seeing firsthand as well as in the trade press, is the rise of custom software spending. While 58% of CIOs plan to spend more on software in '04, only 35% are planning implementation of major packages or industry-specific packages, while 65% are planning to develop new applications themselves.

The IT Governance results from the article were interesting as well. A nice infographic depicts the different decision-making roles among IT, finance, purchasing and business units in different types of oversight models for different types of expenditures. The most common model is one in which IT and finance jointly decide on medium and large new initiatives, IT and purchasing jointly decide on small and medium commodity infrastructure and CIOs can make autonomous decisions otherwise (including anything related to integration and complex infrastructure).

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

Ford Says No To Packaged Applications

Computerworld reports on Ford's decision to abandon the use of Oracle's eBusiness Suite for purchasing and procurement, and return to their mainframe-based custom system. The Oracle 11i implementation was a 5-year initiative Ford called "Everest."

What I found interesting is that although no real reason was given by either Ford or Oracle (who claimed to be honoring an NDA), sources said it was due to performance problems. While I tend to expect package implementations to have challenges due to functionality (or difficulty tailoring the package to meet the needs of a specific company), performance is something that can usually be addressed fairly well, either by a consulting firm, Oracle's own consulting group, or other Oracle resources, especially for a customer the size of Ford.

I do give Ford credit for making a hard choice to go back to a previous system. However, it is unfortunate that now they are left with a fairly old legacy technology base. In addition, waiting 5 years into a project to kill it seems like very slow decision-making. I suspect a combination of deeply-held optimism and an unwillingness to recognize sunk costs as sunk contributed to this.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

AMR on HP's SAP ERP EPS WTF?

That is, AMR Research on HP's problems with their upgrade of their SAP Enterprise Resource Planning (ERP) software, causing them to miss their earning targets. [PDF Link]. Some highlights:

A Project Mishap Can Cost Far More Than the Project
"HP lost $160M in revenue and $70M in margin...5% of the division’s revenue. It was also many times the project budget. Using AMR Research’s estimation metrics for these projects, the project cost for this near-$4B division was around $30M."

The Business Failure Was In Contingency Planning
While the project didn't come off without a hitch, it was a big effort: it was a system consolidation and upgrade, requiring two business units to unify their business processes; the project was also part of the larger ongoing HP/Compaq integration. "The deleterious results were due to a lack of contingency planning. HP believes the divisional management should have had plans in place to detect and work around the problems and delays possible in any large systems project. As a result of this and other execution problems, three top division executives are gone."

HP Management Holds Business Leadership Accountable

• "Three top division executives are gone."
• "There were no terminations in HP Consulting, which provides IT implementation and operations services to the division."
• "HP does not blame SAP for the problem. In fact, HP did not even mention the vendor until a financial analyst referred to the 'SAP migration' in a question on the conference call."

The Upshot
Ultimately, one of the few places a business manager can control for IT risk to their organization is in contingency planning. Contingency planning can be difficult and many feel it is time ill-spent ("If those IT guys would just get the project done right, we wouldn't t need to waste our time making a contingency plan.") The fact is that there are a lot of things we do in business that are focused on risk mitigation, and contingency planning for IT risk needs to be one of them.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

Some Quick Reading Recommendations on the Subject

	E-Business and ERP: Transforming the Enterprise (by Grant Norris, et alia) While I'm not a huge fan of the title, this is a short book written by PWC folks that really does a good job of walking through some of the high-level aspects of ERP systems and the implementation process. Covers issues from valuing your ERP investment to architecture to political and cultural challenges in implementation. The book is too short and too informative not to be worth a read.
	Maximizing Your ERP System: A Practical Guide for Managers (by Scott Hamilton) Oriented at manufacturing organizations, the book covers many of the key business processes enabled or affected by an ERP implementation such as lean manufacturing, demand planning and made-to-order (MTO) product. Good for a business manager or a technologist unfamiliar with ERP.
	Stop IT Project Failures (by Dan Remenyi) Regrettably Out of Print today, but this is a good, if slightly dated, book on IT project risk, accounting for it, reducing it and managing it. Tables and checklists make this good for a quick primer or a more thorough read. Check Amazon for used copies (they don't have any as I write this) and pick it up if you see it used.
For some quick high-level thoughts, BearingPoint has a good white paper "Implementing ERP Systems In The Public Sector: Nine Sure Ways to Fail - Or Succeed." [PDF Link] Although it is directed at the public sector, most of the ideas apply directly in the private sector as well.

The $1.6 Billion Web Site

How does your organization account for the cost of project overruns? Most of the time, the easy way is to look at the final cost of the projcet and subtract the budgeted cost, the result being the overrun cost. But is that the only way to look at things?

The problem is that in very large companies, even very large budget overruns can look smaller than they should. A million here and a million there might not seem so large if one is inside a Fortune 200 company. But the impact of overruns is enormous.

The title of this article is from an e-mail I sent to the finance chief for a very large company's IT organization (yes, the IT group spent so much money they had their own finance group). I was giving him a hard time about a very large online project that was over budget by tens of millions of dollars (and about 300% over the initially planned budget). I'm not going to say what company, obviously, but I can assure you that you most likely know them well.

I sent him an e-mail after he and I had been out for a cocktail and he had be bemoaning how out of control this project was. Unfortunately, there was little he could do about the situation (more on that another time). My e-mail simply said:

The site is now up to 26.4 cents/share, or at today's 18.6 PE, up to $1.58 billion.

BTW, how many [widgets] do you guys need to sell to net $85 mil?

(To be clear, the $85 million was the overrun, not the total spend.) He apparently circulated the e-mail around his organization some. Some people laughed, but I think it did get people thinking. Since that time, it would be an understatement to say that there has been substantial change in the IT model at that company.

When thinking about budgets (and especially overruns) in projects (IT or otherwise) it would be helpful if companies took a moment to frame up the expenditure in other contexts than just the dollars spent. Frame it out in EPS terms. Think of the machinations a company will go through to meet the street estimate, having to gather a penny or two EPS from squeezing different places in the organization.

How much management attention was spent trying to juggle the rest of the business to meet street expectations with all this missing money? Was it worth it?

How much other investment was the company deprived from making to cover this $85 million gap? How much of that deferred investment would have had a higher ROI than the web project? Was it worth it? The part I am really curious about is how often the ROI gets recomputed on a project like this. Maybe at the budget of $20 million, this project had a very good ROI. Maybe even at $30 million? I don't think it had the same ROI when it got past $70 million?

Most importantly, how much work did the company have to do to earn that money in the first place? Unlike, for example, sales commissions, IT costs get paid by the value-creating functions of the business. This is not to say that IT can't create value itself, or be a force-multiplier for value creation; however, I can assure  you that the business in question receives no direct income from the development of web-based applications; they have to sell widgets to people and businesses to pay for their very expensive IT habit.

Sometimes $85 million isn't just $85 million. It came from somewhere and it could have gone somewhere else. Just looking at the numbers ignores the real cost of these overruns on the business.

Now, any modern corporation usually assess the ROI on a project during the budgeting phase, but how many do it again when budget increases are approved, when everyone is falling victim to the sunk cost fallacy?

It is incumbent on business leaders to focus on the real cost of projects, and the real impact of project overruns on the short-term financial and long-term overall impact on the business.

Exercise: What was the aggregate cost of project overruns in your company last year? What was that as a percentage of your net profit (because it would have all gone to the bottom line)? What was the EPS impact? What projects were unfunded or underfunded to cover the shortfall? How did that lack of investment impact the business today, and for the future?

See why project risk management is a business leader's job, not just an IT leader's job?

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

The Seven Habits of Defective CIOs

TechRepublic has a little guide to the seven habits of wildly unsucessful CIOs. The article's worth a read, especially if you might want to anonymously send it along to someone you know. The defective habits (and my comments on them) are:

1. Acquire technology simply because it's new - [But everyone likes bright, shiny new things.]
2. Exhibit a knee-jerk reaction against open source - [I would change this to exhibiting a knee-jerk reaction to any viable solution alternative.]
3. Create solutions in search of a problem - [The unfortunate practical downside to a limitless desire to solve problems.]
4. Eagerly reach beyond competency level - [This usually is found in a CIO getting into a deeply technical matter when they have risen the ranks because of their skill as a generalist.]
5. Act as CMOs—Chief Marketing Officers - [Although I have had clients that would not have been harmed by someone, anyone, taking on this role.]
6. Fail to understand relationship between technology and business - [The ultimate blames here lies with the one who promoted this defective CIO into the executive ranks.]
7. Don't communicate well with nontechs - [a.k.a. Don't communicate well with the vast majority of humanity...always a problem.]

I would also add:

• Exhibiting blind faith in a package vendor's silver-bullet solutions
• Weak management skills
• An inability to involve the business in technology initiatives.

I am certain we could all come up with more, but this is a good start. CIOs who exhibit one or more of these traits are quite common. If you're in IT management, check yourself. If you're on the business side and see this behavior, there is value in further expanding your own knowledge of IT for your organization's benefit.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.