Using SpiraPlan for Vendor Selection & Management

July 20th, 2022 by Adam Sandman

We recently demonstrated SpiraPlan to a large, multinational life sciences manufacturing company. During the series of demonstrations and proof of concepts, we configured SpiraPlan for a set of different use cases, including demand management, application portfolio management, vendor selection and management, change management, application decommissioning, configuration management, and supplier qualification. In this series of articles, we will be highlighting these different use cases and providing best practices and ideas for how to configure SpiraPlan. In this article we will be covering the topic of vendor selection and management.

Vendor Selection & Management Overview

Successful organizations understand the importance of forming relationships with the right vendors. Many businesses make the mistake of choosing a vendor based on cost alone; however, this can result in more expensive problems in the long-run. A business should choose a vendor that aligns with their operations and shares similar goals. By being careful with vendor selection from the very start, companies can avoid potentially costly hassles down the road.

Vendor selection involves looking past surface-level sales and marketing gimmicks to see what the vendor really has to offer its clients. While a vendor may offer the goods or services that a company needs, customer service may be lacking, which will ultimately affect the vendor-business relationship. There are several ways that an organization can help ensure that the vendor they choose is able to meet or exceed their expectations.

The 7 Steps for Managing Vendor Selection

The following seven steps are typically followed for managing the vendor selection process:

Define and Analyze Business Requirements
Identify Third Party Vendor Candidates
Develop Evaluation Criteria (with weighting)
Conduct Vendor Briefings
Evaluate Vendors and Schedule Demos
Complete Vendor Selection
Complete Contracting with Vendor

Graphic depicting the 7 steps of vendor selection

Configuring SpiraPlan for Vendor Selection & Management

Creating Vendor Selection & Management Projects

In order to manage a typical vendor selection engagement, it is important to be able to manage the requirements such that:

There is a core set of requirements managed by the vendor selection team for the Request for Proposal (RFP)
These requirements can be viewed by the individual vendors that will be responding to the requirements and conducting demos
The vendors have their own workspaces where they can manage information specific to their bid / proposal

Therefore, we recommend that you create a new dedicated SpiraPlan program for the initiative and create multiple projects in the program:

One core project that will be used to store and manage the core RFP requirements
Individual projects that will be allocated to each of the vendors. In this example we'll have just two vendors for simplicity.

SpiraPlan workspaces for vendor selection

Furthermore, we recommend that you use a single, dedicated SpiraPlan template for all the projects in the program (including the one storing the core RFP requirements). That way any custom properties and customized fields will be the same across the programs. You will also want to associate the program itself with this standard template:

Now we need to setup the project associations and membership to ensure that the RFP selection team and vendor teams have the appropriate access and visibility.

Defining the Core Requirements for the RFP

In accordance with the standard 7 step vendor selection process, the first step is to define and analyze the business requirements. To do this, you will select the core RFP project and use the standard SpiraPlan requirements management functionality to create the core requirements that each of the vendors will have to satisfy:

Note that we have assigned the various requirements a priority rating. Typically you would define the different priorities so that the vendors will have an idea what the relative priorities are.

You can use the standard 1-4 scale that comes with SpiraPlan or customize it further:

In addition, you may want to create standard test cases in the various vendor projects which are mapped to these requirements to capture how the vendors will support each of the requirements:

Configuring the Project Associations and Membership

First we need to setup the Project Associations so that the core RFP project can share the core requirements to each of the vendor teams. This lets them share the requirements defined in step (1) with the identified vendors from step (2) of the vendor selection process.

In the example screen above, our vendor selection core RFP project is sharing its requirements with each of the individual vendor projects.

Next, we need to allow each of the vendors to be able to report back how their solution matches the needs of the RFP. We do this by allowing each of the vendor projects to share their test cases with the core RFP project:

Finally we need to setup the project membership:

Core RFP Project
- Read/Write Access by RFP Selection Team to requirements and test cases
- Read-Only Access by the different vendor teams
Vendor Projects
- Read/Write Access by the vendor team to requirements and test cases
- Read-Only Access to requirements and test cases by the RFP Selection Team

Vendor RFP Submission

Now that the requirements have been created, prioritized, reviewed, finalized and shared with the vendors, the next step is for the vendors to login to their own SpiraPlan projects, read the requirements and propose the solutions that will best satisfy the requirement. When a vendor goes to their requirements list page, they should choose the option to show requirements for All Products, so that they see both the core RFP requirements and their own specific answers to the requirements:

Then each of the vendors can use the test case module to write their responses to each RFP requirement, using the test execution status to describe how well each requirement is met by their solution.

For example, if we have two vendors:

Vendor A Submission

In this example, vendor A has the following replies:

Vendor B Submission

In this example, vendor B has the following replies:

In the Actual Result section, the vendors can write how they are going to meet the specific requirement needs.

The following methodology should be used:

Passed = The requirement was fully met
Failed = The requirement was not met
Caution = The requirement was partially met
N/A = The requirement does not apply (explain why)

We'd probably recommend you disable the Blocked status in Testing Settings as it won't apply.

Vendor RFP Evaluation

Finally, the vendor evaluation team can look in their project to see how each of the vendors scored against each question:

In this example you can see that Vendor A met the requirement whereas Vendor B did not.

You can then run the Requirements Detailed Report if you want to get this information in a consolidated printable form:

Once the vendor selection is complete, we can then begin the contracting and procurement process. You can use the SpiraPlan document repository to store and manage the various contractual documents from the different vendors as well as the central RFQ documents: