Project portfolio management

case study implementation in a microprocessor design center

Mike Strevell, Program Controller, Motorola M•Core™ Technology Center
Subu Subramanian, Project Manager, Motorola M•Core™ Technology Center
Pamela Cantu, Project Manager, Motorola M•Core™ Technology Center

This paper describes our extensions of project management principles to manage a portfolio of microprocessor design projects at Motorola's M•CORE™ Technology Center (MTC). We started with the Project Manager's triangle—resources, scope, and schedule—and extended it to create the Program Controller's triangle. We extended our resource tracking from the project level to the organization level. We control the scope of our entire organization by prioritizing our projects and opportunities. And finally, we expanded schedule from an individual schedule to managing multiple project schedules simultaneously. In this paper we describe these principles and the tools we are using to control the Program Controller's triangle of Resources, Scope, and Schedule.

The mission of MTC is to create small, very low-power microprocessor cores, which excel in battery-powered applications such as pagers, cellular phones, and personal digital assistants. From a small group of around 40 people in 1997, MTC expanded to 170 people by the summer of 1998. Due to the rapid growth and high need for low-power processors, the number of active projects quickly grew to 30. However, MTC did not have a master list of active projects and the staffing needs exceeded the available people. Requests for new projects continued to increase and we didn't have a formal process to review requests. The Director of MTC recognized the need to institute formal project management to manage the high demand.

Exhibit 1. Resource Needs Chart. Since staffing needs for Thunder and Lightning exceed available resources more people will need to be hired in order to complete these projects on the schedule shown. If needed resources are hired, Lightning's primary deliverable will be delivered in January 2001. Lightning will then gradually ramp down as follow-up and support diminish.

Resource Needs Chart. Since staffing needs for Thunder and Lightning exceed available resources more people will need to be hired in order to complete these projects on the schedule shown. If needed resources are hired, Lightning's primary deliverable will be delivered in January 2001. Lightning will then gradually ramp down as follow-up and support diminish

Exhibit 2. Resource Constrained Chart. This chart shows the schedule impact of not hiring additional staffing for the lightning project. Relative to Exhibit 1, Lightning's primary deliverable slips from January 2001 to January 2002.

Resource Constrained Chart. This chart shows the schedule impact of not hiring additional staffing for the lightning project. Relative to Exhibit 1, Lightning's primary deliverable slips from January 2001 to January 2002

The mandate for our new project management group was to ensure that the right projects were chosen for execution, that schedule commitments were met, and that the organization's resources were assigned to fully staff the highest priority projects. We decided the best place to start managing the project portfolio was to figure out what everyone was doing.

Resources (Staffing)

The first side of the Program Controller's triangle that we needed to control was our resources, or project staffing. We wanted to track what everyone was working on. In MTC, as is likely the case in most organizations focused on advanced technology development, people are our critical resource. It is very difficult, especially in today's market, to hire people with the required skills. We also wanted to know how many people were working on each project. In order to track this information we set up an Excel-based database we call the Resource Allocation and Forecasting Tool (RAFT).

Resource Allocation and Forecasting Tool (RAFT)

RAFT tracks the project assignments for each person by month, as well as their skill. Individual assignments are forecast three to six months into the future.

In addition, each project manager identifies the skills needed for each phase of the project. RAFT counts the number of people assigned to the project, compares these actual assignments to the skill needs, and identifies staffing shortages by project. This is useful not only in recognizing areas of the projects that are under-staffed, but also in feeding back into the long range hiring plan those skills that limit our project execution. Each project manager regularly updates their skill needs spreadsheet to reflect changes.

Exhibit 1 shows the sum of project assignments for current projects plus the skill needs for future projects. The vertical axis is the number of people, the horizontal axis is time, and each area, or layer, represents one project. The horizontal line running across the layers is the total number of resources available to work on projects in our organization. In this example, the total number of resources required exceeds the total available line past April 2000. This tells us that we either need to delay project “Lightning” or get additional resources to execute the project on the proposed schedule.

Individual assignments are fairly accurate for three to four months, or until the end of the project. But past that, it is difficult to forecast assignments by person. However, the skill needs provides an estimate for the number of people that will be required in the future. So we developed an approach for transitioning from individual assignments to skill need forecasts. Actual assignments are used through the current date. For future projections, the total number of people assigned is compared to the skill needs for each project for each month. The greater of two numbers is used in the resource needs chart.

