How to write an RFP for your Web Portal project

Whether your web portal project is about a corporate intranet, an online collaboration platform for researchers or an app designed to help members manage their data, you will most likely need to write an RFP to identify possible suitable vendors.

At Six Feet Up, we have been developing web apps for 20+ years. Most RFPs tend to be overly simplistic and generic. This leads to inconsistent responses, as well as proposals that are hard to compare - not to mention many contract extensions down the road to remediate the lack of initial details.

Here are some tips to help you write a solid RFP:

1. Start with "Why"

To echo Simon Sinek, you'll want to ask yourself (and the decision-makers) the following questions:

• What are the top 5 problems you want to fix?
• What will happen if you do nothing?
• What do you stand to gain with this project?
• What has to be true for this project to be considered successful?
• What will facilitate the project?

Once everybody is on the same page as to why you are embarking on this adventure and what you will build, then it's time to delve into the details.

If you are struggling to answer those questions or to achieve a consensus on the vision, we'll be happy to help. Consider scheduling a complimentary Vision Builder™ workshop. For more details, simply contact us.

2. Consider all the features you might need

Sometimes RFPs are blatantly missing key functionalities. Be sure to consider what you need for the MVP, but also down the line.

To this end, list the 5 problems the new system will solve and make sure to describe how the app will address each one.

To get you started, here is a list of common features in web portals:

• Secure user management
• Member vetting
• Granular permission management
• Chained publication workflows
• 3rd party system Integration (CRM, ERP, etc.)
• LDAP and/or Active Directory integration
• Search engine integration
• Faceted search
• Single Sign On (SSO)
• Notification system (email, SMS, etc.)
• Content export/migration
• Reporting/auditing
• Etc.

3. Think about "hidden" requirements

Some of your requirements may not be expressed in the form of features. Consider the following specs:

• "App must be accessible as defined by WCAG 2.0"
• "App must be responsive"
• "App must be fast"
• "App must be secure"
• "App must have a modern and user-friendly interface"

4. Decide "who"

It's fun to dream about the new portal and what it'll do in an ideal world. Details are initially fuzzy. It looks simple. Easy, even. It should take no time at all.

This is the curse of software development. Everyone, including engineers, usually underestimates the complexity of any new development. That's because the devil is in the details, and details don't show their ugly heads until you are hip-deep into implementation.

To avoid being burnt, you'll want to spend a good amount of time in discussing, developing and documenting user journeys as well as mocking up the various screens. This leads to the following key question: who will do this? You might have a designer on staff, but do you have a user experience (UX) team? Do you have a business analyst to question your thinking and help prioritize feature development? Do you have expertise in house to ensure your app is accessible?

If the answer is no, you'll want to be sure to add a Discovery and Planning component to the RFP.

5. Think about launch early on

Your app will need to be deployed to server(s) somewhere.

Here are some questions to ponder:

• Where will you want to host your new system? Will it be on AWS, on a private server on premises or somewhere else?
• How mission-critical is this new system? What is your target uptime? Will you need a full HA (High Availability) setup?
• What kind of backups will you need?
• Do you have expertise in house to provide managed services for the new portal?
• If you decide to outsource deployment and support, what are your expectations in terms of guaranteed response time and expertise of the support person?

6. Ask vendors about their approach

Selecting a technical partner is an important decision. You'll want to make sure it's a good match. Of course your vendor needs to be technically savvy, but you also want to make sure your values and processes are aligned.

Some key questions to ask:

• How long have you been in business?
• What's your area of expertise?
• What are your core values? Tip: compare them to yours
• How many years of experience do the people you will assign to my project have? Tip: don't accept general estimates like "a combined 100 years of experience"
• How many web portal projects have you launched?
• Which industries have you served? Tip: a wide variety of industries is as good as a focus on your industry
• Describe a few web portal projects you have rolled out.
• How long are your engagements on average?
• Provide a list of client references
• How do you approach software development?
• How will you keep us posted? Tip: consider "how" and "how often"
• What will you need from us? Do not underestimate your own involvement into the project
• Who will provide testing? Bonus point if they do!
• Will you provide delivery and hosting services? Bonus point if they do!
• What support options do you offer? Hint: some vendors don't support their projects.

This may look quite daunting, but this process is all about setting expectations right. Upfront research will save you from disappointment down the line.

Still feeling perplexed? We're happy to help. Consider scheduling a complimentary Vision Builder™ workshop. For more details, simply contact us.