Managing the Pipeline

To this point, we have been concerned with how to leverage use cases to measure the mix of projects in the project portfolio. But we also need to be able to measure if the projects in the portfolio are executable within the times specified by the portfolio given the finite set of development resources in the company. This is called pipeline management, taken from the analogy of software development being like a pipe with fixed throughput capacity. The problem of balancing the portfolio of projects has to take both these dimensions into account: the mix of project types and the quantity of projects that the organization can realistically take on at a given time.

Let's look at how the work we have already done to estimate use case effort and assign use cases to projects can help with pipeline management.

Full Time Equivalent (FTE) Models of the Project Portfolio

Full Time Equivalent (FTE) is a simplified measure of work that provides a quick way to get ball-park estimates of the number of staff needed to get a job done within a specified period of time. Let's walk through a simple example; see Table 8.3. Let's say we have five use cases to implement this month. Each use case is estimated to require 10 work days for one person to implement. That works out to be 50 staff days of effort to implement all use cases. If one FTE is counted as being able to work 20 days a month, to determine the number of FTEs we need to implement all use cases this month, we divide the total effort by 20 (the number of work days for one FTE), which yields 2.5 FTEs.

Table 8.3. Calculating FTEs needed to implement use cases

5	Use cases to implement this month
10	Work days for one person to implement one use case
50	Work (staff days) to implement all use cases
20	Work days in a month for one full-time person
2.5	FTEs needed = Work divided by working days a month for one full-time person

FTE models present us with a 20/80 solution to balancing project portfolios: they are a simplification of the complexities of real life projects, so they are quick and easy to apply to large aggregates of projects. And because they are a simplification of reality, they represent a best-case scenario: if your project portfolio doesn't balance using the FTE model, it most likely will not balance under the messy conditions of scheduling in real life!

Run Chart of FTEs Through Time

A good way to sanity check the project portfolio is to build a run chart of the number of FTEs required to do the work in the project portfolio through time. If the portfolio calls for all the work being done at the same time, say in six months, the run chart will show a large number of FTEs required to implement the work in that period of time. If the portfolio spreads the work out across two years, the run chart will show a quarter of the FTEs required, but for a longer period of time. The sanity check to perform is that the run chart should never call for more FTEs than we actually have available to work. That is the upper limit on our capacity to develop software: the number of FTEs we have available.

Microsoft Project has the capability to generate run charts of FTEs through time, called resource graphs. These are ideal for viewing the data in a project portfolio; your favorite scheduling tool probably provides similar functionality. The run chart in Figure 8.2 was produced by importing combined data from both the project portfolio database and from the use case CM database into Project (see Appendix C for details on how this is done).

Figure 8.2. Schedule and resource graph of project portfolio database generated by Microsoft Project with effort supplied by use case CM database.

As a member of a use case development team, one of the first things you might notice about Figure 8.2 is the time scale: years. Your first reaction might be: Nobody has use case-driven projects that last years! Keep in mind that the time scales are not for one project, but rather all ongoing or planned projects. Portfolio management is about strategic, long-term planning, so a portfolio of projects typically reflects the company's three-year business plan, which is illustrated here. How do you write use cases for a project that won't start for another year? As already noted, use cases that are identified for such projects can be at a very high level of abstraction and with as little as a name and just enough information to provide an expectation of what is intended (refer to the "The Good Thing About Use Cases…" section).

Let's hit some of the highlights of what we see in Figure 8.2.

Gantt Chart: Top Half of Window

Figure 8.2 presents a split window; the top half provides a Gantt Chart view of the projects in the portfolio. The percentage that Project calculates for each project (each line of the Gantt chart) is the number of FTEs needed for that project. An entry like FTE[100%] means one FTE, the equivalent of one full-time person. An entry like FTE[50%] means half an FTE, or one person working half of the time. An entry like FTE[2400%] means 24 FTEs.

Even at this level, you can start spotting problems. For example, you spot what you know is a five-person project that shows up here as requiring, for example, 15 FTEs to accomplish the number of use cases assigned to it in the time allotted by the project portfolio.

Resource Graph View: Bottom Half of Window

The bottom half of the window shown in Figure 8.2 provides the resource graph, which is a rollup of all FTE calculations for all projects in the portfolio. In this way, we get a portfolio-wide look at the capacity being called for to execute all projects in the portfolio.

The Y-Axis of the resource graph is labeled from 2,000% to 16,000%. Again, these entries can be read as the number of FTEs required: 2,000% = 20 FTEs (remember, 1 FTE = 100%) and 16,000% = 160 FTEs.

Notice that the graph has a horizontal line drawn at 8,000% (80 FTEs). This line marks the upper limit of capacity for work of the company in FTEs. The area above this line indicates the extent to which the portfolio calls for more resources than are available. In our example, the capacity for work is exceeded by the portfolio of projects in a number of places by as much as 75%.

For the example here, the company's capacity for work has been set to 80 FTEs. You should set this to the number of FTEs you have to work on the projects in your portfolio.^[18] If your estimates of effort for implementing use cases include all roles associated with software developmentdevelopers, testers, managers, marketinguse that as a basis for the number of FTEs you have available. If, however, your estimates of effort for implementing use cases include one rolefor instance, the bottleneck in your development processuse the number of FTEs available for that role as your capacity limit.

^[18] In Project, this limit is set via the resource sheet.

Keep in mind that the number of FTEs available to work on projects in the portfolio probably does not equal head count. Let's say you have 50 developers, and in your company the same developers who will work on the portfolio of projects also spend 10% of their time doing maintenance, which in our example is not covered in the portfolio of projects. In that case, you really have more like 45 FTEs that are available to work on the portfolio of projects (50 minus 10%). In general, it is rare that 100% of a person's time at work is spent exclusively on projects. So remember to adjust the FTE limit to account for non-portfolio efforts, such as training, meetings that don't relate to the project, sick leave and vacation, and so on.^[19]

^[19] Company-wide down time such as holidays and weekends can be accounted for by adjusting work time in the scheduling tool.