As a SharePoint Architect, you’ll define a policy concerning the management of sites or at least will have an input to it; and whatever policy or process that comes from that is not called Tech Support – it’s called Business Content (content hierarchy) Support – meaning management of content and structure.

Effectively, I would assume that it is the responsibility for those who own sites to own sites. So, if you are Site Owner and there are subsites, you own those subsites. This means that users of those sites would seek you first if there is a problem on that site concerning say access permissions etc. However, you are an owner of the parent site and that parent site includes the subsites under your direct control and others. You are therefore responsible in the same way for that root site and that cascades to every site in that tree whether you ‘control’ them or not.

Top level root management of a site means you are responsible for the subsites. Hence, if a user in a subsite has a query concerning site administration they could of course seek your aid or you would pass it up the tree to me for advice and resolution.

As site owner you carry out the responsibilities concerning content structure for your sites and subsites. The knowledge you cascade and/or the aid you provide is based on the agreement you set with those who need to collaborate on your sites.

Some sites have adopted a rigid approach where they have defined people responsible for looking after the site. Some have left a more open approach where they have a large number of people accessing the site and only one looking after it. The key thing here is that those who originally requested the site are still there either (a) looking after it or (b) have defined the rules as to who is looking after the site.

As a SharePoint person, you will face queries concerning How Do I and Can SharePoint Do and What Rules does SharePoint pushed to you. One way you may have combatted that is to produce a centralised FAQ, but, at the end of the day its always best to show a face to Sharepoint and to answer questions that are beyond the reach or would take a while to get to. From a human perspective, that’s one of the purposes of what I call SharePoint Third Line. Why? Because SharePoint is unlike other applications in IT – it is a collaborative technology – it’s there to address collaborative and information challenges – it’s there to centralise what groups of people do. It’s there for people to Share content. Its only right they have shared knowledge in building that content. Therefore, IT people in applications are not the same as IT people in SharePoint.

However, as you may have guessed, no one knows SharePoint in its entirety; and it’s impossible for someone to know all of it. So, designing training sessions to ensure that those attending have confidence in doing the things that matter to them on their sites for their company, and emparting what they know to others as required. So, if they wish to learn HOW TO something all they need to do is drop a help desk call, and/or ask their site owner. If it hasn’t been asked before and valid it ends up, guess where, in you’re FAQ.

Of course, there will always be someone who can answer those questions beyond your remit or reach from SharePoint land who are there to help people create sites using best practice (not to actually do it for them). And in my view there’s no point in giving technical advice to solve business problems, because it will not benefit those trying to learn how to apply Sharepoint to their sites. Additionally, there’s no point in having a ‘person who designs sharepoint sites’ as a resource, because there would be no end and no beginning to the kinds of requests that person would get.

The key is education and training. Education; to ensure that those using your sites, are aware of the boundaries for your group of sites in terms of support. What they can expect and how. Training; because there is no point having a site if you don’t know its purpose or how it should be used in the company it lives.