Portfolio Analysis in Project Online: Engagements Edition

I started writing about the mechanics of the portfolio analysis module of Microsoft Project Server back in 2010-2011 with Microsoft Project Server 2010.  That resulted in this somewhat comprehensive (at the time) white paper that’s probably due for a couple of minor updates.

Over the last several years, I’ve made a couple of attempts to correct some of the errata and omissions in the paper as well as bring it into line with Project Server 2013 and the Project Online cloud based release.  That has resulted in the following posts (organized in chronological order):

  1. Original white paper (See errata in the comments)
  2. Generic Resources and Portfolio Analysis
  3. Resource Plans and Portfolio Analysis (Note: As of writing, Resource Plans are effectively retired in the Online version of the product)
  4. Prioritization with Custom Fields

And now this.  In this episode, I want to get you caught up on how Resource Engagements impact the resource analysis functionality in the Portfolio Analysis module.  Turns out, this is quite easy.  You’ll note in tenants with the features activated, you will now see this option in the setup screen:


So as you can see, you have the option of selecting whether resource engagements decrement from available capacity.  One important thing to note is that if I have assignments that don’t map to an approved engagement – those assignments may not be part of the portfolio analysis if the second option is not selected.

Hence, if you want portfolio analysis to work the way it “used to” work, you would probably want to select the second option, i.e. don’t require resource managers to approve work before it shows up in the resource analysis calculations.

Portfolio Analysis in Project Online: Engagements Edition

ConEd Talks Capital Governance in Atlanta in October

Frank La Rocca, Director of Business Improvement Services for Consolidated Edison will be presenting on how they have been able to manage their capital portfolio at this exclusive event in the Atlanta area.  Two sessions will be presented….Alpharetta and/or Midtown (10/28 PM and 10/29 AM respectively).

For more information, please click here….


ConEd Talks Capital Governance in Atlanta in October

PMOs: You’re Either With Them….Or Against Them

It’s an oft repeated joke about PMOs that the difference between “policy” and “police” is only one letter.  (The other joke being that PMO’s are like potato chips; you can’t have just one.)  Preparing for the webinar we delivered this week on annual planning caused me to reflect on this statement.  Specifically, what is the role of the PMO in a responsive Mode 2 method of annual planning?

We defined this responsive mode of annual planning as having three main characteristics:

  • Segmented Portfolios
  • Program Based Allocations
  • Frequent Rebalancing


It’s basically moving from a model where annual planning is an exercise in work authorization to where it becomes an exercise in work allocation.  Goals are defined as well as key metrics and KPIs.  It’s then up to the program and asset managers to best define how to get to those goals.

What is the PMO’s role in this?  Once we defer the goals to a specific program manager, the PMO’s job is to support the program manager to achieve these goals.  The fundamental relationship of the PMO to the organization has now shifted.  Instead of being a roadblock in the name of process compliance and risk mitigation, the PMO takes on the role of a support office, providing the analytics, tools, and know how to assist program managers in achieving their goals.

This is the fundamental realignment required to support a responsive annual planning model.

PMOs: You’re Either With Them….Or Against Them

Annual Planning, Mode 1 Management and Circular Logic

Gartner introduced an interesting concept at the PPM Summit in Dallas last May: Mode 1 and Mode 2 planning.  Mode 1 planning, as they described it, is the traditional planning approach to projects.  Each project is scoped out, estimated, a business case is built, and then approved in some sort of an organizational cadence.  When performed annually, this process is called “annual planning.”

The alternative to Mode 1 planning is Mode 2.  Mode 2, as presented, is much more agile and responsive.  As the request is identified, the project is approved, funding and resources allocated, and the project team is off to the races.  The challenge, Gartner presented, is for IT organizations to move from the Mode 1 planning model to Mode 2.  Or rather, it’s to determine when Mode 1 is appropriate and when Mode 2 is appropriate – and then shift back and forth as required by the organization.

We’ve written on that topic in this blog before, specifically here and here.  In that latter post, I theorized that the farther ahead of starting the project that the planning and the resource allocation takes place, the more complex are the systems required to support the planning.  For example, if I have an annual planning process where all resources are planned, funded, and resourced prior to the beginning of the fiscal year, I’ll need a system to support the resource modeling of all projects throughout the fiscal year – and to model the cascading impacts of delays in one project.

