June 22nd, 2008
IT “neglects” the human side of change [SOA podcast]
Mike Kavis is chief enterprise architect at Catalina Marketing, a large data analysis company serving the retail industry. Mike is a prolific writer and speaker on topics related to implementing Service-Oriented Architecture (SOA).
Here’s one of Mike’s presentations, discussing how to sell SOA to the business side of an organization:
In this podcast, Mike described his large and successful SOA initiative at Catalina. He talks about how the team “stumbled” into SOA after a business process transformation project and discusses how IT tends neglect the human side of change, which he believes is the leading cause of failed SOA projects.
If you’re interested in successful SOA, listen closely to the podcast.
June 16th, 2008
Windows Live FolderShare: unacceptable 3-day outage
Update 6/17/08 12:00 EDT: The FolderShare blog now reports the outage will last no longer than eight hours, down from the planned three days. Glad the madness is over. Although it’s a significant improvement, one day is still too long and we’d like to know why downtime is required.
Microsoft’s FolderShare is a great service for synchronizing files across computers. As with any backup service, reliability is a critical user requirement for FolderShare. For this reason, I was rather shocked to learn of an planned three-day service outage starting tomorrow evening.
What’s Microsoft thinking by bringing down the service for such a long time? Zoliblog comments:
Such outage would be unacceptable from any service provider - except apparently from Microsoft…
When Salesforce, Twitter, or Amazon go down for hours, it’s big news. Although FolderShare’s user base is small compared to those services, we’re talking about huge Microsoft, which should have the ability to manage downtime more effectively.
Users are attracted to services such as FolderShare for two reasons: useful features and the promise of always-on reliability. Remove reliability from the equation and the service’s value plummets.
FolderShare, three days is unacceptable and your poor explanation makes it worse.
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.
March 8th, 2008
Building a great CIO dashboard
Enterprise dashboards summarize measurements and results of critical business functions into visual displays. In areas such as IT, it can be difficult to define useful metrics, because the performance measures may be highly complex or subjective. For example, determining accurate measures to answer the question, “Is our IT project on-track for success?” may be challenging.
Well-designed dashboards represent operational activities and results, relating them visually to key organizational goals and strategies. The key is selecting useful and meaningful metrics, determining how to collect data on these metrics, and then building a system that displays the data clearly to the intended audience.
Information Week’s eight steps offer an excellent, business-oriented overview of this process:
- Define the key performance indicators (KPIs) that need to be measured in your dashboard.
- Map KPIs to specific data requirements. Determine if the data exists in systems or needs to be collected.
- If data-collection gaps exist, explore improvements to fill holes. Develop a plan and timeline to implement those systems.
- Investigate business service management, project and portfolio management, and BI tools based on your KPI requirements. Pay attention to how tools integrate with your existing infrastructure.
- Budget for the initial cost of the CIO dashboard, annual maintenance, and fees to implement the system. Take into account the complexity and cost of changes and updates.
- Develop an implementation plan that provides dashboard visibility into key systems one at a time.
- After systems are integrated, focus on correlating data across those systems to provide meaningful visual information and alerting capabilities should a metric violate a threshold.
- When new components are considered, evaluate how they’ll be integrated into the dashboard.
Visit The Dashboard Spy to see interesting dashboards from many industries.
February 11th, 2008
Customer blames bankruptcy on IBM IT failure
American LaFrance (ALF), the “leading brand of custom-made fire fighting, fire rescue vehicles, ambulances, and heavy-duty work refuse vehicles,” has declared bankruptcy, blaming IBM and a failed ERP implementation.
According to filings in the District of Delaware bankruptcy court (PACER case no. 08-10178), problems occurred when ALF was spun out as an independent company from Freightliner, the previous owner. During the transition, ALF outsourced “accounting, inventory, payroll, and manufacturing process services” to Freightliner. As part of the transition, ALF developed a “standalone” ERP system designed to support the firm after the Freightliner separation was completed.
The bankruptcy filings describe the painful cutover from Freightliner:
Almost immediately upon the changeover to the ERP System, ALF recognized serious deficiencies with the system that had a crippling impact on ALF’s operations. Some of the problems that ALF encountered in implementing the ERP System included, among others: (i) inability to reconcile data between the Freightliner system and the ERP System; (ii) incorrect or incomplete inventory, purchasing and customer data due to either problems with the Freightliner system or the conversion of the data to the ERP System; (iii) inaccurate or incomplete vehicle configurations loaded in the ERP System; (iv) insufficient training on the ERP System; and (v) missing financial information including accounts payable detail, incomplete or inaccurate accounts receivable data, and inaccurate beginning general ledger balances.
For the next several months following the changeover, ALF attempted to solve the plethora of problems with the ERP system. Despite such efforts, as a direct result of the problems with the ERP System, ALF became unable to complete the manufacture of many pre-ordered vehicles.
The manufacture of highly-customized Emergency Vehicles requires the availability of a large number of inventory SKUs at key points in the production process. The conversion from the Freightliner system to the ERP System resulted in the inability to account for inventory on a reliable basis. This, in turn, severely limited ALF’s ability to deliver completed products to its customers. Consequently, ALF’s inability to deliver vehicles had an immediate impact on ALF’s cash flow and created a liquidity crisis.
ALF claims that IBM is responsible for the IT problems that precipitated the bankruptcy:
ALF is currently analyzing potential causes of action against IBM based upon services provided by IBM in connection with the problem-riddled transition to the ERP System.
The documents describe IBM Corp. (for the “customer agreement”) and IBM Global Services (for “systems applications project assistance”) as having open contracts with ALF. IBM is listed as a $5.5 million creditor, although ALF disputes the invoices:
THE PROJECT FAILURES ANALYSIS
In my reading of the documents, which only present ALF’s side of the story, it could be said that both ALF and IBM dropped the ball during the transition from Freightliner. Here are my conclusions:
- IBM did not manage the project properly. Given ALF’s dependence on Freightliner, “serious deficiencies” in production software should have been identified prior to the cutover, for example by testing and running the systems in parallel. IBM managed development, which typically includes extensive testing before deployment.
- ALF did not manage the project properly. IBM’s role does not minimize ALF’s ultimate responsibility for managing this mission-critical IT project. ALF’s management was probably distracted by the deteriorating Freightliner relationship, by a major facilities relocation that didn’t go well, and by generally poor market conditions.
- The ERP problems were managerial, not technical, in nature. The list of ERP and data problems cited in the filings suggest poor project management, rather than technical issues, were at the root of the difficulties. Since the division of labor between ALF and IBM is not made clear in the filings, it’s impossible to discern where responsibility lies.
- General market conditions made things worse. While all this was happening, the market for ALF’s products tanked:
[T]he Emergency Vehicle industry is currently depressed. Many competitive manufacturers are experiencing financial difficulties and several have ceased operations.
- All these issues created customer service problems, multiplying the negative effects of the market downturn. For example, the Bellingham Herald reported:
The city is trying to get a refund of the more than $362,000 it spent on an American LaFrance pumper that has had electrical problems 10 times [since 2005].
- In addition, FireRescue1, an industry news source, states:
Several departments that have ordered apparatus have suffered lengthy delays in delivery.
“I think one of their problems may have been that they underestimated the problems with moving a plant and production and actively pursuing business for new apparatus,” [Bill Peters, who runs New Jersey-based Fire Apparatus Consulting Services] said.
“Perhaps they bit off more than they could chew, especially with the building of a new factory. It might have been wise not to take as many orders and not to have backed themselves up so much.”
This risky, high stakes project was primarily business in nature, despite the heavily technical components. Project failures often arise when non-technical senior management don’t fully understand the business ramifications of technical decisions made by IT. Poor communication and lack of understanding between IT and business management remains a serious problem contributing to many IT failures. My ongoing interview series, NakedIT: Conversations with Innovators, explores this issue in depth.
The combination of so many negative conditions ultimately created a situation where the company could not recover, leading to the bankruptcy. ALF was founded in 1832, so it’s a shame to see this happen. Unfortunately, many of ALF’s vendors will probably suffer as the company goes through bankruptcy.
(To research this post, I studied the bankruptcy documents, left messages for ALF’s proposed Chief Restructuring Officer and its IT manager, spoke with two attorneys connected with the case, and got unpleasantly barked at by a third. All facts, conclusions, and interpretations in this post are based on information obtained from publicly-available filings.)
Update 2/22/08: IBM ignored a request for comment on the story. Larry Dignan wrote a great follow-on post.
December 16th, 2007
UK Rural Payments Agency (RPA): IT failure and gross incompetence screws farmers
A combination of IT failures and management incompetence have prevented the Rural Payments Agency (RPA), which administers UK farm subsidy payments, from successfully executing its core mission despite years of effort. This extremely negative assessment is based on a new report issued by National Audit Office (NAO). Accenture is implementing the IT system on behalf of RPA.
SUMMARY AND BACKGROUND
Rural farm subsidies in the UK are handled by the RPA, under a system known as the Single Payment Scheme (SPS), which was established by EC Council Regulation 1782/2003; SPS replaced most existing UK crop and livestock payments from January 1, 2005 and marked the UK’s efforts to align with broader European farm subsidy policies.
Here’s a summary of this deeply unfortunate situation, from the 2007 National Audit Office report (emphasis added below):
The single payment scheme was introduced by the Member States of the European Union as part of Common Agricultural Policy reforms which replaced 11 separate crop and livestock based production subsidies with a single payment based on land area. In the first year of the scheme (the 2005 scheme), the agency had experienced considerable difficulties in capturing and processing the data required to process payments, and as a result failed to meet both its own target to pay 96 per cent of the fund by the end of March 2006 and the European Union legislative requirement to pay 96.14 per cent of the fund by the end of June 2006 to avoid late payment corrections. Many farmers experienced financial hardship as a result and the then Chief Executive of the Agency was removed from post. The Agency made a commitment to pay outstanding payments on the 2005 scheme by the end of December 2006 and to implement its recovery plan by April 2008. The Department agreed to provide an additional £40 million to help the Agency recover and make changes to its IT and processes.
For additional background, it’s helpful to look at the 2006 National Audit Office report (emphasis added below):
The single payment scheme is not a large grant scheme compared to some government programmes, but the complexity of the EU Regulations, the complex way in which the Department planned to implement them in England, combined with the deadlines required to implement the scheme for 2005, made it a high risk project. By choosing to integrate the scheme into a wider business change programme, the Agency added to its already considerable challenges.
Many of the Agency’s difficulties arose, however, from:
- underestimating the scale of the work needed to implement the scheme;
- over optimistic progress reporting; and
- governance structures which, in practice, proved overly complex, and the absence of clear metrics, arising from the lack of appropriate management information that would have allowed the oversight boards to measure progress objectively.
By the end of March 2006 implementation of the single payment scheme had cost £46.5 million more than the Agency had anticipated in its November 2003 business case. The implementation of the single payment scheme and the wider business change programme had cost £258.3 million, will not achieve the level of savings forecast, and there is risk of substantial costs for disallowance by the European Commission. The farming industry has also incurred additional costs, 20 per cent of farmers have experienced stress and anxiety as a result, and five per cent of respondents to our survey said they have considered leaving farming.
MANAGEMENT RESPONSIBILITY
The level of RPA mismanagement can hardly be over-estimated. As a small example, representing a broader pattern, see this House of Commons testimony (section EV8), by Johnston McNeill, former RPA boss, during an inquiry into the SPS debacle (emphasis added below):
Had we known that there was going to be that [level of claimant and land registration] volume, we could have looked at the volumes that the system could handle; whereas we could only look at the normal requirements. When we specified this system in 20034, when we were talking to Accenture, we had had a lengthy contract procurement and specification. We were specifying without any understanding of SPS requirements. We were specifying on our normal business requirements.
Although government incompetence has played a role, Accenture’s involvement in this mess should not be ignored. Commenting on Accenture, a House of Commons investigating committee stated on page 5 (emphasis added below):
Accenture witnesses appeared to have been well schooled in not venturing comment on matters which they deemed were beyond their contractual observations. This attitude denied the Committee an important perspective on the way the SPS project was being run from the standpoint of a company at the heart of the venture. We regard this as an unacceptable attitude from a company of international repute and which may still aspire to work with UK government in other areas.
In evidence submitted to the House of Commons, Accenture denied responsibility for the problems, saying that (emphasis added below):
As has been widely acknowledged by numerous commentators and experts, significant IT enabled business change programmes can be difficult to manage. There have been many examples of problem projects in the public and private sectors in recent years with difficulties attributed to poorly defined requirements, changing business needs and lack of business involvement and preparedness that can lead to delivery difficulties.
NAO RECOMMENDATIONS
To address the issues, the National Audit Office offers these suggestions:
We recommend that the Agency:
- recovers high value overpayments to farmers (such as those over £25,000) as soon as practicable;
- brings its key offline databases into the single payment scheme IT system to make its forecasts more accurate and reliable;
- in the event that the European Union makes policy changes to the scheme, explores whether its existing IT systems would be able to accommodate such changes without the need for major redesign of the application. If the system is unlikely to be able to accommodate such changes, the Agency should notify its Management Board and the Department of the risks accordingly and update farmers once a revised timetable can be defined;
- draws on the good practices we identified from the IT systems supporting the German model of the single payment scheme on how to keep claimants informed about the progress of their claims, and the online processes already available to German farmers to transfer entitlements; and
- learns lessons from implementation of this IT system, to take account of best practice. In particular, the Agency should:
- use appropriate off the shelf rather than bespoke software whenever practicable, after considering business needs and scheme complexity, because bespoke software is costly to develop, needs to be thoroughly tested, and takes more time to implement;
- avoid offline systems, on which the main IT system depends;
- align the system to business needs, rather than the business to the system needs, applying caution to any significant movement away from tried and trusted business methods to accommodate the IT system; and
- ensure the system specifications retain a realistic level of flexibility to cope with future changes.
MY ANALYSIS
The National Audit Office recommendations listed above illustrate the extent to which basic IT best practices were not followed. Consider this as well:
- RPA developed custom software, rather than use off-the-shelf products. What was Accenture’s role in this decision? It’s precisely the kind of issue I addressed in a blog post called Consulting’s dirty little secret, which explained how consulting companies can gain financial benefit when a project becomes larger and more complex than expected.
- RPA created databases in which data was stored in computers disconnected from the main system, despite the fact the main system depended on that data to function properly. Such issues force questions around who designed this system, from both technical and business perspectives, and how experienced these folks actually were.
- In general, the entire situation represents poor planning and project management taken to new heights of incompetence. Despite complexities in aligning UK practices with EU policies, both RPA and Accenture designed and executed a system based on poor practices, lack of experience, and world-class levels of bad planning.
IMPACT ON VICTIMS
This situation is different from many government IT failures, where money is wasted but innocent victims don’t suffer personal injury. In this case, delayed and incorrect payments have directly affected farmers depending on subsidies to maintain their operations. In the words of Roger Williams, Liberal Democrat from Wales:
Farmers have found it difficult to accommodate problems with cash flow. Mention has been made of paying bills, but at the end of this week interest payments will be due on most accounts. That money will be taken out of the farmers’ accounts. They will not have to make a conscious decision about it; the money will be removed from their accounts. That may take them above the level that they have agreed with their banks, and they will suffer the financial consequences—not just additional interest, but the other costs involved.
The BBC further reports on the damage caused to farmers:
Farmers in the East are being forced to the brink of bankruptcy by the Government’s failure to pay their subsidies.
Many are struggling to survive while awaiting money from the Single Payment Scheme (SPS).
Johnston McNeill, former head of the RPA, eventually apologized for his agency’s role in the disastrous situation:
“I deeply regret that we in the RPA and I as chief executive were not able to make payments to farmers in the targeted timetable”. He said he was “saddened by the consequences”.
Unfortunately, apologies coming from a man who earned £250,000 per year (about US$500,000), while inflicting such damage on his constituency, leave only a bereft and hollow sound.
November 30th, 2007
Eight lessons for a successful IT implemention
Given this blog’s focus on the causes of IT failure, it’s great to read about successful enterprise software implementations. Mike Kavis describes what his team learned during the course of deploying their first SOA application.
Here’s Mike’s description of “things we did right,” along with my annotations:
Focused on business not technology - we performed a 90 day business process assessment where we documented current state, brain stormed on future state, and defined a portfolio of projects that each had their own ROI.
By recognizing the project as fundamentally related to business improvement, Mike’s team established a solid foundation for success. Software and technology change should be considered enablers that bring material, specific improvements to the business. Hidden benefits that can’t be articulated, measured, and communicated are suspect.
We did our homework - We attended conferences, read blogs, researched web sites, collaborated with experience architects, and a got our hands on anything or anyone that had any information about SOA.
This point should be obvious. Unfortunately, too many IT customers rely strictly on external vendors for advice, without doing sufficient real learning themselves. That approach leads to unhealthy dependence and limits internal stakeholders’ ability to make intelligent decisions.
Thorough POC - We invested a lot of time in an extensive vendor assessment for both the BPM and SOA tools.
Take time to evaluate the vendors, do a proof of concept, and get to know your partners. Shotgun weddings aren’t an ideal form of matrimony and rushing unprepared into a large project is almost always a mistake.
Surrounded ourselves with talent - We put several of our best people on this project on both the IT and business side. We embedded our architects with our SOA partners to accelerate the learning curve.
Strong executive support - Our executive sponsor is from the business and the person who went to the top to get the funding for the project. Like a couple of us in IT, she put her career on the line by signing up to deliver substantial ROI numbers over the next four years.
Even though this was their first SOA project, Mike and his team are clearly old hands at the software implementation game. For understandable reasons, business-side managers are often reluctant to hand over resources for a technology implementation. Strong executive support can be used to convince the business side to participate more freely.
Mike’s executive sponsor put her career at stake to make the project successful, which publicly demonstrates commitment and confidence. If your executive sponsor has no skin in the game, find another sponsor.
Squash resistance instantly - Any time we encountered or were told of resistance or negativity, we immediately addressed it head on.
Naysayers are everywhere. While constructive criticism is always helpful, negativity isn’t, and should be dealt with swiftly. Mike did the right thing, even though I’m sure it was difficult at times.
Short, iterative deliverables - We took a look at all of the projects that we identified and used a combination of portfolio management and a SOA roadmap to determine the priority and size of the scope for each project.
Sound architecture - We are laying the foundation for a loosely coupled, service enabled architecture….
Don’t play guessing games with project schedules or technical architecture on mission critical projects. Proper, professionally-handled planning is key, on both the business and technical dimensions.
Although this was their first SOA deployment, Mike and the team did a lot of things right. Follow his lessons, and your enterprise software projects will definitely be more successful.
November 7th, 2007
Enterprise 2.0 IT governance: Whole Foods bans execs from blogs and chat
Enterprise 2.0 and IT governance have just kissed and jumped.
In a Nov. 2 update to its corporate Code of Business Conduct, Whole Foods has banned executives from participating in non-company blogs and chat rooms, except in connection with absolutely personal topics. Clearly, this is an extreme response to CEO John McKay’s anonymous, negative chat room postings about competitor Wild Oats Markets, which led to an SEC investigation.
From the Whole Foods Code of Business Conduct:
Online Forums
To avoid the actual and perceived improper use of Company information, and to avoid any impression that statements are being made on behalf of the Company, unless approved by the Nominating and Governance Committee, no member of Company Leadership (as defined below) may make any posting to any non-Company-sponsored internet chat room, message board, web log (blog), or similar forum, concerning any matter involving the Company, its competitors or vendors, either under their name, anonymously, under a screen name, or communicating through another person. Violation of this policy will be grounds for dismissal. For purposes of this paragraph, “Company Leadership” includes each Company director, Executive Team member, Global Vice President, Regional President and Regional Vice President.
From this point forward, the whole notion of IT governance, including how we define IT failure, has become more complex. In the past, IT failure analysis primarily dealt with relatively straightforward concepts such as completing projects on time and within budget. Now, IT governance needs to consider far more difficult issues, such as overseeing users who deliberately remove themselves from the yoke of IT control. Not an easy task to accomplish.
In many ways, Enterprise 2.0 software is following the path already blazed by personal computing hardware. Personal computers diffused through the market back in the seventies and eighties, replacing legions of mainframes and mini-computers. This change empowered users and small company departments to purchase their own cheap machines, without the knowledge or approval of the IT “priesthood.” While painful for IT , this diffusion of technology wrought the personal computer revolution.
Enterprise 2.0 software places tremendous software and communications power into the hands of distributed users, who cannot easily be controlled by centralized IT policies. As Enterprise 2.0 tools evolve, IT governance and our notions of project failure must evolve as well.
November 5th, 2007
New research into CRM implementation failures
AMR Research has released results of a new study describing CRM implementations. As the chart below shows, nearly one-third of CRM implementations fail:
The research suggests that CRM initiatives often fail due to insufficient end-user involvement and buy-in. Unlike ERP deployments, which tend to be back-end focused, successfully deploying end-user systems requires substantial user engagement:
This type of situation seems to be much more common in CRM, where user adoption, particularly by the sales organization, is one of the keys to success. In applications such as ERP, supply chain, or financial management applications, the users have much less flexibility or choice in whether or not to adopt an enterprise application
standard.Keep in mind that experience and success implementing ERP bears virtually no weight at all when implementing CRM. Also remember that, unlike an ERP implementation, the active involvement, support, and buy-in of the end users are critical to success. This posture is especially important given the relatively high and seemingly unchanging level of failed CRM implementations. Usability, integration to office productivity tools, and dashboards and reporting take top priority rather than sophisticated functionality, transaction speeds, and five nines of availability.
In my experience, many organizations equate “software implementation” with “back-end IT infrastructure.” Unfortunately, this attitude increases the separation between IT and functional business units, where end-users live and work, worsening an already-significant problem.
Here is my four-item framework for evaluating whether end-users are sufficiently engaged in your implementation:
- Goal involvement. Have you developed a statement of business goals for the project that has been formally endorsed by the stakeholders, or was installing software the only formal goal?
- Project origin. Did an end-user group actively participate in defining project requirements and selecting the vendor, or was the project completely IT-driven?
- End-user benefit. Will the application give end-users valuable new capabilities, or is there little apparent benefit to end-users and managers?
- Project communications. Will stakeholders receive frequent updates on project status, or is that considered to be low priority?
The research is clear: engage end-users for a more successful implementation. Ignore end-users at your peril.
October 27th, 2007
Complexity and false hope
It’s hard to simplify complexity. Sometimes, this painful reality causes managers to grasp at straws and wallow in denial, seeking the allure of easy, yet ultimately pointless, solutions.
The following Geek and Poke cartoon precisely captures this unfortunate, yet all too common, phenomenon:
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
- 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
