Thanks to everyone who came to my session at the Christchurch SharePoint User Group and Matt (Btw Matt is doing 1 post a day about SharePoint related development until Xmas!), and Gary for organising the event. This post is aimed at covering off some key points which I  wanted to clarify. I introduced a planning framework and wanted to clarify that I use this depending on various factors and the engagement that I am doing.

1. Initiation or Pre-deployment should answer questions related to your existing infrastructure and how you manage these. This is the stage where you will spend some time analysing your current processes and also how you may need to establish some ownership and guidelines to what you want to achieve in the longer term with your SharePoint deployment. Governance and Capacity planning can be a lengthy exercise if not scoped correctly. Remember that you are not going to set up the world's best SharePoint deployment but being practical about what you have today and identifying the gaps so that you can potentially address these.
   
   Governance Resources - The best place to start for Governance is the TechNet Governance landing page - [ http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx ]
   Architecture Resources - Again TechNet has content to cover all types of deployment scenarios - [ http://technet.microsoft.com/en-us/library/cc261834.aspx ]
   
2. Core Installation and Configuration – This covers installing and testing your architecture and ensuring that your SharePoint farm can service your business initiatives. A document should be outlined on how the install process has been carried out. Load and stress testing - Yes, you have to, this is one key thing that everybody misses after a core installation. This is the point where you can get an benchmark prior to deploying code and other configurations. It’s always the best point to catch performance implications after custom code has been deployed into your farm. Some may argue that you don't have to but I tend to benchmark the server once the installation has been carried out.
   
   Installation Guide for MOSS - [ http://technet.microsoft.com/en-us/library/cc298924.aspx ]
   Development server configuration for team development for SharePoint deployments - [ http://msdn.microsoft.com/en-us/library/bb428899.aspx ]
   
   
3. Configuration and Development – Now that you have a core SharePoint deployment now you can start configuring and adding custom functionality to deliver business related applications. This is where you need to ensure that your development teams follow guidelines on how to create and deploy applications for MOSS. You'll need an established software development process to manage code releases and test these accordingly.
   
   Administration guide – Usually it’s a wiki located in Central Administration site with clear and precise information about what should and should not be done on the server farm. This should also include what type of customisation's you should allow to be deployed. This is for your SharePoint server administrators to know how to manage the environment.
   
   Customisation Guide – This is very essential in terms of establishing what is customised in your SharePoint farm. Example: Custom code/BDC (Business Data Catalog) configurations and any other “foreign” artifacts that you introduce to your farm should be documented. Why? Because when you want to recover or move your SharePoint farm you will need these.
   
   Users Guide and Training – You can build the most extravagant portal but if your users don’t know how and why, why would they use it? Make sure that your business users get the correct amount of training by qualified trainers. Training can and should also be extended to the core Infrastructure team that carry out or are appointed to support your deployment.
   
4. Post Deployment – Establishing your SLA to the business and what is and is not supported is key to on going support. The Governance guide you created should have a section about ongoing maintenance and support scenarios that may be specific to your deployment. The recommendation is to have a regular review of your support process by a team of people (Governance Board) to ensure that service continuity is maintained. One key aspect of post deployment is how you maintain your farm by applying the required service packs and hot fixes when they are made available.
   
   Deployment of Service Packs - [ http://technet.microsoft.com/en-au/office/sharepointserver/bb735839.aspx ]
   Data Protection and  Recovery - [ http://technet.microsoft.com/en-us/library/cc262129.aspx ]

One of the key aspects that I believe that should be taken into consideration no matter how small or large your deployment is that you need to have an established requirements document that outline your business requirements. Then you can map these to your key cycles of your deployment. In one of my previous posts I highlighted some guidelines for Project Managers on how to approach a SharePoint project. I am keen to hear some feedback about this approach and happy to share some real world experiences in using the above framework. If you are interested email me on chandima 'at' chandima '.' 'net' or via the Contact me link at the top.