That’s okay. That’s because, if I take something off my list and finish it, I can choose what to do next. I might rank projects one way one day and another way the next day. For example, a few weeks ago, we had some high winds, and I noticed some chimney bricks in the yard. I put “fix chimney” on my list. It was pretty low on my list. I had client work and some writing I thought was higher priority. Now, after 12 inches of rain outside and wet carpet in my office, fixing the chimney is at the top of my list. But I take an agile approach to my work, as well as teaching agile to my clients. In order to “fix chimney”, I need to call masons, get them to come out and look at the chimney, get the quotes, compare the quotes, get them start and finish their work which may require me to negotiate how to work with them, and who knows what else. What I’ve listed is the known list of tasks to the relatively large user story, “As a home owner, I want to live in a house with no chimney leaks” and the smaller stories of, “As a homeowner, I want to compare prices and masons so I can get the best person for the job,” and “As a homeowner, I want the chimney work to be done quickly so I don’t have to worry about more rain ruining the carpet in my office.”

And, I have other work to do. But multitasking—literally trying to do two things at once—doesn’t work. I get confused, make mistakes, and more importantly, take longer to finish anything. So, when I look at my to-do list, I make decisions about what is most important—for now. Not forever, just for now. And that means I will interleave my phone calls about my chimney with the client work or writing work I’m doing.

I bet that sounds like multitasking to you. The difference is this: I have each phone call to a mason as a separate item on my to-do list. That means that once I have finished one phone call, I can cross something off my list and go on to the next thing. If the next thing is an article, I can timebox work on that article. If the next thing is another call, I can make that call. I don’t go on to the next item on my list until the thing I’m working on is done.

Now, done can mean many things to many people. I don’t normally write an article in 30 minutes. But, I can timebox an article to 30 minutes, stop it there, save it, and safely move to the next task on my list, because the article is as done as I need it to be for now. As long as I have worked on the article so I don’t have dangling thoughts, my work is complete for the timebox.

Collect, Rank, and Commit to Work
Maybe you noticed a system to my planning. I’ve collected all the work I have to do. I‘ve ranked the work. You’ll notice that some of the work I described in the first paragraph, such as presents to buy, is not even up for discussion. That’s because it’s not on my list of staffed work for now. I’ve decided what’s worth staffing for now—I’ve committed to the work.

Once I commit to the work, I can work on it in small-enough chunks to get to done on the work I need to finish. Now, the only parts left to do are finish the work and periodically re-evaluate the project portfolio. Take a look at Figure 1, the Project Portfolio Flow to see what the flow looks like.

Figure 1: Project Portfolio Flow

Since I’m a business of one, I evaluate my project portfolio formally every week, and when I have emergencies, such as a flooded office. Your organization might want to wait a little longer than every week.

But the nice thing about working in timeboxes, or working off a kanban board, is that you can re-evaluate the project portfolio as often as you complete a timebox or finish a task. If you want to manage the project portfolio weekly, as I do, as long as you make sure the tasks or stories are done, you can re-evaluate the project portfolio.

With project portfolio management, work flows through a team. It doesn’t matter much what the work is, as long as it’s relatively small; the team finishes it as in done-done-done; and that it’s clear what the next piece of work is. The key is that are no unfinished pieces of work.

That’s why project portfolio management is all about decisions for now. The decisions don’t have to be permanent—in fact, they should not be permanent. Because agile and lean approaches to work allow you to re-decide what work is most important for now, you should plan on making project portfolio decisions often. I often recommend that people who are new to agile start with decisions once a quarter, mostly because it’s so difficult for people making the agile or lean transition to break down user stories into small-enough chunks of work that they actually finish all the work they committed to inside an iteration. They need more time to finish enough that’s really done so you can evaluate the current business value.

But once the project team is facile with agile or kanban, re-deciding about the relative ranking of each project in the project portfolio every iteration or every few weeks is a great idea.

Frequent decision-making about the project portfolio means that the organization is always working on the most valuable-to-the-organization projects. Those projects can be the support projects, as my chimney is for me, or growing the organization as columns or articles are for me, or allowing the organization to move in an entirely new direction, as a book might be for me.

Review the Mix of Projects
One of the issues with project portfolio management is to see that the organization is working on a variety of projects. That mix of projects can describe the health of your portfolio.

