When you start gathering data to help your portfolio decisions, as in Section4.2,Decide to Commit, Kill, or Transform the Project, on page52, you might be able to more easily make a decision quickly. When the project teams know they will have to produce this data, they may be able to help you make the decisions too. I recommend you start with just the project portfolio burndown chart.
Remember, just as you can’t calculate ROI for a project as in Sec- tion 5.9, Don’t Use ROI to Rank, on page 81, you can’t calculate ROI for the portfolio. But if you use a lean approach for the portfolio and an agile or lean approach for your projects, you don’t have to try. You’ll see value, or lack thereof, every time you evaluate the portfolio and can make the small adjustments you need for the organization.
In addition to the project portfolio burndown, you might need to track other data for your organization.
• Number of iterations completed, cost per iteration, total cost for the project to date
WHATYOUNEED TOMEASUREABOUT THEPOR TFOLIO 156
• Capital expenses for the project
• When you can capitalize software
• Number of simultaneous projects you are asking teams to work on
10.9.1 Expensing vs. Capitalizing Software
I’m not a lawyer, nor am I an accountant. You should talk to your legal and financial people to hear what they have to say, especially if your government mucks around with the issues of expensing or capitalizing software.
If you’re not familiar with these terms, here’s what they mean. Expens- ing software means you pay for the cost of the product as you develop it. The expense comes out of the organization’s cash flow and off the income statement. Expensing has an immediate effect on the organi- zation’s profit and loss statement. When you pay for software as an expense, it means that the software has no inherent value as an asset to the organization.
Capitalization is different. As the software is developed, some part of it is considered an “asset” to the organization, not just an expense.
Because it’s an asset, it’s expected to provide a greater value when it is sold than the value it currently has. If you were making a table, the cost of the wood is an expense. But at some point, as you make the legs and the topandput it together, the table has more value than the cost of the wood or the workers’ pay to make that table. The table is an asset and can be sold at a higher value than the expenses. It’s the same idea with software.
If you always generate running, tested features, you are creating an asset. I don’t know when your software is an asset that you can cap- italize. You, your lawyers, and your accountants are the only people who can decide that. But if you are tight on cash flow, make sure you know when you have to start counting your software development as an asset, because that may change when you need to finish a project.
10.9.2 How Many Simultaneous Projects Are You Asking a Team to Work On?
If the answer to this question is greater than one, you’d better have a good reason. Once teams attempt to work on more than one project at a time, they make less progress on all projects. That puts you in a position of not being able to manage the portfolio, being in a position
WHATYOUNEED TOMEASUREABOUT THEPOR TFOLIO 157
Project Progress
0 2 4 6 8 10 12
1 2 3 4 5 6
Month
Features
0 10 20 30 40 50 60 70 80 90
Defects (Trend Line)
Features expected to be done Features actually done
# simultaneous projects
#Defects remaining open
Figure 10.1: Project progress, reducing and eliminating multitasking
like Figure2.2, on page31instead of being in a position where you are managing the portfolio, as in Figure2.1, on page30.
But what if you’re transitioning to agile and lean approaches and you don’t see another way out of the current mess you’re in? What if you’ve decided that instead of one- or two-week iterations on just one project, you are willing to staff the team to two projects for four weeks? If you track the number of simultaneous projects the team is working on and track their velocity and technical debt, you might be surprised.
Early in my management career, I thought that asking a team to work on “just” two projects was a good idea. After all, I’d stopped having everyone work on four projects. I must be doing a good job, right? The people were working in cross-functional feature-based teams, so they had everyone they needed to finish the work. They were using contin- uous integration. I did see a little improvement in the first month (see Figure 10.1). But notice how much more improvement there was, not just in the number of features but in the reduction of defects, when I finally told the teams to work on just one project.
MEASURECAPACITY BYTEAM, NOT BYINDIVIDUAL 158
How to Create a Chart Displaying Multiple Types of Data If you’ve never tried to create this kind of a chart in Excel, here’s how. Make the bar chart line. Now, select the data you want to add as a trend line. Select the chart and “paste special.” Bring up the contextual menu with a Ctrl-click or right-click depend- ing on your machine, and you can select the trend line format.
In Numbers, you can select a “mixed chart” type and follow the instructions.