The Road to Portfolio Analytics

I’m gradually working my way through Charles Betz’s excellent book, Architecture and Patterns for IT Service Management, and parts of it are resonating to me.  I’ve only gotten to the section on Demand Management, but it’s definitely starting to correlate to what I’m observing in our clients.  Let me see if I can put my own spin on it….

The basic gist is that demand comes in many different forms.  In IT, demand shows up as formal project requests, service requests (i.e. minor changes that don’t rise to the level of projects), and the output of various systems monitoring services.  The latter category in an IT setting would include all of the outputs of availability and capacity monitoring.  In a non-IT setting such as capital equipment, I would extend that to include the output of our maintenance scheduling systems, which spit out tickets for required maintenance.  As ITIL is really the extension of capital equipment management best practices to the relatively immature field of IT, that logic seems to make sense.

So that’s the work intake process, or if you want the sensing mechanism that determines what work the organization could do.  Let’s go to the other side of the intake process, the work queuing mechanism.  This is the viewpoint from the technician in the field, the person who must actually perform the work that’s coming through the intake funnel.  In a perfect world, this is all funneled into the same assignment queue.  That way, I can see my queue, and see all of the work assigned to me, whether it originated as a project task, a service request, or the output of a maintenance system.

In a perfect world, all of that work is prioritized – either by the work, or through some sort of prearranged prioritization mechanism, and every time I finish a task, I can go back into my queue and determine what the next task in order of priority is.  I might also throw other characteristics into the task selection, such as how long it would take to perform the task.  If I only have an hour, I’ll pick the next task that can be completed within a single hour.

The reality is that this rarely happens.  In the organizations we see, there are fragmented intake and queuing mechanisms.  As a result, we have different work streams that end up in different queues tracked with different metrics but assigned to the same individual.  As a member of IT, I will have tasks assigned in the ticketing queue, the release queue, and the project task queue.  Each of those tasks are competing for my bandwidth.

This takes us to the holy grail of enterprise work management.  In essence, the goal of an organization, IT or otherwise, whether they realize it or not, is to centralize all of that demand into a central location, prioritize it, and then spit it out the other end into an appropriate work management system.  I won’t say a consolidated work management system, as that may not make sense – especially when I have resources that are dedicated to performing preventive maintenance and can easily live within a single queue.  However, when I have resources that are pulled across multiple queues, then that requires a more rationally designed work management system.  (More on that in another post.)


Which leads us to the logical fallacy that has shaped the world of portfolio management for years.  There’s been this underlying assumption that we can take all of the work that comes through the demand intake and prioritize it against other work.  That’s the fundamental premise of many PPM systems, i.e. that I can throw all of my projects into a single bucket, define their priorities, and then map the priorities against the cost to optimize my portfolio.  As long as I am prioritizing similar work streams, this more or less works.

The problem comes when I try to compare apples and oranges, when I try to compare a project to support Application A to a ticket to support Application B.  At that point, the portfolio optimization breaks down.  The inevitable result is either a logjam of work that kills the adoption of the PPM system, or a regression to the multiple siloed work intake and management systems with their own on board prioritization and fragmented queuing systems.

Enter the world of portfolio analytics.  In portfolio analytics, we’re not looking to prioritize individual work, but instead, we’re looking to tie that work to a specific organizational asset.  In IT, each project, ticket, or release supports an application, which in turn, supports a service.  In a non-IT scenario in Oil and Gas, for instance, each project or ticket or release supports an asset such as a rig or well, which then can be quantified in terms of production and profit.  If I can identify the business criticality of the service, then I can assess the priority of each element of work in supporting the service, and therefore derive a cohesive, comprehensive framework for work prioritization.  I don’t look at the individual work items, but instead at the work in aggregate in terms of the assets it supports.

The first step in performing this analysis is to map the costs of the work to the assets.  While that sounds simple, it gets complicated when you throw in the fact that we have to model shared services, work that supports multiple assets, outsourced and insourced models, etc.  By mapping the relationship between our logical work entities and our logical assets, we can identify the total cost of ownership of the asset.  That’s the first step in portfolio analysis.

The next step would be in defining the value of the asset, whether it be in quantitative profitability terms, or in qualitative benefits.  Once the benefit cost ratio can be determined, that prioritization can be fed back into our demand intake structure – provided each of the demand entities can be coded appropriately back to a prioritized asset – either in financial or material terms.  This gets us that much closer to being able to prioritize all work that comes into the system….prioritization through association.

The Road to Portfolio Analytics

Taking Resource Plans to a Whole New Dimension

