Applying Enterprise Architecture to an EPMO Process Framework

Thinking a bit more about last week’s post on scoping the EPMO.  In that post, I asserted that there are certain “stock” capabilities that an organization requires to execute projects.  Some of those capabilities should be best owned by the EPMO, some by the various PMOs supported by the EPMO, and some jointly owned by both.


One thing I left out of that post was a suggested framework for how to determine where a specific capability might actually fall, i.e. should it be considered a centralized capability or a decentralized capability?  As I was thinking about this, I realized that the framework proposed by Jeanne Ross, Peter Weill & David Robertson in their page turning EA book, Enterprise Architecture as Strategy, could be brought to bear on the discussion.

As I’ve mentioned before on this blog, they suggest reviewing architecture from the perspective of unified process and/or data.  Every capability should be reviewed by asking two simple questions:

  1. Do we need to centralize and standardize the process that each of the PMOs and EPMO follow?
  2. Do we need to centralize the data that each of the PMOs and EPMO generate and/or use?

Simply put, you can take each of the capabilities in the above chart and map it on the following 2 X 2:


After going through that exercise, that should give you a decent foundation upon which to allocate ownership of the various capabilities inherent in a PM system.

Applying Enterprise Architecture to an EPMO Process Framework

Querying Project Online with Natural Language

One of the most useful things to surface in the latest Microsoft BI offerings is the Natural Language Query (NLQ) functionality inherent in the Power BI online offering.  NLQ allows users to simply type questions into the interface to generate dynamic reports.


The beauty of this is that it’s not limited to Project Online data – or even a single source of data.  I can add multiple sources of data, create a data model and then go to town on asking questions of the data, literally.

This post will walk you through how to get this up and running in Project Online.  This assumes that as part of your Project Online tenant, you have at least one license for the Power BI offering.

Create the Data Source

Creating the data source is relatively simple.

  1. Open Excel
  2. Add an OData connection.  In this case, I actually added a couple of tables (Project, Assignment, Resource).  Feel free to check out prior blog posts on the topic here.
  3. Ensure the tables have relationships.

Navigate to your PWA site and add the report to the Power BI app.


Set Up the Refresh

This took a couple steps and some troubleshooting before I got it all working.  The basic instructions can be found in the following three blog posts.

  1. Get the Site Collection Feature turned on to allow dynamic refreshes
  2. Background Refresh Your Project Online Reports (Peter Charquero Kestenholz)
  3. Setting up the Scheduled Refresh (Peter again)

To check if the refresh is working, try refreshing the data connections in Excel Online.  If that works, the scheduled refresh should work.

Set up NLQ

Click on the ellipses next to the report, and add the report to Q&A.


From there click on the Ask with Power BI Q&A in the top right of the page.


Throw some queries into the search interface to confirm data is being returned.  You may note that it’s showing the wrong fields by default, i.e. it’s showing the Project ID instead of the Project Name.  We’ll take care of this in the next step.

Training The Language Model

Open the data source in Excel again, and navigate to PowerPivot.  You’ll see that you can right click on the column headers to select the option to Hide from Client Tools.


The other thing you can do to train the language model is to change the default field set.  You’ll see this option in the Advanced tab in PowerPivot.


Finally, you can go back in and add aliases for many of the fields.  Note that for this option to even be available in PowerPivot, you need to have installed Excel from the Office Online Click to Run installation option.  I don’t have that available right now, so I’ll provide you with the link to the reference: 

Luckily, there’s also a Web based option for training your Power BI model.  Buried in the Power BI Site Settings, underneath the Q&A tab, you get the option to Optimize for Q&A.


That yields an interface to add synonyms and other key elements to help your users connect with their data.


Finishing Touches

Add a link to Q&A onto your Project Web Access and feel free to fry all of your report developers’ squid.


Querying Project Online with Natural Language

25 Years, a New Site, and a New Blog

Looking for more portfolio management information?  Check out our new corporate blog, recently (re)launched:

…and for the full list of UMT blogs:

  1. The Corporate Team:
  2. The Development Team:
  3. The Product Team:
  4. The A Team:
25 Years, a New Site, and a New Blog

Scoping Your EPMO

In the ongoing quest for PMO relevance, many organizations are aligning to the PMO specifications defined by PMI in the Pulse of the Profession report unveiled in last year’s PMO Symposium.  In that report, five different PMO frameworks were defined: everything from a PMO stood up to support a large program to the enterprise PMO, or EPMO.

