I am Planning a SharePoint project - is it any different from typical software development projects?
A friend of mine asked me this the other day.. and I was glad that I was asked this question. (Let’s just say my friend was relatively new to SharePoint but have had years of managing typical software development projects).
From a pure Project manager’s view it can be seen that SharePoint projects are not different to any old IT project. BUT let me tell you that to successfully complete a SharePoint project you’ll need to think and plan a lot more outside of a standard software development Project. If you are a Project Manager who is “New” to SharePoint and want to apply your traditional PM methodology to deliver a SharePoint project then please take a timeout and head over to Paul Culmsee’s blog and read the series of posts on “Why SharePoint projects fail”. Paul points out all the reasons why sometimes the best efforts of Project Managers and strict text book process does not help with projects that are driven by technology enthusiasts who know little about actual drivers for using SharePoint and required change for SharePoint project.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/175/image4_2.png) And to be perfectly clear each SharePoint project is unique. Why? Because SharePoint can be used in many scenarios (See the infamous PIE? try defining what “Collaboration” means in a functional sense and writing a functional specification for an implementation.) and may have changes involved that may include developing and integrating of custom code and the core configuration of SharePoint itself.
Example : Your organisation is a medium sized enterprise with about 1000 users. You have a business requirement of using document management and collaboration software. Your primary means of IT project delivery is by partnering with a suitable or preferred IT supplier. (This is most common among most organisations). The typical process will be to list out your functional requirements forward these to a IT supplier or vendor, go through a selection process and appoint a project manager to come up with an estimate and project plan to deliver the project based on functional requirements. Fundamentally you may have chosen any product before or after you had written up and evaluated your functional requirements. Let’s say the business or the CIO has chosen SharePoint for a number of reasons and now it’s time to start the project. (So many things wrong on that which I won’t go into instead read Paul’s posts).
One of the main issues with this is that before you can start configuring or developing your functional requirements the actual SharePoint infrastructure deployment itself requires a plan of it’s own. Now put in a project manager or a business analyst who has been asked to give estimates and a task list for the functional requirements created by the business without having an understanding of how SharePoint infrastructure layer is deployed your actual work estimates and tasks are not going to match up. In a Project Managers world the functional specification is the system that is being delivered. Which for a SharePoint project may spell disaster however you may look at it. Well disaster not literally but some confusion as to why the project which was estimated at $XX,XXX originally has suddenly ballooned to $XX,XXXX. This usually means lot’s of meetings with various project stake holders to reset expectations that the wonderful picture that was painted by the SharePoint pie is now becoming very messy and losing its appeal by the hour. I’ve been asked to review a few SharePoint projects in my time that have gone off the rails and it’s always the same old story of “oh we wanted all of the features of SharePoint”. Read my previous post titled “Ambulance waiting at the end of the Cliff”.
So how do you as a Project Manager or Sponsor or vendor or Solution provider avoid this sticky situation?
Typically for my “Example” the organisation with about 1000 users who are relatively new to SharePoint and going to depend on SharePoint for document management day to day will first need to establish and validate a suitable system architecture to support such a deployment. Usually this conversation about the deployment architecture is best had with the organisations IT infrastructure team. I’ve heard many things over the years from business users which go on the lines of “Oh we have server racks we can put SharePoint on those!” or “We just spent $XXXXX and bought 5 blade servers”. However once you go and have a proper conversation with IT infrastructure teams and you’ll typically find that to properly support a two or three server farm you are looking at new hardware. Why? Well because the IT guys just bought the new stuff to use them for existing applications that needed upgrading. So now you need to buy more hardware and also buy software licenses for operating systems.
Anyway my point being, that you are better off actually budgeting for new hardware and when I say budgeting I mean that you will end up spending some serious money on hardware to ensure that your solution has longevity and redundancy. Then you also need to budget for actual technical resources that will setup and configure these.
If you are an IT Pro who has been asked to help a SharePoint Project or you are a resource that has been assigned to a SharePoint project at a technical capacity make sure that you can answer or ask these questions and get answers.
-
Is your Active Directory (AD) healthy? - Do you have a process to manage your end users details in AD?
-
Is your SQL infrastructure healthy, can SQL handle additional storage and redundancy?
-
What will your Web front end server infrastructure look like and will it handle your planned SharePoint load?
-
What is your Disaster Recovery and Business Continuity Plan and is SharePoint factored in as a critical service?
-
What storage capacity do you have and need including backup space?
-
What kind of performance do you get out of your network i.e. how long would it take to upload a 1 mb, 5 mb, 10 mb, 25 mb file?
-
Is there a solution like Microsoft’s System Centre in place to perform system reporting?
-
What is your current release management and testing process?
Thanks to Brendon for posting above questions..
The most important aspect of a SharePoint project is also the expertise that you may have internally to support and deploy SharePoint and manage the deployment on an ongoing basis. If you are using a third party solution provider you will need to ensure that once the project is completed that your own organisation can support and maintain the solution.
This is not an exhaustive list but some common most often missed steps when planning a SharePoint deployment.
One thing I always put emphasis on is that no matter what you are trying to achieve with SharePoint if you do not deploy and test your core infrastructure then your SharePoint deployment has a higher risk of not providing what you desire as per the PIE “features” that a lot of CIO’s have been sold on.
In case you were wondering what I mean by your core infrastructure here it is:
From all my endeavours and adventures with SharePoint projects one key thing I would say to any Project Manager is that throw out your strict RUP, Waterfall methods out of the window and try and be agile in your approach to a SharePoint deployment. You probably will not be able to write out a series of requirements in a requirements specification and give it to a developer to build, test and release in an iterative process. If you do and you are successful drop me a line I’d really like to hear about it.
Download and check out this Sample Project Plan for SharePoint and adopt it to your deployment. Note this just outlines the core deployment of SharePoint as a product and some high level tasks that are required for a core deployment of the product. If you are providing a solution (Such as a Web Content Managed site) with SharePoint as one of the enabling technologies then your plan will need to factor in additional tasks such as development etc.