Should we find an intranet solution using an RFP?

Why choosing an intranet product matters

Enterprise intranet systems cover some important organisational processes and user journeys including internal communications, employee self-service, providing access to policies, facilatating search and much more. They can drive efficiency and productivity, underpin engagement and more.

Choosing intranet software takes time. There is a lot of choice in the market with products that have different strengths, price points and technical dependencies. The range of what is on offer can be overwhelming. However, you absolutely want to make sure you get the right solution that meets your requirements and your budget.

Although there is some overlap between different solutions, it’s a market where one size does not fit all. Getting the wrong solution can impact success, and that is why a vigorous and structured intranet software selection process is almost always worth the effort. An RFP for intranet process involving an intranet solution evaluation and an intranet vendor comparison can pay dividends.

What is an intranet product RFP?

An RFP stands for “Request for Proposal” and is a formal, structured process where an organisation seeking a particular product or service invites suppliers to submit proposals to a documented set of requirements and questions. An intranet product RFP is therefore a Request for Proposal relating to producing intranet software and any related implementation and consulting services. Sometimes an RFP is called an Invitation to Tender (ITT) which tends to be more detailed in terms of the requirements, but there is a lot of overlap.

A related concept is the RFI (Request for Information) which is a formal information-gathering process which invites suppliers and vendors to submit information, usually leading into the RFP. Sometimes there is more of an informal period of market research which acts a little like an RFI, helping a team get to know the market, inform their requirements and identify some key vendors to contact to invite them to participate in the RFP.

Context: A very brief overview of the intranet software market

There are a lot of options in the intranet software market and selecting the right solution can feel daunting. There’s the potential for the “tyranny of choice” to be a factor.  

SharePoint is the dominant base technology for intranets, but there are also a range of SharePoint accelerator intranet products that work alongside SharePoint that add value and arguably plug some of the gaps. There is also a mature market of standalone “in-a-box” intranet software products. Some intranet products have cross over with enterprise social networks or started off as employee engagement apps. You can even choose products which are more of a series of web parts or provide a specialist capability which can then be integrated into your intranet. Custom development is also an option, although most teams keep this as limited as possible.

The benefits of RFPs for intranets: why structure matters

Because of the sheer volume of choice, taking a structured approach to intranet product evaluation is key. Usually this will be through an RFP process or something very similar. A structured process helps to ensure that:

• Intranets products are reviewed and selected based on their fit to your requirements and strategic need, rather than on assumptions or opinions.
• All the right stakeholders who need to give input are involved and represented – remember intranets are almost always a cross-functional effort.
• You can align an intranet product to your intended operating and publishing model, a point that is not always realised and can really trip people up later down the line.
• You can ensure decisions are actually made around a timetable – rather than wasting months with discussions going round in circles.
• Most importantly you can procure software that is capable of delivering a world-class intranet that will delivers value for the short-, medium- and long-term, helping you to achieve ROI with your investment in an intranet product.

But is an RFP for an intranet solution the right approach?

But RFPs do have a downside. Running an RFP process can turn out to be very expensive. It can involve multiple stakeholders – including some pretty senior people – who end up burning a LOT of time. There’s documentation to be prepared and approved. Questions to be respond to. Demos to sit through. Detailed responses to be reviewed in microscopic detail. There are some additional costs usually associated with an RFP platform. Responding to the RFP is also expensive and time-consuming for your suppliers.

Many organisations that run an RFP do so because they are mandated to, either because of the sector they are in (particularly government and public sector) or because they have procurement and risk management processes in place.

It is possible you can avoid a lengthy RFP process, or at least run an RFP process that is still robust but streamlines the process. Ways this can be done include:

• Running an RFI before the RFP and then inviting a limited number of parties back to actually take part in the RFP, or helping the results guide the review of the RFP responses.
• Involving external consultants to give you an expert view, scope your requirements and carry out a product evaluation or give you a view of the market, so you know you get it right first time (said Spark Trajectory, waving at you).

Additionally, there are a number of challenges and pitfalls which we explore in more detail below.

What are the main steps of an intranet RFP?

Most RFP processes have a formal number of steps, but there will always be some preliminary work involved. Your organisation may also have a mandatory process. Here’s our view of the main steps, some of which will run concurrently.

1. Define your intranet strategy.
2. Engage with the market to help define requirements and get to know vendors.
3. Carry out an RFI, if necessary.
4. Finalise and agree your product requirements.
5. Agree the process for your RFP in terms of who is involved, your timetable the platform to use for responses, evaluation criteria and the main steps.
6. Agree RFP documentation.
7. Issue the RFP and inform any vendors you want to invite to take part (as long as this is allowed in your process).
8. Invite and respond to questions during the RFP process.
9. Review responses and carry out any further presentations etc.
10. Evaluate responses based on the criteria agreed.
11. Make a final decision and let suppliers know of the outcome.

Who should be involved in an RFP?

Intranets are ensemble efforts and project teams involved in implementations often span multiple support functions. At a pinch, an intranet RFP might include stakeholders from IT, Internal Communications, HR, a “digital” function, Knowledge Management (if applicable), Procurement and/or Finance. There could potentially be representatives from your leadership team, business units and operations across your business, depending on their activities.

These stakeholders will have different levels of involvement and may be interested at different points. Our old friend a RASCI matrix can be useful in determining who is involved and how. Too many stakeholders can mean you drive inertia. Too few means you can lack the consensus which can undermine the legitimacy of a project and effectively kill a business case.

What are the main points to consider in an intranet software selection process?

There are lot of different points to consider in selecting your intranet software. There are too many to go into detail here, but at a high level, the following will all come into play in an intranet RFP:

• Functional requirements: Ultimately does an intranet product have all your “must have” features and a healthy number of the “nice to haves” so it ticks the boxes on your functional requirements?  When we evaluate a product for a client, we always carry out MoSCoW to prioritise requirements.
• Non-functional requirements: These are all the qualities and characteristics of a solution and its vendor that make a difference, such as the support in place for the implementation and beyond, compliance around privacy and security, and even the financial independence of the vendor.
• Costs: It is critical to look at the total cost of ownership over time including any additional resourcing, infrastructure or software required, above and beyond annual licensing plus implementation costs.
• Testimonials: Getting some real-world insights from others who have used an intranet product is always very useful input.
• Gut reaction: This sounds counter-intuitive to our data-driven approach based on user research to scope your requirements, but you’ll also get a feel from meeting a vendor and trying out a product, that is really important. Does the product feel right? Does the vendor want our business?  Why do I have that slightly uneasy feeling about Vendor X or Product Y?

‍