Table of Contents | Archive

Another Look at Project Portfolio Management

By Donna Fitzgerald

A year ago, I edited a magazine issue on project portfolio management (PPM). At that time, our discussion was focused on whether or not a good PPM process required tools and infrastructure or simply a decisive mind-set. The consensus of the authors was that without an infrastructure, even the most decisive organization would eventually lose focus and begin to sub-optimize its portfolio.

Looking back over the past year, I would say that all of the columnists were right, but our comments failed to address the single greatest pain point for most organizations: correctly matching resource capacity to planned projects. This seems to be the problem that doesn't have an easy solution.

According to conventional PPM wisdom, the solution to this problem should be obvious: initiate fewer projects. But that's advice most companies don't want to take at face value. The most frequent counter I hear is that if project estimates are correct, and the organization has the people, why drop the number of projects below what the organization “should be able to handle”? After all, the argument goes, given tight IT budgets, no one can afford to have people sitting around doing nothing just to solve an occasional peak loading problem.

PPM practices, at their core, focus on strategic fit, return and risk across the portfolio. Resources are a factor in the analysis, but good portfolio analysis shouldn't concern itself with details such as resources. At the highest level of PPM, the goal is to look at what projects should be done and why. If the project list that achieves all the company's goals can't be accomplished because of lack of resources, then and only then should the company decide whether to add more resources or scale back the list of approved projects.

Some software vendors imply that PPM can be more efficiently done if detailed resource information is available to executive decision makers. But, from my perspective, it is a waste of time to ask executives to make decisions that are better made at lower levels. It's for this reason that I have recently come to advocate a concept I'm calling Scalable PPM. By this I don't mean to imply that all generic PPM practices can't work at any level of the organization. My use of this term implies that there are different things that need to be done at each level and that the correct view of PPM is that it works best when the focus is simultaneously on both the top-down process and the bottom-up process.

Executive Responsibilities

Beginning with the top-down process, executive management needs to take responsibility for the following activities:

• Evaluate the list of projects
  • Confirm alignment
  • Determine level of acceptable risk
  • Define value threshold
  • Confirm timing
  • Confirm high-level resource capacity
• Prioritize projects
  • Group projects by line of business (LOB), product or function
• Eliminate the bottom tier by cutting, canceling and killing projects

Once this review has been completed, the prioritized lists, segmented by LOB, product or function, can be given to the next level of management for their review. Segmenting the portfolio by function or LOB has a number of advantages. Most companies segment their IT resources by one of these categories. This ensures the resources are indeed available. It also ensures that the responsibility for successful implementation rests with the people who are on the front lines.

Since the focus of this article is on resource capacity, it's important to highlight that one problem with delegating a “pot of money” down to the next level is that there is a strong possibility that the organization's resource capacity will be artificially constrained because the “best” resources may not reside in the organization that has the highest priority projects. One infrastructure change that will facilitate good PPM is a center of excellence, where resources are available to move across functional lines. I've seen different companies implement this idea in different fashions.

At Oracle, we centralized some of the more highly skilled resources into a formal center of excellence and then matched the resource to the project's needs and priority. At Intel, we solved that problem a little differently. Rather than centralize any of the resources organizationally, we created a virtual labor pool through a policy of frequent transfers. An annual ranking and rating of all employees ensured that highly ranked individuals were moved from group to group every year or two in order to meet the ever-changing needs of the organization.

Another factor to consider here is that people really aren't plug-compatible “resources,” even though we often talk about them as if they are. As a project manager, I can attest that a team of 100 people might be a recipe for failure, whereas a team of the right 15 people may be able to succeed against all odds. The more closely people and projects can be matched, the higher the probability of success. This is one of the reasons I would lean toward the Intel system as being the more versatile technique. The ranking and rating at Intel is always based on current performance, which prevents some of the inefficiencies of building an organization that risks becoming a “caste system.” The role of a conventional center of excellence should be limited to a very few people who can operate at the mentor level and whose presence can elevate the performance of the team as a whole.

Line Management Responsibilities

Assuming that the organization has established some sort of flexible staffing policy, the prioritized list of projects should then be handed to the next level of management for implementation. Responsibilities at this level include:

• Re-evaluate the list of projects
  • Confirm resource availability
  • Confirm cross-project dependencies
• Evaluate maintenance and enhancement efforts

• Establish monitoring procedures (e.g., a project steering committee)

Re-evaluating the projects at this level is not intended to give line management an opportunity to completely re-adjust the portfolio. Rather, it is intended to recognize the fact that executive decisions now need to drop down to this level in order to have any chance of being implemented. Focusing specifically on resources, this is the level where the matching of people to projects occurs. Since it is standard practice in most PPM methods to exclude these activities from executive review, this is also the level where the organizational impact of maintenance and enhancement activities needs to be accounted for.

In order to more tightly align resource capacity to a project, the mapping of all enhancements activity into a product road map and the scheduling of this work according to a product release plan must happen at this level. The impact of this one process change is significant. A product road map offers increased visibility to everyone in the organization, allowing for the prioritization of enhancements. Prioritization can't happen if enhancements are received on a piecemeal basis. For COTS systems, a product road map makes it easier to avoid duplicating enhancements that the software vendor is intending to provide.

The second way to control your resources is to embrace a more agile form of software development. Frequent releases of the product and continuous testing decrease the number of post-implementation bugs and required enhancements, thereby enabling your people to focus their efforts on new projects rather than past projects.

Project Level Responsibilities

Assuming the right decisions have been made at the executive level and that line management has implemented the correct organizational and support systems, the final element of solving the resource capacity problem lies with the project manager and/or the immediate department manager. It's the project manager's responsibility to know what's going on with her staff. If a team member is completely overwhelmed because he has too much work, then the problem needs to be fixed, either as a one-off solution or at the structural level, depending on the source of the problem.

This returns us to one of the reasons I am advocating the concept of scalable project portfolio management. When a structural problem (e.g., we messed up and started too many projects) is identified at the lowest level, it needs to move back up the organization until it can be solved. Depending on the culture of the organization, carrying this message back up the line is the job of the project steering committee. Of course, the project manager could do it herself, but some organizations still believe in “shooting the messenger.”

Conclusion

A good PPM process does require structure, but from my perspective, that structure isn't necessarily dependent on software tools or fully deployed project management processes. By taking a scalable approach to PPM, each level of the organization can concentrate on making decisions and setting up the management structures that will encourage the visibility and flexibility an organization needs in order to obtain results. After all, the most expensive PPM software in the world coupled with the best project management processes still won't help if the organization continues to approve too many new projects and fails to support those projects already underway. By adopting a PPM process that empowers people to solve the problems in front of them, I believe most of the resource capacity problems that organizations are currently experiencing can be solved.

Donna Fitzgerald is a senior partner with Knowth Consulting, specializing in portfolio and project management. She is also co-founder of the NewGrange Center for Project Management, www.newgrance.org, a worldwide nonprofit project management organization. Fitzgerald has more than 20 years of experience managing projects at Oracle, Bell Atlantic, SUN, Intel and Nortel.

Submit an Article to ESI Horizons

To inquire about contributing articles to ESI Horizons, contact the Horizons editor at horizons@esi-intl.com. Please review our submission guidelines.