Does Microsoft Project Online Integrate with [Blank]? (Part 2)

This question comes up increasingly in our discussions with clients:  “Does Microsoft Project Online integrate with [fill in the blank with whatever Agile tool your organization happens to be using….TFS, Jira, Rally, VersionOne, Excel, etc.]?”  The answer is invariably “Yes, and….”

Given that it came up again this week, I figured it was probably worth a blog post to review the options available.  First, we looked at the technical options for integration in the last post.  Now that we have that out of the way, let’s look at specific scenarios that we see come up most often in this post.  (Yes, I realize I should be doing it the other way around, but to be honest many organizations haven’t identified the specific scenarios they’re trying to support yet, and are really just looking to keep their future options open when standardizing on an overall PPM platform.)

For prior postings on how to integrate Agile processes with an overall portfolio management mindset, please take a look at some of our old blog posts here.

Scenario 1: Portfolio Management

Portfolio management is probably the biggest aspect of using Project Online and an Agile tool.  The project is proposed and selected within the boundaries of the Microsoft platform.  Once the project has been chartered, a high level schedule is generated within Project Online, and the development efforts are pushed to the Agile tool.


In this example, the integration scenario is that once a project has been chartered, the same project must be created within the Agile tool (presumably with the help of a project identification number).  This allows us to ensure that all work has been properly authorized and prioritized against other work.

The reality in this case is that the Agile work is bookended by the portfolio management processes of the organization as well as the high level project execution activities…the user adoption, training, initial planning, etc.

Scenario 2: Resource Modeling

In this scenario, which is probably the most common scenario, the organization is seeking to develop a comprehensive view of resource capacity and demand.  Projects are chartered and work is managed within the framework of the Agile tool.  How does the organization gain an overall view of resource commitments?

In theory, this is quite simple.  To perform true Agile, your development staff is dedicated to the project, i.e. no more of that nasty task switching that causes delays in a traditional waterfall model.  Hence, you follow the same process as above, and when it comes time to allocate resources, you simply calculate the duration from the beginning of the first sprint to the end of the last sprint, and assign your development staff full time.

The details are then managed in your Agile tool of choice, and “integration” simply consists of comparing the finish date for the last sprint with the finish date estimated in the schedule tool.  There may be some reporting requirements, but these are easily handled by aggregating the data from the two systems into the same data model within Power BI.

Scenario 3: Task Scheduling

The final scenario usually involves scheduling of the specific sprints in the Agile tool.  As Microsoft Project is the preferred scheduling engine for many organizations, the overall schedule is modeled in the Project Online tool, and then specific dates are pushed into the Agile tool.


This gets a bit more vague, as the trick here is to identify specifically which data is being pushed into the Agile tool.  If really we’re managing the development activities in that tool, then the only dates I really need are the dates when I kick off my first sprint…..and when my final sprint completes.  Potentially, I may use this to schedule around release windows, i.e. to model release windows and blackout dates in my schedule, and then use that to assess impact on the sprint schedules.

Those are my scenarios.  Did I miss any?  If so, let me know in the comments below.

Does Microsoft Project Online Integrate with [Blank]? (Part 2)

Does Microsoft Project Online Integrate with [Blank]? (Part 1)

This question comes up increasingly in our discussions with clients:  “Does Microsoft Project Online integrate with [fill in the blank with whatever Agile tool your organization happens to be using….TFS, Jira, Rally, VersionOne, Excel, etc.]?”  The answer is invariably “Yes, and….”

Given that it came up again this week, I figured it was probably worth a blog post to review the options available.  First, let’s look at the technical options for integration in this post.  Once we get that out of the way, let’s look at specific scenarios that we see come up most often.  (Yes, I realize I should be doing it the other way around, but to be honest many organizations haven’t identified the specific scenarios they’re trying to support yet, and are really just looking to keep their future options open when standardizing on an overall PPM platform.)

