As I deliver my online webinars and training sessions, I get frequent requests from attendees to share my SharePoint Project Management Template. I kindly decline to do so and then proceed with a 5-minute sermon on why I don’t do this. With this blog post, I would like to explain my logic and reasoning for doing so. And no, it is not because I am greedy or because the template represents some sort of Intellectual Property. It is much simpler than that.
“Some things like underwear, toothbrushes, passwords and SharePoint Project Management Templates are not meant to be shared”
Reason # 1: Your organization is unique
Every organization is different. I have rolled out hundreds of Project and Team Sites to my clients and I yet have to encounter a situation where different client sites would look identical or even close. Some organizations are crazy on standardizing their project documentation via metadata, some prefer to focus on Task Management aspect and MS Project synchronization. Others are interested in Social features. Some organizations are managing their projects using Waterfall methodology (with serial phases). Some are more Agile. You get the idea. No template will get you what you want, unless you create one yourself from scratch.
Reason # 2: Customize your project or team site to your process, not the other way around
You should never customize your internal process to the SharePoint Project Management Template. In other words, you should never force your users into a particular template you got off the web. I have written a number of blog posts on the topic, but your success will not be determined by SharePoint technology or flashy templates and dashboards – your success will be determined by User Adoption.
What I am trying to say is that always think of the end user. At the end of the day, they will be the ones managing projects and using these sites day in and day out. I am talking about project managers, team members and various project stakeholders. I am not talking about executives who will access flashy project dashboards once a month – these are not the people you should design your processes or sites around!
However, if you design your project site to be simple and intuitive, with easy navigation and customize to internal processes – your users will embrace it. Else – your SharePoint will be a subject of jokes and scape goat for everything that is wrong in the company.
Reason # 3: Evolve bottom-up, not top-down
SharePoint Evolution within your organization should occur slowly and organically. The best way to achieve this is by starting with a clean sheet of paper (or in your case clean SharePoint site). You know when you grew up, you probably first learned how to ride a tricycle, then a bicycle and then a car? Same with SharePoint, learn how to ride the tricycle first. Moreover, starting with clean site will enforce you to only utilize features and web parts that you need, instead of the unnecessary ones that already exist on a template.
Reason # 4: Template should tie into your overall Information Architecture
SharePoint Sites never really exist or function in a space – they are all tied in together via solid Information Architecture. For example, if you have a document library to store documents on a Project Team Site and you want your documents to be consistent, you might want to utilize metadata. That metadata needs to reside in a central Term store and the columns in the library would be defined at the root of the site collection (if you follow best practices). So in other words, you need to build out that functionality anyway – no template will have it for you.
So this was my long answer to why I never share my SharePoint Project Management Template. Do you agree?