UltraVista project managers believe strongly in Requests for Proposals (RFPs) as a tool for companies to find the best products and services at competitive prices, but also as an evaluation method for finding that elusive "best fit". However, too often the RFP process is run by people who have never experienced the process before, either from the issuer or vendor side, and essentially don't know what to say or what to ask.
UltraVista project managers, business and technical subject matter experts have written huge number of RFPs/RFIs for submissions to:
MERX – for Government of Canada, Government of Ontario, Government Agencies
Public and Private Corporations Procurement Departments
UltraVista’s own website
Our simple six step strategy of writing a successful RFP/RFI will underlay the basics that prospective writers might need to create their own RFP and run a RFP process without too much frustration. We're going to use a Network Management System (NMS) design project as an example template, and we hope that would be a good foundation to extract the concepts one may need for their own projects.
Step 1: Researching and Defining Requrements
Before writing anything, we have to be doing our own internal homework of defining business and technical requirements. Otherwise, after receiving our RFP vendors will be calling back with tons of questions; we do not want to be scrambling to find answers in a short time which could then derail our timeline. Defining the project as best we can will enable us to pass that information on to potential vendors, but also receive proposals that are tailored to our needs (pricing and project plans) by vendors who understand the project they are bidding on.
For our NMS project, we have defined our business requirements:
- Pouring our soul into the Executive Summary
- Description of the existing production networks environment in details)
- Defining a Business Process Model (BPM) for the NMS:
"The Network Management System should be a scalable, application-centric platform that makes extensive use of state-of-the-art graphical displays to provide intuitive and powerful network management dashboards for network operations staff. By automating a number of complex and error-prone tasks, the management application raises productivity, improves accuracy, simplifies training, and reduces costs for operation centers. The NMS should support ready-made, comprehensive set of fault, configuration, accounting, performance and security (FCAPS) functions, inventory, provisioning, along with bundled customizable interfaces to most popular network elements, OSS systems and other management applications."
System must handle simultaneous receipt of events from any intelligent device, resource, or software entity. It must support the reporting of alarm conditions in a near real-time or scheduled manner.
Alarm Correlation and Filtering
System must handle efficiently lengthy alarm lists with robust capability to correlate and filter alarms.
Resource Status Displays
A single window should provide an efficient, graphical overview of the status of all managed resources.
Active Alarms Display
A consolidated list of active or “open” alarms compiled across all managed resources must provide an overview of fault localization and correction tasks that are currently in progress.
System must support industry standard protocols SNMP, CLI, HTTP or customer-specific messaging adapters to discover automatically managed resources and poll for updates to their configuration attributes.
Managed Resource Domains
Administrator should be able to group the discovered managed resources into a set of managed resource domains using a point-and-click interface.
Graphical Topology View
This consolidated topology view should display the configuration and status of the entire managed resource inventory.
Through a convenient, single-click operation, managed resources can be placed in one of several service states such as “working”, “unavailable”, or “standby”. This high impact operation confirms that the requestor has appropriate permissions before fulfilling the request. The following network resources should be provisioning-enabled:
|Remote Management||Optionally enables management of remote locations deploying Distributed Mediation Servers locally. The servers can correlate network data, forwarding relevant information to the central site. These servers support buffering to prevent network data loss and can even work on dial-ups.|
|Software Image Downloads||Provides a powerful facility to orchestrate the organized download of software images.|
|Data Collection||Scalable application architecture powers the simultaneous collection of measurements from multiple managed resources across the network.|
|Resource Configuration||Managed resources typically support a number of settable attributes including alarm thresholds, logical addresses, and device specific parameters like data rates. The user can set such attributes for a single managed resource or a group of managed resources.|
|Performance Computation||Collected data is analyzed, filtered, and aggregated to produce performance metrics that are relevant to the operations staff such as user-oriented transaction response time or service availability.|
Real-time Graphical Displays
|Intuitive line charts and bar charts provide operations staff with quick snapshots of the performance metrics over time.|
|Security Domains||Fine-grained control of access to critical managed resources is accomplished through carefully defined security domains.|
|Audit Log||A detailed log of all access permission requests and responses supports the analysis of resource usage patterns as well as attempts to breach access control.|
This is by no means an exhaustive list of the types of questions that vendors will be asking ones they get engaged. The more we know about your project, the better the answers you'll be able to give to guide the vendors into great proposals. Yes, vendors will also be asking questions we've never considered, so we need to be prepared to do additional definition work once we've received the questions from them.
The Telecommunication Management Network (TMN) framework has provided functional model for achieving interconnectivity and communication across heterogeneous operating environments and telecommunications networks. According to TMN model, the NMS system has been stacked of several system layers:
Network Element Layer
Element Management System
Network Management System
Operation Support System
Business Support System
The NMS should define how these layers interface with other, level hierarchy and interaction.
The communication between the EMS, the NMS, and higher level Operations Support System (OSS) is called Northbound Communication. Like any other communication between devices, this communication is also effected by protocols like SNMP, HTTP/HTML, RMI
Step 2: Defining a Project Space and Deciding on Distribution Strategy
The RFP work must have defined a project space on the corporate servers (Content Management System, SharePoint Server, and Shared File System) or the Cloud. The project space will be determining how we are going to be collecting information from vendors, providing updates and finally distributing and publish the RFP.
First, we recommend to create a project page or project site that will house the project overview, contact information, timeline, the RFP document itself for sharing, and all other project documentation that we need to share with cross-functional teams and vendors. We usually include a link to this repository (in most of the cases protected website with guest login) in the RFP and direct people to it as a central repository for the project.
Second, we also recommend to think or the profile of vendors whom we'd like to be bidding on this RFP. We have to decide if we only want to receive proposals from a specific number of vendors that we invite to participate (sole source or single source procurement processes), or do you want to open the process up to qualified proposals from anywhere (public bid). If we want limited number of predefined bidders, we contact them and ask to download the RFP documentation from the project space website. If we decided to go with a public bid, the best place for the bid publishing would be MERX website (merx.com).
Third, we recommend preparing the bidding conference to clarify and provide detailed instructions and respond to bid-related questions.
Step 3: Pouring a soul into the Executive Summary
We strongly recommend writing a very strong executive summary. The executive summary demands a whole different approach to writing than the rest of the proposal, one that balances efficient delivery of key information with a persuasive, well-substantiated pitch. Above all, the executive summary must demonstrate a clear communication of the project deliveries and capture interest and understanding of potential vendor's. A strong executive summary is crafted with the audience firmly in mind: busy decision-making executives interested in bottom-line if they can fulfill deliverables, not details. If that is not clear, they may drop this RFP and pursue others.
We recommend opening of your project space repository for access to the potential vendors. This might seem a bit obvious, like spending time giving them information about the organization, culture, marketing/branding efforts, any deadlines that need to be hit, a narrative of the project that we wish to implement... anything that will enable the best proposals to be written. If there are specifics we make sure to list them out. If we don't mention them most vendors won't know to include them.
Step 4: Creating a Reasonable Schedule
This step starts with creating a number of dates that we should include in the RFP timeline. For example, take the following schedule:
Based on our experience we prefer creating of a less optimistic schedule. Experience project managers with good procurement management background understand well that it take to move mountains to reach some schedule milestones. If we do not allow enough time for vendors to get and consume the information, they may select to drop this RFP priority and focus on something else. We highly recommend varying this schedule based on our specific needs. In our NMS example which involves running a complex software development project and receiving technically complex questions, you're likely to need more than 14 days to answer all of the questions and provide them to vendors. We provide time both before and after the Q&A deadlines for vendors to both pose the questions, but also take the provided information and create their final proposal.
Step 5: Identifying need from the vendors and proposal format
We must specify the information we need from the vendor which should be useful and meaningful, and to avoid a boilerplate template. Using the NMS design example, the following includes some of the questions and information you might ask and request:
Proposals should include the information outlined in this section; our ability to interpret and apply your proposal to these questions will factor into our decisions.
- Describe in detail the firm's proposal to address the requirements outlined in this RFP, including details such as technologies to be used.
- Provide a timeline for the completion of this proposal; if the project involves a multi-phase approach please provide approximate timeframes.
- Describe the fee structure and how the organization will be charged. The costs involved may be categorized separately as redesign, implementation costs, maintenance costs, and software licensing costs. Also include the firm's plan for post-deployment maintenance, support and upgrades including hourly rates for services.
- Provide a brief history and profile of the firm and its experience providing services for organizations similar to ours. Provide a list of the firm's clients comparable to our organization; include contact name, telephone number, website location, services provided and length of service.
- Describe the project process and methodology including sample deliverables from past projects of similar size and scope. Document examples of the firm's experience in designing/developing each of the project requirements.
- List the project team (including programmers and designers) and short biographies of each team member. If using freelancers or outside resources please indicate them as such; we reserve the right to approve/disapprove of selected resources. Indicate how many full time staff does your firm employ.
- All proposals must include a hosting solution, whether that solution is provided by the company or a 3rd party service provider. Please detail the cost structure, hosting platform, uptime statistics, location of the server, data backup and integrity plan, etc. Clearly identify additional costs incurred with a change in hosting site.
- Please provide an unsigned copy of your standard service contract for our review and any additional stipulations of which we should be aware.
- Please be sure to document experience illustrating expertise in:
- working with non-profit organizations and providing design services
- building websites that engage the users and encourage them to register
This is by no means an exhaustive list. Determine the information that you need to make your decision and what information will enable you to select the vendor that is the best fit for your organization and your project.
Step 6: Determining the RFP Evaluation Criteria
Last but not least, we have to determine if bottom pricing or per diem rates are our only evaluation criteria or we are looking for the best fit, best overall value and the best project for our budget.
Some possible evaluation criteria for you to consider:
- Is the company good at communicating with us, for both our needs and for their needs during the project?
- Is it important to us to have someone that can come in for occasional face to face meetings or is over the phone ok?
- Do we like the project examples we've been shown and can we easily see our project reflected in those examples?
- Do they seem to "get" us?
- Is their pricing and timeline reasonable and within our parameters?
- Did they educate us on how they will complete our project, the team that will be working on it, and the deliverables that will be provided?
- Is their contract something that we can agree to or will that be cause for concern? Have they adequately detailed the costs and payment plan so we know how we will be charged?
These are just a few examples of evaluation questions beyond the "is their pricing the most competitive", but they'll hopefully lead the enterprise to a vendor that is more than just a supplier, but truly a partner in the project.