How to implement SharePoint in 5 meetings

In this post, I would like to explain the way I implement SharePoint for my clients. That is correct, I do this in just 5 meetings. This is my own methodology, essentially my own business model that I have developed over the years from my experience in the business of SharePoint consulting, business analysis and project management. While other consulting firms might carry you through the lengthy phases of requirements gathering, documenting content types, site hierarchies, security, and navigation, I have none of that nonsense when I work with my clients.

The way I help clients build SharePoint Intranets is bottom-up, by thinking big and starting small. This methodology applies to any size and type of the organization, by implementing just a few sites at a time (phased approach). Also, this methodology incorporates Agile project management principles and techniques (iterative approach). Hey, my 15+ years in the field of IT Project Management come in handy here :)

In the past, I have shared the various phases of the SharePoint implementation project. While they provide the phases from the project management standpoint, they do not explain the actual logistics of the implementation. This is what I intend to do with this post. By the way, I use the same methodology not just for building Intranet Portals, but also for other types of SharePoint sites (Project Portals, Document Management Systems, etc.). The 5 meetings and SharePoint configuration occurring after each meeting can be translated into Sprints for those of you who are hardcore Scrum fans. Below diagram gives you a visual representation of what my SharePoint implementation looks like to my clients.

Sprint 1

Meeting 1: Project Kick-Off

• Gather initial high-level requirements
• Determine just enough information to build an initial mockup
• Establish Site Hierarchy

What happens after the meeting

• Obtain access to the environment
• Provision site collections
• Build landing page (mockup)
• Build subsites (mockup)
• Create initial web parts on all sites
• Create high-level navigation

Sprint 2

Meeting 2: Project Status / Design Review Session

• Review sites and web parts with client
• Gather metadata requirements (if applicable)
• Discuss additional functionality requirements or sites (if any)

What happens after the meeting

• Create additional subsites (if applicable)
• Refine existing sites/web parts
• Configure Term Store, add metadata capability (if applicable)
• Configure views on all lists and libraries (if applicable)

Sprint 3

Meeting 3: Project Status / Design Review Session

• Review all sites and web parts
• Discuss security model for all sites in scope
• Discuss changes/feedback

What happens after the meeting

• Create security groups, add users
• Configure external sharing (if applicable)
• Refine existing sites/web parts

Sprint 4

Meeting 4: Project Status / Design Review Session

• Review sites and web parts
• Discuss topics for upcoming training
• Schedule Administrator and End User Training

What happens after the meeting

• Final cleanup per user feedback
• Create Site templates (if applicable)
• Enable usage/auditing feature in Office 365

Sprint 5

Meeting 5: Training

• Administrator/Power User Training (1 hour)
• End User Training (1 hour)

That’s all there is to it! Nice and easy and the next step is Go-Live! See, I told you, you don’t need to spend months gathering business requirements!

All of the above steps/sprints occur over the span of just 4-6 weeks. The idea for this business model is to deliver value/quick win to the client quickly and easily and get them in the habit of using SharePoint ASAP. Once the client is comfortable with the new technology, future phases can use same sprint model to add additional sites and functionality as required.