Back in April, I presented at the International SharePoint Conference held in London. One of the sessions was titled ‘We need a portal’. It was part of the business track, exploring how to run SharePoint projects
Embedded below are the slides I created for the business track at the International SharePoint Conference. Additional notes follow. (Please note: modified for Slideshare formatting with notes added and animations removed)
First up, establish why you need a portal. It should be to improve decisions and actions. But will it? How do people currently make their decisions, on the data alone? It’s rarely the case and an important consideration because if habits don’t change, there will be little return on investment from a shiny new portal. A great book for understanding how people make decisions is ‘Sources of Power’ by Gary Klein. Or for lighter reading, consider ‘Blink’ by Malcolm Gladwell.
Check whether it really is a portal that is required versus a platform. A portal takes a lot more planning up front than a platform and is more rigid. Platforms are often what is really required, with the flexibility to adapt to different solution needs.
Of the different types, there are four key categories:
- Information – news-centric, centralised communications, formal published content – ‘the official word’
- Data – analytics-centric, aggregating data sources, automated where possible, structured
- Search – activity-centric, seeking answers, mixed sources of content, formal and informal
- People – contact-centric, seeking knowledge when the answers can’t easily be found
Projects are often looking for a mix of all four types, under the label ‘Intranet’. Makes for an ambitious set of requirements and external factors, such as compliance needs, may trump all. It is important to establish priorities because resources are usually limited…
Key questions to answer when establishing requirements:
- Where’s the content – and what state is it in. Accessible? Well managed? Duplication issues? Ownership? Is it staying put or being migrated?
- And where are the users – multiple locations? How’s the connectivity? Language-barriers? And the big one – culture (and its distribution). Is sharing or hoarding encouraged?
What trends will alter the future portal? Will it be online instead of onsite? Mobile devices are driving the push for information to be accessible online. And touch-based interfaces are changing what the future portal may look like. Will there even be a future portal? Or is the device start screen becoming the new portal, listing apps and status updates.
With so many questions, where to start? Requirements for portal projects are rarely well-defined. They tend to be more of a visual back-of-the-napkin concept – “I want something like this”, than a well thought-out specification.
Start by establishing key business goals. Don’t be tempted into requirements just yet – requirements tend to be based on past systems and often miss opportunities for new ways of working. If the project comes with a set of requirements, find out who defined them. How confident are you that the key priorities have been understood?
Is it feasible to introduce a portal? Consider using personas and scenarios to visualise realistic solutions. Build a conceptual model and then consider resource constraints on that model. Personas and scenarios are great because they create a story that people can relate to far more easily than viewing facts and statistics. Try to use real people and case studies if possible. It creates stronger buy-in to the proposed solution and makes it much easier to tease out potential barriers, often not technology related…
And a key question when determining feasibility – what’s the alternative? There’s a reason why email and document folders are still in use…
The final question
Who is the stakeholder? A portal project will touch on so many different business and technology areas, you need a strong executive sponsor prepared to make some difficult decisions regarding resources required and processes that may need to change if the portal is to succeed.
This article was originally published on www.joiningdots.com