6 min read

A Practical Approach To Project Portfolio Management, Part 2

Realizing that you can't afford not to have a PMO is half the battle. Now it's time to take inventory.

In the first column in this series I said the question is not, “How can we afford project management?” but rather “How can we continue without it?” I also laid out the two overarching keys to success and the four cornerstones of a prioritization process. Now let’s start digging into those.

Step 1: Inventory the Project Portfolio
Before you can set priorities, you need a project inventory that lists active and requested/pending work, as well as ongoing business initiatives and nondiscretionary and upgrade/release items:

  • Business initiatives include projects to support strategic and tactical business needs; they may be date-driven and have contractual implications (example: acquiring and installing a new sales forecasting system).
  • Nondiscretionary items include regulatory, compliance, and contractual obligations; they are sometimes date-driven (example: a loan-servicing system needs modifications to comply with regulatory changes).
  • Upgrades/releases are initiatives that ensure the infrastructure is up-to-date and, sometimes, help meet contractual obligations. This bucket involves both business and system applications and may be date-driven (example: vendor has released an important upgrade to your accounts payable system).



The delta between total capacity and what's in use at any given time represents available resources to assign to new initiatives.

Depending on your level of project management sophistication, you may or may not have a good handle on definitions for each project. If you’re in the latter camp, start the classification exercise by creating a high-level summary for every ongoing initiative that includes: 

  • Sponsor/owner
  • Initiative name
  • Description and objectives
  • Timeframe
  • Expected results/benefits
  • High-level estimate of duration and costs
  • Expected payback (ROI if available)

[ Are data volumes still spiraling out of control, or have you cracked the problem? Tell us in our fifth annual State of Enterprise Storage Survey and enter to win a 32 GB Nexus 7 tablet. ]

Next, create a spreadsheet of initiatives, including the requesting (owning) department, cost, ROI, and month needed. Assign a category to each, such as: “Grow/Diversify Revenue,” “Improve Efficiency/Expense,” or “Maintenance and Compliance.”

This helps you review the amount of work being requested and performed. Having this information in one spot and tagged with key information will help the team measure the fit of each initiative against the company’s strategy and goals.

Now you’re ready to set some priorities.

Step 2: Prioritization
The objective here is to decide the relative importance of each initiative based on its fit with the company strategy and goals. If you don’t have dedicated project delivery resources for each major business unit, there can be only one No. 1 priority, one No. 2, and so on. Having a forced ranking paints a clear picture for your support teams on how to approach work and will go far in settling conflicts over resources.

If you can resource more than one initiative concurrently, do so. This can lessen the perception of lower-priority work being completely ignored. Either way, keep your focus on prioritizing initiatives within a three- to four-month horizon. Each subsequent prioritization review (done every four to six weeks) should extend forward about one month to keep the process dynamic.

I recommend discussing nondiscretionary and upgrade/release initiatives only during prioritization reviews focused on the time periods  in which they’re needed -- there’s no sense worrying in June about a software update scheduled for December.

Actually attaching rankings to initiatives inside the three-to-four month active timeframe should be a three-step process:

  1. Establish relative priority across all in-flight projects, realizing that prioritization can change over time. Be flexible. If specific timeframes within a month are a concern (say, directly before or after a billing cycle), note that.
  2. Incorporate new nondiscretionary and upgrade/release initiatives. Establish relative prioritization among them andwithin the in-flight projects. Note that discussions in this step usually center on options for delivery dates, level of risk the company is willing to accept in potentially delaying dates, and the scope of the effort.
  3. Incorporate the business initiatives within the timeframe being discussed; again, identify and establish relative prioritization, then merge them within the relative prioritization of in-flight, nondiscretionary, and upgrade/release initiatives addressed in Step 2. Discussion in this step usually centers on aligning initiatives to corporate goals and individual business area objectives -- it also tends to take the longest and involve the most debate.

Design your prioritization process to ensure that in-flight projects get the resources they need to wrap up successfully and on time, unless you make a conscious decision to delay them. Also ensure that nondiscretionary and upgrade/release initiatives are given consideration. This is important for a few reasons. First, it helps avoid the common mistake of focusing only on business initiatives, which creates frustration for IT and the temptation to ignore work on nondiscretionary and upgrade/release items. It’s also critical to have everything in alignment as you move from prioritization to assessment and sourcing/scheduling.

There’s nothing like assigning numbers to bring clarity of vision. Remember: Keep in perspective the relationship of strategic initiatives to those required to keep the business running. However you go about setting priorities, be consistent, consider all factors (not just cost or ROI), and agree as a group on the final rankings. Showing unity to project teams is critical.

A couple of points: Budget approval for a project is not prioritization. Approval gets a project on the list, but it will still need to be ranked against inflight and other pending work. And, just because a project is prioritized does not mean work will begin right away. Stakeholders should realize that only once resources become available and the initiative is the current highest priority will work begin.

As you start this process, it will be difficult to come to consensus, but as the team learns to work together, and project work is moving through the system to completion, it does become easier. I promise.

Next up: Assessment and sourcing/scheduling.

Enterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. In this report we discuss how to master provisioning resources in different clouds; allocate the right resources to each application; and assign applications to the "best" cloud provider based on performance or reliability requirements.