Just as a healthy financial portfolio does not have just bonds or only stocks, a healthy project portfolio has a mix of different kinds of projects: projects that support the business, that allow the organization to stay in business; projects that extend the current business; and projects that allow the business to move in an entirely new direction. You may not have many new-direction projects—in fact, they are usually so risky that you want to consider starting a few of those projects for just a few short timeboxes or stories and then evaluate what the projects have delivered in terms of business value.

Organizations that are past the start-up stage tend to have many support projects and continue-the-business projects. Unhealthy organizations have no or few new-direction projects. Healthy organizations have a number of potential new-direction projects.

But new-direction projects tend to be high risk and high return. You may not be able to finish them, for any number of reasons.

Imagine you had terabytes of data in a database and you want to allow remote access to that database. But, imagine it’s not 2010, but 1995. We had the net, but we didn’t have the kinds of robustness and speed of access over the net that we have now. If you had tried to start that project, you might well have discovered at the end of that project that you could not provide the reliability or performance that the access required.

But, if you only tried to do several user stories of work and assessed the value of the work at the end of those stories, you would know whether or not to commit to that work now or postpone it until later.

Sometimes, we attempt projects that not only are not easy; they are past our capabilities now. In that case, it’s useful to put projects on a parking lot for now, evaluate them periodically, and decide whether to start them again or keep them on the parking lot.Use the Parking Lot for Projects Not Under Consideration
A parking lot for projects helps you remove the projects from consideration that don’t deserve to be ranked. Maybe they are past your capabilities for now. Maybe they just don’t supply the business value now that you will need. Maybe you just don’t have enough people to commit to those projects right now. Whatever the reason, you want to remove those projects from consideration for now. That’s why you use a parking lot.

A parking lot helps people in several ways. First, it removes the project from direct consideration for now. You can always take projects off the parking lot later. Second, if you are not sure how to start a project, or how to know when it’s done, you can put them on the parking lot and explain why they are blocked. Third, if you want to kill a project, but you need a politically correct way to do so, you have the parking lot.

Maybe you don’t need to park projects. Maybe you can transform them so they do return business value to the organization.

Transform Projects so They Make Sense
I have periodic projects that my husband likes to give me, such as cleaning out my clothes. That’s supposed to involve going through my clothes and weeding out what doesn’t fit and changing my drawers and closet around so that this season’s clothes are in the drawers and the out-of-season’s clothes are in a closet. You may have noticed from my wording that this is not my favorite project!

For the last few years, I have transformed this project. The public reason is that since I’ve been losing weight (on purpose), I don’t need to change what clothes are in drawers—when they are too big, I put them in bags in the closet and eventually give the bags away. I find this ongoing work of try something on, if it doesn’t fit put it in a bag, if it does fit keep it on, a much easier approach to managing my clothes than a whole project. I don’t have too many clothes, so everything fits in my drawers, in-season or out-of-season.

Yes, my husband’s project just lasts one day or a half-day. Yes, it would make my husband happy to see me do this project. But it’s just not valuable enough for me to placate him and do this.

It’s the same idea with projects in your organization. Maybe they don’t make sense the way they are currently organized or configured. In that case, transform them so they do make sense. If they really don’t make any sense at all, it’s time to kill the project.

Have the Courage to Kill Projects
Maybe you’ve tried transforming a project and it’s still not returning business value. Or, maybe a senior manager has a pet project with no perceivable business value.

You don’t have to do those projects. In fact, you have an obligation to the organization not to do those projects.

Once you start ranking projects by business value, and the senior manager buys into that ranking, you can start to kill projects. When you kill a project, it’s dead. No one works on it part time. No one does a little bit to prepare for it. In Star Trek vernacular, “It’s dead, Jim.”

Project Portfolio Decisions Are for Now, Not Forever
The nice thing about agile and lean approaches is that they make managing the project portfolio easy. You can assess the projects and re-decide at the end of every iteration. Or, you can reassess whenever you’ve finished one card in a kanban system.

Because the project portfolio decisions are temporary, it’s easier to commit for now to high-risk projects. It’s easier to decide if a project is not returning enough business value and park it or kill it. It’s easier to decide if a project is not worth anything at all to the organization and kill it outright.

And, because the decisions are for now, not forever, it’s easier to experiment and commit to just one project at a time and avoid multitasking.

Excuse me now, I’ve finished this article, and I need to go back to fixing my chimney.