How does one track resource allocation?  What does resource “allocation” even mean?  These are the sorts of questions that project managers often struggle with when mandated to account for resources within an enterprise project management tool.  On the surface, this would seem like a simple problem:  I simply define the tasks in sufficient detail to support resource estimates, slap a couple of resources on said tasks, and call it a day.

The question arises however….what about consultants?  What if I have consultants that are dedicated to my project that charge a specific daily or hourly rate?  In that case, I can pretty much assume that I will be paying these consultants for 40 hours / week over the lifetime of the project.  The question these PMs typically ask me is how do we track these consultants?  Do we track them at a set 40 hours / week – because that’s what we’re budgeting them at?  Or do we track them at the actual number of hours we’ve got them assigned to tasks in any given week?


The correct answer is that you should be tracking both.  This is not a one or the other situation.  Instead, we’re looking at two different dimensions of the resource puzzle.  One dimension is the budget for the resources – either in dollars or in hours.  The other dimension is the allocation of these resources – which is typically measured in hours.

Think of the question more in these terms: Given that I’ve budgeted for a 100% of this consultant, why do I only have them allocated for the next four weeks at 65% of their availability?  Does this mean that they’re really working on unplanned work for the remaining 35% of their time or does this mean that they’ll be sitting around waiting for the work to proceed through the queue?  Why would an expensive consultant be working on unplanned work in the first place?

For employees that are not dedicated to a project, this may or may not be a problem – as it is typically assumed the employee is returning to their day job to support the organization.  Hence, their resource allocation really does represent the true cost of the project.  If the employee’s costs are carried in whole or part by the project though, this could become an issue.

The Resource Plan as the Budgeted Dimension

Project Server gives us the ability to track budgeted work through the much maligned resource plan.  To use the resource plan, I simply have to navigate to the project within PWA and add resources.  (Microsoft has posted a lot of guidance on the use of resource plans, so I won’t rehash it here.)


In the example above, I am assigning resources by FTE by quarter.  That’s the cost that will hit my project budget.

The Project Plan as the Allocated Dimension

I then allocate the resources to specific tasks within the project plan.  This allocation may or may not target 100% allocation.  In fact, I would generally recommend an 80% target, as that allows for some schedule buffer.


Comparing the Two

Unfortunately, there’s nothing native that compares the resource plan and project plan values within Project Server.  There are however some quick reports that can be generated with relatively simple SQL code, such as the query below:

SELECT P.ProjectName, TBD.TimeByDay, R.ResourceName, 
ABD.AssignmentResourcePlanWork AS Budgeted, 
ABD.AssignmentWork AS Allocated, 

CASE WHEN ABD.AssignmentResourcePlanWork > ABD.AssignmentWork
THEN ABD.AssignmentResourcePlanWork - ABD.AssignmentWork
ELSE 0 END AS Unallocated
FROM dbo.MSP_EpmAssignmentByDay_UserView ABD

INNER JOIN dbo.MSP_EpmAssignment_UserView A ON ABD.AssignmentUID = A.AssignmentUID
INNER JOIN dbo.MSP_EpmResource_UserView R ON A.ResourceUID = R.ResourceUID
INNER JOIN dbo.MSP_EpmProject_UserView P ON A.ProjectUID = P.ProjectUID

Throw that into an ODC and open up Excel to generate something like the following report:


…which if I were managing that PMO would indicate that we’re either underutilizing expensive external labor or my project managers aren’t adequately planning the tasks that the resources will be performing.

Throwing Financials into the Mix

That accounts for the hours assigned to a resource.  How do we convert all of that back into dollars for incorporating into the larger financial picture?  Check out this feature from UMT’s flagship product, UMT 360.  I can import my resource plan back into my budget to map my financial estimates that much closer to my resource estimates.


Taking Resource Plans to a Whole New Dimension

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

A Simple Archive Workflow Example

It’s a workflow kind of month, and I figured I’d post this quick article on how to leverage UMT’s Project Essentials 2012 with Project Server 2010 to generate a no-code archive process.

In this case, the goal is to close the project out, and then create a report that will notify the administrator to archive the project at a later date.  Now, exactly what that archive process looks like is kind of up to you, as I find many organizations vary widely on definitions of the archive process and when they decide to trigger it.

First, I see up a couple of stages to move the project between.


Then I create a security group containing the folks who are required to archive a project.


Now we go into Project Essentials and generate a simple workflow.  I won’t walk you through step by step, but it’s pretty self explanatory once you open up the wizard.


The only real nuance is that I am adding a manual submittal requirement and an approval step for the Closing step.  This will require the PM to submit the project to be archived, and will send a notification to the members of the Custom Archive Approvers group to do so.


I link the workflow back to a project type, and run a project through the process.


