Decisions, Decisions, Decisions


If you're working on more than one project at a time or if your managers are asking you to do so, it's time to make some decisions. Not every project should be started or finished, and certainly no one person or team should work on all projects at the same time. The organization needs to make some decisions about whether to commit to a project, kill it so it doesn't interfere with other projects, or transform it so it can succeed in a reasonable time.

Dear JR:

"I'm on three different must-do projects. I can't tell if they are all really "must do." If they were, wouldn't my managers decide which one I should be on?" - A Harried Developer

Dear Harried Developer:

If you're in this position, as a developer, tester, project manager, or some other person charged with helping complete projects, I can sympathize with you. You have managers who have made only a partial commitment to each of your projects. If you're a manager, there's a tool you can use to decide which project each staff person should work on for now—the project portfolio.

Some managers don't realize that the portfolio decision of when to do which project isn't a final decision for all time but a decision for now. It's much easier to realize that when you have agile teams all working in the same duration timeboxes. Even if you don't have agile teams, you can still decide when to start and finish each project.

Make a Real Commitment
When you commit to a project, make it a full commitment, meaning that all the necessary people are on the project full time and that they have all the necessary resources they'll need, such as a project room, computers, networks, white boards, and sticky notes.

When you make a commitment to a project, decide how long that commitment should last. If you only evaluate the project portfolio once a year, then the commitment is for the entire year. I can now hear some of you saying, "JR, we only formally evaluate the portfolio once a year, but our managers change their minds every week." If you're in that situation, start working in timeboxes of one week in which you commit to completing no more than one week's worth of work at a time. That way, if your managers change their minds, at least you've finished something. You shouldn't incur more context switching costs.

For those of you working on waterfall projects, working in one-week timeboxes can be agonizing. You can only make very small increments of progress in a week. Also, usually the progress made at the beginning of the project is just on specs and plans. But, if you only have a week to work before you have to move to another project, you can actually accomplish more because the timebox focuses you, the entire team, and, as a result, the organization on this project.

One of the reasons managers in waterfall-project organizations have such a difficult time deciding which project is top priority is that the projects rarely release something useful. If you can't tell when you're going to get a project done, it's much harder to commit to it for a long period of time. That's why a commitment for now works better. Then all you'll have to do is define the for now time period.

If you use an agile lifecycle or any kind of lifecycle that allows people to see progress more often than just at the end of the project, you can also decide the lengths of the commitments. The least amount of time for a commitment should equal the length of an iteration in an agile project, when a feature is complete in an incremental lifecycle, or when a piece is ready for evaluation in an iterative lifecycle.

The key is to make a real commitment. If the managers can't commit, put this project on the project portfolio backlog for now. You can always move it from the backlog to a committed project when you have people and resources available.

What happens if you've committed to a project but the project isn't making progress? Then maybe it's time to kill the project.

Kill Projects When Necessary
I once worked on a project that was stuck in the mud. We had no way of moving forward; the state of the hardware was not sufficiently advanced to let us do what we needed to do in the software, yet my managers kept exhorting us to work harder. When that didn't work, they told us to work smarter. After a particularly frustrating day, when a senior manager told me, "Just work smarter," I sarcastically said, "Gee, I thought I'd have a stupid day tomorrow." Not my most career-enhancing moment.

When you work on a project that can't make progress or has no more value to deliver, it's time to kill that project. I prefer the word "kill" to Peter Drucker's word of choice, "abandon." I like the conscious decision making you get with "kill," rather than letting projects fade into the twilight as "abandon" might imply.

Keep in mind that the decision to kill projects doesn't have to be permanent. In my example above, we "shelved" the project for about a year. Once the hardware caught up to what we needed, we finished that project in three months.

Shelving a project (i.e., putting the project on the project portfolio parking lot or backlog) is a great way of killing a project for now. Committing to projects that meander or don't make progress doesn't help anyone and prevents the organization from finishing the projects it needs to complete first.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.