Exhibit 2 is a resource-constrained version of Exhibit 1. The project staffing is leveled to fit under the total available resources line. This is similar to resource leveling on a single project, and represents the scenario most organizations face—due to budget or hiring constraints, they aren't able to hire the needed resources. The staff-years required to complete project Lightning are stretched out over a longer period of time. Project Lightning is now shown completing almost one year later than the original plan, which assumed full staffing. This graphical representation of the resource-schedule tradeoff has been very useful in our organization. It shows the consequences of budget and staffing decisions.

RAFT also allows us to track staffing-related project costs. People are the predominant component of our project costs, and RAFT can provide the number of staff-months for each project. By using our average cost per staff-month along with our organization overhead rate to account for indirect costs, we can closely estimate the cost for each project.

The challenges that we have experienced with RAFT are similar to maintaining any database. In order to keep the information accurate we must update it regularly. We ask our supervisors to update the database at least quarterly, but it often takes several reminders. Supervisors don't object to updating RAFT, they just find it hard to make the time. After they have done it they always express their newfound realization of how useful the information is to them.

The most important aspect of any resource management tool is that it be very easy to use so that managers will be more inclined (or less disinclined) to keep it up to date. In the future we would like to transfer RAFT to a web-based database. A web-based interface will make the information more accessible to our supervisors, and they may even update it more frequently without the reminders.

The ideal would be a unified, enterprisewide scheduling and resource management tool. We have evaluated several tools, but most are better at scheduling than high-level resource management.

Scope

The Scope of a portfolio of projects is much more dynamic than that of a single project. It changes as projects are completed, new project opportunities emerge, and the organization adjusts its strategy to track changing market conditions. In contrast, the scope of an individual project is carefully managed to keep changes low. Portfolio Scope management involves prioritizing projects and selecting opportunities based on profitability, resource constraints and alignment with the organization's strategy. We started by roughly prioritizing current projects with limited hard data, and progressed over time to fine-tuning the prioritization with profitability estimates.

We compiled a complete list of active projects by determining what each person at MTC was doing. One of the advantages of this step was that it helped people view their efforts from a project viewpoint rather than a functional viewpoint. To this list of active projects we added known project opportunities. We collected the information that was available on the resource needs and profitability of each project and opportunity on the list. The result was a comprehensive list of current and potential projects.

We established a decision board to prioritize this list. This board, called the Program Steering Group (PSG), is comprised of the director and staff at MTC. The PSG started by clearly formulating the organization's strategy, including what the organization should and should not do. Each PSG members prioritized the comprehensive list of projects based on available information and their perception of its profitability and alignment to the strategy. We averaged the individual inputs and presented the results to the Director of the organization.

The Director classified the projects into three different categories: Commit, Cancel, or Hold. We staffed projects in priority order. When we ran out of people, the remaining projects were either canceled or put on hold. The “Cancel” classification is very important. Canceling projects is often a very difficult step for an organization to take, especially when resources have already been spent on the project. Projects that are low in priority, low in profitability, or not aligned with the organization's strategy need to be canceled. Canceling these projects allows resources to move to high priority projects. The director then communicated the resulting prioritized list of committed projects, canceled projects, and future opportunities to the entire organization.

After completing the original prioritization effort, the PSG now meets once a month to evaluate new opportunities and reprioritize committed projects and known opportunities. When evaluating a new opportunity, we require the product groups to present the following information: (1) profitability analysis, (2) total resource needs, and (3) required delivery dates. We use an Excel-based worksheet called Chip Profitability Analysis (CPA) to analyze profitability of products. CPA is a complex worksheet that uses market data including size of the market, projected market share, and sales price in conjunction with die size, manufacturing cost, and development costs to estimate the Net Present Value (NPV) of the project's profit stream. We created a one-page summary sheet that extracts the key values from the CPA for easy review. We normalize the NPV by dividing it by the number of person-years required for development of the product. The NPV per person-year is a key input the PSG uses to prioritize the project. We also combined the NPV of all M-CORE projects to summarize the return on Motorola's investment in MTC.

Schedule

