I have used it often and I have been happy with the results most of the time. For status reporting I use an active list for tracking progress on Risks, Issues,Action Items, Deliverable and Documentation. Then export these lists into a MS Excel workbook with macros and VB scripts to produce an executive summary dashboards that can be published as web parts for Weekly and monthly status meetings. To do this you need to have admin control over your SharePoint site.

I've worked with many many clients that have started out using Sharepoint because that was what the IT department gave them when they asked for a collaborative solution.

They inevitably are unsatisfied with the

• a) amount of time and effort they needed from the IT department to configure Sharepoint to do anything close to what they wanted it to
• b) the amount of time and thought it required for them to create a structured project management process and
• c) the difficulty people had in understanding the application's role in their process.

From my experience it works best if there are well defined project management processes and procedures in place. On the other hand, for a less mature organization it can be the death of any initiative for better project management.

An out-of-the-box SharePoint Team Site can be very useful for small projects - it certainly gives you more than email and Excel. Remember, basic SharePoint is free if you have Windows Server 2003/8

However, as pointed out, discipline is required to ensure that things don't become messy - it is very easy to create sites and lists in SharePoint.

Difficulties can also arise if you need to deliver varying amounts of process (i.e. depending on the complexity of the project and the maturity of the team). SharePoint only includes a few simple lists (forms). You may find you need more.

The real problem with SharePoint as a PM tool arises when you have multiple projects and need to get oversight over these projects. Native SharePoint does not do cross-site and cross-list reporting without some coding and even then it is very inflexible.

I would suggest you try a project with a default Team Site and see what you are missing, if anything. Then investigate whether 3rd party tools such as BrightWork pmPoint or a Bamboo product can fill the gap.

My company has been in the SharePoint and Project management business for more then 10 years and we have created a number of very successfull project portals based on Scrum, PRINCE2 and similar methodologies. The key is to create some good templates and then lock down the system. Otherwise pawelbrodzinski's argument about clutter will come true very fast.

The lists and the document libraries is just building blocks but they really are the foundation on which you can build your project management portal. Of course you can build just the same system in ASP.NET or Rails and it will only cost you the same as the average jet fighter :-)

According to some of our customers the primary reason for picking SharePoint as a platform is the tight integration to MS office including the versioning system.

Check this out:

How SharePoint Delivers Project Transparency http://bit.ly/6cI0h1

If you combine Sharepoint with Project Server you will get a great prject management tool, look this solution developed with project server and sharepoint http://www.gedpro.com/en/Solutions/gedproEPM.aspx

I do agree with pawelbrodzinski's comments. You can store all the project/programme related artifacts like

1) Project/Programme Plan 2) RAID Logs 3) Team meeting calender 4) Lessons learnt documentation 5) Sharing/broadcating of any communication

These can be updated by the responsible person, preferably, project/programme support team.

The issue comes only if we try to use it as an EPM tool.

I have this short video that shows how I am actually using Sharepoint on my projects:

http://www.guerrillaprojectmanagement.com/simple-setup-for-using-sharepoint-for-project-communication