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

Deliverable Dashboards with SharePoint Workflow

A common request in project management is to be able to create a dashboard for each project that shows the status of specific defined deliverables that must be created.  For example, the project manager must be able to see that a SOW or proposal has been posted to the site.  The project manager must also post a status report to the project each week – or get flagged as being out of compliance.


In prior versions of SharePoint, this was typically performed through the use of custom code.  For this post, I decided to sit down and see if it could be done with a little SharePoint Designer workflow.  Turns out it wasn’t hard at all.

To create this solution, we’ll need:

  1. A custom SharePoint list for the dashboard
  2. A document library
  3. A couple custom content types
  4. One list workflow on the document library
  5. One site workflow on the dashboard list

Dashboard List

This is a simple list with a couple of fields:


Note that Status is a drop down with Red, Yellow, and Green as the available options.  (Red is the default).

I modified this list to add conditional formatting using SharePoint Designer 2010 as in this blog post.  It looks like SharePoint conditional formatting is being deprecated in 2013, so this is a bit of a hack where I had to install SPD2010 to get this to work.  I’d trust smarter folks than I to figure out a better way of sprucing up the dashboard – i.e. adding icons or leveraging some other method to create the conditional formatting.  For today’s post, this will do the job.


Add list items to your list for each deliverable you will be tracking.  I used the same names as the content type in the document library to facilitate the workflow finding the correct item to update.

Document Library

For the document library, I added a couple of content types and an Approved field.


Dashboard Update Workflow

I then created a simple workflow on the document library.  This is set to trigger whenever a document is created or modified.


Adding some additional detail to the picture above:

  1. Line 1 picks up the UID (as a string) of the dashboard item corresponding to the content type of the document in the document library.  This allows some minimal error handling by skipping the items that will throw an error if it can’t find a dashboard entry corresponding to the document content type.
  2. Line 3 establishes the URL of the document in order to populate that in the document dashboard – so the user can click directly from the dashboard to the document.
  3. The if….then clauses flag the dashboard item as green or yellow depending on if the document has actually been approved.

Here’s a shot of the step that updates the dashboard item.  (This is for approved documents.  The other one will flag the item as yellow.)  Note I’m copying the Last Modified date into the dashboard Updated field.


That will update our dashboard list per our requirements.  One more quick item, and we’re good.

Status Report Monitoring Workflow

For the final step, I want to add a bit of logic to flag the status update column yellow if no status update has been posted in the last week.  To do this, I’ll create a site workflow that will wake up every 24 hours, check to see if a new status update has been posted, and flag the item as yellow if it’s been a week since the last update.

That workflow looks like this (if anyone can suggest a better way to present SPD workflow in a blog post that’s not too tedious, let me know.)


More detail:

  1. Line 1 is pickup up the GUID for the status report item in the dashboard list.
  2. I’m basically picking up the Updated date, adding 7 days, then comparing it to today’s date to determine if the item must be shifted from green to yellow.

And there you have it…one compliance dashboard.  If anyone has suggestions on how to clean up the look and feel of the dashboard itself, feel free to post in the comments section.



Deliverable Dashboards with SharePoint Workflow

Updating Milestone Reports One Project At a Time in Project Online

One of the main concerns about reporting with OData is that it’s tough to control the specific parameters of the data query on the fly.  The default solution is generally to run one massive query, dump the data into a single repository, and then report on that.  When that massive query exceeds a certain size, performance concerns kick in and organizations need to start looking at the SSIS option that’s been well publicized of late.

The question came up the other day as to whether or not there could be a mechanism to automatically generate queries for each project individually – and thus mitigate potential performance issues.  This post is an attempt to address that using SharePoint Workflow to pull data from OData and deposit it into a centralized SharePoint milestone list.  These milestones may then be reported on within the context of a PDP.

