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.Transform Projects That Don't Make Enough Progress
Sometimes projects don't make progress in their current form. Sometimes it's because the hardware isn't where you need it to be, as in my example above. Sometimes projects get stuck because the team isn't jelling. Sometimes it's because the project isn't organized for success. In that case, management doesn't commit to the same project. They may request some form of transformation and then commit.
I once worked on a project where the architect received a better offer and left abruptly, without giving two weeks notice. The team members were upset and confused. They muddled through for a couple of weeks until a manager finally acted. He interviewed everyone on the team and decided to reorganize the project, including the lifecycle and everyone's roles.
The team transitioned from a top-down, hierarchical, strict waterfall approach to a more collaborative, incremental approach to developing the product. At first, the team only made small increments of progress. It took people a while to understand how to work with each other and how to use the lifecycle effectively. After the first month, the team felt more confident and improved their delivery of features.
Decide, Don't Multitask
If you're a manager, make a conscious decision about the state of each project. If you're a technical person, help your manager make that decision. Whatever you do, don't avoid a decision. Not making a decision means each technical person decides for him or herself which project to work on, and that means no one finishes projects quickly.
Making the commit/kill/transform decision isn't easy, but it's necessary. You'll get more work done, and everyone will be thrilled to focus their attention on one project at a time.
