Launching a new intranet is a major project, especially for large enterprises. One way to ensure that intranet planning goes smoothly is to use an intranet proof of concept (POC) as you develop your new platform. This article sets out the meaning of a POC in software development and explores whether you should use one to achieve your objectives.
Buying or building a new intranet can be a long, multi-stage process involving many stakeholders and checkpoints along the way. There may be initial research on software comparison sites, an intranet demo with different vendors, an RFI or RFP, technical consultations, and much more.
With so much at stake when planning an intranet, you need to know you’re getting a solution that will deliver. An intranet proof of concept is an extra planning stage that can help you better understand how the new intranet will look and be used by a variety of internal stakeholders.
A software POC is not always included within the sales process, so should you ask for one?
Proof of concept definition
A software proof of concept is a prototype or preliminary application that demonstrates how a new piece of software will ultimately work.
The ultimate guide to intranet planning
Produced during the early stages of development, a POC tests the feasibility of a concept and helps to determine whether a particular software solution can help solve a specific problem or meet general requirements. A proof of concept in software development can also help to identify potential risks and issues early in the development cycle.
A POC is developed with limited functionality and for a small audience. It is not intended to be a complete or fully functional product.
- Prototype version of a software application
- Limited functionality
- Used to test the feasibility of a solution before further development
- Used to identify potential risks and gain buy-in
What is an intranet proof of concept?
New intranets are typically set up in one of two ways; buy or build. An organization may invest in an intranet product that fits into its existing digital workplace or it use internal IT resources and external consultants to custom-build a platform — most often using SharePoint or open-source software.
Either way, before the final product is implemented and rolled out to all users, the intranet project lead and senior stakeholders will want to know that their investment is justified and that the platform can actually achieve its objectives.
As with a general software POC then, an intranet proof of concept should be a limited, early-stage version of the eventual application. It will likely feature a small of content (such as key pages), have limited branding, and allow a restricted number of users to experience the possible workflows.
- Early-stage intranet site
- Limited content, users, and design
- An optional part of the sales or development process
What is a proof of concept trying to achieve?
An intranet POC provides a targeted trial environment to accomplish specific objectives and understand how the platform will work in context.
Although it is not a standard part of the sales process, some very large organizations request a POC before they sign a contract with a vendor. This is more often the case for projects where there are particular use cases or objectives.
To know whether a POC is useful then, it’s important to be clear on your intranet objectives.
Objectives typically fall into one of two categories: generic and specific. When thinking about an intranet proof of concept, consider both generic and specific objectives.
Generic objectives
Generic objectives are high-level and may be difficult to quantify. They won’t necessarily be defined in business strategy, but they represent considerable potential for an intranet project and shouldn’t be overlooked in a rush to present ‘bottom line accounting’ benefits. These tend to have ‘soft’ measures or be broad in nature.
- Improve internal communication
- Increase collaboration between teams
- Drive greater employee engagement
Specific objectives
Specific objectives are precise and quantifiable. They may begin as a generic objective but go further by assigning a specific metric.
- Reduce the number of all-company emails by 70%
- Decrease IT workload by 50% by introducing a self-service knowledge base
- Improve eNPS response rate by 80% in 12 months
Although the limited functionality and usage of an intranet proof of concept will not be able to deliver these goals, it may be a starting point for discussion.
If you know, for example, that your organization wants to prioritize decreasing the number of help requests made to IT and HR, you can use a POC to test the feasibility of this.
What would your IT self-service knowledge base look like on the intranet? How easily could users access it? Can your IT team update the content or would it need support from another team?
Beginning with objectives may help to structure the intranet POC.
The benefits of an intranet test site
Here are some of the potential advantages to scheduling a software prototype into your buying or development process.
- Risk identification: One of the benefits of an intranet POC is that it allows an organization to spot potential risks. Although this is necessarily limited because of the small scale of the site, you can still use it to your advantage. If one of your key objectives is to have different workflows based on permissions, but the proof of concept site has no ability to provide this, this could be a risk factor to consider before investing.
- Engages stakeholders: A POC can help engage stakeholders, especially financial decision-makers, by demonstrating what the final product will look like. This can help secure support and buy-in.
- Improved communication: Circulating a report outlining a new intranet is important, but offering a select number of team members the chance to try the POC may be valuable too. By working with directly with the UI, for example, content authors can develop a better understanding of how they will be asked to use the platform.
Potential drawbacks of a proof of concept
As valuable as they may be in some circumstances, a proof of concept is not a standard part of most intranet implementations.
Why? Mainly because a POC adds more complexity to a project. Here are several factors to consider.
- Time and resources: Depending on its size and complexity, the preparations for a POC may take as long as several months. Not only will the vendor creating the POC need to spend time on the project, but your organization will also need to set aside time and personnel to agree and manage it. Some suppliers also charge for running a POC.
If the intranet proof of concept site is also constructed and run as part of a sales process, it is likely you will have several vendors creating them at the same time. This could add months to the timeline and may mean that your test users need to devote more time than they had planned for.
- Governance: Understanding who your stakeholders are, what they require from an intranet, and then involving them in the POC is essential if you are to ensure organizational buy-in for your project.
Most POCs involve the following areas, so you will need to identify and enlist the support of relevant stakeholders associated with each area. They will require briefing, training, and communications about the project and their role in it so they can assess the POC appropriately and provide feedback on its relevancy:
- Internal Communications
- Project Sponsor
- Legal / Procurement
- IT Stakeholder
- Information Security
- Marketing
- HR
- Users
- Feature relevancy: Most intranet platforms will have a significant number of features, and some will be more important to you than others at this early stage. A POC will be restricted in the number of features available, so it is important to identify those which will perform a critical function in order to receive a true demonstration of the platform’s ultimate feasibility.
- Evaluation: Do you know have to accurately grade a POC in a way that will be most useful for your organization? Every stakeholder will use the platform in a different way and will have different ideas about what success means, so how can you get them all on the same page?
How to get the most from a POC
As with any implementation project, preparing effectively for a POC will help you and your stakeholders get more from the experience.
Follow these steps to ensure you find out all you need to know about the product in the time you have to trial it.
1. Keep to a restricted time period
It’s likely you’re assessing solutions from multiple vendors, so your POC with each vendor may run concurrently or sequentially. Have you got a month for five different vendor POCs? It’s worth bearing this in mind when planning the timescale of your procurement period.
2. Limit the number of stakeholders
If you don’t want the POC period to take longer than necessary, it may be wise to limit the number of users. However, it is worth including as many stakeholders in your procurement process as possible to ensure everybody involved understands the value and functionality of the product. Can it do what their department needs?
3. Plan user journeys and permissions
It is important to consider the role each stakeholder in the POC would eventually play in a full intranet, and how this cascades into the permissions they will be given. Stakeholders who will be intranet admins should be given the appropriate permissions for the POC, while others may not require the same permissions and will instead test the product as an end user. You do not want a POC where everyone is testing all the same features or user journeys as this would not reflect the end experience.
4. Identify what you want to test
What are the specific features, functions, and use cases you want to test? Do you need to understand how easy it is to post blogs on behalf of a senior leader? Is it important to have an end user utilizing employee recognition features? Ensure each of your stakeholders are clear what they’re assessing and have defined roles for the POC process.
5. Even a POC needs content
Set up test scripts for stakeholders to perform their roles. Having pre-defined pieces of content and interactions on the POC intranet will increase efficiency and give users a truer sense of the eventual experience.
6. Expect training
Even at the POC level, product training will be provided. This should include initial overview training with features, so you and your fellow stakeholders know how to use the POC intranet site and aren’t wasting time trying to figure out how everything works.
7. Be aware of a POC’s limitations
A POC will not represent the same experience as a complete intranet. The POC site will be a limited test set-up that allows you to perform certain functions, but it’s important to remember (and to reminder POC users) that the final product will be far more developed.
Do you need an intranet POC?
You might be surprised to know that it is common practice to procure an intranet without running a POC. In fact, the majority of organizations rely wholly on standard procurement exercises such as demonstrations, Request for Information / Proposal processes, and robust vendor vetting.
Although they can be an important testing ground for the largest organizations, if you have a clear idea of the functionality you require and the intranet business case you are aiming to answer, a POC is often simply not necessary.
