How Are You Currently Invested?

When you balance your investment portfolio, you are looking at the allocation of money across various investment instruments of different types (e.g., stocks, bonds, and cash). When you balance your project portfolio, you are looking at the allocation of resourcesthe efforts of your staffacross a set of projects of different strategic types (e.g., new product development versus extensions to existing "cash cow" products).

Say you walk into your local Fidelity Investment or Charles Schwab office and tell them you need help with your investment portfolio. Before they even begin to determine the mix of stocks, bonds, and cash you need based on your investment objectives and risk tolerance, the first question they are likely to ask is "How are you currently invested?" And, as Cooper et al. (1994) suggest, this is a good place to start with project portfolio management as well. So ask yourself, for all your projects that are already underway and for all your projects that are planned for the futureyour current portfolio of projectshow is your staff effort currently invested by strategic project type?

This is the first fundamental question we will look at answering by leveraging use case CM.

Inventory of Projects

The first requirement for a balanced portfolio of projects is…a portfolio of projects! If your company has one of these, much of the work is already done. But you may find that the process described in this chapter is a very useful sanity check on your portfolio, comparing what you think your allocation of resources looks like versus what your use case CM data reveals.

If you don't have a portfolio of projects, you'll need to build a database that lists the inventory of all projects you want to manage. While conceptually simpleyou make a list of all projectsit can be a politically charged activity. But, remember, this could well be one of the best investments in time you will ever spend in improving the quality of your staff's work environment and, consequently, the quality of the products they produce.

A project portfolio database need not be complicated. Here is basic information you can track for each project:

Project Code: An alphanumeric code that uniquely identifies each project in the portfolio. This serves as the key in your project portfolio database.
Project Name: The common name of the project. I recommend not using a project name as a key in a project portfolio database; names change too frequently and hence are not stable as a key.
Duration: The amount of time that you expect the project to last. A common measure for duration is calendar work days. Because a portfolio database deals with both projects that are underway and those planned for the future, this will range from semi-accurate (former) to best estimates (latter).
Start Date: The project's estimated start date.

Note that Duration and Start Date don't have any relevance to the mix of project types in your portfolio, but are key to pipeline management. We'll go into more detail about this later.

In addition to these fields, each project in the portfolio needs to be categorized however you want to balance the portfolio (e.g., the same way you balance your investments in terms of cash, bonds, stocks, and so on). There may, in fact, be several different ways you want to slice and dice your projects, risk and reward being two common ones (If a large percent of your resources is spent on high-risk, low-reward projects, you have a problem!). A field is added to the database for each dimension along which you want to categorize your project portfolio. For our example, we'll stay with one category, which we'll call Project Type. Each project in the portfolio will be categorized as one of the following types:

New Product Development: Projects that establish new products for your company. This could be done as part of your expansion into new markets or to replace aging products.
Cash Cow Extensions: Projects that develop new functionality for your existing, mature, cash cow products.^[11]
^[11] "Cash cow" is industry lingo for a typically mature product that is a main source of revenue for the company.
Custom Development: Projects that involve custom work for a specific customer. Companies may be concerned about the amount of custom work they do because it is often not reusable with other customers and can drive support costs up.
Research: Projects that experiment with new ideas. This is typically an internal release; we'll assume here that these do not generate any revenue for the company but are needed to pave the way for new product development, and so on.

Figure B.1 in Appendix B, "Bare Bones Project Portfolio Database and Use Case Metadata," shows a Microsoft Access table for a bare-bones portfolio database implementing these fields.

Having defined these project types, an obvious question is "What is the right balance?" Our goal is not to answer that question but to provide the tools to measure the current allocation. The process for deciding what is right for your company is literally a book in itself and has been thoroughly covered elsewhere. However, let us assume for the purposes of this example that you have a target mix in mind: your company strategy calls for the allocation of development resources shown in Table 8.1. If your company already has a project portfolio database in place, this could represent the mix that you think you have.

Table 8.1. Target allocation of resource by project type
Project Type	Percent of Resource Allocated
Cash Cow Development	50%
New Product Development	40%
Custom Development	5%
Research	5%

Now let's turn our attention to the role of the use case in project portfolio management.

Metadata Needed for Use Cases

