Looking for more portfolio management information? Check out our new corporate blog, recently (re)launched:
…and for the full list of UMT blogs:
Looking for more portfolio management information? Check out our new corporate blog, recently (re)launched:
…and for the full list of UMT blogs:
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:
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.
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:
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
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…..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.
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.
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 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.
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.
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.
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:
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.
For the document library, I added a couple of content types and an Approved field.
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:
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.
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.)
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.
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.
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).
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.
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:
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.
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.
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:
3. Count the number of results using a couple of variables. (Don’t ask – you just need to)
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):