It’s that time of year again: We find more requests for proposals (RFPs) in our inbox during the late summer and early fall than any other time of year. RFPs vary dramatically in length, complexity, and level of ambition. In a spirit of cooperation, allow me to make some suggestions about those RFPs, and about the procurement process in the large. Begin by singing the next line to the tune of The Beatles’ “Revolution”.

You Say You Want a Portfolio Management Software Solution

R&D portfolio management software tools are very useful, but they won’t take the place of an effective process for project valuation, communication, and portfolio decision making. When deployed in the context of an existing process, a portfolio toolkit can reinforce that process and remind users what comes next. We recommend that you clarify what you are looking for by asking your team the following questions:

  • Process-related needs: Are you happy with
    • your process for building a business case?
    • your current project review meetings?
    • your current portfolio review meetings?
    • your process for governance and decision making?
  • Tool-related questions: Are you happy with
    • your current valuation methods? Why or why not?
    • your ability to manage risk at the project and portfolio levels?
    • your ability to update portfolio views with new project information and alternative deployment scenarios?
    • your ability to construct alternative portfolios using ranking, prioritization, and optimization methods

We have helped clients to clarify both process and tool-related needs. We believe the needs are often nuanced and overlapping (for example effective management of uncertainties straddles tools and processes), so it is always worthwhile to clarify matters rather than narrowing the scope to a tool prematurely.

In your RFP, list all the process changes that you anticipate undertaking as you deploy a system. The vendors you engage with should be prepared to offer their support for these process improvements in the proposal. Just remember that process changes require considerable up-front research, consensus building, and refinement. These steps will have schedule and resource implications for the engagement.

Communicate Use-Cases and Requirements, Not Lists of Features

A list of general features (e.g., “can perform optimization”) will be checked off categorically by most vendors who have been in the space for a while. As a customer, you won’t have gained much by parsing the completed checklists. So if a list of features won’t help you differentiate the capabilities of each vendor, what should you do? Craft a detailed set of requirements. The flow looks like this:


Start with the Objectives

Why are you considering an RFP in the first place? Perhaps you have a mandate to reduce portfolio risk, or add more valuable projects to the portfolio. Try to think about the organization’s objective here; it may be true that you were asked to “implement a portfolio process this quarter”, but

[we hope] there is an underlying rationale for implementing the process, such as a dearth of promising initiatives, or a need to cut the R&D budget by abandoning projects that are not relevant to the strategic plan.

Move on to the Jobs-To-Be-Done

Based on the objectives, look at what you do today in your project and portfolio processes.What is the job-to-be-done? Can you describe the job in substantial detail? Who is involved in the task, and what are their respective roles? Here are some example jobs:

  • Identify the bottom third of the ongoing initiatives to cut 30% from the portfolio budget
  • Accelerate projects when a lead opportunity is unexpectedly cancelled
  • Judge portfolio alignment against our long-range plan and fund specific activities to address the gaps
  • Develop a project business case, identifying key uncertainties and the steps to be taken to resolve or mitigate them

Make Your Current Scope Crystal Clear

Given the diversity of stakeholders involved in R&D, there might be two or more categories of jobs-to-be-done. Agree to focus on no more than two initially, with a road map to accommodate the others eventually. For example, initially you may want to concentrate on portfolio prioritization, then follow that up with more sophisticated project valuation with uncertainty, and move on to resource and capacity planning third. These three activities are closely related, but they have different implications for the breadth and depth of the supporting system.

Devise Use-Cases and Related Requirements

Next, it is time to unpack the jobs-to-be-done into use cases. These use-cases should consist of a sequence of activities that get the job done. Some of the activities might be performed with the help of software, and some may involve meetings where the software does not play a central role. Think about what makes the job hard in the present environment. Are the challenges situational, organizational, tools-based, or a mix?

Your use-cases should be detailed enough that the requirements are an extension of the use-cases. List the requirements in the context of each use case. If a requirement doesn’t support a specific use case, it may not be a real requirement.

Walk through Every Use Case

Sit down with each vendor and walk through every use case. Make sure you see the use cases demonstrated from start to finish. Allow the vendor the opportunity to suggest different methods for accomplishing the task at hand. Ask the vendor for demonstration accounts that allow you to walk the system through the use cases yourself. If you have difficulties, ask the vendor for a web conference to see the features again.

Shed Light on the Competition

Let the vendors know who is in the running for the project. They will have comments on the strengths and weaknesses of their competitors, in the context of your proposal, which will be useful to you.

Don’t Consume; Collaborate

Successful portfolio management requires effective software, but that software must strike a pitch-perfect note in concert with the organization’s processes and culture. There is a necessary degree of collaboration with the vendor that makes deployment unlike other applications; more than simply purchasing a tool, you are choosing a collaborator. Our most successful implementations are those where

  • The RFP demonstrates clear consensus about top requirements and deployment scope
  • Management is truly engaged and wants to encourage systematic, deep thinking about the risks and benefits of each opportunity
  • We are given an opportunity to collaborate with the client at each phase of the engagement, from clarifying the RFP at the outset, to crafting a portfolio aligned with strategy and effectively communicating that portfolio to management once the tool is deployed

I hope these points will help you refine your understanding of your needs, which will be reflected in your discussions with tool providers like us, and consequently lead to a more successful implementation. Please let me know what should be in the ‘buyers guide’ that I’ve neglected to discuss today. And to save you some time, here is where you’ll find information about our portfolio management software!

Read more:

Keeping things simple: Preventing Your Portfolio Management Software From Taking Over 

Strategic R&D Portfolio Management vs. Operational Capacity Planning: A Tale of Two Disciplines