The final side of the Program Controller's triangle is schedule. MTC holds project reviews to track the progress of our projects. In conjunction with project reviews, we use a web-based tool called Dante to track project schedules at the portfolio level. In addition to Project Reviews and Dante, we use two metrics to measure the progress of our schedules—Earned Value and weighted slippage factor.

Dante

Our organization uses an internally developed web-based Program Management Information System (PMIS) called Dante, which tracks projects through all phases. The project leader is responsible for maintaining in Dante their project information such as stakeholders, milestones, schedule, risks, and issues. For more information on Dante, see the PMI 2000 paper “Dante: Getting Out of the Inferno” in the Global Project Management track.

Project Reviews

We conduct monthly project reviews at which each project manager presents a one-page summary of their project, which is generated by Dante. The one-pager includes the project objective, risks, issues, and milestones. To encourage management by exception, there is no status section on the one-pager. In the past our project reviews were bogged down by lengthy reports on what the team did the previous month. Critical issues were often buried in the information overload. Now our project reviews are a forum for project leaders to escalate to upper management the risks and issues that may prevent a project from completing on time. To make this process successful, we have also educated our managers to not “shoot the messenger.”

Earned Value

Along with the one-page summary, each project leader presents earned value at the monthly project review. Employees at M-CORE do not track actual hours spent on tasks, so our Actual Cost of Work Performed is based on the number of people assigned to the project. The number of people assigned is derived from the resources on the schedule and is crosschecked with the information in RAFT.

Weighted Slippage Factor

The second metric that we use to gauge the overall project performance of our organization is weighted slippage factor.

First we calculate the slippage factor for each project, where:

Slippage Factor = Actual Duration / Planned Duration

In order to avoid eternal optimism, we use the most recently completed milestone rather than the estimated project completion date for both actual and planned duration. Specifically:

Slippage Factor = (Actual Date of Last Complete Milestone – Project Start Date) ÷ (Baseline Date of Last Completed Milestone - Baseline Start Date)

We then weight each project's slippage factor by the number of people assigned to the project. Weighting by “number of people” more accurately represents the status of all work in the organization.

Conclusion

Over the past 18 months, we have used the processes described in this paper to successfully consolidate and manage the project portfolio at MTC. We measure our success by on-schedule projects and the conversion of project management skeptics into believers in this short time:

• MTC has delivered on schedule on all customer commitments. Customers have expressed their confidence in MTC's ability to deliver on its commitments in a timely manner.

• Executive management, both within MTC as well as its parent organizations, has appreciated visibility into accurate status of projects and resources, as well as easily accessible information to make informed decisions.

• Several processes and tools described in this paper, such as CPA, CPA summary sheet, project prioritization process, and RAFT are being used by other organizations within Motorola, with minimal support from MTC.

• Last, and most important, the design community within MTC, which initially looked upon project management as another management fad, has experienced the satisfaction and rewards of completing projects on time. They appreciate the benefits of a disciplined process that results in realistic, well-planned schedules and reduces scope creep, which protects them from overload.

Lessons Learned

Following are some lessons we learned along the way:

• If you're not sure where to start, start by figuring out what your people are doing. Good resource tracking is critical to portfolio management.

• Start with imperfect tools and processes and fine-tune them along the way, rather than waiting for a perfect tool. A simple tool available today is better than the promise of a grand tool in the future. As General Omar Bradley said: “The brilliant execution of a mediocre plan will outdo the mediocre execution of a brilliant plan every time.” For example, we started with a simple resource management tool based on Excel, rather than waiting for an enterprisewide resource management tool that was promised several years ago.

• Make tools and processes as easy to use as possible, especially if they will be used by part-time users who have other jobs. For example, we found that an inexpensive, widely available scheduling tool was much easier for our engineers to use than an expensive, more powerful scheduler. The simple scheduler was sufficient for our projects.

• It is very important to make sure the assumptions underlying any results are exposed for scrutiny. For example, the CPA tool computes a specific profitability number that is useful in prioritizing projects, but the marketing, manufacturing, and development assumptions that drive this number are not always apparent to the decision maker. This was the reason we designed the CPA summary sheet to present the key assumptions and results in a single, easily read page.

A disciplined use of the techniques described in this paper to manage resources, scope, and schedule will provide the foundation for the successful management of a portfolio of projects.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.