I’ve spent the last few weeks working on a SharePoint portal for the researchers in my group. In some ways, I’m flying blind in terms of user requirements. Our collaboration is new and still coalescing. Plus participants are scattered all over the world and not readily accessible. I’ve been forced to fall back on developing the portal based on what I think my users need instead of collective actual requirements — never a good idea.
To compensate, I’m starting small and simple. We’ll be launching the portal with one small working group that’s working intensely on a pilot project to study BMI in Asian populations. With about a dozen researchers, the group is a good size for a first-stage launch. It’s big enough to give the system (both technological and human sides) a good test but small enough that we can handle any problems without beinv overwhelmed.
More importantly, it’s also a group that’s actively working on something. So instead of telling them, “Here’s a portal, let’s collaborate!”, we can say, “Here’s the portal and we have two tasks set up for you to complete that are crucial to our collaboration.” My experience is that users in our type of situation (i.e., not forced to use the portal) get overwhelmed by the depth of SharePoint and just give up. If they don’t see a specific purpose, they simply won’t use it.
We’ve limited our team sites to the basics, including a contact list, discussion board, calendar and a couple of document libraries. The plan is to start simple then introduce *necessary* new features slowly. A blog for the sake of a blog isn’t helpful. But a blog — which we call “Updates” because some people find blogs scary — that keeps all of our updates in one place is useful.
Given my tech-savvy user group and this focus on the users, I have high hopes that our launch will be successful.
