When your organization is a consumer of software capabilities and a producer of software capabilities, every project may be subject to a buy versus build decision. Many organizations struggle to have a rational repeatable process to make these decisions. Turf battles between IT and functional business units, personalities, experiences and emotions often become involved in these decisions, and as a result the decision is often made poorly.
A decision framework for buy versus build should be rational, based on the projection of expected benefits of from either direction. This requires us to renounce hidden agendas, political objectives, and be empirical.
In a build versus buy decision, we are comparing already existing capabilities in the vended solution against the our confidence in the ability of our IT unit to build software that meets our requirements.
From the business perspective factors that go into such a decision are:
- New Business – Does the business practice that will benefit from the software capabilities already exist, or is the business practice dependent on the software capabilities in order to be realized?
- New Solution – Is the new solution replacing an existing software solution, or are these net new software capabilities?
- Secret Sauce – Does the business practice that will benefit from the software capabilities provide your organization competitive advantage?
- Well Regimented – Is there well understood process documentation for the business practice that will benefit from the software capabilities?
From a vendor perspective, factors that go into the decisioin are:
- Corporate Risk – Is the vendor financially sound, ripe for a takeover, entreprenurial or managed, focused or comglomerated?
- Relationship Risk – Are you going to be the vendors biggest client, smallest? Do you have expertise or market share that they want? How long is their implementation pipeline?
- Capability Risk – How good are they at delivering on time, delivering quality software? How good are they at understanding your business, your needs?
- Product Risk – How much of your current/future need does the current version of their product meet right now?
- Roadmap Risk – How much is your organization like their other clients? Are they focused on gaining market share in your market segment?
From a Internal IT perspective, factors that go into the decision are:
- Capacity – Is your IT organization able to deliver solutions quickly, or ramp up to deliver when needed?
- Flavor – Is your IT organization more oriented to integrating and supporting solutions or major appliction construction?
- Relationship – How is your relationship with your IT group? Do you partner well to accomplish things, or are there political impediments to progress?
- Predictable – Does your IT organization deliver on its committments with tranparency and integrity?
From a Financial Perspective :
- Initial Cost – what do we spend to get the software capabilities? Installed? Working?
- Integration Cost – what does it take to get the information we need into/out of this application?
- Testing Cost
- Training/Business Change cost
- Annual Support Cost – what will it cost us per year over the expected life of this application?
- Staff Cost
- License/Vendor Maintenance Cost
- Cost of Taking new releases, or making Capital Improvements
- Cost of maintaining infrastructure (hardware, OS, dbms, application platform)
Last, we must consider product risk – how well the existing vendor products meet our current and future needs. This assumes that we can articulate our current needs and/or predict what our future needs might be. If we don't have this well in hand, we need to be able to articulate and prioritize current and future needs based on business value. If we can't do this, neither buy nor build will be successful.
No Comments