The release this past week of the updated TFS 2012 – Project Server 2013 demo image underscored a point that we’ve been making in discussions with implementing organizations of late: Project Server is really no longer the appropriate name for the technology that we work with. Instead, it’s really morphing into a Work Management Server.
With the emphasis this year at technical conferences on the TFS connector, we’re seeing Project Server leveraged more as a work management hub than a project management hub, i.e. a centralized location where organizations can perform resource planning, capacity allocation, and portfolio analysis. The work being managed is increasingly broader than simply projects, as an IT portfolio typically encompasses both break fix and project work, and allocating capacity against project work only yields only part of the overall picture.
Hence, what more organizations typically do is to set aside resource capacity for operational work – and using the remaining capacity for project work. For projects, we can pretty much manage the entire lifecycle (with some exceptions) within Project Server. With operational work, we can allocate resource capacity to specific items within Project Server at a high level, but we still need to marry this allocation to our tracking mechanism – usually in the form of ticketing systems.
What does Project Server bring to the table? It’s the most logical place to develop a view into the entire portfolio of organizational work – although it still doesn’t quite get us across the goal with regards to service ticketing. That’s where reports come in….they pull the ticketing data and map it back to the allocation data stored in Project Server.
At the same time, we must acknowledge that at this point in its lifecycle Project Server is designed for managing projects – it’s not designed for short term reactive work. Short term, itemized work is where other tools excel. As we start looking at the integration of Project Server with other tools, we need to look at tools that are specifically designed to support areas that Project Server doesn’t. Usually that means either tools designed for tactical, reactive work – or tools designed to support very specific work management methodologies such as agile (IT) or linear scheduling (construction).
Another way to map the work to the tracking system is to identify the window of time within which we can plan and capture the work. Then each look ahead period can be mapped to an appropriate tracking system for each work management methodology in the portfolio.
In this new world, Project Server serves as a centralized reporting hub that pulls in the data from disparate work management systems designed to support specific work management methodologies. The day to day management of the project and tasks may occur in a different system like TFS, but roll up to Project Server for resource capacity and demand modeling.
That, in my mind, is what the TFS connector for Project Server really means….one more step in the repositioning of the tool from an end to end project management system to an open work management hub.