For prior postings on how to integrate Agile processes with an overall portfolio management mindset, please take a look at some of our old blog posts here.  Note these are a bit more process oriented.  The blog below is designed to be a bit more tactical in nature.

Project Online

Rest assured, Project Online has all of the “hooks” required for integration with your tool of choice in the CSOM interface.  (For more on CSOM, click here).  Yes, you do probably require a developer to create these links to your tool – but most partners (such as, ahem, ahem, ourselves) have plenty of those on staff.  In fact, as we like to say, with our UMT360 add in – which integrates with Project Online, we are responsible for the most complex integrations performed to date on the Microsoft Project Online platform.


One caveat we would typically throw out is that the easiest way to prototype an integration and validate the processes underlying it is through rapid development of VBA macros within the Microsoft Project desktop tool.  Once the process has been vetted, and the underlying fields defined, that may then be coded up into the CSOM interface.  (See here if you want to tie an event handler into the mix, i.e. to trigger an integration action based on an activity in Project Online).

Project Online not only allows folks to push data into it, but obviously it also supports extracting the data.  To get data that may need to be pushed into another tool – or simply integrated into a common report (see below), the OData interface is generally sufficient.  This functions like a reporting database that may be accessed from the cloud – or via reporting tools that your organization may happen to have lying around.

The OData store may also be replicated on premises in the form of a standard SQL database.  This allows for slightly more ease of use in terms of keeping your Project Online data in sync with your Agile tool of choice.

Agile Tool of Choice

As for your Agile tool of choice?  Well, that’s a different question.  If you’re using TFS, there’re definitely hooks to push data into the system.  If you’re using another tool, we can probably assume there is an interface by which data may be imported – either manually or through a coded interface.  I can’t really speak to that – other than to say that it has never been an issue in our experience to push data into another Agile tool – or even any other kind of ancillary industry specific scheduling tool (WellView, RigView, etc.).


At the same time, the question then becomes….what data?  That’s something we’ll take a look at in the next post.

Finally, in our experience, any Agile tool worth its salt will have the required data available in an easy to use format, whether it be cloud based, an on-premises database, or some other data extract method.  This data may then be consumed and pushed back into Project Online via the CSOM interface or Microsoft Project desktop through good ol’ VBA macros.

Integrated Reporting Platforms

Most of the time, when we hear of a need for integration, after we do some discovery, we realize the need is really for shared reporting.  “I need to have one report that shows the overall project schedule as well as sprint progress,” the client says.  This greatly simplifies things – because at this point, we really don’t need to integrate.  We can simply extract data from the Agile tool, extract data from Project Online, and then integrate them into a single data model.


This is where Microsoft’s Power BI shines as a cloud based reporting tool.  It can easily pull multiple data sources from both the cloud and on-premises repositories to generate a seamless reporting interface.

And that’s it for the overview of the integration options.  In the next post, I’ll talk about why you might want to integrate and we’ll examine specific scenarios that might require integration.

Does Microsoft Project Online Integrate with [Blank]? (Part 1)

TFS and Project Online Integration

Pulling the development and the project management worlds together into a single view has long been regarded as the killer feature of the Microsoft IT work management world.  For evidence of this, check out this link to the 2007 Project Conference keynote where Steve Ballmer himself was on stage helping demo the new (at the time) connector with Project Server.

Needless to say, Microsoft has made great strides since 2007.  The version of the connector released for 2010, well, just worked.  It was a bit of an effort to install (usually due to security configurations), but once you got it working, it could plug along happily.  That is still the case with Project Server 2013 on-premises…..but once you start talking about the cloud based world, it becomes a bit murky.

At the time of this writing, Microsoft offers Project Online, a hosted Project Server service and  Visual Studio Online, a hosted Team Foundation service.  This means that we regularly run into customers that have Project Server, Visual Studio, or both online.  The question inevitably comes up about whether any of the online options can be integrated with each other – or with on-premises installations.

This post is intended to run through the various options and provide recommendations:

Out of the Box Server – Server Integration

