Home Page

Have a question or comment?

Printer version

9 Steps for Selection Success

Selecting and deploying a business software system is a mission-critical project that every company performs.  These business systems will undoubtedly be a driving force in your quest for corporate success.  Understanding your requirements and selecting the right system are the first steps in ensuring your company can operate as planned and that you realize all the advantages afforded by the software technologies available. 

The following nine steps are a methodical progression of evaluation, planning, research, and decision making that will yield a successful selection and prepare you for the implementation phase.  Each step describes the major activities and needs.  Tools and templates that can be downloaded are provided in certain steps.

Step 1 – Problem Identification and Resolution Justification  

A person within the organization needs to see an issue or problem with the way the business process is currently working. The issue may pop up because a measurement is not being met or people in the process are complaining that something is wrong.  If the problem cannot be eliminated by changing the process or the way the existing business system is being used, then maybe a new system may be worth investing in.  The person who identified the issue or some other ‘Champion’ needs to justify the need for a new system and garner support from others to move the problem resolution to the next level where resources can be applied.  The ‘Champion’ is anyone who sees the need for change, has a passion for improving the process, and can get things moving.

Problems that may initiate discussions for investing in a new system:  

• Manual system in place is getting to cumbersome, so automation may be the next step.

• Current system is not integrated or does not have the required functionality/scalability.

• Current system is difficult to use (i.e. Poor navigation, Not user friendly, High maintenance)

• causing inability to achieve critical efficiencies.

Resolution Justification:  

• A problem statement needs to be created describing the problem, background of the issue, and business impact (i.e. How it affects resources, benefits, costs, customer satisfaction, etc).

• A resolution statement needs to be created outlining the potential workarounds or solutions to the problem. (This includes all estimated costs and benefits as part of a justification.)

• Present the problem and resolution justification to management for approval.

Step 2 – Project Organization  

In order to get something done in a given time frame, resources of people need to be committed to carry out the project.  The project may start out as a single person assignment to gather additional information to validate the initial justification.  Once it has been decided that additional resources should be spent, a Steering committee and Project Team will be set up. The team and its leader are empowered to begin the project.  Start with clearly defined roles.

The Steering Committee:  

•   Depending on the company structure and the size of the project, the Steering Committee could consist of one person or multiple people, from the upper level management of the different departments affected by the project. (This may also include someone from your Customer’s, Supplier’s, or Partner’s organization)

• The steering committees role is to provide the “Vision from Management”, business strategies, and mentoring/guidance for team members.  They also set project rules and review periods while acting as a go-between and escalation path for the project team and senior management or board of directors.

• The steering committee will approve or reject taking future steps in the process at each review point.

The Team Leader:  

• Could be the ‘Champion’ of the project or other individual with the proper skill sets.

• Knowledgeable in project management, leadership, presentation, and have ‘people skills’.

• Guides the team on their journey to success.

• Evaluates skill sets provided by team members and decides on any training requirements that may be required for team members.

•   Decides on tools needed to manage the project and for collaboration with team members.

The Project Team:  

• There should be a team member representing each function within the cross-functional process the team plans to be working on.  (This should include customers, partners, and suppliers, whenever possible)

• Members should be knowledgeable in their areas, have an open attitude towards change, and have the ability to envision/understand the bigger cross-functional picture.

• The team maps out the current and future processes while evaluating different pieces of software.

• Teams should have a majority consensus on all decision-making activities.  If not, further research and debate should be warranted.

• Team members should keep their departments informed as to the status of the project and solicit feedback regarding concerns and expectations.    

Step 3 – Publish Plans  

This is the stage where the road map is created for this project. It is here where all the pieces start to come together.  This document should be used as the schedule and include major milestones.  The plan should also be broken up so that each phase is a small measurable increment.   As each increment is successfully completed, the team will gain confidence in the process and build relationships for success.

Include in the plan:  

• Schedule (GANT chart with milestones, timeframes, and deliverables)

• People requirements (Who needs to be involved, beyond the core team)

• Resources (Meeting area, process mapping tools, other skills training)

• Budget (Cost of performing project including tools needed to effectively complete tasks)

• A gross cost/benefits analysis (A more detailed version of the justification from step 1)

• A ‘measurement of success’ for each phase and the total plan.

Review the plan with the steering committee.

Step 4 – Create a Functional Map and Requirements Document  

A functional map is a pictorial flow of the corporate processes being addressed in the project.  This will allow the team members to visualize the cross-functional processes and aid in understanding the short term and long term process needs.  The functional map becomes the foundation for setting up a requirements document.  The requirements document defines what you want the new business software to do and what you want from the company that is selling and installing the software.  It is here that the team creates the requirements that are needed to fulfill the corporate strategy, differentiating you from your competitors. 