The EPMO is something we see increasingly in large, international corporations – or in organizations that have grown rapidly by acquisition.  Usually these organizations have a federated portfolio governance model.  There is an organization at the middle, the EPMO, that handles centralized functions such as portfolio selection or portfolio analytics.  The actual execution of the projects is then relegated to a PMO that exists within a specific line of business or national organization.


The trick is to look at the capabilities required for project delivery and then to relegate them across the various organizations.  Off the cuff, I’d designate at least three categories:

  1. Capabilities owned and performed by the EPMO – to which I’d generally relegate large, strategic, enterprise crossing initiatives, portfolio selection criteria, and other big picture items.
  2. Capabilities co-owned by the EPMO and the Regional/LOB PMOs – these would be the basic processes that the PMO must follow to support the overall EPMO activities.  Think of things like resource management, project lifecycle management, or those techniques for classifying work and cost such that they roll up effectively to the portfolio level to create those ever so important portfolio analytics.
  3. Capabilities owned by the PMO – These are the capabilities required to execute a project successfully, i.e.  scope management, deliverable management, and all of the detailed requirements that make projects a success.  Many of these need to be relegated to the specific group closest to the work to support their local or industry-specific needs.

Another way to group these capabilities lies in whether the portfolio being served directly impacts the client, i.e. a Type I portfolio, or if it’s a Type II Portfolio that supports the layer of the organization responsible for delivering services to the client.  I might offer a framework analysis such as the following to help lump capabilities into the right level of ownership.


That’s not to say that an EPMO has no role in supporting the federated PMO structure.  In general, we see success rates where the EPMO provides the role of process support, i.e. sharing best practices across the organization on how specific capabilities are performed by the various PMOs – but not necessarily being prescriptive about how those practices are carried out.

How does an EPMO share practices across various PMOs within the organization?  Through knowledge sharing and training – through roundtables and lunches.  More specifically, we see this done through sponsoring a shared technical platform upon which each of these processes may be enabled.  This shared technical platform provides the ability to easily share practices and processes across the organization as they’re developed by each of the PMOs.

Scoping Your EPMO

Calling all PPM Folks in Houston, Dallas, Austin and San Antonio….

Project and portfolio management is coming to Texas this November!  We’d like to invite you to an Executive Briefing coming soon to a location near you:

  • Learn how companies such as Devon Energy were able to leverage modern project and portfolio management (PPM) principles to enhance performance throughout the enterprise.*
  • Hear from Microsoft leadership how the enterprise cloud as well as Microsoft’s investments in business intelligence and work management will empower your business.
  • Be the first to see what’s in the 2015 release of Microsoft’s project management platform.
  • Network with your PPM peers.

Please select a city to for more details and to register:

  *Houston event only: Presented by Mike Dickey, Manager of Devon Energy’s IT PMO 

Calling all PPM Folks in Houston, Dallas, Austin and San Antonio….

Running Workflows on a Project Server Linked Task List

In Project Server 2013, Microsoft has introduced a new feature where task data from the project schedule is automatically synchronized with the first task list found alphabetically on the linked Project Site.  When it does that, it locks down the target task list so that it may only be edited through the main PWA interface or Project Professional.


There are a number of scenarios where you might want to enable workflow on this task list.  For example, you could create a change log that records whenever a task is modified.  You could create a centralized list of milestones… could create a task approval process…..I’m sure I’ll come up with a number of options.

The interesting thing is that the default workflow options seem to get hidden on a synchronized task list.


Drill in to the task, and you’ll see the workflow option noticeably missing from the ribbon.


So it seems Microsoft is not keen on you leveraging workflow to the list.  Hence, proceed at your own caution.

Luckily, the workflow option is hidden but not removed.  If you dig up the right URL, you can still access the workflow for each task.   In this case, I had to get the ID of the item and the ListID (from the List Settings URL) and the following URL will display the task workflow options.


So now we know the workflow is feasible, let’s create a simple one.  The following workflow creates a “Hello World” item in a custom list called WorkflowTest.


The trick is on the Workflow Settings screen…


See the option I’ve deselected?  If that is on, it will try to set a column in the task list with the status of the workflow.  As the task list is locked for editing due to the fact that it’s being synchronized with Project Server, this will cause the workflow to fail on execution.

