You're developing a knot in the bottom of your stomach. It's not because your son didn't make it to the best peewee baseball team. It's not because your daughter fell during her last dance recital. It's because you've got this feeling that your SharePoint project is in trouble, but you can't quite put your finger on why.
SharePoint projects are very complex. They require a large number of skills to be done correctly. In some ways they resemble ERP package implementation projects. These are the same projects that have a relatively high failure rate. So here are seven signs that your SharePoint project is in trouble and some thoughts on how to put it back on track. With careful scrutiny you can keep your SharePoint project from being a statistic.
Warning #1: You require a large amount of process change
Newton's first law is "A body in motion tends to stay in motion unless acted on by an outside force." In other words, change isn't natural. It happens as a response to an external pressure or force. SharePoint might be an external force encouraging change, but that doesn't mean the humans it is affecting will accept it.
As a rule, organizations don't like change. Sure they might pay it some lip service, but when it comes down to actually making the change there is always a lot of resistance. In general, the great the change SharePoint is introducing, the more resistance you'll get. .
If your SharePoint project has to make large changes to the process, plan for a large evangelism activity to sell why the users need to embrace the change. Many organizations try to use the management -enforcement approach. The problem with this approach is it will wane after months of user adoption not happening the way they want it to. Much like a politician is forced to conform their views to those of the people they represent, management will waver in its resolve that SharePoint is the right solution.
You can't force people to work a different way if they don't want it. In other words, the old cliché holds true, "You can lead a horse to water but you can't make him drink." Work with the proverbial carrot by preparing evangelism activities. Work hard to make everyone OK with the tools and even harder to make them OK with the process changes.
Warning #2: Your defaults encourage bad behavior
In nature, things tend to take the path of least resistance. In organizations, the path of least resistance is centered on how you create the defaults. If the default for your organization is to cause Microsoft Word to open to the user's home directory on the network, this is where most people will store their documents -- even if those documents are useful to their group and aren't in any way private or personal.
In implementations where collaboration is crucial, changing something as simple as the default storage location in Microsoft Word can make a big difference in how well the solution is used. Creating defaults throughout the organization -- from setting a browser home page to setting the default directory for Microsoft Word -- can have a big impact on how your system is used.
Look for every opportunity to encourage the right behavior by setting default directories, default home pages, permissions, etc. in a way that encourages the behavior you want.
Warning #3: SharePoint doesn't work well for ____, but you're going to use it for that task anyway
You know you're hammering the proverbial square peg through a round hole, but you don't feel like you have a choice. You believe the only way you can get through the project is to implement SharePoint for something it's not good at. While this might sometimes be necessary, it's always risky.
Going into the implementation, you must focus on the implementation's exit strategy. For instance, if you're using SharePoint to manage large numbers of scanned documents, what will you do to add a document management system in the future when it becomes necessary? What planning steps or activities do you need to address today to prepare for the move when it comes?
Using SharePoint for something it's not good at, without planning your exit strategy, is like painting yourself into a corner on purpose.
Warning #4: You have a hostile business-to-IT relationship
Since the beginning of computing there has been a natural tension between IT and the business. If you ask a room of IT professionals how many of them have a good relationship with the business side of things you're likely to see few -- if any -- hands raised. (I know. I've done it.) That is not to say every relationship is bad because it's not good. On the contrary, there are many working business-to-IT relationships in organizations across the globe.
However, sometimes the natural tension between the business desires and the ability of IT to deliver can cause rifts that divide and polarize the relationship between the business and IT. The relationship begins to take the perspective of "necessary evil" and everything begins to be difficult.
Although the road to recovery is a long one, there are some easy things you can do from the IT side of the fence to start the process. The first thing to do is to let the business vent about the things they struggle with in how they relate to IT -- without being defensive or responding other than to acknowledge the problem or apologize.
The next thing to do is make sure you allow the business folks to feel like they are driving the process and controlling its evolution. They are ultimately your customers, so helping them feel like they are being served is an essential part of the road to recovery.
Finally, as you move forward, do not attempt to cover up your mistakes or the risks to the project. Be open with them even if it is uncomfortable or requires you to listen to a bit of yelling.
If you're on the business side, arrange for discussions -- and make them discussions about how to move forward rather than whining sessions about all of the things that have gone wrong in the past. Don't expect IT to own up to their part of the problem. You'll have to focus your efforts on facilitating the move forward rather than looking backward at past problems.
Warning #5: You have a disconnected workforce
SharePoint is an online Website with an ability to connect people and help them be productive. However, SharePoint's offline story isn't great. It can be made to work, but it generally means third-party products, some extra work, or both. When you're designing systems in SharePoint where most of the workers are mobile most of the time, expect that you'll need to spend special time figuring out flows, working through quirks, and finding or building missing pieces to make everything work together.
Carefully consider what information the mobile workers are most likely to need, how you might keep it on their systems automatically, or how you're going to support their connectivity needs when they're out of the office. Failure to plan for problems with a disconnected workforce will generally mean that you're going to find the problems pop up at all the worst times possible.
Warning #6: You're focused on turning off features
SharePoint is often described as a Swiss Army knife. There are many blades, screw drivers, saws, and other apparatuses that are all neatly wrapped into one package. The problem is sometimes those apparatuses can easily hurt the user. In the physical world it's hard to prevent someone who holds the knife from using any of its features. However, in the world of SharePoint, it becomes a trivial process to prevent access to some features which may be difficult or harmful to the user or organization.
There are, however, two problems with taking this too far. First, you end up turning so many things off that there's little or no value to the site. As a result, gaining adoption will be difficult.
A second and often subtle unintended problem with focusing on locking down features so users can't use them is you get so focused on turning things off that you forget to focus on enabling users to solve problems with the features that have. This, too, will make adoption difficult but generally in a more hostile way. Most users understand the need to limit the number of features available, but few understand technology that has been deployed but doesn't clearly solve their problems.
Warning #7: Your organization is bad at project management
SharePoint projects are more like large package implementation projects than the more traditional infrastructure or application development projects a typical organization is used to running. SharePoint projects tend to be special because they require implementing a foundational infrastructure, implementing and configuring the software, and using application development resources to bridge the gaps between what the software does and the precise way the organization wants to use it.
The problem with this is that package implementation projects are difficult. They require many diverse sets of skills and many different kinds of sub-projects. The way you approach an infrastructure project is different from configuring a package. This, too, is different from application development. Threading them together into one cohesive unit is difficult for organizations that do have a strong project management team. Threading them together when your project management team is already struggling is a recipe for disaster.
If the project management skill in your organization isn't the strongest, you'll need to provide extra resources, extra planning time, and be cautious of falling off track. If you can't hire project management assistance, break the different phases of the project into sub-projects and manage each one according to the type of project it is. Don't attempt to force a "one-size-fits-all" approach to managing a project like SharePoint.
Ideally, when you're looking for project management assistance you'll find someone with SharePoint experience. However, if that's not available, you can substitute someone with a strong ERP implementation background. Strangely enough, ERP implementations face many of the same challenges that a SharePoint implementation faces.
On the right track
Just because there are warning signs doesn't mean that you can't have a successful project. The key is identifying warning signs early and taking the appropriate steps to mitigate the problems that can be the result of untreated warnings. With diligence, your SharePoint project can be a great success: one which will serve the organization well for years to come.