October 26th, 2009

Can open source software stop IT failure?

Posted by Michael Krigsman @ 9:19 am

Categories: CIO issues, Devil's Triangle, IT issues, Open Source, Project strategy

Tags: Software, Information Technology, Open-source Software, Failure, Dana, Custom Software Development Project, Devil, Tools & Techniques, Open Source, Strategy

In a post today. ZDNet open source blogger, Dana Blankenhorn, says the primary value of open source software is transparency rather than low cost. He then argues that open source software offers at least a partial solution to the problem of IT failures. Let’s examine that view.

Dana argues that open source code transparency aligns the interests of customers and vendors, which can have a positive effect on IT project outcomes:

With code visibility, you and your vendors become partners in trying to make something work. The vendor can’t over-promise, but you can’t over-assume either. This may be one of main hidden reasons for IT failure, the two sides of the transaction not being on the same page.

From an IT failures perspective, this logic consists of two primary components:

1. Shared visibility into open source code reduces hidden assumptions and makes explicit what the vendor is actually selling to the customer.
2. Such transparency can reduce failure by forcing alignment between vendor and customer goals.

Although Dana raises an interesting and important question, I do not share his confidence that implementation projects based on open source software should more successful than those based on commercial software.

In my experience, most failures associated with packaged software arise from expectation mismatches in the business, rather than technical, domain. Custom software development projects are even more complicated, since these situations include creating something that does not yet exist.

This diagram summarizes my view regarding why many IT projects that are late, over-budget, or don’t deliver planned results:

Read the rest of this entry »

April 9th, 2008

Australian senator demands open source against US "lock-in"

Posted by Michael Krigsman @ 4:22 pm

Categories: CIO issues, Government projects, IT issues, Microsoft, Open Source, Politics, Vendor relationships

Tags: Software, Senator, Open Source, Software Company, Tools & Techniques, Management, Michael Krigsman

Australian senator, Karen Lundy, believes US software “lock-in” reduces both competition and technology innovation, thereby hurting the Australian technology market. Speaking at an Australia 2020 Local Summit, Senator Lundy’s remarks made clear her commitment to open source at the expense of “proprietary” systems. Her comments also negatively suggest that US software companies engage in planned obsolescence at the expense of Australian software buyers.

Australian IT reported:

“The lockdown of large agencies and departments around specific proprietary systems under the former government is a market failure resulting in very little competitive tension, and very little innovation,” Labor’s ACT senator, Kate Lundy, said yesterday. “There’s a pre-timed refresh of the technology, and the money spent on license fees is effectively dead money because it’s not going into innovation.”

The arrangement had “sustained many of those larger US software companies and their place in the Australian market”.

These are threatening words for software companies selling into the Australia market. As ZDNet’s Jason Perlow describes, proprietary lock-in is an important strategy across all segments of the US software business:

Microsoft is hardly the sole practitioner of closed protocols and APIs, although they get the lion’s share of scorn in this area. The Insanely Cool Apple has a completely closed interface to the iPod, making 3^rd party syncing software for non-Apple platforms a bit more than just a clever exercise in reverse engineering. Try to hook a non-Apple device into iTunes? Fuhgedaboudit. And as much as Google can play cool about being Open Source with Android, one only has to peek under the hood of the SDK to see it uses a completely proprietary, closed source JVM that sits on top of the Linux stack to provide the application environment.

These are scary times for both enterprise and consumer software companies. Based on such reports as this, that fear seems well-placed.

July 31st, 2007

Open- and Closed-Source Services Convergence

Posted by Michael Krigsman @ 7:53 pm

Categories: Consulting, Open Source, Packaged Services

Tags: Open Source, Convergence, Michael Krigsman

Recently, Peachtree Pro Accounting was given away for free, making this commercial software look open source, from a financial acquisition perspective.

Against this backdrop, I read comments by Roberto Galoppini, where he raises the issues of services in the open source world. Roberto makes this comment:

Open Source franchising is aimed at delivering to the market IT basic services using OSS, with a fixed-time fixed-price methodology meeting clearly defined performance criteria (SLA).

I see no difference whatsoever between open source services and traditional consulting services.

Once the license is obtained, whether through payment or free, the software must be deployed. At that point, the key issue becomes integrating the new software into an existing technical and business infrastructure.

While I agree with Roberto that fixed-price services are the right model, it’s not specifically an open source issue.

August 31st, 2006

Open Source ERP: Training Doesn't Matter??

Posted by Michael Krigsman @ 10:11 pm

Categories: Open Source, Training

Tags: Michael Krigsman

The following quote is taken from an article explaining key differences between open source and commercial ERP software:

Open Source ERP does not require much training. The source code is more than a training manual. The results are also bound to be effective because the user gets to learn through the process of self teaching. The company need not spend much on training and makes a minimal utilization of the resources.

Users will get trained by reading the source code??? Yes, I know this can’t be taken seriously, but it’s just so ridiculous I had to share it. The link to project failure is so obvious that no additional comment is needed.

August 17th, 2006

Open Source Fiasco

Posted by Michael Krigsman @ 6:12 pm

Categories: Open Source, Project failures

Tags: Michael Krigsman

Hugger-Mugger Yoga Products  is a $5 million supplier of yoga-related products such as clothes, yoga mats, and so on. After struggling with a variety of individual software products that did not integrate well, the company decided to implement open source ERP package Compiere. This package was chosen on basis of low-cost and because it includes modules that Hugger-Mugger specifically required.

After implementing Compiere, the company faced a variety of serious operational problems related to the software. From an article on SearchOpenSource.com:

“[The IT staff] didn’t do any pre-work. They just installed Compiere,” said [new company president] Chamberlain, who wasn’t with the company at the time. “They didn’t understand that ERP is very complicated, and moving from point solutions to an integrated suite requires a whole different way of looking at the business. Most people take about a year of preparation.”

The IT staff only did a small amount of testing and did not do that testing with Hugger-Mugger’s data and processes, according to Chamberlain. Instead, early this year, they just put Compiere into production fairly quickly. Chamberlain, still stunned by this approach, said: “You don’t go live and say, ‘Gee, how does this work?’”

The only user training given was a short speech.

“Operators didn’t have a clue how to use the new system,” Chamberlain said.

In fact, the way Compiere was set up – incorrectly, that is – made all the processes more complicated than they had been before. The IT people set it up from an IT perspective, one in which some processes are intuitive to an IT expert and clicking from screen to screen isn’t considered a chore, according to Chamberlain. So, call center reps had to click through eight screens to enter an order, making a process that should take only a couple of minutes take five-to-10 times longer.

Many data entry and data routing mistakes occurred due to lack of training, the result of a failure to create needed reports and other oversights in implementing Compiere.

Enterprise software implementations are complex — jobs can change, processes across an organization can be affected, and great care and feeding is required to be successful. This situation offers a classic study in how an IT initiative can move forward under its own steam, without sufficient reference back to what users actually need. In addition, it can be tempting to think that open source means cheap and easy, which is not necessarily the case. As someone wise once said, “Don’t let this happen to you!”