Microsoft Project Absurdity

We are now using Microsoft Project Server to track project status for Taranna (the project on which I’m a program manager, at Microsoft for those that might not know.) Project Server lets the team have a central server rather than a shared file, much like the difference between SQL Server and Access. There are two ways to interact with the Project server: a Sharepoint web site and an Outlook plug-in. I was much more interested in the Outlook plug-in, since I use Outlook for so many other things that I’m already actively in it constantly. What the plug-in does is lets you synchronize tasks between your local Outlook file and the Project server, either at given times or when you click an update button.

Here’s where it gets absurd. When you synchronize your tasks, it creates tasks, right? Wrong. It creates calendar items. This requires that the plug-in, on installation, adds custom fields to the calendar object definition to support things like percent complete or estimated duration. In other words, it creates new fields that already exist in tasks, exactly where you would expect that kind of stuff to exist. On top of that, it clutters your calendar with a bunch of calendar items. To just look at your tasks, you have to select a special custom view also installed by the plug-in that hides “regular” calendar items and displays the “project” calendar items in tabular format with categories that looks remarkably like the default task view.

What were they thinking? It’s clear someone on that team knows this is just plain foolishness, because the marketing page on Project Server has a sentence about, “Note, this imports items as calendar items, not tasks.” Pointing this out means that whoever wrote that text, likely someone in marketing on the Project team, knew that the expected behavior to customers would that Project tasks would become Outlook tasks. This is just so disappointing, that smart people can just miss the boat in such an obvious way.