My goal for the last couple of posts has been to introduce the features of the Project Server Resource Analysis component of the Portfolio Analysis module with the help of an Excel mockup.  Why Excel?  Because counting with your fingers only works for low CMMI organizations. 

To give you coming attractions, this post is where we actually start getting to the meat of the discussion – and it’s where I realize I totally missed the boat on my Resource Analysis Simulation worksheet….

Just to get you caught up on previous posts in this series:

1) Introducing the Resource Analysis Worksheet

2) Configuring the Resource Pool

3) Configuring the Resource Analysis Parameters

4) Organizational Capacity Planning

This post represents part 1 of a two part discussion on how the original baseline scenario is calculated.

That being said, I’d like to take a minute and talk about something else entirely….

Reasons for Blogging

I blog for a number of reasons: to communicate with the Project user community at large, to communicate with current and potential clients, to finally beat my brother’s site in the search rankings and have bragging rights at Thanksgiving dinner….but when I go off on a series like this, generally that implies I didn’t know much about the topic before sitting down to write.  Blog posts to me are akin to the anti-library depicted in Taleb’s Black Swans.

You see, typically, if there’s a topic I want to examine within Microsoft Project and Microsoft Project Server, I’ll deliberately set out to document it in a blog posting.  That forces me to understand the key concepts, and in the writing process also forces me to test out various theories.

Why am I bringing that up at this point?  Well, when I got to this post, and I began validating my theories about how the Resource Analysis module actually works, I realized that my assumptions were fundamentally wrong.  On the other hand, recognizing you’re wrong is the first step to being right – as I will document later on in this post.

So I realized that I whiffed it on the Resource Analysis Sheet I kicked out the door last week.  Specifically, I identified two primary portfolio optimization heuristics and then used the wrong one in my calculations.

Luckily it’s just a blog.  It’s not like I killed someone.  When I get some free time, I’ll go back and redo the worksheet.  In the meantime, I am happy to have developed an alternate method of portfolio optimization. Maybe I’ll productize it one day and release it as a third party tool – or at least incorporate it into a fascinating cocktail party spiel.  You know that spiel – the kind that’s fascinating to the talker, but utterly boring to the listener. 

I am still figuring out which of my planned posts can still be released in the near future, so I may abruptly interrupt this thread until I redo that worksheet.

…that being said….let’s return to our normally scheduled blog post.

Overview of Baseline Portfolio Calculations

The baseline portfolio calculation represents the default portfolio selection of the projects in your portfolio.  More specifically, the baseline calculation takes the subset of projects that were included in your last saved cost-based optimization, and matches them to your organizational resource supply.

The baseline then provides the, well, the baseline against which various variables may be assessed.  Those variables specifically are:

  • Additional resources (people or money).
  • Project start dates.
  • Forcing in/out specific projects.


Your goal is to manipulate those variables to develop a mutually acceptable portfolio selection.  The tool enables these manipulations and calculates the results.


Put simply, in the example of the BHS, your goal is to take the above solution, and try to change as many projects to green and optimize your strategic value while still meeting organizational constraints.


Cost Analysis Interaction

The baseline resource analysis scenario is populated by those projects that have been marked as selected within the Cost Analysis module.  Unselected projects do not appear as options within the scenario.

This implies a logical workflow for performing portfolio optimization:

  1. Plan the projects.
  2. Perform cost-based optimization.
  3. Validate the results against your resource pool constraints.
  4. Perform what-if analysis against your resource constraints.


This results in the following behavior:

  1. After running a cost constraint analysis, the Resource Analysis button is grayed out.  The revised cost analysis must be saved before the Resource Analysis button is reactivated.
  2. Projects not selected in the cost constraint analysis are not part of any Resource Analysis calculation that I could identify.  The resource requirements for those projects appear to be eliminated from the calculation engine.


That’s one more slightly confusing aspect of figuring out which projects are relevant to the Resource Analysis discussion.  Let me see if I can summarize this in a table:

Scenario Result
Project not included in original analysis. Requirements are decremented from available resources, but no option to review or to force out.
Project not selected in the cost analysis. Requirements excluded from calculation engine.
Project forced out of the resource analysis. Requirements excluded from some parts of the calculation engine, but still included in the Deficit Surplus report.


Got it?  Good…..moving on….

The Optimization Algorithm

So this is where I started making my false assumptions.  When I was developing the BHS, I identified two potential portfolio optimization algorithms, which I’ll refer to for lack of better terms as the queuing method and the holistic method.  The best way I have of describing the two methods would be with a metaphor.

Let’s say you’re organizing a charity concert.  You line up a big star to headline your concert – perhaps even Bruce Springstein.  Your job then is to figure out how to fill the seats and get the maximum impact for your charity.  You will invite key patrons with a history of donating money to your charity.  Now, this is the Boss at the concert.  These patrons aren’t just coming by themselves.  Everyone in their family, all of their business associates, everyone wants to come with them.  And you can’t tell them no.  After all, they’re your best donors.

So what do you do?