Our goal is to measure the current planned allocation of development resources against each of the identified project types. To do this, we'll estimate the effort planned for each project in the portfolio, and then roll the results up by project type.

It is in the estimation of the planned effort for each project that the use case comes into play. By estimating the effort of each use case in a project, we get a bottom-up estimate of the overall project effort. We'll discuss this more later. For now, we just need to make sure that after the effort of a use case is estimated, we have somewhere to record it in the use case CM database.

Here's an example of metadata we need to associate with each use case (Figure B.2 presents this information in a Microsoft Access table):

Use Case ID: An identifier that uniquely identifies the use case as a configurable item.^[12]
^[12] If you are using a commercial requirements management tool or commercial source code CM tool an identifier is generally automatically generated for each configuration item. If you are building your own database for use case CM, you'll need some ID such as this. The use case name can't be counted on to uniquely identify a use case, nor is it a stable field (i.e., it is very likely to change over time) so it is not suitable as part of the key.
Project Code: Use case metadata specifying the project code of the project in which a use case is to be implemented. This field ties to the field of the same name in the project portfolio database.
Estimated Effort: Use case metadata providing an estimate of the effort to implement the use case; for example, staff days: 3 staff working for 10 working days = 30 staff days. It could well be that one use case is implemented across multiple projects, which we'll discuss later.

Notice that the effort to implement a use case is ambiguous. This could either mean the effort of all roles associated with software development, such as developers, testers, managers, marketing, and so on, or it could refer to just the effort of one role, such as developers (i.e., the ones who design and code). For our purposes, it doesn't really matter which interpretation you care to use, with one caveat: a portfolio balanced for one role might not be balanced for all roles unless your organization has the right ratio of staff for each role. This is particularly true for the ratio of testers to developers, the two biggest staffing requirements for most software development projects. If the ratio of testers to developers is not sufficient, the development organization can produce far more (unstable) code than a testing organization can test. Balancing a portfolio of projects based on development resources will do little to alleviate overloading on the testing group in this case. In short, if you want to do portfolio balancing for just one software development role, figure out which is your bottleneck and balance to that. It won't be perfect, but it's a good 20/80 heuristic.

Assign Use Case to Project and Estimate Effort

After metadata fields are set up in your use case CM database, all that remains is to assign each use case to the project it will be implemented in (i.e., assign it a project code) and provide an estimate for the effort required to implement it. It's important to keep in mind that this is not an activity a single person is likely to undertake (i.e., assigning use cases to projects and estimating effort for use cases across the company). With a CM framework in place, development teams will perform this task, enterprise wide, for the use cases of their projects. With a possibly wide variety of application types and a wide variety of staff doing the estimation, you could very well wind up with a variety of estimation styles and accuracies. But, luckily, for portfolio management, it's probably OK.

For project portfolio management, one doesn't necessarily need pinpoint accuracy in estimates. First, because we are working at the portfolio level, we are dealing with an aggregate of use cases, so underestimates in one use case will likely cancel overestimates in another: the law of large numbers from statistics is on our side.^[13] In the worst-case scenariowhere estimates are made via the WAG^[14] methodwe can almost be certain that any estimate for a project made by bottom-up WAGs on use case effort will be closer to the truth than a single WAG on the project as a whole.

^[13] Breaking a big task into smaller ones, and then estimating their effort to derive the estimate for the whole is a common project estimation technique. It works because errors made in the small tend to cancel one another out: you overestimate one, but underestimate the next. See (McConnell 1996) for more discussion on the Law of Large Numbers as an estimation technique.

^[14] WAG stands for Wild A** Guess, a common software project estimation technique.

Besides, if your project portfolio is really out of whackand industry trends suggest there's a good chance it probably isbeing off a bit on a use case estimate here and there is not going to make a significant difference.

Techniques for Estimating Effort

Though we don't need to necessarily take a rocket-science approach to use case estimation for portfolio management, it's still worthwhile to have some ideas on how to approach the problem in order to provide guidance to development teams. Here are some examples illustrating three common themes in estimation of effort: effort based on size, historical data, and collective wisdom and experience.

Use Case Points: Estimation Based on Size