Currently, the downloadable integration pack only works to link Project Server on-premises with TFS on-premises.  Note this pack is downloadable from MSDN Ultimate. I’m pretty sure it’s the same pack for both Project Server 2010 and 2013, but let me know if you find out otherwise.

This option is definitely the recommended option if both TFS and Project Server are on premises.


Project Desktop Integration with Team Explorer

This works reasonably well, although it assumes your project managers are scheduling within the Microsoft Project desktop application and not using the Web based scheduling feature.  Essentially, you download the free Team Explorer add in, which then adds a tab to your Project installation.


When updating tasks in Project, click the option to Publish, and the tasks appear in your TFS (online or on-premises) instance.


I was able to create a Visual Studio Online tenant and link it to my project in a couple minutes.  Admittedly, this is not a seamless integration:

  • It requires use of desktop scheduling (which – to me – is not a major issue.  I live in the desktop scheduling tool).
  • It requires a couple extra steps to push the data from the desktop to TFS – well actually, one button push.
  • It requires an extra step to download the data from TFS into the project schedule.

Also in the past, I’ve heard of issues where TFS will overwrite key data in the project schedule, like durations, etc.  In testing out the Team Explorer add in, I didn’t experience these issues, but feel free to report back in the comments below.

Until there is direct out of the box integration with cloud based implementations, I’d definitely recommend going this route for connecting Project Online with Visual Studio Online, Project on-premises with Visual Studio Online, and Visual Studio on-premises with Project Online.

Custom Development with CSOM to Project Online

For those of you running TFS on-premises and Project Online – which is the most common scenario we see these days, there is always the option of writing custom code to push or pull data from Project Online into TFS.  To assess whether or not the Project Online Client Server Object Model will support custom scenarios, I would encourage you to look at this link:

…then take a look at this link that Ionut wrote about remote event handlers for Project Online:

Visual Studio Online is also extensible.  See the link below for more information on integration with other services:

I would stress that the effort to develop your own integration package probably outweighs the incremental benefits that may be earned over using the desktop integration method.  Customization scenarios typically only work when there is a significant need for automation and your processes are very well defined.

3rd Party Tools

Last but not least, take a look at third party tools that may be out there to assist you in the integration.  More and more offerings are coming out each day, and stay tuned on the Project Server or Visual Studio application store to see if anything has popped up to support this scenario.

As more and more organizations move to the cloud, it will be refreshing to see Microsoft add extensibility options to allow improved integration and customization.  That’s definitely the direction I see happening with the cloud based offerings – and it will only drive the development of ever more applications that fill in the current gaps in functionality.

For some additional blog posts about connecting integrating Project Server and TFS….

TFS and Project Online Integration

When Chickens Become Pigs…or…Why Does It All Have To Be So Complicated?

There was a great comment from Mike Kaplan on my last blog post about integrating agile project methodologies into a project portfolio:

“I am struggling to see the overall value, or benefit for the investment, especially considering the effort required to build, manage and maintain the overall system,” he writes.  “Having used these systems for many years, I don’t believe they are the right fit or the right answer for any enterprise. Project, program, and portfolio reporting should be handled more simply. Proper governance is the right answer, which doesn’t require sophisticated aggregation of data across the enterprise using EPM, or PPM technologies. In a nut shell, it’s overkill.”

Couldn’t agree more.  In fact, as I was just pointing out to someone the other day, one of the main failure modes in an EPM tool implementation is that the initial implementation is overengineered and way too complex.  After initial implementation, a tool like that invariably falls apart….only to be replaced a couple of years later by a kinder, gentler tool implementation.

That’s why I actually prefer to work with organizations that have failed to do this a couple of times.  They’re the organizations that know what they don’t know.  They’re the ones that realize complexity doesn’t work for them, and simplicity is the order of the day.

The Work Taxonomy, or ‘Waxonomy’

The comment also hit right on another theme that I’ve spent some time noodling about as of late, i.e. the work lifecycle.  More on that in a bit.  First let’s unpack this statement:

