TFS Integration and the Increasingly Misnamed Microsoft Project Server

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.

TFS Integration and the Increasingly Misnamed Microsoft Project Server

The Consultant of La Mancha

One of my parenting lessons learned is to never take your kids to a performance of Spider Man: Turn off The Dark in New York.  After that, any show that doesn’t have a guy in colorful leotards swing out over the audience and land right in front of your balcony seat to the background of a Bono-penned rock anthem just won’t cut it.  I’ve got to take them to a revival performance of Tru just to reset their baseline expectations.

These were just some of the thoughts passing through my head a couple of weeks ago as we took a family trip to see The Man of La Mancha down at the Hobby Center.  As you may be aware, the show tells the story of Alonso Quijano, a Spanish nobleman who dreams of being a knight, and who sets out to live his dream as Don Quixote.  The story revolves around how he perceives the world, and how the characters outside of his dream react to his perceptions.

It reminded me of a comment my old college roommate told me when we met up for lunch a couple of weeks ago.  According to him, the “problem” with consultants, is that they always want to make the world a better place.  They can’t just accept the world as it is.  The consultant, you see, is the ultimate optimist.  They see an organization, and think, “a challenge.”  They see a work intake process, and think “portfolio optimization.”  They see a spreadsheet, and see an opportunity for “efficiencies.”

We consultants dream that impossible dream.  And gradually, just like Sancho Panza, and Aldonza, our clients start to share that dream.  And maybe, just maybe, if they start to share that dream, even just a little bit, we have proven our worth and delivered value.

The Consultant of La Mancha

Financial Governance Made Simple

Readers of this blog are probably familiar in concept with UMT’s flagship product, Project Essentials.  You’ve probably heard the elevator pitch and are aware that it has something to do with financial governance.  Maybe you’ve seen the demos.  Maybe you’re currently using it.  But what does financial governance actually mean in the context of project portfolio management?

In a previous post, I talked about how Project Essentials can complement your corporate accounting system.  In this post, I wanted to introduce a couple of fundamental concepts related to financial governance as it is implemented within the Project Essentials tool.  My hope is that this may demystify some of the bits that are under the hood and give my readers a better entrance point to conceptualizing what capabilities this software can actually enable.

Enterprise Financial Types

The fundamental building block of the solution is the Enterprise Financial Type, or EFT.  An EFT is a collection of financial settings and dimensions that an organization wants to track.  For example, Cost is an EFT.  Cost is typically tracked in terms of the approved budget, current estimates, and my actual cost to date.


But what about financial benefits?  Benefits also can be tracked in terms of the same dimensions, i.e. approved benefits, current benefit estimates, and my actual benefits to date.  Benefits are typically tracked along a different timeline than Costs though, and as such we would treat Benefits as another EFT.

With Project Essentials, you can essentially create as many EFTs as you require.  For example, cash flow, contracted costs, resource capacity planning….all of these can be created and tracked in terms of the original estimate, current forecast, and actuals to date.

Financial Dimensions

How do we break down the EFT into more detail?  As discussed above, one of the ways we break down the EFTs is through the use of Financial Dimensions, the standard ones being original budget, current forecast, and actuals to date.


We can easily add dimensions as well.  For example, let’s say I have two levels of approved budget: the version that’s entered in SAP for work that is part of my annual budgeting cycle, and the version that is not in SAP, as the project was not allocated funds from the annual planning cycle.

In this case, I can create a new financial dimension.  I can have one that captures the allocated funds within SAP – and another that tracks the amount approved for the project, i.e. the unplanned approved budget.  For these projects, for the Cost EFT, I can now have four dimensions: Planned Budget, Unplanned Budget, Current Estimate, Actuals to Date.


Financial Trees

So far so good.  We have Financial Types and we have Financial Dimensions, how do we break it down even further?  I can now capture each of those financial dimensions within each time period per an assigned Cost Breakdown Structure.  For instance, I can capture my approved CapEx and OpEx for May 2013 in the budget dimension – and compare it to the matching CapEx and OpEx entries in my Forecast Estimate for the same time period.


The above example is just a simple one.  We regularly work with many organizations who define their cost breakdown structure to a far more detailed level with hundreds of specific nodes to track cost against.

Everything Else

…which brings us to workflow.  Project Essentials takes all of the above and ties it to your project development workflow, so we can define what level of granularity is required at each workflow stage, or whether the estimates should be entered in multiple currencies and aggregated into Euros, or when the budget should be locked down and subject to a change approval process…or any one of a host of other typical financial governance activities that take place routinely in a project lifecycle.


That, in a nutshell is the financial governance that we enable: simple concepts adapted to match the complexity of real world operations.

For more information, or to catch one of our Webinars, check out the following link:

Financial Governance Made Simple

Fixing SharePoint Sync Errors in Project Server 2010

Here’s a common issue I am finally getting around to blogging up: certain projects always seem to throw an error on Publish, specifically on the part of the Publish job where the Publish database data is pushed into the Reporting database.  Everything works fine in Project Server, but the Reporting database (RDB) doesn’t refresh.

