SharePoint Notes from the Field "Planning"

Discussion in the last Blog Post was all about "Discovery" and in this post I wanted to move onto what I call the next step

It has been a couple of weeks and my apoligies, but some external issues had to be dealt with.

"Planning" which is often referred to as the Project Plan is so much more than just a simple "Gantt Char" and a timeline. If that was all there was too it then I wouldn't so constantly be seeking Project Managers and Coordinators who have some level of SharePoint knowledge. How often is it that we spend as much time trying to explain beyond the terms and delve into the basis that SharePoint is more than a "Webified" file share. If anything one of the largest failures here is to understand that this is not just a data migration, but with all of the "Discovery, Analysis and Rationalization" we are migrating a framework from one platform to another or even worse integrating the data from a disparate platform such as Public Folders and Windows Files Shares into this Framework for the Future.

We have reached the apex of what we know, what we have decided and for a realistic PM a set of guidlines delineating the in from the out. This has now come down to how strong you can be in controlling scope creep. limiting additional requirements and not falling off the IT cliff of Projects that never get done.

I often find that we are working with others in the SharePoint Community such as, "Dux Raymond Sy aka http://meetdux.com" or "Ben Curry aka http://benjamincurry.com" on how we don't have a Project Plan or we don't even have a SharePoint Implementation without some measureable goals that allows us to know if we have done our migration/implementation correctly. Meaning is there some measure of success and how did we measure success versus failure in these migrations. For the simple minded folks in SharePoint of which I am one, how do you know you are done if you don't know where the finish line is.

So again we have gathered all of the rules, guidelines, business drivers. We have reduced the data, branding templates and look and feel to somewhere between a bread box and the 2010 monolith. What do we do with all of that?

Success in this phase and for the project is going to be using what you know, what you have gathered so you can become the skilled project manager in pushing phases, timelines, communication and weilding the word "No" as required.

What should you be including and what should you leave behind are entailed as a few ideas following, but by no means a complete listing.

  1. The Team
  1. Who are the Key Stakeholders or Project Sponsors
  1. You have reached high enough in the organization when this person or persons can say no to settle a dispute
  2. They understand the end goal and will help you adhere to it as required
  3. This set of folks have some control of the purse strings
  • Who are the Business Owners
  1. Those tasked with validating and verifying you meet the goals
  2. The sign off team who says you are meeting the requirements and they are satisfied
  • The Business Users
  1. Those whose favorites may change on their desktop
  2. Job duites or process might be affected
  1. HR and Staffing should be involved with this team at all times
  2. Contractual obligations may have to be redefined
  3. Training may be the key to issues here
  • The Migration or Implementation Staff
  1. Who is doing the work
  2. Whose work schedule, backups or weekends will be affected
  3. Who are the leaders and knowledge workers in this spaceThe
  • The Help Desk
  1. This is the first area where failure or success will be known
  2. Training and understanding is essential
  • Communication Strategy
  1. How will you communicate
  1. Email
  2. SharePoint Alerts
  3. Voice Mail
  4. Town Halls
  5. Team and Department Meetings
  • How often and to what level wil you communicate
  1. Who needs to know the timeline
  2. What other projects are affected
  3. What and when do you start
  4. What deadlines for response are considered
  5. FAQ's. Wikis and Blogs can all be affective here
  • What is in and What is out
  1. Document and Display the Decision Points
  2. Determine Change Management Process
  3. Path for Scope changes
  4. Path to respond for next phase changes
  5. When do changes affect the timeline
  6. When do changes affect the measures for success
  • Project Plan
  1. Test, Pilot and UAT are a must for success
  2. Timelines
  1. End User
  2. Goals
  3. Project
  4. Detailed versus an overview
  • Types of Project Plans and integration with your PMO
  • Change Management
  • Budget(s)
  1. External Resources
  2. Hardware Acquisition Schedule
  3. Software Acquisition Schedule
  1. Build
  2. Buy
  3. Replace with built in components
  • Communication
  • Training

 

At the completion of this phase you will have a semblance of a plan often times i will say is it set in stone or written in sand with the tide coming in. The more concrete that your plan can be with some level of stretch ten to fifteen percent should be realistic. Your plan will change and that is a given from standard issues to your change management project. Where is it that we are flexible and where is that any flex will break or halt the migration.

Once you have a set of plans you will be able to start on the road to your testing and pilot with an ultimate plan on getting this project done.

So where do you go and how to do you get into the testing phase I will work on that in the next entry in this series, "Testing".

Anonymous