SharePoint – The Spend, the Schedule, the Scope

SharePoint – The Spend, the Schedule, the Scope

A SharePoint Implementation combining a detailed Project Plan and Quality Plan allows you to capture key pieces of information; namely, the commitment to spend (i.e. what the budget is); the schedule (when it is needed by) and the scope (what is SharePoint going to solve).

If you are about to implement SharePoint and the client states a nebulous scope of a project on the level of “I’ll take all of it right now, please; as soon as you can” then that sounds like the client is ordering a meal at a fast-food restaurant. If that happens, take a deep breath, sit the client down and negotiate the scope. Ask questions that help you determine the client’s requirements and vision for SharePoint.

Ask questions concerning the budget the client has allocated, and not just to cover the cost of hiring project members. You should be sure that the budget covers the technical costs, such as the cost of servers, software, licenses, third-party products, and so forth. To determine the budget, you need to define the top-level scope and work out the basics of the SharePoint 2010 implementation.

Time framing the project is also vitally important. There is little point of doing the project if you have no idea when the client wants it completed. It is like being in a bar, ordering a drink, and saying to the bartender, “Just bring the drink when you are ready.” At that point, the bartender has no compulsion to bring you anything and your budget will linger for a long time without anything being delivered.

Make sure SharePoint fits the organizations client tools – are they using Microsoft Office or Open Office for example? I think it is probably one of the most important aspects of ensuring you have a proper scope and you don’t end up biting off more than you can chew.

Take this scenario, for example:

A client would like to implement SharePoint in an organization where there is a Linux-based environment. They are using Open Office and have been for the last 3 years. The client wants only the installation of SharePoint and training to use the product, and wants no productivity issues from the addition of the product. After some investigation, this requirement is deemed to more costly to the client. The investigation determined that extra servers would have to be purchased, additional software would have to be installed, training would take longer and become complex, support would be a challenge to implement, and so on. Before long, the client would be looking at a monster of a project, amounting to an organizational technology refresh.

I’m not saying that as soon as you hear “They use Linux!” that you should dash out of the door. What I am saying is that you have to clearly state in your Project Overview document what you intend to provide to the client. This means that if the client wants SharePoint 2010 implemented you need to list the parts of SharePoint 2010 you will implement, including any components that support its installation.

Check out more information concerning the production of SharePoint Quality and Project Plans in the book Managing and Implementing SharePoint 2010 Projects.

Build Template

Build Template

This is a SharePoint Build Template. It is designed so that you can record the content of the SharePoint installation in terms of its software, and refer to the documents that will guide the installation of SharePoint.
The Software Build Template is referred from my book, Managing and Implementing SharePoint 2010 Projects.

(more…)

Build Template

Content Control

This article is concerned with how the management of documents and data in a site related to the delivery of a SharePoint solution, thus allowing the control, storage and management of information related to a SharePoint delivery program. (more…)

Content Deployment – Whats the Best Way?

Content Deployment – Whats the Best Way?

Bunch of my friendly architects chatting over a significant number of beers and spirits, telling rather silly jokes got into a heated discussion on SharePoint Content Deployment. Hrm… Sounds like a punchline building up here – Anyway, it all went a bit like the ‘I went fishing and caught one this big but it got away’ scenario; highly amusing. After recovering I though mmm… sounds like a blog this; so here’s my take…

Before a little chat about what Content Deployment is, lets look at the options available to you:

1: Content Deployment Method

Using the Central Admin, create content deployment jobs to schedule the content that you wish to copy into the production environment.

http://blogs.msdn.com/jackiebo/archive/2007/02/26/content-deployment-step-by-step-tutorial.aspx

2: Third Party.

There’s a mass of products for doing this for example Quest , Content Deployment Wizard on Codeplex – the content deployment wizard is good (and its free ):

  • http://www.quest.com/sharepoint/migration.aspx
  • http://spdeploymentwizard.codeplex.com/Wikipage
  • http://www.codeplex.com

3: Coding.

You could write a web service or delve into the land of SharePoint Object Model coding, that scans the content of your staging environment and maps it into production – this is a big deal and a lot of work. If you’re not a developer be prepared to learn about SPSite, SPList, SPFolder and much more. If this grabs your fancy, and pretty keen to going it alone, check out the below link:

http://blogs.technet.com/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-1.aspx

Of course, you may have your own methods, but these ones work well for me!

The problem with Content Deployment – what do you deploy? Whats the scope? From where to where? Whats the reason for Content Deployment.

  • Use it to synchronise a Staging Environment with Production. For example, you have some new master pages you want to push into the new environment following a succesfull client test
  • You have some stuff on Production but want to test it so you push back that content to Staging
  • You want to ensure you have a backup of Production (yes some people do this) so you sync Production to a Backup SharePoint box (which sounds even crazier because that would have to be really really controlled )

In any case, a lot of careful thought needs to go into the provision of Content Deployment and Best Practice would be to analyse the requirements with the client (even if the client happens to be another tech team), trial it in a test environment then apply it to your staging / production environment.

Some links?:

Video: http://www.youtube.com/watch?v=8_Vy6a1sI_Y

Technet: http://technet.microsoft.com/en-us/library/cc263428.aspx

A Best Practices Blog: http://blogs.technet.com/stefan_gossner/pages/content-deployment-best-practices.aspx

Email Distribution Groups – Document Library Governance

Email Distribution Groups – Document Library Governance

Sharepoint has the ability to take incoming emails via Microsoft Outlook into a document library or calendar. For example, one could setup meeting requests via Outlook and send these into a calendar on SharePoint. Also, an email could be sent directly into a document library from Outlook. The reasons for this is from a document library perspective that there is a method of capturing key emails and storing them for policy / retention / compliance reasons.The email address used for these document libraries are created by the users – there is no ‘support helpdesk’ involvement – additionally, SharePoint doesn’t carry out cross-checking to see if an email alias has already been taken in another document library in the current or another site.
Site Management – Support, Education, Training

Site Management – Support, Education, Training

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.