Proper governance is the right answer, which doesn’t require sophisticated aggregation of data across the enterprise using EPM, or PPM technologies. In a nut shell, it’s overkill.

From a portfolio level, I will agree with this statement provided we have gone through the effort of creating a standard data taxonomy throughout the portfolio.  This is a topic that will undoubtedly be in my soapbox going forward.  What I see as a requirement for successful end to end work and financial management is a common taxonomy of work, i.e. all work within the organization can be tagged with the following metadata:

  1. Resource performing the work.
  2. Business unit/cost center to which the resource belongs.
  3. The asset that the work is supporting (this is the hard one).
  4. Whether the work is building new stuff or maintaining existing stuff.
  5. Whether the work is planned or unplanned.
  6. Other really important metadata….

As long as all work (and investment if the organization is mature enough for it) is mapped to a common taxonomy, all of the data can be rolled up to the portfolio level so that I can get an overview of what my assets cost – and where that cost is coming from within the organization.  That’s the same story whether I’m managing drilling platforms or IT applications.

Since the likelihood of all of that source data being stored in a single location is effectively nil, I would say that any inquiry into the TCO of an asset would almost certainly require at least a high level aggregation of data across the enterprise – whether it be in an EPM tool or in an overall data warehouse.

Authorization vs. Allocation

But let’s focus downward at the project level, which is what I was discussing in that post – which was originally prompted by the new Microsoft Project Server – TFS demo image.  Do we require sophisticated aggregation of data across the enterprise at the project level?  The answer here, I would posit, is it depends.  It depends on what the organization is (rightly or wrongly) looking for.  It depends on the organizational viewpoint on where in the lifecycle of work authorizations happen.

There’s an old sales story that gets bandied about.  It’s a bit cliché at this point, but in the interest of being thorough, I will repeat it here:

When you have breakfast (assuming you have no religious or ethical issues with eating pork or other animal products), you have bacon and eggs.  The chicken was involved in the making of the breakfast.  The pig was committed.

The general gist is that the sales prospect is just thinking about committing, but they need to make that mental leap and commit entirely.  Let’s think about that in the context of work.  Let’s assume that work can be identified and traced through a lifecycle:

  1. Work begins its life as capacity.  That capacity appears on paper the minute a functional manager commits next year’s annual staffing plan to the staffing system.
  2. The work gets closer to realization when a resource is hired into the organization.  Now we don’t have planned capacity; we have actual capacity.
  3. Along comes a project business case.  The business case may not specify the exact resource, but once it is authorized and becomes a project, that work is now converted to demand.  The work begins to take shape and be associated to the organizational work taxonomy.
  4. The project is authorized.
  5. The work is assigned to an individual.  The proposed work has become an allocated task.  In a traditional project, this might occur when the project is authorized to enter execution.  In an agile project, this allocation would occur long after the project was authorized and only after the appropriate user story has been prioritized into the next iteration.  This is putting us pretty close to the chicken/pig tipping point.
  6. The individual then performs the task.  This is what I would call the “work conversion event,” i.e. the planned work has now been unalterably converted to historical work.  The work has become the pig.  (This also begs the question of whether or not some sort of conversion rate metric could be applied to identify how much planned work actually becomes historical work – which would be a post for a different time.)

So essentially, we have had that work unit progress from planned capacity to actual executed work.  That is the work lifecycle.  That is what drives PPM system complexity in organizations intent on managing resources within the system.  The farther down the work lifecycle that the organization tries to push before authorizing the project, the more complex the tool becomes.


The Road to Kanban

Let me try a different tack… about these two statements?

  • In an agile planning methodology, availability drives the work.
  • In a traditional planning methodology, work drives the availability.

There are at least two things about agile that significantly simplifies the planning process:

  • We allocate dedicated resources.
  • We don’t define the detailed tasks until they’re ready to be performed.