What is contained in a Functional Map?  

• Visual depiction of processes and departments.

• Identifies core competencies and where processes cross-functional boundaries.

• Can include customer, partner, and supplier processes.

Information required creating a robust Requirements Document:  

• An understanding of your company’s business strategy and core competencies.

• An understanding of your customer’s, supplier’s, and partners needs and deliverables, so they can be factored into the process re-engineering.

• A review of “Best of Breed” practices to understand how the process can be re-engineered.

• Make sure you don’t just look short term at your process.  Visualize what it might be in the future and make sure that any future needs are addressed now.

• Obtain knowledge of what technologies are available in the market and what they can do for your business.

• Mapping out of the existing process and understanding of how the future process is required to work.

What is contained in a Requirements Document?  

• Outline of current technology/systems in place.

• Questions and specific needs regarding the ability to execute and financials of potential candidates.

• Technical Architecture requirements.

• Questions and specific needs regarding service and support for potential candidates.

• Questions and specific needs regarding the vision of the potential candidate.

• Specific functionality requirements covering all areas of concern with a rating system that allows the reader to understand which functions are more critical than others.

Review the Requirements Document and Functional Map with the steering committee.

Step 5 – First pass review of software packages  

This step involves researching different software packages available in the marketplace and deciding on whom to send the Requirements Document to.  The goal is to find 5 to 10 companies that you feel offer the best combination of financial stability, cost, technology, vision, and service.  These candidates can then review the Requirements Document and respond with a proposal, outlining how they meet (or don’t meet) the requirements.  Based on the responses, pick the top 2 to 4 candidates to proceed to the demo step.

Research available software packages in the market.  

• Locate sources of information to gain an understanding of the software industry/marketplace. (i.e. Consultant, Web site, IT department, etc.)

• Use telephone interviews and web site reviews to learn scalability, flexibility, friendliness, cost range, and other metrics for specific software packages.

• Benchmark what software packages are being utilized within your specific industry.

Send Requirements Document to 5 – 10 candidates.  

• These candidates should offer products targeted for your company’s size.  Be sure to understand if the software company is a Tier 1, 2, or 3, and if they offer a solution suitable for your current and future user base and budgets.

• Most software suppliers will insist on a meeting to review the requirements, prior to providing a response.  This will allow them to better understand the needs and hot points.

Review proposals, pare down to 2 - 4 candidates.  

• Review proposals for completeness and vagueness.  Don’t be afraid to ask for a clarification.

• Be wary of mission-critical functionality that is “due out in the next release”.

Research Implementation companies.  

• Once you feel you have your 2-4 candidates, you need to explore what organization might do the implementation for each one.

• If the software supplier does not do their own implementation, then you need to research the value added resellers that they have.

• Thought should be given to methods of training, project management, best practices, and customization when evaluating them.

• The final decision does not have to be made at this point in time if there are multiple options, but it is important to have an implementation company (if different than the software supplier) present through the rest of the process, (especially the demo stage) so you can evaluate how knowledgeable they are and how well they work with your team before making the final decision.

Step 6 – The Demo Process  

The demo process allows the users to see how the software application can fulfill the business process needs while also ensuring it works as advertised by the sales person/literature.  In order to facilitate a “value packed” demonstration, a demo script should be used.  Without a scripted demo, most suppliers will steer clear of any weaknesses and only show the strengths of the package.  A scripted demo digs out the strengths and weaknesses by ensuring all areas are covered.  A well-written demo script will also ensure the team considers all functional areas affected by the potential software change.

What is contained in a demo script?  

• Tailored to have the supplier demonstrate mission critical and priority functionality.

• Non-critical functionality should still be discussed, but not demo’d.

• Provide sample data to include in demo – Proves it can handle your part numbers, etc

How should the demonstration be handled?  

• Entire team should be present at start and then during their specific functional area.

• Make sure the supplier follows the script.

• If functionality does not meet a requirement, discuss workarounds.  (Some suppliers will try to get you to change your requirement to fit their software.  Beware of the trade-offs!)

• The team should garner an understanding of what modules are being demo’d.

• Each team member should capture data/notes using a copy of the demo script.

What is the follow up to the demonstration process?  

• The team should meet soon after each demo to come up with a group consensus on the functionality pros, cons, and workarounds.

• Don’t be afraid to schedule an additional demo if some functionality was missed or greater clarification is needed.

Step 7 – Preliminary implementation plan and life cycle cost analysis  