When I get to Closing, I require the PM to manually approve it – or perhaps require the PMO to submit it.  That kicks off a workflow request that gets logged in the Workflow Task List.


One more step and we’re there.  Let’s create a new view of the Workflow Task List and modify it to filter only on those tasks exiting Closing and entering Archived.


I now have a screen which time stamps the date the project was closed, and gives the administrator an overview of which projects need to be archived.  As a project typically hangs around for 6-12 months before being archived, the administrator can review this list on a quarterly basis to identify candidates for the archive process.


Even better, add a simple workflow to the Workflow Task List to send an e-mail to the administrator 6 months after the workflow task has been created.

A Simple Archive Workflow Example

Project Management Systems vs. Accounting Systems

As many of you are aware, UMT has long been in the project financial governance space, and for the last several years has been proud to offer a tool that brings financial governance into the project portfolio management fold.

Often, when working with clients in designing their project financial governance processes, the question arises of how such a system would interact with an existing Line of Business (LOB) application such as SAP or PeopleSoft.  The LOB application is the official enterprise system of record and, as such, must contain the latest and greatest financial figures.

So what purpose can be served by effectively taking those figures and copying them to a secondary data repository?  As any enterprise architect would tell you, unless doing so enables a specific strategic capability, data should never be replicated into a secondary repository.

First off, let’s look at simple reporting.  One common scenario is for project managers to desire to capture accounting data in the same interface as project data.  For this purpose, creating a second data repository actually defeats the point, as we want for PMs to have access to the latest and greatest financial data.  In this scenario, we may be better served leveraging the rich SharePoint Business Intelligence features to surface accounting data through the use of Excel Services, SSRS, or PerformancePoint.

But what happens when we move beyond simple reporting?  Let’s take a look at a couple of scenarios that are enabled by the Project Essentials tool:

Preliminary Estimate Development – Often, as projects are developed, an initial business case is developed.  This financial business case may be captured in a project request form, a request database, an estimating tool, and occasionally within the PMIS.  Rarely is this sort of data captured in an information system that allows roll up and analysis.  Even rarer would be when this sort of data is captured within a LOB accounting application.

The general workflow we’ve seen is for the initial estimate to be prepared outside of the accounting application and then imported into the application upon project approval and funding (which then allows the organization to utilize portfolio analysis and optimization techniques).

Status Reporting – Nothing indicates the difference between project management and accounting more than status reporting.  This really hits to the heart of what Eric Uyttewaal once claimed in his book on project modeling, “The difference between accounting and project management is that accountants are focused on the past while project managers are focused on the future.”

Common scenarios in status reporting include the fact that the accounting application typically doesn’t display actual costs until the invoices for the work have been received.  This might happen anywhere from 30 to 90 days after the date of the actual work.  From a status reporting perspective, the project manager is better served depicting an unofficial “incurred” cost in the status report for work performed that has not yet been invoiced.

While this may violate basic accounting best practices, the reality is that this practice enables more effective status reporting and emphasizes the difference between the world of accounting and the world of project management.

Benefits Management – Another key aspect of project portfolio management lies in defining project financial benefits.  The general model involves defining timephased financial benefits before approving the project.  Upon project closeout, or at a predetermined period thereafter, those same benefits will be reviewed to assess whether or not the project was successful.

Since benefits are very often hypothetical values, they often have no place within the data structure of an accounting system.  Hence, benefits tracking is often relegated to the PMIS.

Integration with Project Management Workflow – It’s a lot easier to integrate with your project management workflow when you can replicate at least some of your accounting data into a PMIS. For example, imagine that you would want to take a snapshot of all of your actuals as well as project cost forecasts at each stage gate approval. This would allow you as an organization to assess how much you’ve spent within each stage gate, and what the forecast looks like upon the conclusion of each phase.

While a LOB accounting system will allow you to roll back time to identify the value of specific elements at any given period, it is often difficult to map those periods to the phase gates approvals in a true project management solution.  How could you determine how much you’d spent at the end of the Build stage from your LOB application without first looking up the date that you exited Build in your PMIS, and then cross referencing that with your LOB estimates?

Performance Management – And last but not least, what about financial requirements for performance management?  Often times, the project performance must be measured against various baselines.  For example, we may have a data structure within our accounting system to capture approved annual planning budget.  We may also have a structure to capture our current project forecast.  If a project has been approved out of cycle however, the annual planning figures will be zero.  We need to capture a snapshot of the forecasted cost at the time the project is approved to ensure that we are tracking against the appropriate financial baseline.

Looking for something a bit more substantial on the topic?  Check out UMT Chairman Mike Gruia’s white paper on the need for project financial governance.

Project Management Systems vs. Accounting Systems