For well over ten years, we’ve helped organisations select new technology platforms, for both intranets and websites. Our clients have ranged from huge banks, to government agencies and small retailers of construction equipment.
We know what’s in the market, we’ve created many RFPs (Requests for Proposals) and have seen countless vendor responses.
Across all of these projects we’ve shown that selecting a new platform doesn’t need to be hard — if you do it right! We’ve also seen many evaluations in trouble, struggling to proceed, or uncertain which solution to ultimately choose.
These are our five pro tips for successfully selecting a new intranet technology platform:
- Determine clear business requirements
- Look into the future, but not too far!
- Always assess at least three products
- Help vendors give you what you need
- Spend as little as possible on the technology
We’ll explore each of these in the sections below.
1. Determine good business requirements
One of the most common requirements we’ve seen written is “the platform must integrate with existing systems” (don’t laugh, it’s true!) This requirement obviously raises many further questions, such as: which systems? integrate how? to what end?
This is why it’s vitally important to write clear and meaningful business requirements.
In our work, we use our Intranet Building Block cards to help teams determine broadly which requirements they need.
Beyond these generalities, it’s then important to drill into the specifics, and to challenge every item.
Ask yourselves these questions:
- Have we considered the full scope of requirements?
- Do we really need this particular requirement?
- Are our needs simple, or complex? (Could they be made simpler?)
- Have we been specific on what we want?
Aim to write clear selection criteria, beyond general requirements, which will help you compare products.
3. Look into the future, but not too far!
Purchasing a product by considering only what’s needed today is clearly short-sighted. The danger is that as the business evolves, and your needs grow, you may hit the limits of the technology platform.
On the other hand, no solution is “for life”. Trying to guess all future requirements leads to buying a big expensive product that may not elegantly meet today’s needs.
We suggest planning on the basis of a 4-5 year lifespan for the platform. At that point, you may choose to continue with the solution, or to head in a different direction.
Having agreed on an expected lifespan, write requirements accordingly.
The pro tip is this: avoid writing a requirement that you can’t describe in concrete terms, or give a specific example for.
Without these details, it’s impossible to actually judge whether a platform meets your needs. It also opens you up to slick salespeople with promises of future capabilities.
4. Always assess at least three products
With the emergence of new SharePoint intranet solutions, and the resurgence of out-of-the-box intranet products, there are a huge number of products in the market. More are being added every month, as the industry pivots away from custom-built solutions.
The great news is that these dramatically cut the cost of delivering a new intranet, while addressing many of the risks involved in bespoke development. But one risk remains: picking the wrong product.
The key truth is this: the products in the marketplace are very different from each other.
Each product starts by solving one particular problem, and grows from there. Even when products deliver the same functionality, they can do so in quite different ways.
So if you’re looking at just one product, it’s too few!
We strongly recommend evaluating at least three products, to give yourself the best chance of finding the right solution. Evaluating several solutions will also build your confidence that you’re heading in the right direction.
If you’re located in Australia, get in touch, and we can help you with a list of vendors to approach, based on your requirements.
4. Help vendors give you what you need
There are two common traps when writing a request for proposal (RFP, or equivalent):
- Writing too much. 50 pages of detailed functional requirements were boring for you to write, and even more boring for the vendor to respond to.
- Writing too little. A page of general bullet points doesn’t give any clear idea of what you want, and definitely doesn’t help when comparing product capabilities.
Also remember that vendors are evaluating you, alongside your assessment of them. They’re choosing whether to respond, and how much effort to put in, based almost entirely on the documents you give them.
Writing clear requirements is a good start. Alongside this, provide the vendor with meaningful context about your broader strategy and what you want to achieve.
Make it clear what you are expecting back from them (hint: it shouldn’t be just “complies/doesn’t comply” responses).
Finally, put a “human face” to the selection process, as much as you can, allowing vendors to establish a meaningful relationship with you from the outset.
5. Spend as little as possible on the technology
As the Intranet Roadmap shows, there’s a lot that goes into a successful intranet project.
To name just a few crucial activities:
- determining a strong strategy
- restructuring and redesigning the site
- cleaning up and migrating content
- change management
- intranet governance
So our pro tip is this: spend as little as possible on the technology.
In our work with clients, we’re always able to provide a short-list of vendors that contains cheaper (but still great!) solutions alongside the “big name” offerings. In many cases, we’re able to save clients $100k or more, just through our deeper knowledge of what’s in the marketplace.
Just remember: spending more money doesn’t guarantee a better solution.
Spend the money you save on technology on the rest of the project, to allow you to make a bigger jump forward.
Need some help?
For 15+ years, our technology selection services have helped organisations of all sizes find the best product for them.
Drop us a line, and we’d be happy to talk through how it all works.