The inevitable result of this is that indeed planning for an agile project requires a lot less detail.  I won’t get into the debate of whether or not it is less rigorous, or where the quality focus is, but at this point, when the project is authorized or even in the planning stages, there is a lot less detail developed.  As a result, we can employ a kanban approach at the project level and pull the tasks into the next iteration as availability allows it.  Availability drives the work.

Now let’s take a look at a traditional waterfall planning process:

  • We generally assume multithreaded resources working on multiple projects.
  • We define the detailed tasks long before they’re ready to be performed.

Those statements are both different aspects of the same issue.  If we assume that our resources will be working on multiple projects, then we must plan their tasks out to the nth degree to ensure the work can be performed on schedule.  This pushes our planning farther down into the work lifecycle.  The further down the lifecycle we get from a planning perspective, the more complicated our system ends up being.  Work drives the availability.

The inverse statement is also true.  If we assume that our resources are only working on a single project, then we only have to plan their commitment to the project at a high level.  As a result systems embracing this planning methodology can be much simpler in structure.

It’s our old forecasting bogeyman, multitasking, that drives the complexity.

Back to the Portfolio Level

Going back to the statement I saw in Mike Cottmeyer’s presentation about enabling a kanban approach to PPM, it’s all now starting to come together for me.  If we revisit these two observations:

  • In an agile planning methodology, availability drives the work.
  • In a traditional planning methodology, work drives the availability

.…and apply them to the portfolio level of planning.  Then truly, almost any conventional portfolio planning methodology would essentially follow the agile approach:

  • We’re not planning named resources and therefore effectively are using a dedicated resource model.
  • We’re only allowing work into the pipeline when it corresponds to available (or forecast) capacity.

Portfolio optimization essentially becomes an exercise in constraint identification and optimization.  It’s based on estimates of capacity and demand, and then building a backlog of work to optimize our resource constraints.  The complexity lies in the data that supports the constraint analysis, and the fact that this data collection has been pushed far down the work lifecycle.

At this point, I’m willing to concede that I probably totally misread Mike K.’s original comment, but it did launch me on some interesting tangents, specifically around kanban at the PPM level and why EPM systems become so complex.  So definitely, thanks Mike.  It’s the comments that make blogging less like work and more like an exercise in long form improv.

I also point out that ironically, the TFS integration that actually launched the original blog post is actually designed to remove complexity from an EPM system and push it into a more appropriate tool.

When Chickens Become Pigs…or…Why Does It All Have To Be So Complicated?

Integrating Agile into Your Portfolio Management Processes (Part 2)

In that last post, I talked briefly about how to perform a functional analysis as a prelude to integrating agile project methodologies into a mixed PPM environment.  In this post, I’d like take a closer look at some of the functions and identify examples of where their processes would have to be tailored to interface with an agile governance methodology.

Schedule and Financial Controls

Clearly, one of the first steps in integrating agile project management is flagging your agile projects and ensure they are excluded from many of your current reports.  You’ll do this because if you’re tracking stage gate compliance on your other projects, you’ll need to identify a mechanism to exempt these agile projects from that structure – and then develop another report that meets organizational needs to track schedule progress on agile projects.  This, in turn, may confuse your report readers who now need to look at multiple report types to understand the different project types.

One potential solution to this would be to roll your reporting up a level.  Instead of creating different executive reports for each project methodology, identify what question you’re really asking and whether or not a common report could encompass both methodologies.  Often the solution is to aggregate the reporting up a level.

In IT, aggregating your reporting might typically mean reporting not at the project level, but at the application level.  For example, I may have multiple projects supporting a specific application.  I could then track an aggregated budget for project work that supports an application at the application level to show cost overruns.  When I drill into that, I can go to the project level – which would then be tailored by methodology.


Resource Management

Chances are that if you’re the kind of organization that worries about PPM processes, you’re probably tracking resource allocation.  I won’t go to far on this topic as I discussed it last week in The Increasingly Misnamed Project Server…..but suffice it to say that your standard resource management tool may not be suited to managing agile projects.