To solve, simply deselect that option.

Now, whenever I modify a task on the schedule, it will generate a “Hello World” entry in my WorkflowTest list.


Not too far from there to a task change log kept in a SharePoint list.

Running Workflows on a Project Server Linked Task List

Project Portfolio Management: The Perspective of Choice

When enterprise architects meet up over beer and start parsing the terminology of enterprise architectural modeling, the concept of perspectives comes up, i.e. the ability to model the underpinning structure of the enterprise from a number of different perspectives – whether that be from the business, technical or actor perspectives.

A perspective is a useful tool insofar as it forces us to examine the same problem from a different angle – thus ensuring that we reduce the risk of missing something critical from our problem analysis.  When I teach project management workshops, I always have teams develop WBS from both a product and a process perspective – as that forces them to identify elements they may not think of when sticking with a single perspective.

The issue with perspectives, however, is that it is quite easy to get wrapped around the axles and stuck in an endless analysis paralysis as new perspectives are introduced.  At some point, we need to declare that “enough is enough” and move on with our current understanding of the problem.

So in selecting perspectives, as in all things, moderation is key.  We need to choose the 1,2 or 3 perspectives that will almost always give us the 80% of the problem we need to focus on for now, and then trust the ability to modify our approach in the future to ensure that anything we may have missed in the analysis is dealt with in a timely fashion.

Thus, when we look at project portfolio management, we typically arrive at the critical point where we need to determine an appropriate perspective to use when reviewing the issue.

The Process Perspective

The default perspective is probably the simplest one.  Perhaps because of PMP training, ISO standards or natural inclination, many folks start looking at portfolio optimization from the process perspective.  In this perspective, the portfolio management process is broken down into discrete steps: intake, business case development, prioritization, authorization, execution, benefits realization, etc.

Each of these steps is broken into subprocesses: inputs, tools & techniques, outputs (ITTO).  We then start looking at project portfolio management as an exercise in ensuring that all the ITTO are technically accounted for and flow into each other.  With this perspective, we end up with a technical solution to the problem, a linear path to success.

The Capability Perspective

An alternative perspective is that of the capability.  Instead of looking at project portfolio management as a process, we look at it as a strategic capability that enables the company to make intelligent decisions about the projects that it will execute.  Then, we break that strategic capability down into its component parts.  To support project portfolio management, we will need to be able to perform resource management, financial management, enterprise architecture and strategic planning.  Each of these elements becomes its own strategic capability with its own subcapabilities.

Capability Over Process

See what we did there?  We took the problem of how to do project portfolio management and we flipped it on its side.  We went from treating it as a process to a capability.  Both perspectives are valid – but we find the capability perspective to be more useful in framing the solution.  The capability perspective is more useful for a number of reasons:

Thinking in terms of capabilities doesn’t trap us into thinking in the context of a single process or system.  Instead of focusing on project portfolio management, we can focus on the financial management that underpins project portfolio management.  Chances are this is the same financial management that supports project execution or operations or any of the other elements in the Request-to-Fulfillment value chain.  Hence, when looking at financial management (as an example), we need to make sure that we can support all of these needs using a harmonious structure, taxonomy, nomenclature, process, etc.

The flip side of that is to develop financial governance to support each new process individually.  When organizations do that, they end up with a spaghetti mess of poorly coupled systems and data silos.  One financial system is used to manage projects in engineering, and a whole other system is used to manage projects in execution.  Meanwhile, bids and contracts are all tracked somewhere else.  Focusing on the process perspective denies the complexity inherent in the organization as a system.

The second reason to think in terms of capabilities and not process is that continuous improvement is better built on a platform of capabilities than it is on a defined process.  As the organization matures and improves performance, whole capabilities can be enhanced or invested in without forcing a reengineering of the entire process.  This phenomenon is particularly true in the field of project portfolio management, which arguably itself is precisely an exercise in ongoing improvement.  Reengineering an entire process to support continual improvement becomes a significantly more complex endeavor.

Remember, when looking at implementing project portfolio management within an organization, you’re never focusing on solving today’s problems.  You’re not even focusing on solving tomorrow’s problems.  You’re focusing on giving the organization the ability to solve the problems that will arise next week that we haven’t event thought about yet.  Selecting a capabilities based perspective is the first step in identifying how that will be done.

Project Portfolio Management: The Perspective of Choice