about a CMS that can drive a content manager crazy.  Case in point – I spent close to four hours today creating 30 or 40 essentially identical pages.  Leaving aside the pointlessness of needing that many pages on a single site, it’s probably not the most efficient use of time.  In the old days, working in plain HTML, I would simply copy and paste the text into a new file, make what changes I needed, and away we go.  Given what little I changed, I expect the whole business would’ve been done in half the time.

Instead I had to go in and add multiple webparts multiple times, and set the custom properties of each, publish the pages, and then for some reason I couldn’t use the built-in move features and I had to Windows Explore to get all the pages where I wanted them.  I’m quite certain there are ways to copy pages in Sharepoint; our tech folks were working on something but didn’t have enough time to get it all worked out for me so I did it all manually.  What I think it underlines is that Sharepoint is a complex tool, and it creates pages out of a lot of separate moving parts rather than a single lump of code.

So does this make Sharepoint a bad tool?  In some ways I think it does.  Simple things need to be simple if they’re going to work well for users and content managers.  Again, I know there are ways to do this, and given enough time and resources we’ll find it and all will be well.  But it does raise the issue of complexity and its pitfalls  (See Paul’s post on the subject for more).  There are many reasons to be able to do more things simultaneously; also many reasons to be able to do things in multiple places at once.  The complexity of databases that run Sharepoint and other DB-driven applications is a totally different paradigm, however, and it can overwhelm a content manager who just wants to get his work done.

On the flip side, if you can get the pieces in place and functioning properly you can do some tremendously powerful things.  I think the trick of it all lies in two things.  1) If you possibly can, get everything in place before your entire site goes live.  I don’t mean that one can thing of everything, only that if you can do an incremental rollout and make sure silly things like this are covered before a section or an app goes live, do so.  The more likely scenario is 2) accept that the first year or so after go-live will be a period of alternating frustration and elation.  A team’s entire work process will be impacted by these kinds of surprises, and this first year becomes a sometimes clumsy shakedown exercise.

but I’ve finally gotten to looking around at Sharepoint blogs and bumped into CleverWorkarounds, an Aussie blog written by Consultant/PM/Guru Paul Culmsee.  In comparison to the other Spoint blogs I’ve run across, Paul’s is much less technical and much more strategic.  His series on talking to CFO’s is clearly trying to bridge the gap between technical folks and the business side – a major interest of mine.  I’m adding CW to the blogroll, more to come if I find things that don’t focus exclusively on setting up SP Central Administration.

I had an opportunity to see someone else’s portal this week, and it was an eye-opener in many ways.  It wasn’t the design that blew me away (nice though it was), it was the breadth of truly personalized tools and information provided by their site.  This organization provides its many employees – well over 10,000 – with direct access from anywhere on their portal to almost anything an employee could want.

Name it and it was there – personalized benefits information, 401K elections, customized news, personal links.  I think it held connections to every piece of an employee’s work-related life and probably a dozen other things it never occurred to me to add.  The complexity behind this may be less astounding than I think right now, but I’m amazed largely because we have had such a struggle to get much more basic content added to our portal.  I think we’d like to do many of those things, but we haven’t been able to get the traction that this company has.

I think this will serve as a model for where I would want my portal to go.  I don’t imagine it’s perfect, I’m certain getting to this point was not easy for them, but this portal captured the strategic essence of an intranet:

• Get everything an employee needs synched in somehow with your portal – personal needs and professional;
• Give them the opportunity to customize their experience to suit their own needs
• Keep driving home the idea that the portal is meant to be the central repository for all information

Again, I’m not suggesting making this work was easy, but it suggests to me an organization that grasps the power of an intranet for the organization, and that someone in there had both the will and the elbow grease to pull it off.  Lots of people have to buy into this kind of approach, and clearly someone there made it happen.

Many decisions go into choosing what to add to a portal, and not everything will make it.  But clearly if you have the attitude that it can all be connected, you can develop a portal that gives employees everything they need to simplify their lives and work more efficiently.

So, yes, I was pretty impressed by it.

One of the other opportunities presented by a migration is the chance to review policies for users, guidelines, processes, etc.  In our case, I took the opportunity to actually write some.  I don’t know how other organizations do things, but we’ve had a seat of the pants approach up to this point.  There are good problems that come with growth and a reputation for getting things done – you start to find more people want to take advantage of the services you provide.  At some point, the old way of doing things isn’t acceptable anymore – you have to start managing your processes correctly or you lose control.

Hence the decision to try and get something on paper that justifies the limits that have to be placed on the site and the content managers.  It’s not that I want to limit anyone’s creativity or lock people into a rigid process; but the only way to beat back the hordes of people demanding complicated flash pages and hyper-customized webparts is to develop rules of the road.  Getting processes and design guidelines down on paper, and presenting them to your content managers BEFORE their sites are developed is preventive medecine.  It’s a way to preserve the look you want for your site, a way to settle arguments before they begin, and a way to rein in the occasional overkill instincts of clients.

It’s also a valuable thought exercise for the team that owns the portal – what are we trying to accomplish? How do we want to organize and manage these sprawling buckets of information (bad metaphor, I know)? How do we balance the desires of our clients with the need to maintain consistency throughout the larger site?  Perhaps most importantly, do we have an orderly process for developing and maintaining content, or does each site get created in a haphazard vacuum?

It’s a delicate task in some ways – you want to encourage creativity while still maintaining a look and controlling the workload so everything gets done.  I don’t know that we’ve settled all the issues in the draft we’re working on now, but you have to start somewhere, and these documents are meant to be living, changing things that adjust to new conditions.

Is a long time to go between posts; suffice it to say the completion of our migration and the birth of my latest child have both interfered and distracted to say the least.

So what have I learned now that we are a Sharepoint shop?  First and foremost, Sharepoint is not a CMS.  Oh, it was sold as one I grant you, but it is most definitely not a CMS.  A CMS represents a simple interface for users to add and update content without having to know any programming or HTML.  A CMS suggests that one’s content is templated, sliced, diced, and ready to roll without a lot of mucking under the hood.  Sharepoint is, unfortunately, not that simple.

What Sharepoint is in many ways is a frustrating experience for a site manager, especially one on the business rather than the technical side.  Though our tech people seem sometimes as frustrated as we are.  There are things that should be simple that aren’t; there are things that require multiple trips through the publishing steps to resolve; there are things that flat out don’t work.

On the flip side of these complaints, Sharepoint is a wonderful document management tool; there are some neat tricks like group by within the document libraries that have proven very valuable.  The ability to develop customized lists and reuse those lists elsewhere in the portal has been another great feature that both saves time and helps standardize subsites within the portal.  The team sites are great tools for restricted-access group collaboration that meet their stated purpose – provide anytime, anywhere interaction to a limited group of people.

So the takeaway from the migration experience is double-edged; we are undoubtedly a step up from where we were, but the sales job was not as honest as I think it should have been.  Don’t get me wrong – I like Sharepoint, and it’s becoming a common (if not necessarily a standard) tool within the industry.  I’ve learned an awful lot about the product in the few months we’ve been live, and I think we’re making it work.  But caveat emptor as they say – it’s not a CMS, it never was, and it never will be.  Know what you’re getting in to before you sign on.