October 12th, 2009
Oracle's integration strategy: Customer trade-offs
Oracle’s dual Presidents, Charles Phillips and Safra Catz, today opened the company’s OpenWorld conference, which is taking place this week in San Francisco. Their keynote speech emphasized Oracle’s efforts to integrate its diverse product line in a bid to make life simpler for customers.
Catz opened her part of the keynote by explaining what she called the “back story” behind Oracle’s acquisition strategy. She did this with a humorous look at what would happen if we bought cars the way we buy enterprise technology.
In such world, Catz said we would go online to buy thousands of disconnected parts from many vendors, which our children would assemble into a completed car because the parts would not come with instructions. Just as we finished assembling the car, she continued, a light would go on indicating that an upgrade or patch is required. Catz said, “We would then do it all again.”
Catz used this car assembly story as a metaphor for product complexity in the enterprise. According to Catz and Phillips, Oracle reduces this complexity by bringing together under one roof infrastructure, hardware, and database products that are “engineered to work together.”
This diagram expresses Oracle’s end-to-end vision:
Regarding the “open” tag line on the slide, Catz said, “We are slavishly devoted to open standards.” Wow, that’s a pretty strong statement.
THE PROJECT FAILURES ANALYSIS
From a project failures perspective, important truths lie beneath the cute story about assembling cars at home from parts purchased online. As Catz correctly points out, many organizations purchase enterprise technology in pieces from multiple vendors, which can make the selection and implementation process time-consuming and expensive for the customer, relative to buying from a single vendor.
I discussed these points during a follow-on conversation with Paco Aubrejuan, Oracle’s Vice President of PeopleSoft Enterprise, who explained the benefits of single-vendor integration:
October 1st, 2009
The 'Seven Laws of Projects'
Anyone who reads this blog knows projects can go very wrong. While that’s not news, an unexpected source — American Express OPEN Forum — published a blog post neatly summarizing why:
We have delusions of success. We take on more than we should, routinely exaggerating the benefits and discounting the costs. We over-scope, over-scale, and over-sell. At the same time, we under-estimate, under-resource, and under-plan.
I think that does indeed state the problem simply and with complete accuracy.
The post comes from Matthew E. May, author of In Pursuit of Elegance: Why the Best Ideas Have Something Missing, who describes what he calls the Seven Laws of Projects:
- A major project is never completed on time, within budget, or with the original team, and it never does exactly what it was supposed to.
- Projects progress quickly until they become 85% complete. Then they remain 85% complete forever. Think of this as the Home Improvement Law.
- When things appear to be going well, you’ve overlooked something. When things can’t get worse, they will. (Murphy’s Law says, “If something can go wrong, it will”—this is a corollary).
- Project teams hate weekly progress reports because they so vividly manifest the lack of progress.
- A carelessly planned project will take three times longer to complete than expected. A carefully planned project will only take twice as long as expected. Also, ten estimators will estimate the same work in ten different ways. And one estimator will estimate ten different ways at ten different times.
- The greater the project’s technical complexity, the less you need a technician to manage it.
- If you have too few people on a project, they can’t solve the problems. If you have too many, they create more problems than they can solve.
These laws have nothing to do with technology or IT, which makes sense because failure rarely does. To understand failed projects we need to look into dimensions of collaboration, relationships, and management.
Why do failed projects persist? Because it’s easier to fix bugs than to be ruthlessly honest with the team, the project and, most especially, with oneself. And that’s the truth… think about it.
[Thanks to Guy Kawasaki for the pointer. Photo from iStockphoto.]
September 9th, 2009
6 dirty tricks from enterprise vendors
Enterprise software vendors sometimes play unpleasant games to sell their products. InfoWorld describes these tricks in a story called, Dirty Vendor Tricks, written by veteran journalist Dan Tynan, who has covered many stories of IT failure.
Here’s Dan’s list of six tricks enterprise vendors use against customers, but the descriptions are mine:
- The magic demo. Using presentation slides and canned demonstrations, the vendor claims to solve the customer’s most challenging problems. It’s all good, except when there is no real product to back up the promises.
- Underbid, then overcharge. A beautiful trick often played elegantly by consulting companies and system integrators. These folks neglect to inform the customer that the initial software purchase price does not include much higher associated costs for equipment and implementation services.
- The customer headlock. One of the cleverest tricks in the book, this one uses high switching costs to lock-in customers. The time, cost, and hassle of swapping enterprise systems mean vendors have their customers by the… well, you know what.
August 31st, 2009
Debunking Enterprise 2.0 failure
As part of a series of guest posts, I asked Enterprise 2.0 thinker, Paula Thornton, to contribute a blog challenging assumptions about IT failure. Her post jumps into a discussion with ZDNet blogger, Dion Hinchcliffe, on the subject of failure in the Enterprise 2.0 world.
Paula Thornton seeks to understand human behavior and designing interactions for human expectations as 
the means to achieve strategic differentiation. This is the focus of our discipline. It is not just nice to have‚ and is not, like documentation once was, an afterthought. It is the means by which to start a strategic discussion and the means by which to drive a tactical initiative. All design should be evidence-based. Follow Paula on Twitter as @rotkapchen.
As someone actively involved in the Enterprise 2.0 community, a post by ZDNet’s Dion Hinchcliffe, called 14 Reasons Why Enterprise 2.0 Projects Fail caught my attention. While I have great respect for Dion, his piece offers overly general advice that will not actually help practitioners avoid failure.
As a commenter on his post clearly states, Dion’s advice is not specific to Enterprise 2.0 initiatives:
To be honest, I think these are pretty broad and apply to most IT projects. Aside from the generic factors, I would challenge the idea that there is a set of common failures that we can boil down to.
Sincere efforts to observe and evaluate what’s happening with Enterprise 2.0, and why, are valuable. But they face a critical challenge, noted by Christopher Alexander, way back in 1964:
Today functional problems are becoming less simple all the time. But designers rarely confess their inability to solve them. Instead, when a designer does not understand a problem clearly enough to find the order it really calls for, he falls back on some arbitrarily chosen formal order. The problem, because of its complexity, remains unsolved. [emphasis added]
Does Dion’s post contribute to solving the problem, or does it fall back on the symptoms of failure? If not unique to Enterprise 2.0, are these symptoms part of a larger problem that isn’t being solved? If smoke, where’s the fire?
June 22nd, 2009
HP connects IT investment, value, and transparency
Last week, I attended HP’s Software Universe 2009 conference to participate on a panel discussion around success strategies for deploying project portfolio management (PPM). I used the opportunity to speak with HP executives about their vision for the future of PPM and its relationship to enterprise value creation.
To understand the company’s PPM product direction, I spoke with four folks representing HP’s views on features, strategy, and customer implementation:
- Paul Muller, VP for Strategic Marketing
- Ken Cheney, Director of Products, IT Financial Management
- Bruce Randall, Manager of Product Marketing, PPM
- John Wills, Practice Principal for HP’s Business Intelligence Solutions group
HP’s primary strategic message about the future direction of PPM involves helping IT departments improve their ability to quantify project costs, benefits, and derived value, which Paul described this way:
We automate the spreadsheet Kung Fu that IT often uses to analyze financial data. Our goal is reducing decision-making cycle times and creating transparency that quantifies the business value of IT operations.
Ken Cheney elaborated on this message:
Many organizations find it difficult to get an accurate handle on IT costs. We link IT with the business services it delivers and assign value to help IT appropriately price these services. The future of PPM is helping organizations clearly see the total cost of ownership of all IT services.
HP’s strategy positions PPM as a building block in a broader IT financial management offering, as the following diagram illustrates:
May 1st, 2009
Senate introduces important IT watchdog bill
Senator Thomas Carper [D-DE] introduced valuable new legislation designed to increase oversight, transparency, and monitoring of federal government IT projects.
The bill requires agencies to establish public websites showing the status of IT investment projects and mandates creating expert “tiger teams” to help improve troubled projects.
Carper’s introductory statement describes three general goals for this legislation:
- Using a public website to increase transparency around the performance of government IT projects. Carper explicitly calls out VUE-IT, an excellent Office of Management and Budget (OMB) IT status site, as a model.
- Ensuring that agency plans for new IT systems contain a clear business case and provide complete and accurate information before the OMB approves the investments.
- Empowering OMB and agency Chief Information Officers to take action if they realize a project isn’t going as planned, before it spirals out of control including assigning experts to help fix problems.
KEY PROVISIONS
The bill is called S. 920: the Information Technology (IT) Investment Oversight Enhancement and Waste Prevention Act of 2009. It amends section 11317 of title 40, United States Code.
March 14th, 2009
UK prison IT: Massive and 'spectacular' failure
The UK National Offender Management Information System project (called C-NOMIS) failed amid scathing attacks, accusations of mismanagement, and vast budget overruns. The project offers an excellent case study relating failure directly to inadequate governance and oversight.
The project was supposed to create a single database allowing UK prison authorities to track and manage offenders while they are in custody and following their release. After a three-year delay and doubling of costs, authorities abandoned the critical, single database concept.
A National Audit Office (NAO) analysis of this project concludes:
November 17th, 2008
11 "Laws of IT Physics"
Given high rates of failed IT projects, it’s helpful to examine first principles that underlie successful technology deployments. Even though devils live in the details, understanding basic dynamics behind successful project setup, execution, and management is important.
During testimony before Congress, in a hearing titled “The Dismal State of Federal Information Technology Planning,” Norm V. Brown, Executive Director of the Center for Program Transformation, an IT failures think tank, presented what he calls “Laws of IT Physics™.”
These “Laws” highlight hidden pitfalls the hurt many projects, and help explain why some projects succeed while others fail. They recognize that successful IT project delivery is primarily about managing people, process, and deliverables. Yes, technology is important, but the people side comes first. Here’s the list, with slight editing:
July 18th, 2008
Levi Strauss: SAP rollout 'substantially' hurt quarter
SAP implementation problems prevented Levi Strauss from fulfilling orders for a week during the second quarter of this year.
These shipping problems, combined with other economic issues, caused the company’s net income to drop 98% relative to the same quarter in 2007. Levi’s most recent 10-Q SEC filing states that negative effects arising from the implementation “constitute a substantial portion of the decrease in the region’s net sales in the second quarter as compared to the prior year.”
The company has been deploying SAP in staged releases around the world since 2003. A Levi’s spokesperson told me the company launched its US-based ERP initiative this spring, and experienced difficulties connecting and integrating various legacy systems:
We ran into technical issues going through the implementation process, which interrupted shipping for about a week. We experienced shipping delays as we ramped the system back up, resulting in lost orders.
Although Levi’s has not disclosed much detail about the problem’s causes, the company’s SEC filing offers clues:
We are currently implementing an enterprise resource planning (“ERP”) system on a staged basis in our subsidiaries around the world. We implemented the ERP system in several subsidiaries in our Asia Pacific region prior to fiscal 2008. During our second quarter of 2008, we implemented the ERP system in the United States resulting in changes in our system of internal control over financial reporting. Certain controls that were previously conducted manually or through a number of different existing systems were replaced by controls that are embedded within the ERP system, resulting in an update to our internal control process and procedures, the need for testing of the system and employee training in the use of the new system. Subsequent to the U.S. implementation, we encountered issues with the U.S. ERP system which caused us to further revise our internal control process and procedures in order to correct and supplement our processing capabilities within the new system.
The changes described above materially affected our system of internal control over financial reporting during our last fiscal quarter. Our current system of internal controls over financial reporting continues to provide reasonable assurance that our books and records accurately reflect our transactions and that our established policies and procedures are followed.
Francine McKenna, a former PriceWaterhouseCoopers consultant and auditor, interpreted the SEC filing for me:
It’s serious stuff. The language suggests that fundamental internal control errors were discovered after the system went live. Apparently, auditors determined these problems could have resulted in a materially significant impact to Levi’s financial statements if not corrected. I can speculate that perhaps it was inventory related, because it’s the big balance sheet item for a company like this.
Also, given Levi’s previous errors and restatements, and with the recent change in auditors, new auditor PwC is probably taking a very strict approach to assessing Levi’s efforts to implement SAP with required controls.
The filing suggests that Levi’s anticipated potential ERP problems:
In anticipation of that implementation, we provided advance shipments to wholesale customers in the first quarter of 2008 that would normally have been shipped in the second quarter. Our ability to fulfill customer orders in the second quarter was subsequently impacted by issues encountered during stabilization of the ERP system.
The implementation is currently in a “stabilization period” and Levi’s believes the worst is over:
Throughout the ERP system stabilization period, which we expect to last for the remainder of the year, we will continue to improve and enhance our system of internal control over financial reporting. We plan to implement the ERP system in other subsidiaries in the coming years and we continue to believe that the ERP system will simplify and strengthen our system of internal control over financial reporting.
THE PROJECT FAILURES ANALYSIS
Levi’s hasn’t released much technical detail regarding what caused the order fulfillment difficulties; given this lack of information, it’s hard to draw conclusions with any level of confidence.
Nonetheless, a one-week shipping interruption is serious by any measure. Although Levi’s apparently anticipated potential go-live problems, the severity and depth obviously took the company by surprise.
One analyst quoted by CIO magazine in 2003 questioned Levi’s overall project timing:
Levi’s is bucking the industry-wide trend by going ahead with ERP now. “It’s expensive, high risk and requires a lot of cultural change, and unless you have a really compelling reason to do them you don’t [during a downturn],” says Paula Rosenblum, an AMR Research analyst.
It’s interesting to note that Levi’s former CIO has quietly disappeared from the scene. From the Guardian:
David Bergen, Levi’s chief information officer, who came on board eight years ago to reconcile the company’s hodge-podge of systems to a SAP-centric one, has quietly left Levi’s. No announcement was made at the time and no reason is given for his resignation by the company.
Devil’s triangle relationships. Virtually all large ERP implementations involve three parties, which I call the devil’s triangle: software vendor, customer, and at least one third-party implementation services provider.
The complex and interlocking set of business and technical agendas governing these relationships can make failures difficult to dissect accurately. Of course, the parties usually don’t want to discuss their failures in detail, which also makes full analysis hard.
In this case, Levi’s is the customer, SAP the software vendor, and Deloitte appears to be the primary implementation partner. Levi’s responded to my question about Deloitte’s role:
A number of business process and systems integration experts have supported our ERP implementation. This included Deloitte among others.
SAP and Deloitte were associated with another recent high profile IT failure: the Los Angeles school district’s (LAUSD) morale damaging problem printing paychecks. Regarding LAUSD, I offered the following comments to SAP, which likely apply here as well:
SAP…something has gone very wrong and you’re the ultimate experts. It’s high time you crossed some boundaries and pushed Deloitte harder.
Experience studying implementation failures suggests Levi’s also played a contributing role in this situation. Since the company presumably follows a standard methodology for all rollouts and has successfully deployed SAP in other regions, something different happened here. Although we can only guess, perhaps the differences relate to unexpected complexity in the financial environment at Levi’s company headquarters or in project management issues unique to the US rollout.
Regarding current status, Levi’s spokesperson said, “Although more work remains, we’re back to shipping at customer demand levels.”
May 26th, 2008
Twitter: An IT failures management perspective
Twitter, the well-known social messaging service, has finally acknowledged the depth and severity of technical problems causing downtime and disruption to users. While such candor is refreshing, it also offers a glimpse into the kinds of management issues that underlie virtually all IT failures.
The end-user problem. Twitter has raised about $20 million of funding and garnered tremendous publicity, giving users the expectation this high profile company should offer consistent and reliable service. Despite Twitter’s substantial resources, it has acknowledged the service is not sufficiently reliable. From the Twitter blog:
[This graph] should be flat.
We’ve gone through our various databases, caches, web servers, daemons, and despite some increased traffic activity across the board, all systems are running nominally. The truth is we’re not sure what’s happening. It seems to be occurring in-between these parts.
The technical problem. As typical of many Web 2.0 companies, Twitter built its service to meet short-term objectives; in this case, that meant choosing an unsuitable technical architecture, as another post on the Twitter blog describes:
Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system. [This has] introduced a great deal of complexity and unpredictability….This is, clearly, not optimal.
THE PROJECT FAILURES ANALYSIS
When technology fails, management oversight and skill usually determine the impact on a business and its users. Twitter acknowledged they “aren’t sure” where the technical problems lie and admitted they built the basic architecture for “expediency” rather than suitability to task.
Lack of sufficient management experience and judgment ultimately created the difficult situation where Twitter must rip-and-replace foundation technical components to resolve severe performance and reliability issues. These issues are substantial enough to threaten users’ confidence in both the company and the Twitter service.
Management experience and judgment. I asked Steve Mann, social media strategist at SAP, for comment on the experience issue:
In customer-centric organizations one of the most critical factors which these enterprises focus on is the customer expectation of high availability. Now I don’t know the Twitter management or technology teams so I won’t presume to armchair Quarterback on their behalf but as both an outsider looking in and an avid Twitter user, the recent outages suggest a degree of inexperience. Now maybe they’ve done this but I would have expected the Twitter team to project out usage patterns at least six months ago and based on those projections, would have begun re-architecting their infrastructure in order to scale to meet anticipated volumes and the availability expectations we are seeing today.
Steve also blogged about Twitter’s credibility in the face of poor reliability:
Once trust is blown it doesn’t matter if Twitter fixes its availability issues in a week or a year. Its already lost the opportunity it currently has. One might say, its already lost that opportunity for good.
Zoliblog shares similar concerns about Twitter’s management judgment:
On second thought, I am less forgiving. Twitter already raised $5M before this round, that should have allowed them to bring in expertise they clearly lack. If only their priorities were on fixing the service instead of chasing more money.
Legitimate technology challenges. In fairness, the challenges facing Twitter are substantial and push the limits of current technologies. Hueniverse put those issues in context:
The idea that building a large scale web application is trivial or a solved problem is simply ridiculous….The social web is creating demand for new scaling tools and technologies. Current databases and caching solutions are simply unable to handle a complex network of multiple relationship between objects.
Nonetheless, Twitter’s rollout planing process is clearly flawed. In contrast, Facebook has demonstrated professionalism in large-scale rollout planning:
The secret for going from zero to seventy million users overnight is to avoid doing it all in one fell swoop. We chose to simulate the impact of many real users hitting many machines by means of a “dark launch” period in which Facebook pages would make connections to the chat servers, query for presence information and simulate message sends without a single UI element drawn on the page. With the “dark launch” bugs fixed, we hope that you enjoy Facebook Chat now that the UI lights have been turned on.
The same post says: “scalability has to be baked in from the start,” a lesson that Twitter is learning slowly, painfully, and very much publicly. Facebook is a far larger and more mature organization than Twitter and you can see the difference in their respective approaches toward managing technology.
My take. Twitter is a great service and I love it when it works. In addition, the Twitter folks are friendly and accessible, so it feels somewhat mean-spirited to apply the usual IT failures expectations to them.
Twitter co-founder and Creative Director, Biz Stone, offered these comments by email:
I continue to be inspired by both Jack [Dorsey, CEO] and Ev [Williams, Chief Product Officer] and I’d argue that their talent and judgment is precisely what will navigate us through these growing pains and help us reach the vision of Twitter’s future we all share. You’ll be interested in knowing that we are actively seeking talented managers and we are spending significant resources on recruiting.
Despite the obvious good will, Twitter now has an $80 million valuation and provides a communications infrastructure upon which many people depend. From that perspective, users are completely justified in expecting a robust, reliable service with no explanations and no excuses.
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter. See his full profile and disclosure of his industry affiliations.
Subscribe to IT Project Failures via Email alerts or RSS.
SponsoredWhite Papers, Webcasts, and Downloads
- Get top-ranked Novell support for Red Hat when you switch Novell If Linux is going to power your mission-critical applications, you'd ... Download Now
- Key Strategies for Federal Agencies - Safe and Cost Effective Migration for Legacy Hardware GovConnection The federal government has mandated that federal agencies reduce energy ... Download Now
- ChangeAuditor for Exchange ScriptLogic Quest ChangeAuditor for Exchange proactively audits all activity, provides ... Download Now
Recent Entries
- SAP changes leaders: Time for innovation
- UK tax department: Bizarre IT spending incentives
- Analyst relations: Failure in action
- ERP failure: New research and statistics
- Business intelligence success, ROI, and failure
Blogs From Our Sponsors
Most Popular Posts
- 'Pain chains' and the IT Devil's Triangle
- Social CRM: The inner meaning
- Information silos and IT governance failure
- Call for IT Devil's Triangle research
- IT / business silos: Bridging the gap
- Reflecting on IT / business silos
Top Rated
- 'Pain chains' and the IT Devil's Triangle+6 votes
- Reflecting on IT / business silos+5 votes
- UK tax department: Bizarre IT spending incentives+3 votes
- ERP failure: New research and statistics+3 votes
- Information silos and IT governance failure+3 votes
- Business intelligence success, ROI, and failure+3 votes
- Social CRM: The inner meaning+2 votes
- IT / business silos: Bridging the gap+2 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
Archives
ZDNet Blogs
- A Developer's View
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- Collaboration 2.0
- Dev Connection
- Digital Cameras & Camcorders
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Web 2.0
- Forrester Research
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Home Theater
- iGeneration
- Irregular Enterprise
- IT Project Failures
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- The Semantic Web
- Service Oriented
- Smartphones and Cell Phones
- Social Business
- Social CRM: The Conversation
- Software & Services Safari
- Software as Services
- Storage Bits
- Team Think
- Tech Broiler
- Technology and the Global Supply Chain
- Tom Foremski: IMHO
- The ToyBox
- Virtually Speaking
- The Web Life
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
White Papers, Webcasts, and Downloads
- VMware Infrastructure: A Guide to Bottom-Line Benefits VMware Frustrated by the costs of maintain ever larger data centers?or building ... Download Now
- Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now
- Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
SmartPlanet
- Thought-provoking progressive ideas on diverse topics that intersect with technology, business, and life, and matter to the world at large. Visit SmartPlanet
- More from IBM
-
- How to Drive Better Business Outcomes with Exceptional Web Experiences Download the eBook
- Driving Business Agility through SOA Connectivity & Integration Read the White Paper from IBM
- Linking Decisions and Information for Organizational Performance Read the Tom Davenport study
