25 Years, a New Site, and a New Blog

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

http://www.umt.com/blog/25-years-service-brand-new-website/

…and for the full list of UMT blogs:

  1. The Corporate Team: http://www.umt.com/blog/
  2. The Development Team: http://www.umtsoftware.com/blog/
  3. The Product Team: http://umt360.com/blog/
  4. The A Team: http://azlav.umtblog.com/
Posted in Self Referential | Leave a comment

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.

image

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.

image

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.

Posted in Portfolio Management | Leave a comment

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 

Posted in Events | Leave a comment

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.

image

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…..you 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.

image

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

image

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.

https://servername.sharepoint.com/sites/pwa/Document%20Dashboard/_layouts/15/start.aspx#/_layouts/15/Workflow.aspx?ID=1&List=%7BEBFC7875%2DDF56%2D4796%2DB166%2DFF727190053C%7D

image

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.

image

The trick is on the Workflow Settings screen…

image

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.

image

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

Posted in Project Online, SharePoint, Status Reports, Workflow | Leave a comment

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.

Posted in Portfolio Management | Leave a comment

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.

image

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:

image

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.

image

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.

image

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.

image

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.

image

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.)

image

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.

image

image

Posted in Collaboration, PMO, Project Online, SharePoint, Workflow | Leave a comment

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).

image

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.

image

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.

image

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.

image

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.

image

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.

image

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 = https://servername.sharepoint.com/sites/pwa/_api/ProjectData/Projects(guid’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

image

Posted in Uncategorized | Leave a comment