July 20th, 2022 by inflectra
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.
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 following seven steps are typically followed for managing the vendor selection process:
In order to manage a typical vendor selection engagement, it is important to be able to manage the requirements such that:
Therefore, we recommend that you create a new dedicated SpiraPlan program for the initiative and create multiple projects in the program:
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:
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:
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:
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:
In this example, vendor A has the following replies:
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:
We'd probably recommend you disable the Blocked status in Testing Settings as it won't apply.
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:
This will then naturally lead onto the vendor qualification process, which is another use case that can be satisfied by SpiraPlan.
And if you have any questions, please email or call us at +1 (202) 558-6885
Are you looking for a platform that helps you deliver better software, faster?