This issue is almost always caused by somebody messing with key settings in the SharePoint site attached to the project.  You’ll be able to determine if that is the case when you go into the Project Server queue and see something like this:

GeneralQueueJobFailed (26000) – ReportingWSSSync.WSSSyncMessageEx. Details: id=’26000′ name=’GeneralQueueJobFailed’ uid=’dae69759-a3c3-4ac4-a3bf-032022b0dd17′ JobUID=’41f0e5ef-9ca4-4edd-bcf6-f5fca87b3ae8′ ComputerName=’mypc’ GroupType=’ReportingWSSSync’ MessageType=’WSSSyncMessageEx’ MessageId=’1′ Stage=”. For more details, check the ULS logs on machine  myserver for entries with JobUID 41f0e5ef-9ca4-4edd-bcf6-f5fca87b3ae8.

Check the ULS log, and it will tell you exactly what’s wrong with the SharePoint site in question.

PWA:, ServiceApp:Project Web App Service Application, User:myuser, PSI: [RDS] Failed to transfer SP list 1101 associated with project ‘920997d9-050c-4b54-84f2-7d365cbf3449’ to project server reporting database. Error: Microsoft.Office.Project.Reporting.ProjectReportingPublic.ReportException: The field: ‘Category’ on the list for project ‘920997d9-050c-4b54-84f2-7d365cbf3449’ should have type Choice. It was found having a different type (MultiChoice)…

…indicates that someone has changed the default Category field from a single select to a multiselect.

PWA:, ServiceApp:Project Web App Service Application, User:myuser, PSI: [RDS] Failed to transfer SP list 1101 associated with project ‘d32cf50b-8ccf-4405-8251-d26fb59c5d68’ to project server reporting database. Error: Microsoft.Office.Project.Reporting.ProjectReportingPublic.ReportException: Failed to prepare the transfer of SP list 1101 for project ‘d32cf50b-8ccf-4405-8251-d26fb59c5d68’. The field AssignedTo was missing from the SP list and was ignored.

…indicates that someone has deleted the AssignedTo field from the relevant list.  You’ll also be able to determine which list specifically causing the issues, i.e. 1100 equals the Risk list and 1101 correlates to the Issues list.

More Background

As a little background to this discussion, Project Server has certain structures hard coded into the RDB.  Specifically, every time a project is published, a routine hits the Website and pulls a dozen or so specifically named fields from the key Project Server lists and libraries on that site: Deliverables, Issues, Risks and Project Documents.

If a user inadvertently deletes any of those entities – or modifies them in such a way that the RDB can’t find them anymore, an error will be thrown.  If the organization isn’t leveraging the RDB for custom reporting, that’s probably not an issue, as it really doesn’t matter what’s in the RDB.  If the organization is leveraging custom reporting however, this becomes a priority.

Fixing Deleted Lists and Libraries

The first scenario we’ll look at is fixing deleted lists or libraries.  This might happen if the site owner decides “Hey, I don’t need this Issues list.” and simply deletes it.  To fix this, navigate to the site in question, turn off the Project Server feature, and then reenable it.  That reprovisions lists that don’t already exist on the site – but doesn’t seem to impact lists already on the site.


Fixing Deleted or Modified Columns

The second scenario would involve the user modifying or deleting columns.  In this case, simply add a new column with the expected name back to the list in question.  Check a working project site to confirm the correct name for the field – specifically check the URL for the column in a working site to confirm that you’re creating a new column with the appropriate system identifier, and not the alias.

For example, “Assigned To” should be created as “AssignedTo.”  Once the field has been created with the appropriate system name, go back and rename it to something a bit more user friendly, i.e. “Assigned To.”  It will keep the original name, but display as the more user friendly “Assigned To.”

Fixing the Linked Column

The only column that can’t be fixed in this way is the Linked column.  This column captures the links between list items and project tasks. That’s specifically provisioned as part of the list, and can’t simply be added back into the list using the method above.  If there’s no data in the list, go ahead and delete the list and reprovision it using the technique above.

If the user has deleted this column and has data in the list, you’ll have to bring out the big guns.  Here’s the approach that worked for me:

1) Provision a blank team site and add the Project Server Lists feature to this site.  That site will be a parking lot for our data while we fix the list in our source site.

2) In the source site, navigate to Site Settings > Content and Structure.


3) Use the Content and Structure interface to copy the list data to our temporary site.


4) Delete the list in the source site.

5) Reprovision the Project Server list items in the source site (i.e. Site Settings > Site Features > Deactivate and Activate)

6) Use the Content and Structure to copy the data back from our temporary site to the source site.

7) Delete the temporary site to clean up.

Publish the project to refresh the RDB and check the queue to ensure everything processed as it should, and you should be good to go – until the next time an end user deletes a field.  Note that you may have to do this a couple of times on the site, as the ULS logs seem to only catch the first error on a site before failing.  If multiple changes have been made to the site, you may need to review the logs a couple of times to ensure you got everything.

Fixing SharePoint Sync Errors in Project Server 2010