June 17th, 2008
Graphing the triple constraints of IT failure
Every project management trainee is (or should be) taught the triple constraints of time, scope, and cost. These constraints represent trade-offs; you can’t change one without affecting the other two. For example, increasing scope has a corresponding effect on both project time and cost.
In this classic diagram, changing one leg of the triangle affects the other two:
The mysticMundane blog offers an unusual presentation of this fundamental set of project management relationships:
Looking at this graph, I mentioned to project failures guru, Ed Yourdon, that it all seems so obvious. His comment:
It may be obvious, but as Voltaire (and Will Rogers) have said, “Common sense isn’t common”
If you’re managing a project, it’s imperative to understand the relationship between all sides of the triple constraint triangle. The seemingly obvious triple constraint laws are ignored every day, much to the chagrin of those responsible for the failed projects that result.
May 27th, 2008
Moody’s software bug screws investors
Moody’s, a major credit rating agency, incorrectly awarded its top rating to $4 billion of risky debt due to a software bug in the company’s mathematical models. The incorrect ratings misled investors into believing they could earn “very high returns with little risk,” according to the Financial Times. Some investors lost 60% of their investment as a result.
The Financial Times elaborated:
In a time of ever shrinking returns from investments in credit at the height of a raging bull market, early versions of these highly structured and complex deals promised to pay 200 basis points – that is 2 percentage points – over Libor, or the “risk-free” rate at which banks lend to each other. And that spread came with the top-notch triple A ratings that indicate an incredibly low probability that investors could lose their money.
Charles Shumer, Senator from New York, has called for an SEC investigation into Moody’s handling of the situation:
“The ratings inaccuracies that were disclosed are deeply troubling,” Mr Schumer wrote in a letter sent Wednesday. “However, the fact that Moody’s only downgraded these incorrectly rated products in January of 2008, nearly a full year after they became aware of the problem, is much worse, and is indicative of a culture of shirking responsibility that must end.”
Computerworld UK quotes Ralph Silva, senior analyst at financial services advisory firm Tower Group, regarding rating agencies’ lackadaisical attitude toward technology management:
Ratings agencies never put sufficient emphasis on their technology resources,” he said. In spite of technology playing a key part in ratings decisions, “they simply haven’t felt getting technology right was important enough to business processes, unlike banks”.
The end-user impact of computer failures in cases such as this cannot be overstated. Anyone who thinks otherwise should ask the affected investors. Computerworld UK blogger, Mike Simons, summarized the situation well:
It shows both the power of the systems IT professionals build and manage and the stupidity of anyone in suspending disbelief because a computer system tells them black is white. It also highlights the governance issues involved in rectifying mistakes.
Technology problems, whether in the form of unanticipated hardware failures or software bugs, can be notoriously hard to predict and prevent. Since preventing technology failure isn’t always achievable, responsible management policies and governance are critical tools to minimize failure’s impact on users.
Moody’s mathematical bug, exacerbated by management’s delay acknowledging the problem, caused the company’s stock price to drop substantially, may spark a federal investigation, and hurt innocent investors. This situation reminds us that even obscure software bugs can have enormous impact in the real world.
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.
March 20th, 2008
Billion-dollar IT failure at Census Bureau
The US Census Bureau faces cost overruns up to $2 billion on an IT initiative replacing paper-based data collection methods with specialized handheld devices for the upcoming 2010 census. The Bureau has not implemented longstanding Government Accountability Office (GAO) recommendations and may therefore be forced to scrap the program. Harris Corp., the contractor associated with this incompetently managed initiative, was awarded a $600 million contract to develop the handhelds and related software.
In March 5, 2008 testimony before the Senate, Commerce Secretary Carlos M. Gutierrez said: “There is no question that both the Census Bureau and Harris could have done things differently and better over the past couple of years.”
On the same date, Census Bureau Director, Steve H. Murdock, added:
I cannot over-emphasize the seriousness of this problem. My colleagues and I recognize that we must move quickly to address this problem, and implement solutions. While we still have an enormous challenge in front of us, I am confident that we are close to defining and implementing a strategy that will ensure a successful 2010 Census.
The GAO characterized the handheld initiative, known as the Field Data Collection Automation (FDCA) program, as follows:
Of the $11 billion total estimated cost of the 2010 Census, the Census Bureau planned (as of 2007) to spend about $3 billion on automation and information technology in order to improve census coverage, accuracy, and efficiency. Among other things, the Bureau is planning to automate many of its planned field data collection activities as a way to reduce costs and improve data quality and operational efficiency.
The GAO report, dated March 8, 2008, added:
In October 2007, GAO concluded that without effective management of key risks, the Field Data Collection Automation (FDCA) program responsible for the devices faced an increased probability that the system would not be delivered on schedule and within budget or perform as expected. The magnitude of these problems is not clear…. [T]he Bureau has not performed recommended analysis or provided sufficient information to provide a level of confidence in its $11.5 billion life-cycle cost estimate of the decennial census. The Bureau has not itemized the estimated costs of each component operation, conducted sensitivity analysis on cost drivers, or provided an explanation of significant changes in the assumptions on which these costs are based. Together, these weaknesses and actions raise serious questions about the Bureau’s preparations for conducting the 2010 Census.
Computer World blogger, Frank Hayes, summarized the situation succinctly, “The fancy custom handhelds might work. But if they don’t, the Census Bureau will use paper instead.”
THE IT PROJECT FAILURES ANALYSIS
Managing an $11 billion initiative is a daunting task and unforeseen problems are inevitable. Nonetheless, the GAO, going back to January, 2005, repeatedly identified significant procurement, management, and operational risks associated with this project. For reasons unknown, the Census Bureau chose not to follow these recommendations.
The following table summarizes significant project issues identified by the GAO:
How does a failure of this magnitude arise? Clearly, Census Bureau management is ineffective at properly and efficiently executing the organization’s basic mandate. A detailed analysis would probably reveal hidden agendas; conflicts of interest; good intentions gone bad; inexperienced, lazy, and incompetent management; lack of controls; and plain old poor judgment. I believe these deeply ingrained issues are symptomatic of fundamental problems shared by both Bureau leadership and line management.
My recommendation: The GAO must conduct a formal inquiry into two specific areas:
- It should investigate and analyze the management policies and procedures that allowed this situation to develop and persist over the course of several years. We must understand why program controls didn’t prevent this huge waste of dollars.
- It should perform a detailed (and I mean exhaustive) investigation of Harris Corp.’s role. Let an unbiased panel determine what percentage of the billion-dollar waste Harris caused and force the company to pay direct restitution for that amount.
Until the government holds contractors and their agency sponsors accountable, massive failures will continue and more money will be flushed down the drain.
March 1st, 2008
Was Heathrow 777 crash caused by poltergeists?
Despite speculation (also here and here) that the January 17 crash of a BA airplane at Heathrow Airport was caused by defective software, the most recent Air Accidents Investigation Branch (AAIB) report does not draw this conclusion. Although the investigation has not yet unconvered the cause of the crash, preliminary analysis points toward the fuel system:
Investigations are now underway in an attempt to replicate the damage seen to the engine high pressure fuel pumps, and to match this to the data recorded on the accident flight. In addition, comprehensive examination and analysis is to be conducted on the entire aircraft and engine fuel system; including the modelling of fuel flows taking account of the environmental and aerodynamic effects.
Speculation that faulty software caused the accident arose because AAIB preliminary statements did not offer concrete findings:
The investigation is now focused on more detailed analysis of the Flight Recorder information, collecting further recorded information from various system modules and examining the range of aircraft systems that could influence engine operation.
THE PROJECT FAILURES ANALYSIS
Anyone involved with IT systems is keenly aware of the frequency with which software failures occur. In addition, many observers feel almost viscerally uncomfortable when a technical problem cannot be properly explained after some research.
This drive toward closure pushes some writers to accept a kind of “ghosts in the machine” logic, where they place unexplained technical phenomenon into a black box called “software failure.” Such logic represents little more than poor thinking and, even worse, failure-mongering.
Instead of jumping to conclusions, I suggest we wait for the AAIB to complete it’s investigation.
February 14th, 2008
Three risk categories that explain IT failure
A new white paper from Alpha Software describes three broad categories of risk that explain why software projects fail:
Process failures arise when a project is “bumped off track,” relative to the expected plan.
If the goal of a process is to produce a specific outcome, then anything that either delays or prevents the achievement of that specific outcome is a form of process failure. Consider an obvious example of process failure, requirements that are never really (or accurately) determined.
This form of failure usually leads to finger pointing between development groups and users, with each claiming the other did not understand.
[Other examples of process failure involve:]
- Communications (including communications latency)
- Implementing out of date requirements
- Feature creep (or additional features) and its cousin, poorly defined scope
- Bugs (defects)
- Waiting for someone or something
- Partial work
- Context switching
- Unnecessary processes
- Paper shuffling
- Unrealistic schedule
- Unrealistic budget
- Careless, sloppy, or missing software development processes
[T]he presence of one or more of these process failures contribute to business failure if the organization is not able to respond to changing business or market conditions. They also make it difficult to respond to customer-perceived incidents that disrupt service delivery.
Platform failures reflect specific problems with the technology used to develop or deliver software solutions.
The generic term platform applies both to hardware and software individually, and in combination. Some platform failures are also obvious, such as hard disk crashes or network component failure with a corresponding interruption of network traffic. Other examples of platform failure are less obvious, such as when the application does not scale or meet expected levels of performance.Of all the different types of failures, some hardware failures are both the easiest to spot and probably the easiest to anticipate, typically by having spare parts either on-hand or available for just-in-time delivery.
Failures in software platforms (software tools) are more problematic, though they occur frequently enough that they have a name: bugs. It is usually impossible to substitute one software tool for another without a great deal of effort. This becomes particularly onerous if the bug is in a critical tool, and the vendor (or in-house developer) cannot quickly provide either a fix or work-around.
There are also platform failures that can be less obvious to spot, specifically getting close to boundary conditions of the hardware or software including network capacity, balance between physical RAM and swap file, getting close to hard disk space limits, etc.
Business failures refer to issues and problems driven by the internal organization itself.
One of the most obvious forms of business failure also turns out to be the primary reason that development organizations cannot readily adapt to changing conditions: specifically, lack of management commitment. No project can succeed without management commitment (and on occasion, management drive).
[E]xperience [also] suggests an expansion of the concept of business failure to include the notion of tool vendor concerns for the customer value chain. The customer of my customer should be treated like they are my customer. Does the tool vendor do that?
THE PROJECT FAILURES ANALYSIS
The white paper places the risk sources underlying IT failure into three reasonable categories. Nonetheless, for simplicity’s sake, I recommend readers combine business and process failures into a single category encompassing both. Importantly, the paper does a good job making the distinction between business and technical causes of failure, and it provides examples of each.
Although the white paper covers no new ground in categorizing project risk, it includes a useful chart showing “the relationship between complexity, calendar duration, and risk:”
Take a project task, such as developing a particular feature, and map it onto the chart. The grid provides a quick litmus test for evaluating estimates against a consistent framework of risk, complexity, and time. It’s a simple, nice, and useful method to perform intuitive risk testing.
Overall, the white paper is worth a read. It won’t send off skyrockets in your mind but it’s solid, covers good territory, and provides lots of concrete examples.
December 21st, 2007
China’s now building commercial airliners?!¿@!¡
From the land that brought you dangerous toys and poisonous food, there are now…Chinese commercial airliners.
As reported by Bloomberg, they don’t expect to sell many planes:
“We’re well aware that in the international market there’s not a very good impression of China’s ability to build commercial aircraft,” [Vice President Hu Wenming, the manufacturer’s vice president,] said at a conference in Hong Kong in September. “That’s why we’re not expecting a big purchase order before we launch the project.”
Given my personal desire for low failure rates in air safety, I’m glad they won’t be putting lots of these into the market soon.
Update: Some commenters took this post to be a general indictment of China. It wasn’t meant that way at all. Rather, it was merely a statement of personal concern over product safety. My apologies for the confusion if you were offended.
November 27th, 2007
ZDNet UK’s list of top 10 IT failures
As you might imagine, I’m a sucker for failure trivia. ZDnet UK has compiled a list of the top ten IT disasters of all time.
Although I question the inclusion of some items on the list, it’s worth a peek:
1. Faulty Soviet early warning system nearly causes WWIII (1983)
[It] happened back in 1983, and was the direct result of a software bug in the Soviet early warning system. The Russians’ system told them that the US had launched five ballistic missiles. However, the duty officer for the system, one Lt Col Stanislav Petrov, claims he had a “…funny feeling in my gut”, and reasoned if the US was really attacking they would launch more than five missiles.The trigger for the near apocalyptic disaster was traced to a fault in software that was supposed to filter out false missile detections caused by satellites picking up sunlight reflections off cloud-tops.
2. The AT&T network collapse (1990)
In 1990, 75 million phone calls across the US went unanswered after a single switch at one of AT&T’s 114 switching centres suffered a minor mechanical problem, which shut down the centre. When the centre came back up soon afterwards, it sent a message to other centres, which in turn caused them to trip and shut down and reset.
The culprit turned out to be an error in a single line of code — not hackers, as some claimed at the time — that had been added during a highly complex software upgrade.
3. The explosion of the Ariane 5 (1996)
In 1996, Europe’s newest and unmanned satellite-launching rocket, the Ariane 5, was intentionally blown up just seconds after taking off on its maiden flight from Kourou, French Guiana. The European Space Agency estimated that total development of Ariane 5 cost more than $8bn (£4bn). On board Ariane 5 was a $500m (£240m) set of four scientific satellites created to study how the Earth’s magnetic field interacts with Solar Winds.
According to a piece in the New York Times Magazine, the self-destruction was triggered by software trying to stuff “a 64-bit number into a 16-bit space”.
4. Airbus A380 suffers from incompatible software issues (2006)
The Airbus issue of 2006 highlighted a problem many companies can have with software: what happens when one program doesn’t talk to the another. In this case, the problem was caused by two halves of the same program, the CATIA software that is used to design and assemble one of the world’s largest aircraft, the Airbus A380.
Put simply, the German system used an out-of-date version of CATIA and the French system used the latest version. So when Airbus was bringing together two halves of the aircraft, the different software meant that the wiring on one did not match the wiring in the other. The cables could not meet up without being changed.
[Ed. note: To see my coverage of this failure, click here.]
5. Mars Climate Observer metric problem (1998)
[A] problem occurred when a navigation error caused the lander to fly too low in the atmosphere and it was destroyed.
What caused the error? A sub-contractor on the Nasa programme had used imperial units (as used in the US), rather than the Nasa-specified metric units (as used in Europe).
6. EDS and the Child Support Agency (2004)
Business services giant EDS waded in with this spectacular disaster, which assisted in the destruction of the Child Support Agency (CSA) and cost the taxpayer over a billion pounds.
EDS’s CS2 computer system somehow managed to overpay 1.9 million people and underpay around 700,000, partly because the Department for Work and Pensions (DWP) decided to reform the CSA at the same time as bringing in CS2.
7. The two-digit year-2000 problem (1999/2000)
That the predictions of doom came to naught is irrelevant, as we’re not talking about the disaster that was averted, but the original disastrous decision to use and keep using for longer than was either necessary or prudent double digits for the date field in computer programs. A report by the House of Commons Library pegged the cost of fixing the bug at £400bn. And that is why the Millennium Bug deserves a place in the top 10.
8. When the laptops exploded (2006)
It all began simply, but certainly not quietly, when a laptop manufactured by Dell burst into flames at a trade show in Japan. There had been rumours of laptops catching fire, but the difference here was that the Dell laptop managed to do it in the full glare of publicity and video captured it in full colour.
It was an expensive issue for Dell to sort out. As a result of its investigation Dell decided that it would be prudent to recall and replace 4.1m laptop batteries.
9. Siemens and the passport system (1999)
It was the summer of 1999, and half a million British citizens were less than happy to discover that their new passports couldn’t be issued on time because the Passport Agency had brought in a new Siemens computer system without sufficiently testing it and training staff first.
10. LA Airport flights grounded (2007)
Some 17,000 planes were grounded at Los Angeles International Airport earlier this year because of a software problem. The problem that hit systems at United States Customs and Border Protection (USCBP) agency was a simple one caused in a piece of lowly, inexpensive equipment.
[Ed. note: To see my coverage of this failure, click here.]
November 17th, 2007
Oracle’s wall-to-wall software suite
Oracle massive software suite, important components of which were assembled during the company’s aggressive acquisition strategy (41 companies over the last 45 months), has yielded an impressive product road map. Oracle presented its grand vision to the 43,000 attendees of OpenWorld, its annual user conference which was held this past week in San Francisco.
The product suite is impressive, and includes building blocks based on database, middleware, and applications, as shown in the slide below:
The significance of this vision becomes apparent when meaningful product groupings are overlaid onto the stack. For example, the following slide shows how Oracle’s governance, risk, and compliance product set reaches into all parts of the stack.
Each component of the stack is a large world unto itself. As an example, the next slide presents the Fusion middleware suite:
This integration strategy is intended to buy market share and make Oracle a one-stop-software-shop for customers. As Charles Phillips described (quoted by ZDNet’s Dan Farber) during a meeting with my Enterprise Irregular colleagues (read Jeff Nolan’s account):
“The strategy is to deliver more and more out of the box for customers, packaging integration between Siebel and SAP, for instance. Only a third of [IT] spend is off the shelf. The obvious thing for us to do is get that two-thirds. We have more to do to give [corporations] less reason to build it themselves,” Phillips said.
Such a broad strategy does involve risks, one of which is complexity, which Jesper Andersen, Oracle’s senior vice president of application strategy, acknowledged in a conversation. Jesper said that the company is investing to help Oracle employees and customers understand the pieces and how they fit together. While the strategy has resulted in great breadth and diversity, an ever-changing product landscape (resulting from ongoing acquisitions) carries risk that customers won’t understand which products to buy and salespeople will not be properly trained to sell those products.
Despite these risks, the vision is forward-thinking, incorporating the latest Enterprise 2.0 and service-oriented architecture technologies. Unlike most Enterprise 2.0 vendors, this is a large-scale, multinational-ready vision of Enterprise 2.0:
One of the more interesting Enterprise 2.0 applications described at the conference is “social CRM,” which uses a simplified user interface to access enterprise data:
While the product suite is big, and growing, fellow Enterprise Irregular, Brian Sommer, takes issue with Oracle in the area of customer value. Brian says:
Value was clearly a missing in action component at this conference. In one telling panel, five Oracle executives each recapped what they believed were the more critical messages for this year’s show. If I listened correctly, not one of the individuals used the word value. After this panel, I approached an Oracle communications executive and relayed my concern about this to him. Without compelling value propositions, net new sales of product in the marketplace will likely languish.
Brian is correct in asserting that customer value was not an explicit theme at the conference, and with Oracle’s history of arrogance, perhaps that wasn’t surprising. Nonetheless, Thomas Kurian, senior vice president of development for Oracle middleware platform products, did link his technical products to business value, which cannot be ignored:
[Your] organization gets the ability to go consistently from your strategy and plans to operational decisions, and from operational decisions to what we call insight to action — the ability to go from operational decisions to take actions that improve how the business functions.”
In summary, was I impressed by Oracle’s product strategy? Yup, I certainly was.
October 27th, 2007
Facebook fails at privacy
Apparently, Facebook allows its employees to eavesdrop on the comings and goings of members. I said “apparently,” because Valleywag reported this, meaning the whole thing could be a fabrication.
Anyway, it sounds plausible, so here’s what Valleywag said:
Facebook employees can (and do) check out anyone’s profile. Not only that, but they also see which profiles a user has viewed — a major privacy violation.
Reminds me of the stories about IRS agents snooping on tax returns of friends, relatives and celebrities. Not as creepy as the IRS, but a company valued at $15 billion shouldn’t allow this kind of crap.
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.
Essential Topics 
Midsize Business Center
Recent Entries
- Runescape graphic glitches
- 5 more reasons IT projects fail
- Computer ‘mystery outages’ plague Australian Emergency Services
- Stop the madness: 10 steps to kill failures
- Scathing report slams UK gov’t data loss
Most Popular Posts
- Bill Gates' web experience: Byzantine, idiotic logic
- IT catfight in Portland, OR
- 12 characteristics of doomed projects
- 15 non-technical reasons IT projects fail
- Google explains why App Engine failed
- Oracle / SAP increase prices
Top Rated
- IT catfight in Portland, OR+11 votes
- Bill Gates' web experience: Byzantine, idiotic logic+9 votes
- IT failure haiku poems+8 votes
- IT is from Mars; Business is from Venus+7 votes
- Windows Live FolderShare: unacceptable 3-day outage+6 votes
- Has Google demoted FeedBurner?+5 votes
- Graphing the triple constraints of IT failure+5 votes
- IT "neglects" the human side of change [SOA podcast]+4 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- Which solar technology will survive?
-
At the Cleantech Forum in San Francisco, Todd Glass of Heller Ehrman moderates a discussion, among tech execs, on the various solar technologies making a difference in the green movement.
- Watch the video >>
- Hardware Assisted Virtualization to Mitigate Security Risks
-
In this podcast Intel's Malcolm Harkins and HP's Manny Novoa chat about the latest issues in security technologies, notably the emergence of hardware assisted virtualization.
- Watch the Podcast on the Intel Open Port General Blog >>
- The Cisco Mobility Resource Center is your source for FREE mobility solutions
-
The Cisco Mobility Resource Center offers FREE videos, downloads, podcasts and more, all designed to help small and medium businesses get mobile connectivity solutions, improve productivity and drive sales and revenue.
- New mobility solutions at the Cisco Mobility Resource Center