In this case, rather than shoehorning the agile methodology into a tool not suited for it, consider using something more appropriate, provided that the task and work tracking mechanism feeds into your centralized resource management tool.  In this case, when paired with TFS for task management, something like Project Server simply serves as a work aggregation tool, and not a work tracking tool.  Taking it one step further, the agile delivery can be managed in Excel, then passed via TFS back into the centralized Project Server resource capacity.


Those are but some of the functions that would need to be considered when integrating agile project management into a PPM portfolio.  The list goes on and on.

…And Then…

Finally, let’s finish this post where we started…back at the macro level.  We’ve now knit a new methodology into our PPM processes.  What’s the inevitable end result of this?  Well, a more agile planning process.  The inevitable result of PPM maturity and functional maturity is to get more granular in the planning process.  What you’ll find is that your portfolio of work will increasingly look like an agile project writ large, with a backlog of work and a predicted burndown.  Each quarter, work items will be swapped out and reprioritized.

Why is that?  Take a look at this presentation from Mike Cottmeyer for his take.  If I interpret his slides correctly, once we get to the point of mature PPM, we can estimate our available resource capacity well enough that we can begin to apply a kanban system to our portfolio, i.e. we only allow work into the pipeline when we know we have enough capacity.  The corollary to that is that we start to chunk out our work into smaller chunks in order to generate the value possible using the available resources at the time.

As the PPM process becomes more nimble, the operational cost of planning goes down.  And as the operational cost of planning goes down, the relative value of the PPM process overall goes up.

Integrating Agile into Your Portfolio Management Processes (Part 2)

Integrating Agile into Your Portfolio Management Processes (Part 1)

Enjoying one of those rare confluences where my blogging, professional and speaking lives all converge at the same moment into the same topic.  As it looks like I’ll be presenting this at the upcoming Houston PMI blowout, I figured I’d try to capture it on virtual paper as part of my preparation.

The general question is how to integrate agile project management into a mixed portfolio of agile and non-agile projects.  This really ties into the discussion I posted a couple of weeks ago on EPM Bingo, or how to perform a structured analysis of your project portfolio management system.

Start from the Top

The basic gist is to back away from the daily processes, and look at the overall project lifecycle.  Regardless of execution methodology, most project lifecycles follow the same standard process, i.e. registering the idea, building the business case, authorizing the project, doing stuff, reporting on stuff, etc.  The nuance when we start looking at different management methodologies is to determine where the SDLC is determined, and then assessing the downstream impact of that decision.

The macro view is indeed quite simple – just a couple of boxes. 🙂  I didn’t even need to resort to fancy arrows or circles.


The pre-authorization stages of an agile project are pretty similar to a traditional waterfall approach.  We build the business case and do the estimates and maybe a high level risk assessment.  It’s at this point in a mixed methodology PPM organization that we might first consider to assign an SDLC model.  I won’t digress too far into SDLC determination as that was the topic of this rant.

Suffice it to say, I am strongly of the opinion that the SDLC should be tailored to the scope and risk of the project.  In a nutshell, the projected volatility of the scope should really dictate the SDLC model chosen – and that scope might not be accurately defined at this early level in the budgeting/approval process.

Functional Analysis

Once the SDLC determination is completed, things get more fun.  That’s where we need to perform an analysis of the functions we’ll be supporting.  By “functions,” I mean the various other offices and roles within the organization that require information from the project team:

  • Resource Management
  • Release Management
  • Architectural Strategy
  • Financial Controls and Chargebacks
  • Other

How do you know which functions you support?  Take a look at the existing project lifecycle and catalog the various reports and data that are passed back and forth from the project team to those outside of it.  You’ll end up with something like this:


Chances are you went through this exercise informally when PPM processes were first implemented.  Now we’re leveraging that to add another project management methodology to the mix.  Each of the boxes in the grid above should have defined inputs and outputs to the functional boxes hovering around the perimeter of the system.


Let’s take a look at a couple of those functions in the next post.

Integrating Agile into Your Portfolio Management Processes (Part 1)

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