t is now time to build a preliminary implementation and cost structure.  The goal here is to assemble a preliminary plan of what portions of the software will be implemented short term versus long term along with the cost elements for the short term and the long term. The end result will be a preliminary implementation plan and Life Cycle Cost Analysis of each potential package for comparison in the next stage.

Major points of an implementation plan:  

• Contains who will manage the implementation and what their role is.

• Should outline what modules are being implemented and when, along with data mapping activities.

•   Contains a time line of major milestones and a firm estimate of how much time the supplier needs to spend implementing the package.

• Contains the methodology on how current processes are re-engineered into “Best of Breed”.

• Should outline what custom modifications are required and when they need to be completed.

• Contains preliminary info on who needs training and when/where it will take place.

Major points of a Life Cycle Cost Analysis:  

•  Based on all short term and long-term needs and goals.

• Contains all software costs based on the number of concurrent users and modules being purchased.  

• Cost of additional users in the future (Bought one at a time or in blocks?? - Negotiate up front!)  

• Contains cost of additional hardware, facility enhancements and Third Party software products.  

• Cost of additional personnel required to manage the new software/hardware.

• Cost of Implementation companies consultation fees. (Implementation/Data Conversion)  

•   Cost of software training and training tools, include costs for 3^rd Party or new hardware training.  

• Cost of Annual Maintenance for Software, Third Party products or additional hardware

• Costs for upgrades/patches/new releases if not included in the annual maintenance support.  

Life Cycle Cost Data Tool:  

• Tool to capture life cycle cost data

Step 8 – Final review to get to “The One”  

You have gathered all kinds of information from steps 1 through 7 on each potential supplier.  Now, how do you choose a long-term software and implementation partner(s)?  You need to utilize a methodology that allows a ranking and comparison of the potential packages.

Six metrics to rank and compare each potential partner:  

• Ability to Execute/Financials

• Vision

• Technology Architecture

• Life Cycle Costs

• Functionality

• Service and Support

Pick “The One”  

• The team should come to agreement on the strengths and weaknesses of each package and how they rank, leading to a consensus on which package is “The One”.

• An implementation partner should also be decided upon (if different than software provider).

• The team should then present a case to the steering committee regarding their pick and their recommendation to proceed with the final negotiations.  The goal is to get the steering committee’s buy-in and approval to move forward.

If the team cannot decide on “The One”  

• The team and/or steering committee may conclude that none of the three packages have the right combination of strengths to be called “The One”.

• You may need to go back to the Requirements Creation step #4 if your requirements are too stringent or back to Research Supplier step #5 to find other possible candidates.

• Do Not settle on a package that does not meet your requirements to save time, if you feel there might be a better fitting solution.  The consequences of investing in the wrong package typically are much greater than the consequences suffered by spending more time on finding the right fit. 

Step 9 – Closing the deal  

Once the team and steering committee have agreed to move forward with “The One”, the deal must now be finalized between all parties.  This step ensures that all final checks have been made and that all expectations have been negotiated and documented between the client and the software supplier (and the implementation company if separate from software supplier).  Once this has been completed, the original measurements for success in the plan should be reviewed and a post-mortem performed on the project

Reference Checking:  

• Reference checks should be made to companies that are using the product in a similar industry/environment.

• Don’t be afraid to check other references you find on your own through user groups, etc.

• Speaking to a user who is 8-12 months ahead of you in the process should provide you with an abundance of information regarding how the software works versus advertised, and how the implementation has progressed with any problems encountered.

• You may want to include visiting the site of an existing user to see the product in action.

Finalize Implementation Plan:  

• A final review and agreement on the implementation plan is required.

• Assign firm (but not concrete) milestone dates based on the expected contract signing date.

• Ensure implementation and training resources are available from both parties based on these milestones.

Finalize Life Cycle Costs:  

• Perform final negotiation of costs based on the finalized implementation plan.

• All costs are negotiable….Don’t be afraid to deal.

• Incentives can increase towards the ending of a financial quarter.

• Life Cycle Cost Data Tool  

  • Tool to capture life cycle cost data

Contract Negotiations:  

• You may end up with three or more contracts to negotiate. (Software, Maintenance, Implementation, and Third Party products).

• Most provisions are negotiable, but the ones to watch for are the ones that are either phrased with little specificity or not included at all.

• Software licensing typically requires a lawyer with knowledge in software licensing to ensure an adequate review.

• Major points of Contract Negotiation:

  • Document on Contract Negotiation Points

Measurement Review and team Post-Mortem:  

• Did you obtain the measurements for success in the plan?  If not, why?

• What did and didn’t work for the project?

• What did you learn that could be applied to the next project?