Common pitfalls in SharePoint projects
Proper project planning and process management is essential for successful projects, but after working on SharePoint projects for over 4 years now, I have discovered some common pitfalls, some unique to SharePoint projects while others are general issues that seem to pop up more frequently in SharePoint projects.
The following are some common pitfalls and some tips to help make the project more successful (please note that some of these pitfalls has been mentioned in previous posts, and this posts aims to summarize my findings).
Pitfall #1: You are NOT using SharePoint correctly
One of the first things people must understand about SharePoint is that Microsoft did not create SharePoint as a replacement of their existing offering. Microsoft created SharePoint for fulfill an organizational need, and they were clever enough to create in is such a manner that it complements (NOT replaces) there other offerings.
Lets look at an example and focus on Intranets, before SharePoint, we had two extremes when providing a business user with an application or web space to achieve their business goals.
On one side we have business users requesting an application from the IT department, resources were eventually allocation and the SDLC begins, a solution is provided about a month or so later. This application had its own database, little to no integration with other systems, its own security component, meaning another set of usernames and passwords the business users need to remember, and its own unique look and feel.
On the other side, the business user will create an application themselves via Excel or Microsoft Access. The solution will be available quickly but the solution will be stored on business users workstation. The IT department may have no knowledge of this application, and even if they did, they will have a limited skill set in maintaining the solution. This application will not be backed up and will only be accessible when the business user’s machine is on.
SharePoint provides an environment that is governed and maintained by the IT department but also provides the Business User with enough control and flexibility to create and configure an assigned area of the portal to handle their business needs without the need of the IT Department allocating a developer to this task.
Using SharePoint as a workaround solution that is expected to “replace” another offering from Microsoft (for example Biz-talk or even ASP.NET), or adding too much customization so the SharePoint solution stops functioning like a SharePoint solution would mean that you are not using SharePoint correctly
Pitfall #2: Too much customization
This is really an extension of pitfall #1, but it happens so frequently, that it deserves its own point. If you need a magic number to help guide you, use 20% (it’s a number I made up, but so far, it has not disappointed me). If more than 20% of the solution is custom developed you are not using SharePoint correctly.
Also, avoid strong look and feel, rather use the correct template (based on the purpose of the site) , style it via themes only and configure to fit the business need
What people fail to understand is that the more the solution is customized the more expensive the solution; this is the cost in development and the cost in maintenance.
SharePoint provides a platform of templates and tools that assist the business users in creating solutions without the need of a developer, with custom components, you need developers to provide the solution and then maintain the solution, meaning that you are not using SharePoint correctly.
Pitfall #3: Using the wrong skills for the job
This is a common problem, mainly due to the shortage of SharePoint skills. SharePoint projects are different when compared to custom development, meaning that these projects demand a unique set of skills, and due to shifts in project demands, companies find it cost effective to convert their custom developers to SharePoint developers, this transition is not easy and is explained in detail in my previous post.
Unlike custom solutions, SharePoint projects is mainly about planning and configuration, and you would require a set of skills to focus on that rather than development. There are other skills such as defining, understanding and documenting the client’s objectives, which is frequently overlooked, especially in SharePoint projects, since the clients understanding of SharePoint is usually misunderstood and their expectations needs to be closely managed.
Pitfall #4: Clients expectations is poorly managed
SharePoint is very flexible, and has been sold as a solution that can do it all, this is an unrealistic expectation when it comes to delivery, so it’s very important to manage client’s expectations right from the start.
It needs to be understood that sometimes SharePoint is not the answer and SharePoint is about empowering the business users, this needs to be determined and understood at the early stages of the project and clients expectations needs to be well managed at this point, especially since the clients may want to use SharePoint because they happen to have the license and everyone else is using it (and if that’s the reason why you are using SharePoint, then you are using SharePoint for the wrong reasons).
Also, client’s needs to understand that they will not get what they want with a simple installation of SharePoint, SharePoint provides a platform for the solution – and that needs to be configured, and the client needs to be aware of this.
Pitfall #5: Don’t do too much too quickly
SharePoint can do a lot, but if you try to do too much, you will end up with nothing
Work on a SharePoint roadmap that spans over a few years. Identify key milestones and use a phased approach when delivering them. Be aware that, as you complete and review milestones, your objectives will change and the project and roadmap will need to adjust to accommodate the change.
Pitfall #6: Garbage in = garbage out
One of the strong selling point of SharePoint is the Search feature, but in order for the search feature to work correctly, content must be accurate, relevant and current. This involves good use to categories, metadata and taxonomy, and this is achieved through proper planning
Pitfall #7: Don’t forget capacity planning
When deploying a solution, you have a responsibility to provide an environment that can handle the current needs, as well as the predicted future needs.
Capacity planning is challenging in SharePoint as there are no hard limits, only guidelines. But capacity planning tools has been provided by Microsoft to assist you. Use these tools, but be aware that these tools tend to over compensate on the hardware requirements, so use this tool as a guide.
Pitfall #8: Don’t skip the governance plan
This step is often skipped, mainly because clients don’t understand the benefits of it, and see it as the easiest way to reduce the budget.
If you are planning to deploy a solution that will be used by many people, it is good to control the environment with a set of rules, these rules must be easily accessible to all users and it helps promote fairness and it helps control the environment rom growing too big too quickly.
Governance plan needs to include the support and maintenance of the server and network, the SharePoint technologies and even the portal as a whole.
A Governance plan defines if control of certain operations is with the IT department or the business users, it defines policies, standards, approval processes, it gets all relevant stakeholders involved and set rules to maintain a high quality output.
Pitfall #9: Scope creeps, risks and other general IT Project pitfalls.
SharePoint projects may have their own unique set of pitfalls, but they are not shielded from general IT pitfalls such as scope creeps and risk. A skilled project manager is essential for project success.
Plan for a development, QA and test environment – follow a process involving reviews and testing when coping updates to the environments, this will help control risk, can assist with training and keeps the live environment stable
Pitfall #10: Focus on strong user adoption
The SharePoint deployment project is regarded as successful if it receives strong user adoption. So providing proper training and support is compulsory. Spending some time on change management, where the new portal is advertised and there is some excitement created around the change is now seen as an essential step.
The SharePoint solution needs to resolve current problem areas, when launching SharePoint, make sure you shut down alternative sites that achieve similar objectives, otherwise people who are set in there old ways will never move to SharePoint.
Pitfall #11: Remember to measure the ROI
People decide to measure the return on investment after the SharePoint solution is deployed, at that point it’s too late because you don’t have enough data before the SharePoint deployment for a proper analysis. So gather feedback from end users before and after deployment to determine if you have received a positive ROI or increased productivity. Missing this step makes it difficult for the project owner to secure funding for future phases.
Pitfall #12: Dont speed through the planning phase
For the search feature to work well, content needs to be correctly classified. For business rules and policies to be implemented and executed correctly, your content types and workflows configuration settings needs to be designed and configured correctly. This involves alot of analysis before any "SharePoint" work is done, you need to do a "as-is" analysis, determine the "to-be", and work out how (or "if") SharePoint can fill the "gap".
If you are spending less than 20% of the entire project time on planning, you probably dont have a clear plan when configuration, meaning that you are relying on a "trial and error" approach when developing, which is going to cost you more money in the development phase and the support phase.
Pitfall #13: Migration will be quick quick (yeah right!).
If your site deployment involves content migration, treat it as a seperate project, because that alone is a big and difficult requirement, and is essential for project success.
The cleaning up of the content so the new site contains information that is current, accurate and relevant will on its own be a very time consuming process, now add to that the correct classification of the information, applying the correct meta-data, properties, content types. This is not a 1 week job so stop thinking it is when you are drawing up a project plan.
Sure, you can copy and paste all the content from the old site to the new, but then you will end up with the "Garbage in = Garbage out" problem (see pitfall #6), and the truth is, if you are not classifying you content correctly, you are not using SharePoint correctly (pitfall #1).
The following are some common pitfalls and some tips to help make the project more successful (please note that some of these pitfalls has been mentioned in previous posts, and this posts aims to summarize my findings).
Pitfall #1: You are NOT using SharePoint correctly
One of the first things people must understand about SharePoint is that Microsoft did not create SharePoint as a replacement of their existing offering. Microsoft created SharePoint for fulfill an organizational need, and they were clever enough to create in is such a manner that it complements (NOT replaces) there other offerings.
Lets look at an example and focus on Intranets, before SharePoint, we had two extremes when providing a business user with an application or web space to achieve their business goals.
On one side we have business users requesting an application from the IT department, resources were eventually allocation and the SDLC begins, a solution is provided about a month or so later. This application had its own database, little to no integration with other systems, its own security component, meaning another set of usernames and passwords the business users need to remember, and its own unique look and feel.
On the other side, the business user will create an application themselves via Excel or Microsoft Access. The solution will be available quickly but the solution will be stored on business users workstation. The IT department may have no knowledge of this application, and even if they did, they will have a limited skill set in maintaining the solution. This application will not be backed up and will only be accessible when the business user’s machine is on.
SharePoint provides an environment that is governed and maintained by the IT department but also provides the Business User with enough control and flexibility to create and configure an assigned area of the portal to handle their business needs without the need of the IT Department allocating a developer to this task.
Using SharePoint as a workaround solution that is expected to “replace” another offering from Microsoft (for example Biz-talk or even ASP.NET), or adding too much customization so the SharePoint solution stops functioning like a SharePoint solution would mean that you are not using SharePoint correctly
Pitfall #2: Too much customization
This is really an extension of pitfall #1, but it happens so frequently, that it deserves its own point. If you need a magic number to help guide you, use 20% (it’s a number I made up, but so far, it has not disappointed me). If more than 20% of the solution is custom developed you are not using SharePoint correctly.
Also, avoid strong look and feel, rather use the correct template (based on the purpose of the site) , style it via themes only and configure to fit the business need
What people fail to understand is that the more the solution is customized the more expensive the solution; this is the cost in development and the cost in maintenance.
SharePoint provides a platform of templates and tools that assist the business users in creating solutions without the need of a developer, with custom components, you need developers to provide the solution and then maintain the solution, meaning that you are not using SharePoint correctly.
Pitfall #3: Using the wrong skills for the job
This is a common problem, mainly due to the shortage of SharePoint skills. SharePoint projects are different when compared to custom development, meaning that these projects demand a unique set of skills, and due to shifts in project demands, companies find it cost effective to convert their custom developers to SharePoint developers, this transition is not easy and is explained in detail in my previous post.
Unlike custom solutions, SharePoint projects is mainly about planning and configuration, and you would require a set of skills to focus on that rather than development. There are other skills such as defining, understanding and documenting the client’s objectives, which is frequently overlooked, especially in SharePoint projects, since the clients understanding of SharePoint is usually misunderstood and their expectations needs to be closely managed.
Pitfall #4: Clients expectations is poorly managed
SharePoint is very flexible, and has been sold as a solution that can do it all, this is an unrealistic expectation when it comes to delivery, so it’s very important to manage client’s expectations right from the start.
It needs to be understood that sometimes SharePoint is not the answer and SharePoint is about empowering the business users, this needs to be determined and understood at the early stages of the project and clients expectations needs to be well managed at this point, especially since the clients may want to use SharePoint because they happen to have the license and everyone else is using it (and if that’s the reason why you are using SharePoint, then you are using SharePoint for the wrong reasons).
Also, client’s needs to understand that they will not get what they want with a simple installation of SharePoint, SharePoint provides a platform for the solution – and that needs to be configured, and the client needs to be aware of this.
Pitfall #5: Don’t do too much too quickly
SharePoint can do a lot, but if you try to do too much, you will end up with nothing
Work on a SharePoint roadmap that spans over a few years. Identify key milestones and use a phased approach when delivering them. Be aware that, as you complete and review milestones, your objectives will change and the project and roadmap will need to adjust to accommodate the change.
Pitfall #6: Garbage in = garbage out
One of the strong selling point of SharePoint is the Search feature, but in order for the search feature to work correctly, content must be accurate, relevant and current. This involves good use to categories, metadata and taxonomy, and this is achieved through proper planning
Pitfall #7: Don’t forget capacity planning
When deploying a solution, you have a responsibility to provide an environment that can handle the current needs, as well as the predicted future needs.
Capacity planning is challenging in SharePoint as there are no hard limits, only guidelines. But capacity planning tools has been provided by Microsoft to assist you. Use these tools, but be aware that these tools tend to over compensate on the hardware requirements, so use this tool as a guide.
Pitfall #8: Don’t skip the governance plan
This step is often skipped, mainly because clients don’t understand the benefits of it, and see it as the easiest way to reduce the budget.
If you are planning to deploy a solution that will be used by many people, it is good to control the environment with a set of rules, these rules must be easily accessible to all users and it helps promote fairness and it helps control the environment rom growing too big too quickly.
Governance plan needs to include the support and maintenance of the server and network, the SharePoint technologies and even the portal as a whole.
A Governance plan defines if control of certain operations is with the IT department or the business users, it defines policies, standards, approval processes, it gets all relevant stakeholders involved and set rules to maintain a high quality output.
Pitfall #9: Scope creeps, risks and other general IT Project pitfalls.
SharePoint projects may have their own unique set of pitfalls, but they are not shielded from general IT pitfalls such as scope creeps and risk. A skilled project manager is essential for project success.
Plan for a development, QA and test environment – follow a process involving reviews and testing when coping updates to the environments, this will help control risk, can assist with training and keeps the live environment stable
Pitfall #10: Focus on strong user adoption
The SharePoint deployment project is regarded as successful if it receives strong user adoption. So providing proper training and support is compulsory. Spending some time on change management, where the new portal is advertised and there is some excitement created around the change is now seen as an essential step.
The SharePoint solution needs to resolve current problem areas, when launching SharePoint, make sure you shut down alternative sites that achieve similar objectives, otherwise people who are set in there old ways will never move to SharePoint.
Pitfall #11: Remember to measure the ROI
People decide to measure the return on investment after the SharePoint solution is deployed, at that point it’s too late because you don’t have enough data before the SharePoint deployment for a proper analysis. So gather feedback from end users before and after deployment to determine if you have received a positive ROI or increased productivity. Missing this step makes it difficult for the project owner to secure funding for future phases.
Pitfall #12: Dont speed through the planning phase
For the search feature to work well, content needs to be correctly classified. For business rules and policies to be implemented and executed correctly, your content types and workflows configuration settings needs to be designed and configured correctly. This involves alot of analysis before any "SharePoint" work is done, you need to do a "as-is" analysis, determine the "to-be", and work out how (or "if") SharePoint can fill the "gap".
If you are spending less than 20% of the entire project time on planning, you probably dont have a clear plan when configuration, meaning that you are relying on a "trial and error" approach when developing, which is going to cost you more money in the development phase and the support phase.
Pitfall #13: Migration will be quick quick (yeah right!).
If your site deployment involves content migration, treat it as a seperate project, because that alone is a big and difficult requirement, and is essential for project success.
The cleaning up of the content so the new site contains information that is current, accurate and relevant will on its own be a very time consuming process, now add to that the correct classification of the information, applying the correct meta-data, properties, content types. This is not a 1 week job so stop thinking it is when you are drawing up a project plan.
Sure, you can copy and paste all the content from the old site to the new, but then you will end up with the "Garbage in = Garbage out" problem (see pitfall #6), and the truth is, if you are not classifying you content correctly, you are not using SharePoint correctly (pitfall #1).
Comments