Inverhuron Business Information Services Inc

The biggest problem, and yet also the easiest to solve, is the huge investment in license fees. Any open source solution or software as a service would allow you to spend nothing upfront and simply pay for use and support, thereby amortising the risk.

Consider the options:

1. Proprietary. Watch a few demos (hopefully representative of the product's actual capabilities (because you have no real way of knowing)), then fork out a huge pile of cash. Assume the cash has been incinerated the moment you give it away, because it won't buy you implementation or an actual solution to your problem. That costs extra, and it may never work.
2. Open source. Use the product for as long as you'd like. See if it works. If it does, and if you then want support (or, in some models, extra functionality), pay a fraction of what you'd pay to a proprietary software company. 100% of that money is for support, such that the vendor has every incentive to ensure your continued happiness and to continue to invest in the innovation of its product and services. Pay extra for implementation, but often from a third party (and almost always much less) that doesn't have the same conflict of interest that in-house professional services might have. If the product doesn't work out, for whatever reason, you lose far less cash.
3. Software as a Service. Try out a demo if one is available (same caveats apply), then if you like it, fork over a bit of cash to sign on to the service. Your outlay should be only a small fraction of what you would pay to license or own the software, because it is just an initial setup fee and a few months of access to the service. The vendor has every incentive to keep you happy, because if the service doesn't measure up or grow to keep pace with your needs, you can take your business elsewhere. You can expect to pay more for assistance with implementation, but you could possibly get that from a third party. If things don't work out, you have not had to shell out large sums. Just be careful about contract terms, especially exit fees, and whether you can take your data with you. SaaS is like leasing instead of owning, and it is all expensed rather than capitalised.
4. Build it yourself. Make your plans, hire staff or contractors and begin shovelling money into the furnace of development. Something may materialise sometime. If and when it does, you may actually be able to use it. It may even work the way you wanted it to. The great weakness of this method is the multiple points of failure. Success depends partly on the quality of your original plans, partly on those plans not changing during the life of the project, partly on the quality and knowledge of the staff you hire, and partly on how long it all takes to make and whether you can stand the delay. If the project goes like most such, you probably won't have any idea how it is doing until at least 3/4 of your budget is gone, and I don't mean the original budget, but the new one that is now twice what it was to begin with. What do you do with all those IT people when your project is finished?

Is there a real choice to be made here? Who wants to reinvent the wheel or explore the bleeding edge of technology unless they must? Why would you ever take a proprietary software model over open source or software as a service, assuming there is a roughly comparable competition?

Proprietary software increases IT risks in many ways, but especially in the way it dramatically increases the cost of failure. It's common knowledge that many IT projects fail. As such, why not minimize the cost of failure? It's much easier to try an open source or SaaS solution for a few thousand dollars and discover that it's not a good fit for your enterprise than to spend ten times that, or a hundred times that ... only to discover exactly the same thing.

This has nothing to do with the nature of the code itself. It has everything to do with the more customer friendly business models that open source and Saas companies use. Open source shifts the risk to the vendor, whereas proprietary software forces nearly all risk onto the shoulders of the IT buyer. (You don't get the product/code until you pay, and then you pay upfront.)

Larger projects tend to incur greater risks as can be seen from the table. There is no substitute for sound project management which must begin with your own organisation clearly defining its goals and expectations, then conducting sound research to locate the most suitable business partner to help you meet those goals.

There are ways to minimise the direct capital costs and expenses of a software project. Two important ways are open source and software as a service. They can dramatically reduce risk by helping you avoid the overpriced and overly complex software wrapped in a proprietary license.

Often an organisation has not sufficiently defined its business and technology requirements. This is a recipe for a project that lacks overall strategic direction, and for finding that the majority of your employees cannot or will not use the system. The unavoidable result will be a large investment of time and money for a system that is not fully utilised, and a shortfall in intended benefits.

This is a scenario painfully familiar to many IT people. Projects that fail are often due to software that is cumbersome to use and that forces people to fit the way they work to the way the software requires them to work. It's just a matter of a poorly designed product.