Holistic method – You could submit an RSVP request to all of your guests.  Ask them to respond with how many people will be attending as part of their entourage.  Then map that against their predicted donation based on past records.  Throw all of the different permutations of guests and their entourage size into a giant Excel spreadsheet, eliminate any permutation that exceeds the total number of available seats, then identify the solution which generates the maximum predicted donation for your charity.  Send your regrets and a DVD recording to those who didn’t make the cut.

Queuing method – Rank your guests by their historical donations and how much you expect them to donate after the concert.  Before the concert, send them each a sequential number, starting at 1 – kind of like those numbers you have to take at the meat counter so they know who came first.  Make the numbers correspond to their potential donation.  So your highest roller is number 1, the second highest roller is number 2, etc.  When it comes to the evening of the concert, allow each donor and their entourage to enter in the order their number is called.  When the seats run out, close the doors to the concert hall and send the rest home.  You might end up with a few empty seats at the end, if the next entourage is too big, but that’s ok.

Option I: The Holistic Method

So let’s examine how the Baseline Scenario is calculated within the BHS, and by extrapolation, use that to illustrate how the calculations occur within Project Server. how it’s not being calculated in Project Server (as we now know that Project Server is using the queuing method).

First off, we need to assess the resource demands of the projects within the portfolio.  We will assume that these projects have already been prioritized using the AHP processes in the Portfolio Prioritization component.  So as a predecessor to the baseline calculation, we should have something like this…


i.e. a list of the projects in the analysis, ranked by priority.

The next step is to assess the resource demands from each project on a monthly or quarterly basis.  I do that on the BSDemand worksheet.


That data is aggregated up, so for any given period, I know what the overall demand for a specific resource is.

This is the easy part.  The difficult part is calculating whether or not to include the project based on the project prioritization and resource availability.   To do that using the holistic method, I develop a solution set comprising 32 possible solutions.  If you haven’t read this post about defining the solution space, I would encourage you to do so before reading further about this method.

In this case, I have 5 projects in the system.  As each project may have 1 of 2 values (selected or not selected), that gives me a solution set of 2 to the 5th possible solutions.  In the BHS, I then calculate the resource profile for each of those 32 solutions:

That looks something like this:


…where I am using the notation of “NYYNY” to indicate that this is the resource profile for including Projects B, C and E, but excluding Projects A and D.  To get the resource profiles defined for each permutation of projects, I have to perform 32 (potential solution sets) X 24 (time periods in the planning horizon) X 5 (identified roles), or a total of 3,840 separate calculations.

Luckily, we’re using Excel so it’s not too hard to perform all of those calculations.

From there, I compare each of the 32 potential solutions with our organizational resource capacity, developed as per the description in this post.


Any selection portfolio with demand for a role exceeding the organizational supply for any given period will be rejected.

From there, it’s a simple question of selecting the highest strategic value of the solutions that are still viable.  In the screenshot below, I have ruled out any scenario where the work for a role has exceeded the organizational supply for at least one time period.


Option II: The Queuing Method

So at some point, I need to go back into the BHS and revise the calculations to use the queuing method.  Hence, my screenshots for this part of the discussion may be less exciting.  Still, let’s see how we can address this topic.

So as far as I can tell, the system will first prioritize the resource requirements.  In the screenshot below (taken from an early version of the BHS), I sort the resource requirements (the green column) by project priority, then develop a running total of how many resources would be required with each additional project (yellow), and finally compare them to the organizational supply (red).  The results are depicted in the last green column on the right.


Here’s what that looks like for a rejected project scenario.


You can see that Project E would be rejected as the resource requirements for all of the projects in the sequence of priority would require 27 resources, and the organization only has 21.  Thus if we look at the February 2012 time period, we would conclude that we could run Projects D, C, B, and A – in that priority.

These calculations would then have to be performed for each time period within the planning horizon which may give you some sense of the volume of calculation that must be performed each time you run the Resource Analysis calculation.

There’re a couple of useful points here:

1) A project will get bounced out of the selection criteria if any resource requirement exceeds the supply during any of the time periods.  This may be an argument for using less granular time periods, and then using resource leveling to smooth resource allocations out over an entire quarter.

2) If a particularly resource heavy project is forced into the calculation, and the resources on this one project exceed the overall organizational supply, the system will not be able to calculate a portfolio.


One of the implications of this choice of using the queuing method for Project Server is that you might want to do a quick sanity check on your calculations by forcing out some of your top ranked projects.  Recalculate the analysis and assess if the strategic score has actually increased. 

Here’s a simple example to illustrate that point.  In this case, I have a very simple resource pool with two resources.  I have three projects, with the resource requirements defined in the table below.


By default, the system will calculate the results as follows.  You see that we’re using the queuing method to assign resources to the top ranked project, and then exclude any other projects that exceed our resource supply.  This results in a strategic score of 42.86%.


If I intercede with the calculation and force out the Role 2 Test Project, the system will add the next project in the priority queue, followed by any subsequent project that doesn’t exceed the resource supply.  That yields a strategic score of 57.14% split into two smaller projects.


And that’s all I have to say about that.  Next up: Continuing Our Examination of the Baseline Calculation Mechanism