Projects - Do you need them?

In some companies projects are an important concept since they represent a piece of work, well defined at the beginning, maybe with a business case outlining the commercial benefits, with a project to sequence the tasks and to track progress, and with known deliveries at certain milestones and at a specific date. So far so good. There might be a problem with that, though.

What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.

For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.

For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.

There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.

A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?

Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.

What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.

I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!