Thoughts on SharePoint project management: some considerations | Huddle
Sharepoint project management

The original premise of the SharePoint product was to facilitate collaboration. You need to look no further than the name of the product for proof of this; the idea behind SharePoint project management was to be a central “point” at which users within an organization “shared” information with each other. But in SharePoint’s massive growth since its introduction in 2001, SharePoint project management and simple team communications seem to have been dwarfed in importance by other features, like workflow and business intelligence, that Microsoft has added to the product. Why might project management not be one of SharePoint’s biggest drivers anymore?

In my opinion, the biggest issue with SharePoint project management is end user training. It probably feels like this horse has been beaten to death, but it truly is arguably the number one reason why SharePoint deployments are so much less successful than they could be. SharePoint, especially in version 2010 and even more so with 2013, has a complex set of capabilities built into the product, and you simply cannot expect users to take to using the product on a daily basis without investing some money in training. SharePoint’s user interface is sufficiently confusing, and its presence in the daily ebb and flow of your users’ digital lives sufficiently new, that they cannot be expected to learn by doing. For example, your users might have any one (or more) of the following questions about using SharePoint to manage a project:

Should I be entering tasks into SharePoint, or assigning related projects tasks through Microsoft Outlook?

When I upload files to the SharePoint site related to any given project, should I send a team wide e-mail letting my colleagues know new files are uploaded? How will they know what work I have been performing?

How will we all communicate with each other that items (documents, files, schedules, tasks, or other elements) on the SharePoint site have been modified?

How do we ensure all of the members of our SharePoint project management team are working off the same version of files? How can we avoid the problem of one member using an outdated spreadsheet that has been updated several times since?

How do we best communicate among all of the team members on this project? Should we use the built in discussion boards in SharePoint, or should we have our IT department create a special distribution list and alias in our e-mail system and use that for discussion?

How do we make comments when performing peer review of project support materials? How can all of us see those comments and offer further feedback or add our own ideas?

Can I use SharePoint to manage a schedule of deliverables related to my project? How do all of my team members see this schedule and keep track of the various deadlines for this project? Is there a way to integrate that schedule or list of deadlines with my regular Outlook calendar where the rest of my meetings and notifications reside? And if so, how do I go about doing that?

There is also a larger, management level issue that rarely gets the attention it deserves, at least from my point of view. In a lot of projects, SharePoint is used because it amounts to the de facto choice. In other words, people use SharePoint because it is there. Many companies have spent tens or hundreds of thousands of dollars on SharePoint deployments, installation, and consulting, and the default assumption when someone says, “we need a place to manage all of this information for this project,” is to say, “Let’s just set up a SharePoint site!” Often, however, that statement is made without a consideration for the actual suitability of SharePoint to any specific purpose. Do you need all of the power and complexity of SharePoint? Are some of your users on other platforms? Do a lot of your team members want to be able to access the content and information for the project on the go? SharePoint is certainly capable but I do not think any SharePoint expert would consider those areas strong suits for the product. So your users in some cases and in some scenarios end up putting up with a product that is not well suited to their current needs, simply because it exists and is available on the network. Perhaps, however, their needs would be well suited by another service that exists in the cloud that does a better job at sharing, synchronizing data between multiple users on multiple devices, and spins up quite easily and quickly.

Don’t use SharePoint just because it is there. Use the product that best suits your project management needs, whether that does mean SharePoint, or perhaps another product or service. You can explore Huddle’s task management in our interactive demo.

See the Demo

James Matthews

Monthly Huddle news and collaboration tips

Request Demo