"we need a portal..."
DESCRIPTION
Presented at the International SharePoint Conference 2012 held in London. Part of the business track, exploring approaches to SharePoint projects. In this case, starting from the business statement 'We need a portal...' The session looks at understanding why and how to approach building one.TRANSCRIPT
Sharon Richardson
Joining Dots
joiningdots.com
@joiningdots
BUS308
“We need a portal”
Slideshare Notes
This presentation was delivered at the International SharePoint Conference held in London during April 2012
The session was exploring the project scenario that starts with ‘We need a portal’ but little else in terms of defined business requirements. A fictional company ‘Fizz Oil’ was used as a case study to frame activities
Slides have been modified to fit Slideshare formatting restrictions (sadly, means losing some useful animations) and some notes have been added due to the absence of a presenter
More notes are available in a corresponding blog post http://www.joiningdots.com/blog/2012/08/do-you-need-a-portal/
“…Why?”
To improve decisions and actions
Sources of Power: How People Make Decisions
By Gary KleinPublished 1998
“…Why?”
To improve decisions and actions
Sources of Power: How People Make Decisions
By Gary KleinPublished 1998
Notes:
Helps to first consider what decisions or actions could be improved and how – answer should be about more than just implementing technologies
Gary Klein’s book is highly recommended. For lighter reading, try Malcolm Gladwell’s ‘Blink’ (references Sources of Power)
What is a portal?
A web portal is a web site thatbrings together informationfrom diverse sources in a
unified way
Source: Wikipedia
Portal or Platform?
Portal = aggregate multiple sources of
information for a unified purpose
Platform = framework with standard
features and services to build solutions
Portal or Platform?
Portal = aggregate multiple sources of
information for a unified purpose
Platform = framework with standard
features and services to build solutions
Notes:
Clarify terminology. People often say ‘Portal’ when what they really want is a platform, that may have a portal-like home page as the starting point but is tasked with delivering much more than the unified presentation of diverse sources of information…
Types of Portal
Information Data
SearchPeople
Information
Communications-drivenUnstructured contentManual (& formal) publishing
DataProcess-drivenStructured contentAutomatic updates
SearchActivity-drivenMixed content sourcesSeeking answers
PeopleContact-drivenConversations and linksMaking connections
How hard can that be?
Imp
ort
an
ce
Practicality
Priorities?
News
Dashboards
Search
Directory
Compliance
‘Know How’
Intranet
Imp
ort
an
ce
Practicality
Priorities?
News
Dashboards
Search
Directory
Compliance
‘Know How’
Intranet
Notes:
The main priorities are always requirements that are of high importance to the business. The amount of resources they will need to implement depends on how practical the requirements are.
If the focus is on ‘low hanging fruit’ – low importance and high practicality (easy to implement) – the project has a weak business case and probably lacks executive sponsorship.
Beware insufficient resources to achieve desired outcomes.
IN
Value?OUT
Miracleoccurs
“Good work! … but I think we need just a little more detail right here”
Resources?
EDRMS
KMSystem
CRMWebSite
WebSite
WebSite
ERPBespoke
DB
BespokeDB
FileShare File
Share
Where’s the content?
CRM
EDRMS
ERPFile
Share
BespokeDB
KMSystem
Access Standards Quality
WebSite
Connectivity, Bandwidth, Ownership
Notes:
Diverse sources of information. Often multiple instances, duplication and varying lifecycle management…
Where’s the content going?
Where are the users?
Location Language Culture
What about the future?
Online
Process Access
Anonymous Limited public contentRead-only
Create your own account
All ‘public’ contentLogin to participate/contribute
Request an account
Role defines access to ‘private’ dataCustomer, Partner, Employee
Online Identity When the Intranet goes online…
Mobile
Portal vs Apps
Where do we start?...
Case study: Fizz Oil
Business Goals
• Improve accuracy of exploration assessment
• Timely access to information for all
• Raise standards through shared experience, knowledge and working practices
• Integrate complianceNotes:
Beware bland requirements – drill down into specific business needs as much as possible
Challenges
Three companies in one
• Competing business priorities
• Multiple systems and content sources
• Different cultures, distributed workforce
Conflicting business goals
• Maintain Compliance vs Share Knowledge
“We need a portal”
Target priorities• Exploration Assessment• Social Network
Business Requirements• Remote access (increasingly mobile)• Real-time updates
Technical Scope• Central vs Distributed vs Cloud
Is it Feasible?
Personas
Scenarios
ResourceConstraints
ConceptualModel
Personas & Scenarios
FIO Petroleum geologist based in the Antarctic. Leading prospecting team for FIZZ
Zenith Geophysicist based in the Arctic and specialising in mitigation of natural hazards
FIZZ in bidding war to acquire rights to land in a location of high seismic activity
Prospecting team need to evaluate and make final offer…within 48 hours
Personas & Scenarios
FIO Petroleum geologist based in the Antarctic. Leading prospecting team for FIZZ
Zenith Geophysicist based in the Arctic and specialising in mitigation of natural hazards
FIZZ in bidding war to acquire rights to land in a location of high seismic activity
Prospecting team need to evaluate and make final offer…within 48 hours
Notes:
Personas help frame requirements – prioritising what matters, targeting business benefits, highlighting potential roadblocks - it’s never just about technology. Stories trump statistics for achieving project buy-in
Ideally, base on real roles within the organisation and actual scenarios that could be improved with better uses of technology
In this example – two companies have merged and there is a need to break down ‘in-crowds’ in each company to share knowledge – how to encourage people to seek expertise outside their traditional network of contacts
Conceptual Model (Simplified)‘as is’ ‘to be’
Conceptual Model (Simplified)‘as is’ ‘to be’Notes:
Visualise the current scenario ‘as is’ and the desired improvement ‘to be’ using the personas
This is a highly simplified model to demonstrate. Current system – two organisations are functioning indepedently and there is no single social network or corporate directory. The Blue team know an independent expert (Mr Yellow) who could be pivotal to a major business deal being managed by the Red team.
By creating a single enterprise social network, it becomes easier to find people across different teams with shared expertise and the network of contacts spreads beyond organisational walls.
What’s the alternative?
Next Steps• Wireframes• Process Flows
(Interaction)• Technical
Specification• Prototype?vs
What’s the alternative?
Next Steps• Wireframes• Process Flows
(Interaction)• Technical
Specification• Prototype?vs
Notes:
The sanity check – is the proposed ‘to be’ scenario feasible. In this example, the risk is that people will fall back on traditional and comfortable habits – email trails and individual folders of documents versus a social network and centralised knowledge repository. Care needs to be taken to balance competing requirement.
And if it looks feasible, beware devil in the details. The next steps are to flush them out through wireframes and more detailed process flows that lead to defined requirements and a technical specification.
Still unsure, consider prototyping and proof of concepts before committing full resources.
Wrap-up
When the business says ‘We need a portal’…
“We need a portal”
1. Define the purpose (portal ≠ platform)
2. Identify business priorities/commitment
3. Consider future demands and trends
4. Check feasibility of the concept
5. Confirm resource constraints
6. “We need a stakeholder”
Sharon [email protected]@joiningdots