In The Creative Balance Part I, I explained the different assumptions about SharePoint from the business perspective opposed to the technical point of view. In short, the difference is that the creative folks many times want to make SharePoint sing and dance and the technical team wants to leverage out of the box SharePoint. SharePoint can certainly sing and dance. The often uttered phrase, “I want SharePoint, but I don’t want it to look like SharePoint” most often refers to the aesthetics, not the functionality or the data entry screens. So, how do you explain the trade-offs that come with SharePoint to your creative folks as well as other business folks who have a passion for look and feel? If you find yourself in this tension often with the customers you deal with then there are three topics of conversation which need to be addressed with upper management. They need to understand these three topics at a high level and the tradeoffs. If you have upper management that listens and heeds your advice then you should get what you need to support a SharePoint instance that will “sing and dance.”
I want to preface this post by declaring that SharePoint is not a difficult product to enhance, style or maintain. I believe this dilemma of styling versus maintaing has spawned in how the SharePoint product line has progressed over the last ten years. People are used to SharePoint being a quick and easy way to build solutions and they’ve come to expect this for every instance. This same discussion would be had if we were using Drupal, DotNet Nuke, or WordPress. Organizations not mature in their software development lifecycle (SDLC) experiences may also fall into these conversation more than those organizations with mature SDLC processes.
* * * * * *
The first topic that upper management needs to understand is administration. Just like any system, the level of complexity requires a deeper level of support and knowledge to keep the system humming. If we’re talking about a system that services public customers or a large amount of internal customers then the expectations from the business for support will be higher. To offer a greater availability of support and knowledge you have to have a person who understands both SharePoint and the custom work that was done on the system. Also, if this is a high availability site with complex customizations or integrations then you should not rely on a vendor to support it.
Many times, companies will hire contractors on a retainer, but that doesn’t always mean that when disaster strikes that same contractor can leave what they’re doing and instantly tackle your problems. They may need to finish with the client they’re working with before they can assist. And let’s say they can’t make it for days or are on vacation. So, they pass it on to a colleague. With a highly complex site it isn’t feasible for that person to learn the system and then tackle the issue. That person may know SharePoint, but they probably don’t know the custom solutions, timer jobs, content deployment and so on. That is why it is imperative to cross train on highly complex SharePoint sites.
Custom solutions and features can also be complex and not every SharePoint system administrator knows how to correctly handle these. A feature may have files located deep in the “x” hive and deploying a solution demands a person with a keen understanding of deploying features to the correct web application, site collection and site level. I won’t pretend that I know anything about styling or themes in SharePoint. I just received Professional SharePoint 2010 Branding and User Interface Design in the mail today to learn and understand more. What I do know from experience with highly styled and customized SharePoint 2010 sites is that the more sleek they are in terms of UI design, the more complicated they are to maintain, update, troubleshoot and deploy (more on deployment later). We now understand from 3 year of SharePoint 2007 experience and now with a 1-1/2 years under out belt with SharePoint 2010 that it is a massive system. We’re only starting to scratch the surface within of all the intricacies it possesses. It is far too much for one person to handle in a large organization, yet I see it all the time. Large deployments with one or no FTE set the organization up for failure as well as the IT group.
* * * * * *