söndag 13 november 2016

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.

7 kommentarer:

  1. Hi!

    Nice post!

    Overall, I don't really like comparing manufacturing to knowledge work. But, yes, there are also similarities. But I'm derailing.

    I think the aim for most organizations is to have stable organizations continuously improving the service/solution/product. At least that's my experience :)

    This given you have an existing solution/service/product in place. The thing I wonder is how we'd build a new capability/idea (like an MVP) without doing it as a project? And I dismiss skewed language like "*detailed* planning" and "guess". Some planning is always needed, do them wisely and at a "good enough" level, "detailed" is just loaded language. And also: never guess. Act candidly and in good faith - guessing is not that. If you have to actually guess, then be upfront honest about it. And take it from there. Again I'm derailing, but an important note.

    Another note: I've worked in flow of work (in a continuous fashion) on existing solutions. Sometimes the team actually felt that we needed a better focus (a focus from the biz, but as well as from the team) on certain things (larger things). On those times we missed the focus a project gave us, and thus we made sure that it was arranged - a project.

    At one customer we had we decided - in agreement - that work estimated > 40 hours was always considered to be treated as a project. Quite arbitrary :) But it's interesting as a pointer to when a thing is "just another task" and "a project"... When is that for you and your organization? Interesting question, IMHO.

    I've also found that (in continuous flow of work) it's easy to get stuck on small things and miss the bigger picture. An important thing to pay attention to.



  2. On another note. When it comes to definition of words, I use the dictionary. It captures a good overall view of a word, and it matches most likely every person's view of a word. See: http://www.merriam-webster.com/dictionary/project

    So if you have a planned (not only a "detailed" one) piece of work for a specific purpose and that takes some time - you have a project.

  3. And if that minimal definition of the word "project" would be enough, there wouldn't be much of a problem. In my course material I use the term "mini project" myself when I point at the minimal valuable deliverables we deliver. The problem is that "project" in the way it is used in organisations is way more than this. The de facto definition of "project" is made by the method used. The ones I have used: PPS, PROPS, PEJL, PRINCE2, all of them lacks the mechanisms I am looking for in the post.

    I'll return to your other comments in a separate post! Thanks for the feedback, it is VERY MUCH appreciated!

    1. Exactly. And since the word "project" isn't likely to go away, I think it's better to make it mean and turn it into something meaningful rather than trying to avoid the word (or do away with it). But this definition thing isn't really interesting. I'm looking forward to your post!

  4. A very interesting topic! But I am not sure I agree that "The discovery of needs within a domain often has a pretty stable rate". In my experience they can result in clusters, e.g. after external evaluations, opportunities arising from the work of other organizations etc. Also the implementation effort of those needs can vary greatly - sometimes requiring more focus/resources than usual (and sometimes you are better off working on needs in clusters even if you know the clock of unmet needs is ticking).

    At those times it can be valuable to create a temporary (e.g. extended cross functional) team organization that has a specific focus/monetary resources for a specific period of time. Especially when a new product needs to get off the ground or a deadline that is out of your organization's control has to be met.

    If you are in an organization where the budget is fixed you may need to shift focus of a team for a while (and reduce the focus of some other service). An example is where new products/services need to be developed (you may have temporary money but not enough to hire a new dedicated team).

    Some of the problem you are addressing is that "project" can mean many things. I guess one way to move forward would be recommendations on how to (not?) define "project" and how to avoid large scale projects.

    I would love to talk more about this close to a whiteboard and coffee some day!

  5. Peter: I agree that when that is the case, a temporary effort would be a good idea (if not by a temporary team since the domain remains stable). However, often the root cause for uneven discovery of improvement is often that you don't look for it continuously. So that too would be an artificial variation.

  6. A comment on the issue of whether techniques from lean are applicable in knowledge work: http://smidigt.blogspot.se/2016/11/flow-is-generic-concept.html