Our intranet was merely a SharePoint 2007 installation with several document libraries and lists and some random department sites. The look and feel was pure OOTB SP. So, some months ago we came up with this crazy idea of changing the status quo and building a new and real intranet portal.
We did this by starting an internal project. I don’t know how internal projects happen in your organization, but as I’ve seen my fair share until now I’m guessing it’s not much difference. An internal project is always “least pirority” for almost everyone involved. And it’s hard to change this as they are not perceived of generating any money (vs. any external customer).
With this in mind, we’ve set it up. Marketing was the project owner, somehow together with HR (“internal communication” is handled by Marketing in our world). We had a project manager / project sponsor (me). Each business division and department had a unique representant in the project, forming the full team of about 25. And there was also a core project team of about 6 (IT, content, design, strategy) to do the main work.
Here you can find some of my lessons learned from this project.
1. Make sure you know the organization
The person who leads the project need to know and understand the organization in & out. Building an intranet in which you aim to touch all departments, and generate valuable information for anyone in the company is a very complex undertaking. Especially if the company is quite large with multiple business lines and agile in day to day operations.
If the PM does not have this knowledge (say, s/he’s new to the company) then there must be a key project champion in the team which has it. And they must work very well together.
We scored very well on this. I’m with the company for many years now.
2. Decide and move along
We had a big team (imagine having status meetings with 15-20 people, some from management). You can safely assume that if 2 persons are involved, they will have 3 opinions. So, decisions need to be made by somebody and followed through afterwards.
3. Prepare the organization and communicate progress
The intranet has impact on almost all organization members. They must be informed that a new one is coming and expectations set correctly. This is also a motivator down the line to keep the project running and progressing, otherwise people will start wondering what happened.
4. Always keep an eye on the value to be provided
When building an intranet you will encounter many things which can or should be done. Always keep focus on the value (best is to make a checklist) which you aim to provide to the organization. Eg: enable people search, help people find their way through procedures, show the news, enable corporate wide communications, provide links to all relevant apps, provide a valuable search service (enterprise search with facets is a must in today’s day and age), integrate app XYZ…
It’s easy to sidetrack to building more and more web pages with content which would most likely mean nothing to 90% of the organization but is cool or nice for 5%.
The intranet should have an identity of its own. And must have a coherent design. Coherent with the company identity guide (if you have one, please tell me you do). My opinion is that it helps the portal to have a name of its own. It makes people adopt it better, imo.
An intranet is nothing without content. If one can make do without fancy “Web 2.0” stuff, it cannot succeed with an intranet without content. Users come to the intranet portal (voluntarily) for at least these reasons: find info about a person, find info about a department (eg: find what that department role is in the organization and who to contact from there), find document templates for day to day operation…
So, plan to allocate around 70% of the effort to the content creation part. Recognize that content cannot be generated by 2-3 persons, but needs to have this task distributed alongside all department representants. Make sure each of the department representant has the authority from the department head to collect and present the related content (this is a must, since sometimes departments will nominate juniors for this task).
How you organize the team to build the content in preparation for the portal, it’s up to you. One of the simplest ways is to make them collect the content in word / xls / ppt documents and put them in a folder structure resembling the final portal structure. Not so fancy, but easy to understand and do. And can be done in parallel with the technical implementation of the portal.
Please don’t forget the existing content (which may lay in the old portal, some fileserver…). It needs to be migrated. Plan, monitor and act. As in any migration… test test test.
Define a portal structure. This is where everyone should brainstorm to and then one needs to make a decision. Try to follow these guides: any somehow relevant piece of information must be no more than 2 clicks away from the main page, the main page must be clean and small, similar organization units must have almost identical portal structure (if someone enters a department/project/division/… page, it should see mostly the same sections as in other departments/projects/division/…).
8. Functionality – get a grip on technology. Early.
You can spend a lot of time building content and imagining the portal structure, but nothing will prepare you completely for the moment you face “the technology”. People who make content don’t really know what the technology can do for them. Even IT doesn’t know, believe me (we’re talking about SharePoint 2010 here).
We did it like this: define the structure and a design prototype. In these discussions the SharePoint specialists are involved also (even if the talk is mainly about business content and rules). Afterwards, put up a playground SP install, build some content templates, page layouts (based on the design), basic navigation structure… and let the content authors loose! You will find at least 5-6 of them (from 20+) who are eager to try and don’t mind that they will need to re-post the content several times. In this manner you will start to define your content editing and presentation rules. Ah, by the way: train the poor content editors before you leave them in ShP. A few hours of informal training will do wonders for the project.
When this playground time is done, you can gather all business representants, show them the intranet prototype, discuss the content rules and tell them to go to work: move their already prepared content into SP.
9. Have a passionate technology guy/gal
Only the SharePoint 2010 expert will know what he/she can do with it. The IT in general will not know. Why do you care? Because if you just treat SP as “yet another portal tech” you’ll end up with a dull intranet. SP has some great features but you need to know about them and use them in the business context.
So, make sure the IT guy responsible with implementing it is a heavy supporter of the project idea and wishes to innovate. Make sure he participates in all the project meetings and listen to the business explore ideas and requirements. You may need to pull him from the comfort corner where IT staff likes to stay, but it will be for the good of all.
10. Make sure you know what happens after go live
So now you’ve done it. You just created a living thing, under daily scrutiny from all the company employees.
Please make sure it works well (plan and act with IT to have proper maintenance and helpdesk in place) and provides continuous value (define responsible for recurring tasks to update the content, put in place procedures to add new information when certain things happen).
So, what’s this got to do with SharePoint 2010?
Well, we did it with SP 2010. I must say, I find it not very well-rounded. It serves the purpose but has some idiosyncrasies of its own.
Some good things:
- integration for the FAST engine – makes wonders for reviving that old search feature you had in the portal and about which everyone bitched about.
- my sites – gives employees a space to describe themselves
- content editing – with the proper templates in place, business owners can understand it and work with it ok
Some bad things:
- layout limitations – you have to go though many hoops to apply a not ordinary design. Or you need to make concessions on the design
- mobile access – terrible. On iPhone/Android/RIM…. almost forget it. IPad is tolerable (since it’s a full browser exprience more or less) but still doesn’t always work properly
Am I happy with how it went? Yes.
Did it cost an arm and a leg? No.
Can it be done better? Much better.
Would I recommend SP 2010 for an intranet portal? If your IT is Microsoft oriented and has in-house SharePoint skills – yes. Otherwise, it’s a long story.