Businesses of all sizes and across all industries rely on software to optimize their work processes. Too often, however, employees looking to purchase information technology (IT) products and services don't stop to think about which vendor's products will be a good cultural fit for their organization.
That's where this step-by-step guide for how to purchase business-to-business (B2B) software can help.
By completing each of these steps, you'll be able to create a strong procurement plan and make an informed purchasing decision. This outline won't leave you with any surprises -- and the knowledge you'll gain from carrying out due diligence during your research will continue to produce benefits long after the contract has been signed.
In this guide you will learn how to:
- Identify the problem you want your software purchase to solve
- Determine your desired future state
- Identify the stakeholders
- Build a case for change
- Find your budget
- Build a business case
- Research possible vendors
- Evaluate vendors
- Create a shortlist
- Arrange successful product demonstrations
- Hold a productive roundtable discussion
- Make a final purchase decision
- Approach contract negotiations
- Reflect on the decision
Let's go find a vendor!
Step 1. Identify the problem
Before you can even begin considering vendors, you must define the problem you're trying to solve. Maybe your current HR software needs to provide better features for applicant tracking, or you've decided you'd prefer a system that keeps all HR processes in one place. Or maybe you need to purchase new contact center software with reporting features that will provide insight into data in real time.
It may help to consider what your ideal work environment is and then ask yourself: What's preventing me from achieving this?
In many cases, the problem you're facing may be the result of both faulty processes and inadequate software. Identifying these issues is not an exercise in fault-finding. It is an opportunity to approach problems in a new way. Spend time with the affected teams to gain an understanding of the problems from their perspective and how important a resolution is.
Ask them what they like and don't like about the current software. Observe how they use the existing system and ask them to explain what changes would make their job easier. This will help ensure your project generates a return on investment (ROI) because you're investigating systems that your end users will actually use.
When identifying the problem, it is important to determine what is good about your existing software and what is lacking. Understanding your current status will reveal other areas that might need fixing or are already working well.
This first step of the process forces you to look closely at why people may want to introduce a new technology as well as why it's needed. By gathering feedback and ideas, you can determine if there is a strong enough business reason to proceed with the project and invest resources.
|Questions to consider|
Step 2. Determine your desired future state
These first two steps go hand-in-hand. When identifying your problem, you will also need to have some idea of your desired future state. What do you want the software to achieve? It is best to think of concrete, tangible results when determining your anticipated outcome.
The software you invest in should align with your business goals and add value. To make sure this happens, you need to define your requirements for the new technology. It may help to ask yourself: In a perfect world, what will your life look like after the system has been implemented? What will the new software achieve?
Your list of requirements should primarily include business-focused requirements, such as how spending money on software will help keep hiring costs down by improving current employee productivity. However, you should also evaluate and include any major information security, technical, audit and architectural requirements. This list will serve as a reminder for what you need to think about when you start your research.
Consider the necessary security requirements or local and global law compliance that is relevant to your project. What laws, regulations, specifications and guidelines must you adhere to when implementing the new software? Are you affected by state-level laws -- such as the California Consumer Privacy Act (CCPA) -- or national and regional legislation -- such as the General Data Protection Regulation (GDPR)? What security standards should be put in place to support your company and continue to keep your information, employees and customers safe? Evaluating these conditions early on will save you time when researching and evaluating vendors because you can immediately start to cross off companies that do not provide regulatory compliance or your specified security requirements.
|Questions to consider|
Step 3. Identify the stakeholders
Before you can make any further decisions, you need to identify all your stakeholders. Be sure to consider:
- End users. The people who will be interacting with the product daily. Make sure each department that will be affected is represented throughout the project.
- Subject matter experts. The people in your department or company who understand the ins and outs of the project and how it affects the company.
- Decision makers. The critical people you need to sign off on the decision.
- Most solutions usually require technical support from your IT group including understanding platforms, integration points, data flow and more.
- Legal and finance teams.
If your organization is small enough, you may know the names and responsibilities of each stakeholder off the top of your head. If not, you may want to consider creating a RACI matrix. RACI stands for responsible, accountable, consulted and informed. The idea of the matrix is to sort out people according to their role in a project.
Here's a who's who in a RACI matrix:
- Responsible stakeholders. The employees responsible for doing the work and completing the task.
- Accountable stakeholders. Those who sign off on the work and designate it as completed. If anything seems askew, they are the ones who need to answer for it.
- Consulted stakeholders. Those who are actively in the loop and are asked to give input.
- Informed stakeholders. Those who are updated on progress and decisions but are not formally consulted.
Creating a RACI matrix can help you identify who will be involved in each step of the vendor selection process. Below is an example:
|R - Responsible||A - Accountable||C - Consulted||I - Informed|
|Project activity or deliverable||C-suite||Project business owner||Project manager||Operations||IT||Employee|
|Identify the problem||I||R||C||C||C||I|
|Determine your desired future state||I||R||C||C||C||I|
|Build a case for change||A||R||C||C||C||I|
|Find your budget||A||R||I||C||C||I|
|Build a business case||A||R||C||C||C||I|
|Research possible vendors||I||R||R||I||I||I|
|Create a shortlist||A||R||C||C||C||I|
Once you've identified all your stakeholders, choose a representative from each group to form a tech buying committee. This group is responsible for making software purchase decisions. They are also responsible for making sure the business' hardware can support the purchase.
If you're a large company, this can include five or more decision makers, each with different levels of influence and varying requirements that need to be addressed. When you start asking questions, you'll find there are stakeholders whose needs should be considered sooner, rather than later.
The next step in identifying your stakeholders is to determine their various priorities of requirements for each department. You can use the MoSCoW method to put these preferences into a decision matrix.
MoSCoW is an acronym that stands for four different levels of priority:
- Must haves. Non-negotiable product needs that are mandatory for the team
- Should haves. Important requirements that are not vital, but add significant value
- Could haves. Nice-to-have requirements that will have a small impact if left out
- Will not haves. Requirements that are not a priority and therefore do not need to be included.
Below is an example of how to use the MoSCoW method in a decision matrix:
Using the matrix, you can identify an average priority ranking for each requirement. This can help you understand relative rankings so that you can discuss them with the teams to make decisions about conflicts in rankings.
|Questions to consider|
Step 4. Build a case for change
Use the information you've gathered so far -- including the input received from your stakeholders -- to develop your case for change. A case for change is a document that answers a variety of questions, including:
- What is changing?
- What type of change is it -- transitional, transformational or developmental?
- Why is the change needed?
- What is the scope of the change?
- What is the level of urgency?
- What are the desired short-term and long-term outcomes?
- Who are the target groups affected by the change?
By documenting these answers, your stakeholders and leaders can more easily understand the purpose of the purchase, giving them a reason to engage with and contribute to the success of the process. Without a case for change, you risk creating resistance to the purchasing project, uncontrollable budgets and missed deadlines.
You'll know you've created a successful case for change when you see people:
- asking questions that reveal a level of interest;
- volunteering to help;
- suggesting other ways to resolve the problem;
- challenging the case out of genuine concern for what it might mean;
- using first person pronouns -- such as I and we -- instead of you and they; and
- taking on leadership roles in the process.
This process can also help you find your champion, someone within your organization who is passionate about your project and can help get other leaders on board with your idea. The champion will help you navigate through all the different opinions, politics and levels of leadership that exist between you and the approval of your project.
Note: Your champion will not be your final decision maker. In fact, they rarely have substantial power within the company. However, they're essential when closing a deal because they provide credibility, company intelligence, connections and motivation. The best champions have some existing influence over your organization's senior people as well as an understanding of the software buying process.
|Questions to consider|
Step 5. Find your budget
Before seeking funding for your project, examine your budget and consider whether you have enough money to support your needs. You may have to reevaluate your spending in other areas but fitting the project into your own budget is the easiest option.
If you don't have enough money, then you'll have to find the funding elsewhere. Work with department heads and C-level executives to examine the projected yearly budget and gain an understanding of where your company stands financially. Ask these leaders to advise you where you can find money within other departments' budgets.
Note: Using somebody else's budget can end up being a big deal that involves a lot of negotiating and paperwork. Make sure there's no way to fit the project into your own budget before you start looking for money elsewhere.
Determining the direct and indirect costs of a software implementation depends on your line of business. For example, if you work for a management consulting company and the application in question is used to produce consulting deliverables, then your purchase and deployment of project management software can reasonably be considered a direct cost. Similarly, if you're a media company that produces voice-over and digital advertisements, then your annual subscription to Adobe Creative Suite might be considered a direct cost.
In contrast, HR software may be considered an indirect cost because its purchase can't be attributed to a specific product or service; the costs are widespread and needed for everyday operations.
Next, consider the licensing costs. These will likely vary greatly depending on if you want an on-premises, software as a service (SaaS) or private cloud offering. With an on-premises option, you're likely to pay upfront to license the software. SaaS and private cloud products are usually offered on a subscription basis.
You'll also want to consider setup and maintenance fees. While the bulk of on-premises software costs are paid upfront, the vendor may charge annual maintenance fees of 15% to 25%, including security patches. Other costs for on-premises subscriptions address interoperability, ensuring that the software works well with existing systems.
Furthermore, there's the accounting aspect to think about. On-premises software is generally considered a capital expense -- except for the annual maintenance costs -- while SaaS is considered an operational expense.
Other costs to consider when calculating the TCO include:
Data migration. Whether your data is paper-based or digital, it will take time and money to migrate the data, clean it up to remove obsolete or duplicate items, and conform it to the new format.
Training. Some vendors invite your employees to their training site; others send trainers to you or offer online learning courses. Whether the vendor itemizes this cost or buries it in the subscription price, be assured it will cost you.
Hardware. You may not need new servers at all to squeeze the most performance out of your new enterprise software, especially if you are using the SaaS model. But if you're looking to install the software on-premises and you haven't updated your servers or PCs and laptops in a while, you may need to include hardware upgrades in your TCO.
Once you've determined how much you're willing and able to spend on the new software, you will need to justify your budget to prove that the project is thoroughly thought out and planned. Your budget justification describes all your proposed costs, making it less likely that your company leaders will try to reduce or eliminate budget categories. The budget explanation will also help you gauge when you are over or under spending.
|Questions to consider|
Step 6. Build a business case
Your business case will be different than your case for change. The business case focuses on your financial requirements and incentives for the project and includes documentation of the project proposal, outline and strategy. It is a way to prove to your stakeholders that the solution is a reasonable investment.
The business case also aligns the project with your organizational goals. Preparing the document requires an assessment of:
- The business problem or opportunity
- The potential benefits and risks
- Cost of the project
- Potential software options
- The project timeline
- The potential impact on operations
- Your organization's ability to deliver the desired outcomes
A standard business case outline includes:
- Executive summary. Provides an overview of the business case's main points.
- Project objectives. Includes the project's current status, benefits, risk assessment, limitations and required resources.
- Implementation plan. Answers questions such as: When does it start? Who needs to sign off? Who is responsible for overseeing the implementation?
- Financial assessment. Provides an estimated budget for how much it will cost to complete the project by a set deadline.
- Project governance. Explains how the project owners will make decisions and monitor progress throughout the project.
Note: Taking your time to create a well thought out and detailed business case will save you time later in the process when you create a statement of work (SOW). The two documents have many similarities but are used for different purposes.
If necessary, you should also take this time to develop your procurement plan. This document provides you with an estimated timeline for the project and helps you manage the vendor selection process. Larger enterprises and government agencies must provide procurement plans specific to their needs. However, most smaller businesses do not need to create their own plan; it is likely the department head or chief technology officer (CTO) has already created a fiscal procurement plan for technology refresh initiatives that can be consulted and copied.
|Questions to consider|
Step 7. Research possible vendors
You can use a variety of tactics to find and research potential vendors. Maybe you ask for referrals from other businesses that are like yours. Or perhaps you turn to the variety of information available on the internet. People who have bad experiences often share their negative feelings online. Discovering this kind of feedback can help you immediately start to narrow your list of possible suppliers.
Websites such as Gartner, G2 and the Better Business Bureau offer databases where you can find a variety of vendors and trustworthy reviews. Other sources, such as blogs, user groups and LinkedIn groups can provide even more reviews from customers who have worked with a specific vendor. A simple internet search for news or reviews related to the vendor can also return a lot of information about the company -- both positive and negative.
You can also narrow your search based on the needs and budget determined in your previous steps. Do you want an off-the-shelf product that's ready to go? Or are you looking for something that's a bit more customizable? Which vendors offer products that fit in your price range? Considering these factors at the beginning of your research process will help you immediately eliminate some vendors, thus focusing your search and helping you find more accurate options.
You may consider taking advantage of independent consulting firms or specialized market research companies that have experience doing this research. While this approach costs money, it could save you time because the consultants and researchers most likely have ready access to the information you're looking for.
Another option is sending a request for information (RFI) out to a few vendors, asking them to explain how they can meet your requirements and expectations. This can clear any confusion created during your own research and illuminate features that you wouldn't have noticed searching the internet.
|Questions to consider|
Step 8. Evaluate vendors
Now that you have identified your problem, determined the outcomes you want to achieve, researched possible vendors, built your case for change and defined your budget, you are finally ready to begin evaluating the potential vendors.
Note: If you organization requires it, now may the time to send out your request for proposal. The purpose of an RFP is to ask for bids from vendors who match your project requirements and to start to determine which of these vendors is the best option. You will likely need to submit an RFP if you work in a large enterprise or government agency. However, if you do not have the bandwidth to do so, then you can delay the creation of your RFP to later in the process -- before you create your shortlist.
Going into your vendor evaluation, it's important to keep in mind why you're looking for a new provider. Remember the problem you identified in step one and the desired future state you created in step two. Keep this in mind as you start to judge each vendor.
When evaluating suppliers, it may be easiest to consider them based on four traits:
Cost includes a lot more than what the vendor charges for its software. You should also look at:
- your resulting time and labor savings;
- your cost savings from optimizing work processes;
- the cost of dealing with a vendor you can't trust; and
- the cost of working with a vendor who has a bad reputation.
Make sure each vendor provides you with a comprehensive description of their pricing structure, including every line item cost. This includes additional travel charges, maintenance fees and administrative expenses.
You should also always look for hidden costs. Some vendors may charge additional fees for in-person training or document management services. You may also find that vendors charge for both annual maintenance and monthly support. Keep an eye open for any arrangements that allow the vendor to increase their fees during the contract as well as provisions that allow you to break the contract if the service or product isn't working for you.
If you find yourself working with complex contracts, it may be worth investing in an attorney who can provide legal assistance by reviewing and translating the documents for you.
When considering capability, don't just look at the vendor's ability to complete the job. Consider the company's track record and whether you can trust them to continue doing the right thing even when you aren't paying attention.
Look at the vendor's experience. How long have they been in business? What sort of reputation do they have?
You should also consider the level of support or customer service provided by the vendor. This may be based on how they categorize you as a customer. Determine if you're an enterprise customer or a low-priority customer; this will likely impact the amount of support you receive. You're going to want to know if you'll have access to resources such as an implementation manager or if you'll only be provided with a toll-free help number. The company's ability to support you will affect your overall experience and success with the software.
While online reviews can be helpful during the initial research phase, you should now ask each vendor you're considering to provide you with at least two references. If they're unable to do so, then you should probably cross them off your list.
You should try to talk to customers in the same industry as you or with similar implementations. Ideally you would be able to talk to a newer customer and a customer that is more established with the product to get different perspectives of the vendor.
Below are some sample questions you might want to ask the vendor's references:
- How did the vendor address your specific needs?
- How were the employees to work with? Were they professional?
- Was the vendor on time for appointments?
- How responsive was the customer service team? Did they seem knowledgeable?
- If an error occurred or something broke, was the vendor quick to fix it?
- Was the company able to customize their products or services to fit your needs?
- How scalable are the products or services?
- How would you rate the quality of the products or services you received?
- How would you rate the security of the products or services you received?
- Would you use this vendor again?
You will also want to know that the company is stable and will be around for the foreseeable future. Ask the vendor to provide background on the company and the software they are offering, including:
- A history of major and minor version updates.
- A product roadmap of new features and timing.
- Size of the product team developing the solution.
- Number of existing customers and how many match your industry.
- Trend of profitability.
Communication refers to how quickly the vendor responds as well as the ways in which it responds and shares information. Has it been communicating regularly, honestly and clearly up to this point? Is it too aggressive? Or maybe it doesn't communicate enough?
You'll likely want to work with a company that responds to all inquiries and communications within 24 hours or less. You need a vendor that is going to give you straightforward, clear and logical answers to all your questions and concerns.
Character is potentially the hardest trait to quantify when evaluating vendors. A good place to start is by considering whether your two companies align. What is the vendor's philosophy? Is it the same as your company's? Do you share similar ideas of how things should be done?
Try to get a sense of how the vendor operates. Does it work the same hours as your company? Is it just as eager as your employees to provide answers and get a job done?
The reviews you receive from references will also be helpful when evaluating character. How does the reference describe the vendor? How responsive was the vendor if after-market support was needed?
In addition, look for a vendor that really cares about getting to know your company and your long-term business goals and values. This will help increase the alignment between your two companies. It will also make it more likely that it will put in extra effort to make sure your business is provided with the best value possible.
Two additional questions you will want to evaluate are:
How much emphasis does the vendor put on training?
Your employees will need to be taught how to get the best value out of the new technology so they can continue providing the level of service that your customers or clients are used to -- if not better.
What happens to your data if you decide to stop working with the vendor?
Some vendors may refuse to return your data or they will try to charge you large fees to get it back. If your data has been encrypted, then it's likely you will have to pay the vendor something, but it shouldn't be a significant amount.
With all these considerations in mind, you can start to evaluate the vendors based on how they meet your requirements. To do this, transform your decision matrix into a feature requirements list that vendors can respond to. This provides each vendor with a standard format that they can use to identify what features are included, what requires development and what the product doesn't do. The vendor should simply add an "X" for each requirement in the appropriate column.
Below is an example of a feature requirements list:
|Feature requirements||Priority||Included||Additional cost||Custom work||Third-party solution||12-month feature release||Not in product||Vendor comments|
|Front-end platform support|
Each column can be described as such:
- Included. The feature is included in the software and does not need additional development.
- Additional cost. The feature is available as an add-on at an additional cost.
- Custom work. Application programming interfaces (APIs) or a development environment within the tool is available to you or consultants to solve for the requirement.
- Third-party solution. You can purchase add-on products from a third party to solve for the requirement.
- 12-month feature release. The company has a commitment to solve for the requirement within the next 12 months in a feature release that would be included as part of the product.
- Not in product. The product does not support the feature and the company is not committed to solving for this requirement.
Every vendor will have a position on what differentiates its product or service from another. You should give each of them an opportunity to respond openly in writing on how its offering is an advantage to your project goals.
|Questions to consider|
Step 9. Create a shortlist
Now that you've evaluated all your possible vendors, it is time to start narrowing down your choices. You might hear this referred to as the shortlist, the zone of consideration or a down-selecting list. In this guide, we'll continue to call it the shortlist.
To create your shortlist, you should identify the vendors that best meet your requirements and criteria. Sometimes this step involves simply determining the top-ranking vendors and moving on with the process. However, it is more likely that this step will include disagreements and debates between key stakeholders about who they believe is best overall.
It is important to consider each person's opinion when creating the shortlist. The new technology will affect all these different people in your organization in varying ways. You need to make sure your shortlist consists of high-ranked vendors who are capable of dealing with each role's unique concerns and needs.
You should also evaluate each vendor's quality assurance (QA) processes when creating your shortlist. It is important to confirm that you are receiving software from a company that is committed to producing reliable technology and has strategies in place to achieve this goal.
Once you've created your shortlist, you need to inform the vendors that you are either still considering them or that you are no longer evaluating them as an option. Vendors that have not made the shortlist should be told they're currently out of the running, but the information should be communicated in a way that does not entirely eliminate them in case any changes occur.
|Questions to consider|
Step 10. Arrange successful product demonstrations
Note: Before arranging your product demonstrations, schedule a short 15-minute phone call with the vendor's sales development representative (SDR) so they can prescreen you for the sales team and confirm that your company is a viable fit for their technology. You don't want to waste time considering a vendor that doesn't think its software can solve your problems or provide the services you need.
The product demos are your chance to really see how each vendor will work within your organization. One of the best ways to do this -- and avoid getting distracted by the vendor's marketing pitch -- is to present the vendor demoing with a real problem you are facing and ask it how its software would solve it. Also consider asking the vendor to show how it would solve any future problems.
You should also use the demos to get a better sense of how the vendor will integrate into your company's culture. If you're a fast-paced business with employees who spend more than the average amount of hours working, then you will not want to work with a vendor that is more relaxed and only available on a 9-to-5 schedule.
To ensure you get the most out of each demo, consider providing the vendors with an outline that includes your current operations, projected future growth and various use cases for the software. This will likely generate detailed, informative responses and it will help you compare each vendor's demonstration based on how they answered your questions.
Below are some extra tips to keep in mind when arranging your product demos:
- Keep the invite list as short as possible. You'll want all the key stakeholders involved, but if you invite too many people, you risk creating unnecessary complications and chaos.
- If possible, get a trial version of the new software before the demo so you can test it out. This will help you ask more specific and beneficial questions.
- Make sure the vendor is replicating your system as closely as possible in their demo. Describe one of your major problems and several real-world use cases for important business processes beforehand. You may need to share some of your own data with the vendors to make this replication possible.
- Give stakeholders all the information they need before the demo and make sure they read it. Everyone should have a full understanding of the problem you're trying to solve, what the new technology is and why each vendor made it on the shortlist.
|Questions to consider|
Step 11. Hold a productive roundtable discussion
The product demonstrations have likely given you a much clearer idea of who each vendor is and what they will be able to do for your company. Now it's time to sit down with all the involved stakeholders to hear their opinions and start to move toward a final decision. But how can you do this in an organized way, so the conversation doesn't get too chaotic and benefits your process? You facilitate a roundtable discussion.
During the roundtable discussion, each stakeholder is given equal opportunity to participate and debate. You should evaluate and analyze all the information that you have gathered to this point. Give each vendor a score based on your previously created decision matrices.
To help guarantee roundtable success, follow these five steps:
- Clearly identify the discussion goal. In this situation, your goal is to decide on your new IT vendor. It is important to establish this upfront because it will become the basis of your discussion agenda.
- Choose a strong moderator. This person must be able to take control of the discussion, including setting the pace and tone; managing the group dynamics and process; and introducing new ideas to move the conversation forward. The moderator is also responsible for ensuring the discussion stays on track and efficiently reaches its final goal.
- Prepare a brief for attendees. Make sure all stakeholders know exactly what they should be discussing so the conversation remains productive and doesn't get held up on one issue. You can also give the moderator a more specific brief with suggested lead-in questions and discussion points. This will ensure they know where to direct the conversation if it starts to get off track or stops.
- Create an agenda. Every stakeholder should receive a copy of the agenda at the start of the discussion to keep them focused and informed. Your agenda should include a statement of the discussion's topic and purpose; specific questions you want answered or points you want addressed; a timeline for the conversation, including any scheduled breaks; key information, so time isn't wasted asking non-productive questions; and rules for the discussion that will limit unwanted behavior.
- Transcribe the conversation. Make sure you have someone available to record the major points and decisions that are made throughout the discussion. Later on, you can share a transcription of the conversation with stakeholders to keep them engaged and informed.
|Questions to consider|
Step 12. Make a final purchase decision
With the information you've gathered from the demos and roundtable discussion, you can finally make an informed purchase decision. It is important during this step that you minimize your emotions and forget about any possible political positioning so you can make a decision that provides the highest value and is in the best interest of your company.
Note: If you're considering a SaaS option and did not test the software before the product demos, then you should request a free trial now to test the usability, features and benefits. It is best to know exactly what you're working with before you commit to a contract. Make sure to include end users in this trial and observe how they work with the new technology.
Just like when you created your shortlist, you will need to inform the vendors that you did not choose that you've made the decision and you are going with another option. These interactions should be respectful and complimentary. You do not want to eliminate the possibility of working with these vendors in the future if your current choice does not work out.
|Questions to consider|
Step 13. Approach contract negotiations
Now that you've chosen your vendor, it's time to sign the contract. However, before you do, make sure to discuss and define the key performance indicators (KPIs) that you will be using to track the new technology's performance. Establishing KPIs upfront will enable both your company and the vendor to know what must happen to make the implementation successful. This will, in turn, create a trusted relationship between your two companies that is more likely to last over time.
If your organization does not require you to create an RFP, then you should take this time to produce your statement of work. This document specifies the objectives and deliverables for your contract. Having this available when approaching your contract negotiations will ensure the vendor clearly understands what you are expecting of them. You can use much of the information your recorded in your business case (step 6) to create your SOW.
When approaching contract negotiations, it is important to think of the vendor as a partner instead of somebody you want to talk down to the lowest price possible. Below are some other tips you can use to prepare for the negotiations:
- Rank your priorities for the partnership and identify their alternatives.
- Understand what you need, what you want and what your bottom line is -- or what would cause you to drop the deal and walk away.
- Identify any time constraints you may have.
- Evaluate any risks or liabilities that could arise during the partnership.
- Try to do all the above from the vendor's perspective to understand what their mindset might be coming into the negotiations.
At this time, you should also consider whether you will need your new vendor to sign a non-disclosure agreement. An NDA is a legal document that protects any sensitive or confidential information you share with the vendor. Signing an NDA will prevent the theft of your intellectual property and ensure your vendor is not leaking your secrets to your competitors. You may also hear an NDA referred to as a confidentiality agreement (CA), confidentiality clause or confidentiality statement.
Within the NDA, you should clearly define what qualifies as confidential information. You should also outline the penalties that the vendor will face if the agreement is broken. This could include payment for lost profits or even criminal charges.
|Questions to consider|
Step 14. Reflect on the decision
You've chosen your vendor, negotiated and signed the contract and implemented your new technology. The process is done, right? Wrong. Continuing to monitor and consider the success of the new software is almost as important as choosing the right vendor. It's called reflection.
This is where the KPIs you defined before signing the contract become helpful. Your KPIs are a helpful way for you, your stakeholders and your business leaders to determine exactly how well the new technology is supporting you and whether the vendor is satisfying its end of the agreement.
Even if your vendor has been completely reliable, it is still possible that it will make a mistake -- it's just human nature. Make sure to conduct routine performance reviews so these errors don't go unnoticed. You should also ensure the vendor has a direct contact point within your company so they can easily communicate any problems they're facing or notify you about other events that may affect your purchase decision.
Conducting regular performance reviews and continuing to reflect on the success of your new technology will also make your life easier when it comes time to discuss contract renewals. You'll know exactly how well the vendor helped you achieve your objectives and whether it will continue to be useful, or if you should leave the partnership and repeat this process all over again.
|Questions to consider|
Additional terms to know
Application program interface (API). Code that allows two software programs to communicate with each other.
Compliance burden. The administrative cost of a regulation in terms of dollars, time and complexity.
Deliverable (adjective). Describes exactly what is included in the purchase of a product or service.
Encryption. The method by which information is converted into secret code that hides the information's true meaning.
Enterprise resource planning (ERP). Software designed to integrate the main functions of an organization's business processes into a unified system.
Front end and back end. Terms that programmers and computer professionals use to describe the layers that make up hardware, a computer program or a website that are delineated based on how accessible they are to a user.
Implementation. The process of making software available for employee use.
IT procurement contract. A document that details the legal agreement between the purchaser of an IT product or service and the vendor.
Procurement card. A type of company charge card used for smaller purchases.
Procurement software. Can generate purchase orders, execute the ordering process online, match invoices to materials received and pay all bills electronically.
Procure to pay. The process of requisitioning, purchasing, receiving, paying for and accounting for goods and services.
Regulatory compliance. An organization's adherence to laws, regulations, guidelines and specifications relevant to its business processes.
Security posture. Refers to an organization's overall cybersecurity strength and how well it can predict, prevent and respond to ever-changing cyberthreats.
Software as a Service (SaaS). A distribution model in which a third party makes software available to customers over the internet.
Software license. A document that provides legally binding guidelines for the use and distribution of software.
Technical requirements. The factors required to deliver a desired function or behavior from a system to satisfy a user's standards and needs.
User interface. The point of human-computer interaction and communication in a device.