To create this solution, we’ll need a couple of components.

  1. A custom action list with the link to the workflow – as described here. (May need to be adapted to this purpose)
  2. A milestone reporting list.
  3. A workflow to capture the OData milestones and populate the milestone reporting list.

Custom Action List

For this post, I created a simple list that had one required field, the ProjectUID field, and a workflow attached.  This would be the custom action list mentioned above.  (See that blog post for more information).


Milestone Reporting List

This is also a simple list with a couple custom fields to capture the OData values.  I would envision this being added to a PDP and filtered using the QueryString filter on the ProjectUID field.


This list will be populated through the workflow we’ll be deploying to the Milestone Trigger list.

Populate Milestone Workflow

To populate the milestone data, we’ll create a new workflow and apply it to the Milestone Trigger list.  This workflow will consist of 2-3 parts:

  1. Delete all existing milestones from the project on run time.
  2. Get the OData values
  3. Populate the milestone list with the OData values

Note this is all conceptual stuff – i.e. I’m not designing for performance or error handling or anything like that.  I would expect this approach to require some modification before being deployed in a production environment.

Remove Existing Milestones

This part is pretty straightforward.  I’ll just throw a screenshot in here.  You’ll see I loop through and look for any milestone in the master list with the Project UID.  If found, it will be deleted.  If not found, the workflow will progress to the next stage.


Get Milestones

At this point, there are plenty of blog posts on how to consume OData through SharePoint Workflow so I won’t rehash it all here.


In a nutshell:

  1. Build a dictionary to capture the header data for the HTTP call (Accept=application/json;odata=verbose, Content-Type=application/json;odata=verbose)
  2. Set the query string to get the right OData values.


3. Count the number of results using a couple of variables.  (Don’t ask – you just need to)

Populate Master Milestone List

This part is a bit easier.  Iterate through each of the results in the MilestoneList dictionary and create an item in the Master Milestone list for each result.


Put it all together, and execute it, and I ended up with the following log (on a project with three milestones):

  1. Kicking of Milestone Refresh for Project UID = 70ce26da-4251-e411-be78-00155dc21d2f
  2. MilestoneGUID =
  3. No existing milestones found.
  4. Getting Milestones
  5. QueryString =’70ce26da-4251-e411-be78-00155dc21d2f’)/Tasks()?$filter=TaskDuration eq 0M and TaskStartDate ne null&$select=ProjectId,TaskId,TaskName,TaskStartDate
  6. OK
  7. 3 Milestones Returned
  8. TaskID: 97ac721e-8651-e411-8b36-00155d80a23c; TaskName: Task 3; TaskStartDate: 10/14/2014 10:00:00 AM
  9. Item Created
  10. TaskID: 98ac721e-8651-e411-8b36-00155d80a23c; TaskName: Task 4; TaskStartDate: 10/14/2014 10:00:00 AM
  11. Item Created
  12. TaskID: 9aac721e-8651-e411-8b36-00155d80a23c; TaskName: Task 6; TaskStartDate: 10/15/2014 10:00:00 AM
  13. Item Created
  14. Workflow Completed


Updating Milestone Reports One Project At a Time in Project Online

Heading to Tempe on October 16th!

Looking to learn more about how Microsoft’s Project Online will support your strategic project portfolio management capabilities?  Come on out to Microsoft’s Tempe office next Thursday afternoon (10/16) where I’ll be leading a hands on session on the topic.


Please join us for a half-day session to explore how Microsoft Project Online can transform your approach to Project Portfolio Management.

This session is a chance to hear about Project Online, Microsoft’s best in class Project and Portfolio Management solution. Project Online is used by leading organizations around the world to align tactical execution with strategic goals.

Key themes that will be covered include:

•    Data driven, strategic decision making leveraging best in class portfolio analytics.

•    How to successfully leverage project management practices to drive portfolio value optimization.

•    Visibility into your portfolio in the cloud from anywhere and ensuring that work is authorized and reflects the priorities of the business.

Heading to Tempe on October 16th!