Decisions, Decisions, Decisions: Should you Commit, Kill, or Transform?

2012 Johanna Rothman

If youre working on more than one project at a time, or if your managers are asking you to do so, its time to make some decisions.

You shouldnt start every project. You shouldnt even finish every project. You definitely should not consider starting and finishing all the projects at the same time!

Your organization needs to make some decisions about whether to commit to a project, kill it so it doesnt interfere with other projects, or transform it so it can succeed in a reasonable time.

Dear JR,

Im on three different must-do projects. I cant tell if they are all really must do. If they were, wouldnt my managers decide which one I should be on? A Harried Developer

Dear Harried Developer,

If youre 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 youre a manager, theres a tool you can use to decide which project each staff person should work on for nowthe project portfolio.

Some managers dont realize that the portfolio decision of when to do which project isnt a final decision for all time but a decision for now. Its much easier to realize that when you have agile teams all working in the same duration timeboxes. Even if you dont 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 theyll 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 youre in that situation, start working in timeboxes of one week in which you commit to completing no more than one weeks worth of work at a time. That way, if your managers change their minds, at least youve finished something. You shouldnt 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, 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 cant tell when youre going to get a project done, its much harder to commit to it for a long period of time. Thats why a commitment for now works better. Then all youll 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 length 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 cant 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 youve committed to a project but the project isnt making progress? Then maybe its 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 didnt 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 Id have a stupid day tomorrow. Not my most career-enhancing moment.

When you work on a project that cant make progress or has no more value to deliver, its time to kill that project. I prefer the word kill to Peter Druckers word of choice, abandon[1]. I like the conscious decision-making you obtain with kill, rather than letting projects fade into the twilight as abandon might imply.

Remember that the decision to kill projects doesnt 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 dont make progress doesnt help anyone and prevents the organization from finishing the projects it needs to complete first.

Transform Projects That Dont Make Enough Progress

Sometimes projects dont make progress in their current form. Sometimes its because the hardware isnt where you need it to be, as in my example above. Sometimes projects get stuck because the team isnt jelling. Sometimes its because the project isnt organized for success. In that case, management doesnt 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 everyones 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, Dont Multitask

If youre a manager, make a conscious decision about the state of each project. If youre a technical person, help your manager make that decision. Whatever you do, dont 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 isnt easy, but its necessary. Youll get more work done, and everyone will be thrilled to focus their attention on one project at a time.