When you ask people in IT why projects fail so often, the answers include at least things like “the wrong methodology was used”, “business people constantly change their mind”, “the (project) management lives in fairy-tale land”, etc.  What it all boils down to however is communication.  It’s true that business/project management and IT speak a different language.  But what can you do about it?  What do you do when two groups of people have to work together?  Right, you search for common ground.

For most IT projects, this common ground has almost always been looked for in tools.  A couple of years ago, Microsoft had the idea to have the entire project team work in the same tool, namely Visual Studio Team System.  Great! Most of the Microsoft oriented IT world welcomed this and started selling the idea to their project managers, analysts and IT Professionals.  Everybody was going to work in this glorious tool.  PMs had their performance and follow-up reports, analysts could manage the product backlog, IT Pros could manage their infrastructure models, etc.  However, there was one little thing they overlooked however.  Project managers and analyst often think of development as the “dark side” (just like developers think the same thing of analysis or project management).   So asking them to work in a tool that originated entirely from the developer end of the spectrum is like asking a developer to use MS Project or a DBA to use Access.  It won’t really work, now will it?

So what is the common ground? What tool can bring both sides closer together?  As seen before, it can’t originate from the development or the project management side.  It has to be understandable for both and the learning curve can’t be too steep.  Strangely enough the answer comes from Microsoft themselves.  Microsoft Office SharePoint Server 2007.  Earlier versions of SharePoint were already focused on communication, but with the 2007 incarnation, they made up for their “mistake” of trying to use Visual Studio for everything.  However, they did it in a very ingenious way. 

I know a lot of developers are going to say: “Hey, wait a minute.  Most of the features in MOSS for communicating on projects are aimed at the project management side.  There are issue lists, risks, milestones, etc.  Where is our side of the information, the sprint logs, the product backlog?  That’s right they are still in Team System!!”
You know what, you are absolutely right, but that’s where the ingenious part comes in.  Microsoft knows developers like to do one thing most of all … build it themselves.  And that’s what Microsoft provided with a whole new set of API’s, the Business Data Catalog, the customizable web parts even the webdesign can be changed. 

(And now for a short commercial break ;-) ) At Euricom we have built a PMIS (project management information system) that uses the strengths of the existing SharePoint features and combine them with all the information that exists in Team System.  It combines the information from the project manager like milestones, risks, issues, planning and the information for the development side such as the product backlog, change requests, scrum dashboard, test cases/runs, bugs, builds, etc.  All the information on the project is therefore available in one place.  Changes to any of the information in SharePoint are synced through triggers with the originating data sources and vice versa.  This means that developers and project managers can keep on working with their own tools but can communicate through another, commonly used, tool.

Extra benefit is that a third party can also be included much more actively in the entire communication, namely the users or business people.  And since all of this is consultable via a web interface, it also works for distributed teams and for instance fixed price projects were business and development are in different locations. 

More on the actual technical implementation of the SharePoint PMIS that was built at Euricom will be posted later in several other blog posts. 

I know a lot of you are very suspicious when it comes to SharePoint.  And I have firsthand experience of where this might come from.  In a lot of organizations, SharePoint is used to replace a certain network drive that stores all the documents.  So what they do is mimic this drive in SharePoint and call it that.  Wrong, of course.  Implementing a good and easy to work with SharePoint portal requires as much attention as any application you would built, but the reward will be more than worth it.  We have used this PMIS on fixed price project, projects with distributed teams and normal projects.  We have even used our PMIS for a project to set up a PMIS at one of our customers.  And it works.  Teams communicate better and more often.  Customers are very happy that they as well can follow-up the project on a day-to-day basis. 

So if your teams are having trouble communicating, all hope is not lost.  Try using SharePoint to balance the force … whatever side you’re on.

By Ronny Gabriels, Functional Analyst and ex-.net Solution Architect