How long should I have to wait?

After being asked to explain why I and others don't believe that a project is the best way to organize development of services that involves digital assets, I thought that I should try to do that. But I am not interested in bashing projects, but explain what requirements digital service development has on its control structure.

What would a reasonable control structure for development of digital services, a "project method" if you want to call it that, look like?

Services are about meeting human needs, and the question we have is how we can organize a collaboration, a system of people, to be able to meet those needs. As anyone who has had a need knows, one of the most important metric in service delivery from a recipient point of view is the "cycle time": How long should I have to wait from the moment someone has discovered my need until it is either met or rejected?

There are other metrics that are important as well, but the cycle time is special since it both has a strong economic impact and is an indicator of many other things in the system. The value of a delivered service can be translated into a cost of not having it delivered, a cost of delay, so it is fair to say that a suitable project method need to make it possible to optimize for short cycle times.

There are luckily a lot of ways discovered how to reduce cycle time, many that have been discovered by japanese industries in the 50s and 60s. One of the most important ways is to reduce the batch size of everything. Small work packages will flow faster through the system, while large batches increase the variation within the system and cause the system to underperform. So the project method should be able to handle several small batches of changes to the service in parallel rather than focusing on larger change.

The value is created when we meet human needs. It is not created when we spend time on activities. Activities are costs, while meeting needs is valuable. What activities that in the end will lead to value creation is something that unfolds during development of a service. It is impossible to say in a complex environment that we now know what sequence of activities that will lead to value creation in the end. We can guess, and at some point in time create a plan out of our guesswork, but the risk is high that the sequence of activities in our plan needs to be modified as more information unfolds during execution.

So what we need is a project method that allows for continuous replanning of the needed activities. The method needs to keep track how far we are from the goal of value creation, allow for continuous discovery of the best path to the goal, and helping the particiants in doing constant evaluation, discovery of needs and paths, and creation of new plans and forecasts, in a coordinated way.

Good coordination between people is hard to achieve. It takes time. Luckily, while the different changes we want to implement in our service really are separate pieces of work, the very domain where the value creation takes place stays the same. So it is possible to form stable collaborations of people who knows the domain both in a business sense and in a technical sense, and help them making their joint work effective. So the project method needs to support stable organizations and avoid temporary ones.

The discovery of needs within a domain often has a pretty stable rate. Especially when you are going digital. Most services need continuous development in order to stay fit for purpose and be competitive, so there is really no end state here. We will probably always find new needs to meet and will always need to find new ways of meeting them. So the project method should be able to go on forever. Managing constant funding and value generation.

Now, constant work in a constant organization doing continuous small batches of changes in order to meet a need in an exploratory fashion isn't what most project methods are designed for. There is in fact already a name for what I have described here: service life cycle management around value streams. That is a model for development that suits digitalization pretty well and gives the business the agility to experiment with fast feedback loops.

I don't suggest that we abandon projects, but that we realize that they are best suited for large changes that requires a temporary organization and where we actually can create those detailed project plans (often broken down into who should do what activities and exactly when) that the project methods prescribe. For going digital, I instead suggest what I have mentioned above.