Decisions, Decisions, Decisions

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.