Als SharePoint Business Consultant opereer je tussen Business en IT. Je adviseert klanten over de inzet van Microsoft SharePoint voor thema’s als ECM, collaboration, BPM, portals of search. Business cases werk je verder uit in functionele ontwerpen en advies rapportages.
Binnen het projectteam vertaal je het ontwerp naar een concrete SharePoint oplossing waarbij je gebruik maakt van diepgaande technische kennis van collega’s waar nodig. Je opereert nadrukkelijk aan de klantkant en bewaakt de functionele wensen en eisen van de klant gedurende de realisatie. Je overtuigd op kennis en ervaring m.b.t. SharePoint maar ook op bedrijfskundig niveau. Je zit aan de voorkant van projecten en afhankelijk van je achtergrond en ambitie vervul je de rol van lead SharePoint consultant of Projectleider.
Je bent ondernemend en naast billable werkzaamheden ondersteun je het management op het gebied van de ontwikkeling en positionering van Portiva. Bijvoorbeeld door het verder ontwikkelen van de Portiva eigen project en consultancy methodologie; genaamd Portiplan.
Portiva organiseert samen met Microsoft en enkele partners een aantal boeiende SharePoint seminars. De seminars zijn bedoeld voor directie,IT Management (CIO, CFO, CTO) Controllers en Business Managers. Met name de business aspecten en organisatorische voordelen bij de invoering van Portal oplossingen komen aan bod.
De seminars zijn bij uitstek geschikt voor organisaties die de implementatie van SharePoint op korte termijn overwegen, of al SharePoint hebben en hiermee verder willen optimaliseren.
De seminars met verschillende thema’s worden bij Microsoft in Schiphol gehouden. U bent van harte welkom op onderstaande data:
Maandag 21 mei. ’12 – Ochtend: Maak kennis met de veelzijdigheid van SharePoint 2010 – Middag: Een geïntegreerde CRM-toepassing met SharePoint 2010 als stevig fundament
Donderdag 24 mei. ’12 – Ochtend: Migreren naar SharePoint 2010. Welke migratie scenario’s zijn er + best practices – Middag: De kracht van SAP met SharePoint 2010, business scenario’s met Duet Enterprise
1. InfoPath or Not? – Browser vs Rich Client Does the user need to work with the form if he is not connected to the Internet? Yes: InfoPath is a good solution, it runs in the Client! – Do not try to replace Excel with a form – InfoPath is not a Data Reporting Solution InfoPath is good for data input, but not good in performance with output of a lot of data – Pixel Perfect Forms vs “Close Enough” – Your SharePoint infrastructure will be impacted especially with Browser Services
2. UI – Design UI wisely, keep Users Happy – use Views – build “tabs” to allow easy navigation – use database and web service for data connections – when roundtrips are necessary, let the user initiate the request via a button, so they expect to wait – use rules to deliver the data your users expect
3. Views Common Uses – Tab Navigation – Previous / Next Wizard – Confirmation Page – Separate Pages for Display and Print – Pages targeted to different audiences
Whenever a user has to scroll, you should use a new view Navigate to the View using a parameter in the URL: defaultview=[ViewName] Navigate to the View with the ‘defaultView’ WebPart property Use the OnLoad Rule to set view Remember: Views are no security Mechanism
4. Logic Types of Logic 1. Data Validation 2. Formatting (Colours, Show/Hide) 3. Actions (Buttons, Picture Buttons) 4. Default Values
Use Preview often Copy/Paste rules to save time Provide correctly formatted sample values Utilize OnLoad and OnSubmit rules Use Sandboxed Solution Code if rules are not enough
Forms Services Best Practices Design for performance – try to avoid postbacks – think long and hard about using custom code – be realistic about the size of the form and the number of controls – limit the number of richtext and file attachment controls – Monitor your environment, e.g. using Fiddler
What causes Postbacks – conditional formatting – Complex XPath – Out of Context Binding – View Switching – Multiple Binding, Datafield bound to multiple controls – unsupported functions (Translate, Position)
make nice pages for viewing forms try not to get user into the form library
#1. Dont under-estimate – it is very difficult to make an estimation for BI Projects!
Users (Roles, Methods of working, IT Experience)
BI Tool Choices
#2. Be Iterative – Deliver!
#3. Pick the Right Team – more than one person needed, more than “just” SharePoint People!
Skills needed in the Team
OLAP Cupe Developer
#4. Use Excel as starting Point – creates User Adoption
Start with Pivot Tablets to design Data
then use “convert to formulas” to break it free from Pivot (Data Connection will stay) and finish it up with Excel functionality, like
#5. Things to avoid
Don’t let the team get too big
Don’t have more non-tech than tech positions
Don’t employ contractors for core roles (they miss the care for the business)
Don’t work remote for majority of the week
Don’t communicate solely on IM – Speak!
Don’t use cut-back agile methodologies
#6. Understand the BI Toolset
– Chart WebPart – no sum or rull up functionality, not really adviced
– Status Indicator Lists – simple to build, only flat data sources, limited options
– Excel Services – popular, feature rich, lot of data sources, allows fine control over charts
– Performance Point – Best for OLAP Browsing, feature rich, interactive, limited customization possibilities, requires training, powerful dashboard capabilities
– Report Builder – Print Quality Reports, Unique Visualization, Geospatial Mapping, required training, can be used with SharePoint Foundation
– Power Pivot – multiple data sources, for Excel (Free), for SharePoint (requires additional licences), version 2012 comes with SSRS
– Analysis Services
#7. Know your Users!
Who are they?
What are their roles? (Analysists: browse data, Knowledge Workers: write queries, Consumers)
– Business Processes
…are the primary drivers of adoption
Technology alone is not the answer. The alignment of the business process and the users must be part of the adoption goal.
2. What did we learn about Adoption?
– adoption is impacted by design
– design requires the right people involved at the design phase
– trying to train every user heavily impacts the final ROI, there are untrainable users, so it must be intuitive
– Usability and Support go hand in hand, be intuitive and put support and the good spots in the system
– IT Administrators should not be Support, they should be busy building and maintaining the infrastructure, not answer end user questions
– Changing Design and functionality after going live heavily impacts user buy-in and ROI
– Adoption and Training must be measured
3. Master Plan
Pre Live Groups involved
Champions / Power Users (use workshops to see who gets active and understand what’s hapenning)
3rd Party Vendors
Post Live Targets
Supporting the User Base
4. Who needs to be trained?
At project Kick-Off
– Information Architects / Business Analysts -> SharePoint functionality and Limitations
– Technical Administrators / Developers -> Infrastructure Planning and Custom Development
Power Users -> SharePoint functionality and Limitations
– Web Designers -> Branding and Publishing
During Project Pilot
– Champions / Power Users -> SharePoint functionality and Security, 3rd Party Tools
– Content Authors -> Publishing Pages
– Selected Users -> SharePoint functionality / Usability
1 month prior to Live AND Post Live
– Users -> Workshops / Show and Tell, functionality – bite size such as search, introduction to the new environment
– Selected Users -> SharePoint functionality / Usability such as: My Sites, BI, Forms processing
5. Support Mechanisms
– Easy Acces, e.g. Ribbon
– Quick Help
– Just in Time
– How to video
– Show and Tell
– Knowledge Base
– Unified Communication
Support and Training are equally Important!
6. Measuring Adoption
Define what sucess is!
(Is it a lot of reading? Is it if they are writing?)
Define Audience Types
– power users – like to do things, explore
– technophobes – don’t want to use the system
– fearless adventurers – play around randomly
– hit-and-runners – are forced to use it, don’t look around in the system
fictional users based on interviews
give them a name and a story
Define Information Architecture User Experience
Which navigation objects do you want to use?
2. Make it pretty
early decisions to make:
– which browsers should be supported
– which screen resolution should be supported
– which office version is being used
– what is the user change resistance level
– what type of sites will be used?
– what kind of sites will be created: intranet, extranet, public facing, mysites
each type of site has different needs:
Different Site Templates use different css and classes -> define which templates will be used, to know which css to put effort it
Talk to the right people (usually marketing)
Listen to Users!
Take cues from users and stakeholders when it comes to: colours, layouts, fonts, features
Use corporate colours, it creates trust, which increases user adoption
avoid red and blue touching!
3. how to create design
If you have a strange feeling, don’t do it!
step 1: wireframes, separate functionality from design, good for usability tests
step 2: mockups, focus on colours and images, static pictures, only looking, no clicking
step 3: master pages, location of parts
step 4: css, colours
step 5: design page content, close together belongs together, the higher the mort important, important information without scrolling, fonts for emphasis, use sans-serif fonts they are easier to read
Give users the feeling that they get what they want.
Kinds of tests:
– Eye tracking test
– Click testing
– Usability testing, let users perform use cases
Important wiht testing:
– use users from different persona types
– use a controlled environment, separate room, separate time
– use actual content
International SharePoint Conference – Developing an End User Adoption Strategy
Information Architecture starts with the User: I Love Users
Information Architecture: structural design of shared information
Do not (only) look at their current folder structure
folders are easy way to put information, but makes it difficult to find
“If I store it, thats how I use it, but how do others use it?”
Key Components in defining Information Architecure
Content – what does exist?
Context (business, organizational) – why does the content exist?
Users – how does users use the content?
How to search?
Most people use the Google-Model
The users think: “I ask a question, magic happens, and the system gives the answer”
But this doesn’t work because
– users don’t know what they search
– users don’t know how they search (querries, spelling)
– users don’t have patience
There are different ways how people search
Users are looking for exactly one item e.g. a certain form – if the query is clear, search is usually good, since only a few results show up
Users are looking for everything – users don’t know what they search, so they have no expectations of the results
users kind of know what they want, but they are not really sure (exploratory) – usually queries are not good, because users don’t know how to get to the answer
users try to find something again
SharePoint uses the Berry-Picking-Model
How to learn from users
TALK to USERS, not management
…but remember: users don’t know anything!
…but remember: Opinion Right
Just because it’s somebody’s opinion, doesn’t mean it’s right.
…So, Instead look for patterns in the answers.
How to test user adoption?
Surveys – are not a good choice, only the people with strong feelings will fill it int, usually the ones that hate it
Wireframing – Usefull because it does not interfere with design
Card Sorting (http://boxesandarrows.com)
open: participants are given cards showing site content, no pre-established grouping
task: let them group
closed: participants are given cards showing site content, with an established initial set of primary groups
task: let them sort cards into groups
look for significance: the more people the higher the significance
Usability’s Quality Components
Learnability – how easy can users accomplish basic tasks?
Efficiency – how quickly can tasks be performed? (NOT number of clicks, but predictability, I know where to click)
Memorability – after a period of non-use, how easy can a user re-establish proficiency?
Errors – how many errors does the user/system make? how servere? can the user recover?
Satisfaction – how pleasant is it to use the design?
visibility of system status – do I know where I am?
match between system and real world – does it match natural flow?
user control and freedom
Consistency and standards
recognition rather than recall
flexibility and efficiency of use
aesthetic and minimalistic design
help users recognize, diagnose and recover from errors
help and documentation
Performing a test
– before, during and after
– with at least 5 users, not stakeholders
– define list of common tasks (find this form, go to this place and upload a document)
– run the test (& don’t help!)
– analyze and report
What to do with results
– use as proof for nay-sayers
– provide best cost justifications
– identify simple issues that when fixed will greatly improve user acceptance