There has been much study of the COTS selection methodology over the past couple of years, much of it done by Carnegie Mellon’s Software Engineering Institute, which previously had focused almost exclusively on software development methodologies, culminating with the seminal work Capability Maturity Model (CMM).
CMM defined an organizations sophistication level in the world of software development. The body of work, known as SA-CMM, or Software Acquisition-Capability Maturity Model, defines the level of sophistication of the organization in it’s ability to select software for commercial purposes. It ranks organization into one of five levels with one being the lowest initial level, which it defines as:
| More Dan Gingras on CIO Update | |
|
Is the CIO Obsolete? The ERP Renaissance Surviving as the First CIO The Death of the Internet? If you want to comment on these or any other articles you see on CIO Update, we’d like to hear from you in our IT Management Forum. Thanks for reading. – Allen Bernard, Managing Editor.
|
“At the initial level, the project team typically does not provide a stable environment for acquiring products. The project team is staffed based on the availability of the individuals, resulting in a random composition of the acquisition skills. Acquisition does not receive adequate management visibility. The project is pursued in an ad-hoc manner. There are no key processes areas at Level 1.”
This is the level at which most organizations acquire software which can have profound implications to their organizations. It also may be why studies have shown that 60% of all software implementation projects fail.
Step 1- The business case
The first step in formalizing the process is to create the business case document necessary to justify the project. It should clearly spell out the reasons for the projects, the anticipated steps necessary to accomplish the project and a preliminary budget to accomplish the project.
The key here is to create the financial or other justification for the project and to clearly spell out the benefits of what you are trying to accomplish. I like to tell both clients and students this is like navigating a boat on a long voyage; you may not know the exact route yet, but you should absolutely know the destination, or you may end up in a really bad place.
I wouldn’t even consider approving a project which didn’t have a well documented business case with specific and quantifiable benefits defined. This is the root of the entire project, and everything else grows from a well defined business case.
The key is the quantifiability of the benefits: You should know what success looks like before you start or you will not know if you succeeded.
It may be as definable as ROI, or somewhat less measurable, such as customer satisfaction, but in that case, you should have a good baseline against which you can measure. The bottom line is you wouldn’t think of buying a new factory machine without a thorough ROI analysis, so you shouldn’t invest in large information technology projects without the same rigor.
Step 2 – Governance and Control
Once you have the business case defined, you need to put in place a mechanism to keep the project on course. The course may not have been defined yet, (i.e., you may not have a solution or even an approach to the solution, but you really need to insure that the voyage has a captain from the business not IT).
Major projects like ERP or CRM really need a more formal oversight structure in the form of a specific “steering committee” or other governance body, which should represent both the business functions affected and have some participation from IT to insure there is an overall consistence with a corporate architectural plan.
In general, however, this body should be run by the business functions and not by IT to insure that true business benefits are achieved.
Step 3 – Constraints
Any capital expenditure has a pre-defined set of constraints, and it’s best to get these out on the table immediately. These include budget constraints — you want to set a fence around the amount of money you have to spend on the project early before you waste a lot of time and effort.
You may also be constrained by time — this is particularly true in the era of Sarbanes Oxley where new financial systems need to be implemented in a way that will not affect year end closes. You may also have timing constraints in manufacturing systems depending on your specific business environment.
Unfortunately, you may also have specific technology constraints too. This is unfortunate because in the “perfect world” you would select a COTS based purely on business needs and benefits but, in the real world, you generally have sunk-cost in specific computer architecture, and this translates to a specific skill base which can significantly affect costs of the project.
If you are completely an IBM AS/400 environment, for example, then you are adding significant cost and risk by looking at Linux solutions. The trade-offs may be worth it, but you need to factor them into your analysis early.
Step 4 – Requirements Definition
This is the most “technical” part of the analysis, and depending on your specific project, it may be of some benefit to bring in some help with this process. This is particularly true for big systems like ERP or CRM, where you may not know all the features available in the marketplace.
In general, this is the area that consumes the most time and resources in the selection process, and it’s also the most critical. The scale of the project will determine the nature of this step but a large scale, complicated ERP selection can take the better part of a year to do correctly.
The process varies considerably depending on the size of the project, but, in general, it involves fully understanding and mapping the affected processes within the business. Luckily, there has been a lot of new work done in this area over the past decade, and there are a number of new modeling techniques and tools available to help with this step.
Step 5 – Market Intelligence and Survey
This is really the easiest part of the process, and it can be very straightforward or moderately complex, depending on your approach.