A Practical Approach To Project Portfolio Management, Part 2

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:

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: 

[ 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:

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.