Knowing that planning so far ahead requires increased management complexity, why do we plan so far ahead?

That’s when it hit me.  We plan so far ahead, because we believe that we need to take a Mode 1 approach to project management.  Why do we take a Mode 1 approach to project management?  Because we plan so far ahead, we need to take a Mode 1 approach to support the annual plan.  It’s a tautology.

How do we break that logical loop?   How do we short circuit the time spent between planning/approvals and actually kicking off the project, i.e. moving to a rolling wave portfolio planning approach?  We switch to Mode 2 planning, i.e. moving towards an asset or program based allocation model.

Of course, that may not work in all cases.  There are certainly some projects that require extensive approvals and a Mode 1 planning approach.  Off of the top of my head, I might identify the following criteria for these projects:

  • The project will have significant impact on the future operational expenses of the organization, i.e. a large capital project to build a new facility or an IT project that will deploy a new application into production.
  • The project belongs to the category of infrastructure and ongoing maintenance that may be easily planned for far in advance, i.e. the retirement of a given application, the upgrade or replacement of equipment within a specific facility.
  • The project is so large and significant that it requires a major reshuffling of the overall funding allocations within the organization, i.e. we need to divert significant resources to this project.

That’s my criteria for when annual planning makes sense at a specific project level.  What are yours?

Annual Planning, Mode 1 Management and Circular Logic

And Now For Something Completely Different….

My first career was almost the foreign service.  Reading articles like this, a fascinating 1994 interview with Ambassador Joseph Lake about opening the first US embassy in Mongolia almost makes me wish I’d followed through with that.


It is all the more interesting because I showed up on the scene three years later and knew some of the folks he mentioned – and was in the same office space.

And Now For Something Completely Different….

Project Impermanence: The Sign of an Infant PMO

Object permanence is that step in infant development where the infant comes to realize that an object returning to the field of vision may actually be the same object that left several minutes ago, i.e. leaving the room is no longer an existential threat.  (Think a variation of the Schrodinger’s Cat experiment, but hypoallergenic and with less moving parts.)

I was chatting with a friend/new parent/portfolio manager the other day, and we started joking around that PMOs tend to go through the same development milestones as newborn infants.  In fact, his particular PMO was struggling with the concept of project permanence.  The problem was that the PMO would often accept a certain number of projects for execution as part of the annual planning process and then simply ignore anything not approved.  This meant that as funds freed up throughout the year, they would be made available only to the latest and newest requests – the shiny objects that captured the organizational attention at the moment.

More significantly perhaps, when it came time to start planning for next year, the list of projects that didn’t make the cut this year was no longer available and it was up to the business to come up with a new list.  In essence, these become all net new projects.

Instead of this simplistic approach, we see our clients keeping a running backlog of projects that reprioritized on a regular cadence.  As funds are made available (say, through a monthly reforecasting mechanism), they may be allocated to the next project in the queue.  Similarly, when it comes to planning for the next planning period, we already have a list of projects that are in the queue.

From an epistemological standpoint, we can periodically review this growing backlog to spot the emerging trends and categories that we should be focusing on as an organization.  If we see a trend of projects emerging around improving the customer experience, we can call that out as a high level portfolio category and then actually sit down to plot out the capabilities and projects that really would be required to meet those needs. (Building a sensing mechanism)

We find that project permanence may also be fostered through simply moving planning to a higher level, i.e. moving to an asset based planning model (or here for a discussion of the push vs. pull model).  In this scenario, planning is performed at the asset level.  In the case of IT, where an application is considered an asset, I can create a long term roadmap of the projects I will need to support an application – as I know every year will have a project to enhance it and then I’ll need to run an upgrade project in 5 years.  In this case, we don’t treat each year as an exercise in net new planning, but instead already have a good understanding of what our cost base looks like several years in the future.

In the end, what does this mean for the PMO?  This means the PMO is no longer simply focused on planning for this year, but setting up a framework to support decision making, planning and project approvals over a multi-year planning horizon.  That then supports the fundamental underpinning of portfolio analytics, i.e. that the PMO can assist in assessing the long term cost implications of any project that gets chartered today.  More importantly, that repositions the PMO from supporting the simple transactional process of an annual planning process (mapping resource capacity to demand, keeping everything in one place, etc.) to functioning as a trusted advisor on the implications of chartering a specific project.

Project Impermanence: The Sign of an Infant PMO

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)