Last week, I announced my intent to spend the next couple of weeks examining the Resource Analysis component of the Portfolio Analysis module in Project Server 2010. My general goal is to use an Excel spreadsheet I developed, which I will refer to as “The BHS” to demonstrate the various calculations within the Analysis module. “Why an Excel sheet?” you may ask. Because VisiCalc is so 1980s.
Just to get you caught up on previous posts in this series:
As you can probably tell from the title, the first step in this exercise is to ensure your Resource Pool is configured properly to support Resource Analysis. The next step is to work through the various options in the Portfolio Analysis configuration page. Specifically, we’re looking at the options that appear when the circled check box for Analyze Time Phased Project Resource Requirements is checked.
That looks something like this:
The actual name for the checkbox is analyze time-phased project resource requirements against organizational resource capacity. Once we check that box, we get a whole slew of new options.
Let’s step through those options:
Time-phased Resource Planning – This option should be used only if resource requirements have been specified for each project by using resource plans or project assignments, and organizational resource capacity has been defined. Once this option has been checked and saved, it cannot be unchecked.
This option includes the resource calculations in the Portfolio Analysis. You’ll note that once this has been checked and the Analysis has been saved, the Resource Constraints button is activated in the Ribbon at the top. Conversely, if you’re looking for that button and can’t find it in an existing analysis, that’s because the Time-Phased Resource Planning option is unchecked. You can always go back to the options and check that box to add the resource calculations to the analysis.
Planning Horizon and Granularity – Specify the planning horizon and the level of planning granularity. Resource capacity data and project resource requirements outside the planning horizon will not be included. Projects that fall both within and outside the planning horizon cannot be moved, and only resource requirements data within the horizon will be considered.
This option is also pretty straightforward. Basically, define the beginning and end dates for the resource calculations, and set the granularity of the calculations to monthly or quarterly. Note that the BHS is set to monthly.
Note that this configuration has significant impact on cost calculations when calculating the incremental cost of adding internal resources, but does not impact the same calculations when using external resources. More on that in later posts.
Resource role custom field – Each resource should be mapped to a primary role based on a preconfigured custom field as discussed in the post on the Resource Pool configuration. Specify the custom field representing the resource role here. Time-phased project resource analysis will be performed at a role-level.
Now we’re getting into the meat of this analysis. This setting tells the system how to group your resources. Ideally, you have an Enterprise Custom Resource Field configured to identify what role each resource plays, such as Analyst, Gopher, Caterer, Swahili Translator, Bottle Washer, etc. On the BHS, I have set this very creatively to Role1 through Role5. Each assignment to a resource is then grouped by the specific resource role for assessment against organizational capacity.
Note that this is a key difference between Resource Analysis and the Microsoft Project leveling capacity – which is definitely a topic for another post. With resource leveling, we’re looking at a specific resource’s availability and comparing it with their assignments across multiple projects. The Resource Analysis feature, on the other hand, aggregates resources by a specific field such as the resource role. In other words, the Portfolio Analysis feature doesn’t care who’s doing the specific work, just how many people the organization has available to do the work. This is but one example of the difference in focus between Portfolio/Program Management and Project Management.
Resource filtering – Project requirement and organizational resource capacity data will omit resources that have been filtered out by department or RBS value.
More meat. In fact, this discussion came up recently in a client discussion. Consider the case of a department that leverages external contractors. As we all know, external contractors can clone themselves, work holidays and weekends, or just give up sleeping for the duration of a project. Availability is their problem, not yours – and as usually they bill by the hour, they’re happy to solve it. Hence, when evaluating projects that leverage external contractors, you may opt to just exclude them from your calculations. In this case, you could identify these contractors via the RBS so that you may ignore them in your resource deliberations. Note that you may still include them in the cost analysis, but that’s another topic.
Resource capacity impact for projects outside the analysis – Resource capacity is affected by projects not included in this analysis. If project or resource plan assignments use proposed bookings in your organization, you can choose to decrement proposed assignments from overall resource capacity.
I’ll talk more about this in the upcoming post on Baseline Calculations, but for now, note the following:
1) Resources assigned to projects with the committed booking type are included in the analysis.
2) If you exclude a project from the analysis, the resource assignments are decremented from the overall organizational capacity. By default, only committed assignments are decremented, but by choosing this option, you could decrement proposed bookings as well.
Hence, it would be a good practice to ensure that all projects pulling resources from a shared pool are included in the Portfolio Analysis. If you leave some projects out of the calculations, you will end up with all sorts of nonsensical calculations. Include all projects sharing a resource pool and leverage the Force In/Out option for those projects that will definitely happen (or not).
That being said, if your organization routinely uses the Proposed/Committed functionality, you will need to decide whether or not to include the Proposed bookings. Generally, some organizations consider having all booking types set to Proposed prior to the project being selected. That is all highly dependent on your organizational policies and procedures, or as the PMBOK refers to it, your OPA (Organizational Process Assets).
Needless to say, this specific checkbox is worthy of a blog post in and of itself.
…and finally we have….
Project start and finish dates – Projects dates [sic] can be driven by the project schedule or by referencing pre-configured date custom fields.
I can see a couple of use cases for this setting. Perhaps, if you have start dates driven by workflow, or if you’re using a stochastic modeling tool such as ProModel, you may consider using a custom field to capture potential start dates.
Then we have the option to change Force In/Out to terms that may be more politically correct, but I don’t plan on addressing that here. So now we got some of the basic settings out of the way, let’s look at specific functionality.
Coming Next: Organizational Capacity Planning