When dealing with use cases where ample detail is provided and teams are inclined to be as accurate as possible, use case points are an option. Briefly, the estimate of effort is driven by an estimate of use case size in terms of number of transactions between user and system, number of scenarios making up the use case, and number of analysis classes (if available). The size estimate is then calibrated based on various factors, such as technical complexity of the application and team and environmental factors. The final calibrated use case point count is then converted to an effort estimate. Use case points were originally researched by Gustav Karner and are a derivative of Allan Albrecht's Function Points applied to use cases.^[15]

^[15] See (Schneider and Winters 1998) for more detail, particularly the section "Estimating Work with Use Cases" in Chapter 8, "Use Cases and the Project Plan."

Estimating XP Stories: Estimation Based on Historical Data

In Extreme Programming (XP), estimation relies heavily on historical data. A new storyXP's counterpart to the use caseis compared with one you've done in the past, the true implementation effort of which you now know. That historical data is then used to estimate the effort to implement the new story (e.g., it's twice as hard, or half as hard, as the previous one). For use cases that are briefly fleshed out because they are part of projects in the portfolio not scheduled to start for a while, this approach is a good option (Beck and Fowler 2001).

Wideband Delphi: Estimation Based on Collective Wisdom and Experience

A general group problem-solving technique that is often applied to project schedule and effort estimation is Wideband Delphi (Boehm 1981).^[16] Briefly, a team, through an iterative process of making individual, anonymous estimates, followed by show-and-tell, and then group discussion, converges on an estimate all team members agree upon. In the process, tacit assumptions and information held by individuals is brought to the surface for the group as a whole to see. In a workshop setting, any number of streamlined variations on this theme can be used to allow a team to crank out a lot of use case estimates in a short amount of time.

^[16] Originally described by Barry Boehm in the book Software Engineering Economics (1981), there are ample sources describing this technique.

What About Use Cases Implemented Across Projects?

You may have a use case that will be implemented across multiple separate projects. I have been involved in cross-company, multi-project programs where use cases were used to show how several products worked together in large cross-product workflows. The same would be true for a use case that crossed component boundaries and where the components were being implemented in separate projects by separate teams.^[17] For these instances, in terms of CM, you can either introduce a separate project code for cross-project use case work, with effort representing all projects, or each project can have its own "version" of the use casefrom its perspectivefor which it is responsible for CM and which includes the effort for their piece of the use case.

^[17] An example of use case-driven distributed development across separate component teams is presented in Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization."

Checking the Mix

An inventory of projects has been made and categorized by project type. The use case CM database has been extended to include metadata about project code and effort. Development teams have allocated use cases to the projects in the portfolio and estimated the effort to implement each. We are now ready to run a report that measures the allocation of estimated effortvia use casesagainst project types. Figure 8.1 illustrates the use of a pie chart for just this purpose. Figure B.3 in Appendix B provides the Access database query that totals the effort by project type used to generate this pie chart.

Figure 8.1. Pie chart of effort to implement use cases allocated by project type.

With a breakdown of effort by project type available, we can now compare the target portfolio mix against actual. A comparison of target goals for allocation from Table 8.1 is compared with actual contents of the portfolio in Table 8.2.

Table 8.2. Comparison of target versus actual content
Percent of resource allocated by project type in project portfolio
Project Type	TargetPercent of Resource Allocated	ActualPercent of Resource Allocated
Cash Cow Development	50%	29%
New Product Development	40%	59%
Custom Development	5%	8%
Research	5%	4%

As the comparison shows, actual contents of the portfolioas modeled by our inventory of projects and planned use casesare not in synch with the target allocation of resource by project type. The current portfolio of projects has less effort in Cash Cow Development than we want and too much in New Product Development. Planned work in Custom Development and Research are pretty close to target allocations.

We started out this section asking the question "How are we invested?" i.e., how does our portfolio of projects allocate the company resources by strategic project type. By leveraging our investment in use case CM as a means to do bottom-up estimation of effort by project, we've identified a framework for answering this question on an ongoing basis. In Scott Ambler's Enterprise Unified Process, results such as those in Table 8.2 would be reviewed by the portfolio management team at its periodic meetings, probably quarterly or semiannually. For our example, the results of Table 8.2 indicate that some adjustments to the portfolio are probably needed. But before making changeskilling some projects and removing scope (use cases) from othersthere are more questions a portfolio management team needs to answer.