Software evaluation and selection is a learning process. The selection team will learn a great deal about itself, the company requirements, external software vendors, application software tools, and outside consultants. During this "journey of discovery" it is often helpful to take a guide someone who has been there before and can lead you through the process.
When looking for a consultant to guide you through the process, look for a firm that is unbiased and has no hidden agenda. Many consulting firms resell software or have close financial alliances with software vendors. While these consultants may be very useful during the implementation phase, their judgment may be impaired during the selection phase. Also closely examine the specific individuals who will work on the project.These are the people you will work closely with on a daily basis, so choose them wisely. Evaluate their skills, past experience, market knowledge, industry expertise, honesty, integrity and references. Be wary of any consulting firm that will not clearly identify the resources for your project.
Don't rush the process!
This seems like heresy in today's corporate climate where everything must be done yesterday. The key here is to maintain the paradigm of software as a capital investment. Look at similar corporate decisions regarding machinery, real estate, facilities, etc. and use that as a guideline for your decision-making timeline.
Obviously there is a balance between "analysis paralysis" and constructive action toward a known objective. Effective management is crucial at this early stage to ensure the team continues to make progress and does not bog down in over analyzing the selection.
Build a strong business case
Probably the most important deliverable in the entire evaluation and selection process is the business case, which serves as the "guidebook" for the remainder of the project. A strong business case establishes the project expectations and guidelines including:
* Project scope
* Expected costs
* Expected benefits
* Project performance metrics
* Risks
* Overall implementation approach and timeline
* High level project workplan
* Resource requirements
* Assumptions
But it is not enough to simply produce these documents and call the business case complete. Sufficient analysis must be performed such that the project expectations are realistic and supported by factual evidence. For example, saying that a project will result in $1M in cost savings due to "more efficient supply chain processes" is not sufficient analysis. One must identify the specific performance metric that will improve due to the new system, discuss how the software will actually improve that metric, assign an "owner" responsible for delivering that benefit, and then calculate the expected financial results.
For example, if your project is expected to reduce raw material inventory, a thorough business case will record this as follows:
Expected Benefit #1 - Reduce raw material inventory in category A by 25%
* Justification:
o Software and business process enhancements will reduce the purchasing cycle from 4 weeks to 3 weeks. This 25% reduction will allow a corresponding reduction in raw material inventory on hand. This benefit assumes that the three week purchasing cycle will not result in additional transportation costs due to increased shipment frequency or less than truckload shipments (this assumption is supported by the evidence presented on page XXX of the business case).
* Owner:
o Bob Jones, Director of Purchasing
* Savings Summary:
o Expected annual savings = $125,000
o Expected one-time reduction in working capital investments = $1,250,000
* Savings Detail:
o Current average raw material inventory value in category A = $5,000,000
o Expected inventory reduction = 25%
o Expected annual return on invested capital = 10%
o Annualized Dollar Savings = $5,000,000 x 25% x 10% = $125,000
o Reduction in working capital = $1,250,000
As you can see, a more detailed set of benefits will remove ambiguity, assign ownership and give the project team a clear set of goals and metrics to target. Developing a business case at this level of detail is a key component in gathering executive support for the project.
In addition, a strong business case serves as the project reference manual. As the implementation begins questions will arise surrounding scope, objectives, budget, resources, deadlines, milestones, etc. The business case must be used to guide the decision making of the project management team. Without an effective business case, and managers who use it properly, an implementation can quickly lose focus and wander off course.
This is Part two of a two-part article.
Part One discussed some of the reasons software implementations so often fail.
Involve all affected departments on the selection team
What seems to be a simple concept is often bypassed for political, personal, and resource/schedule constraints. But there should be no compromise here. A software evaluation and selection team that does not include affected parties will invariably face high-levels of resistance and increased risk of failure. When implementation troubles set in or questions arise over the software capabilities, organizational buy-in and support will help you manage through these issues. Without it, the project can and will lose momentum.
Be thorough in your requirements definition
Again this is a simple concept, but one that is often bypassed due to expediency or difficulty. A comprehensive set of business functional and technical requirements serves multiple purposes:
* Acts as a basis for software evaluation
* Acts as a basis for defining software gaps
* Acts as a basis for final software testing (system, performance, user acceptance, etc.)
* Acts as a basis for training
* Establishes project scope
SOURCE:
http://www.technologyevaluation.com/research/articles/software-evaluation-selection-and-procurement-part-two-recommendations-for-improvement-16878/
When looking for a consultant to guide you through the process, look for a firm that is unbiased and has no hidden agenda. Many consulting firms resell software or have close financial alliances with software vendors. While these consultants may be very useful during the implementation phase, their judgment may be impaired during the selection phase. Also closely examine the specific individuals who will work on the project.These are the people you will work closely with on a daily basis, so choose them wisely. Evaluate their skills, past experience, market knowledge, industry expertise, honesty, integrity and references. Be wary of any consulting firm that will not clearly identify the resources for your project.
Don't rush the process!
This seems like heresy in today's corporate climate where everything must be done yesterday. The key here is to maintain the paradigm of software as a capital investment. Look at similar corporate decisions regarding machinery, real estate, facilities, etc. and use that as a guideline for your decision-making timeline.
Obviously there is a balance between "analysis paralysis" and constructive action toward a known objective. Effective management is crucial at this early stage to ensure the team continues to make progress and does not bog down in over analyzing the selection.
Build a strong business case
Probably the most important deliverable in the entire evaluation and selection process is the business case, which serves as the "guidebook" for the remainder of the project. A strong business case establishes the project expectations and guidelines including:
* Project scope
* Expected costs
* Expected benefits
* Project performance metrics
* Risks
* Overall implementation approach and timeline
* High level project workplan
* Resource requirements
* Assumptions
But it is not enough to simply produce these documents and call the business case complete. Sufficient analysis must be performed such that the project expectations are realistic and supported by factual evidence. For example, saying that a project will result in $1M in cost savings due to "more efficient supply chain processes" is not sufficient analysis. One must identify the specific performance metric that will improve due to the new system, discuss how the software will actually improve that metric, assign an "owner" responsible for delivering that benefit, and then calculate the expected financial results.
For example, if your project is expected to reduce raw material inventory, a thorough business case will record this as follows:
Expected Benefit #1 - Reduce raw material inventory in category A by 25%
* Justification:
o Software and business process enhancements will reduce the purchasing cycle from 4 weeks to 3 weeks. This 25% reduction will allow a corresponding reduction in raw material inventory on hand. This benefit assumes that the three week purchasing cycle will not result in additional transportation costs due to increased shipment frequency or less than truckload shipments (this assumption is supported by the evidence presented on page XXX of the business case).
* Owner:
o Bob Jones, Director of Purchasing
* Savings Summary:
o Expected annual savings = $125,000
o Expected one-time reduction in working capital investments = $1,250,000
* Savings Detail:
o Current average raw material inventory value in category A = $5,000,000
o Expected inventory reduction = 25%
o Expected annual return on invested capital = 10%
o Annualized Dollar Savings = $5,000,000 x 25% x 10% = $125,000
o Reduction in working capital = $1,250,000
As you can see, a more detailed set of benefits will remove ambiguity, assign ownership and give the project team a clear set of goals and metrics to target. Developing a business case at this level of detail is a key component in gathering executive support for the project.
In addition, a strong business case serves as the project reference manual. As the implementation begins questions will arise surrounding scope, objectives, budget, resources, deadlines, milestones, etc. The business case must be used to guide the decision making of the project management team. Without an effective business case, and managers who use it properly, an implementation can quickly lose focus and wander off course.
This is Part two of a two-part article.
Part One discussed some of the reasons software implementations so often fail.
Involve all affected departments on the selection team
What seems to be a simple concept is often bypassed for political, personal, and resource/schedule constraints. But there should be no compromise here. A software evaluation and selection team that does not include affected parties will invariably face high-levels of resistance and increased risk of failure. When implementation troubles set in or questions arise over the software capabilities, organizational buy-in and support will help you manage through these issues. Without it, the project can and will lose momentum.
Be thorough in your requirements definition
Again this is a simple concept, but one that is often bypassed due to expediency or difficulty. A comprehensive set of business functional and technical requirements serves multiple purposes:
* Acts as a basis for software evaluation
* Acts as a basis for defining software gaps
* Acts as a basis for final software testing (system, performance, user acceptance, etc.)
* Acts as a basis for training
* Establishes project scope
SOURCE:
http://www.technologyevaluation.com/research/articles/software-evaluation-selection-and-procurement-part-two-recommendations-for-improvement-16878/
No comments:
Post a Comment