- Probing as to why more work is being asked to understand where leaders are coming from
- Making work visible. This alone is a great insight, after all "You can't manage what you can't see"
- Setting priorities together with leaders
- Triaging ongoing WIP work-in-process
- Clarify what the teams are optimizing for (you call it delivery system)
However there's a blind spot in the article. Nowhere do you mention the concept of a project, and the process of getting projects approved and their usual delays (average of 60% in my data at two large SW companies).
This project-driven management alone can cause huge amounts of parallel work.
At a company I worked we had 150 projects ongoing for about 120 engineers. Why? Simple! When a project is started it is assumed it will finish on time. But they don't (see above). However there are other important and urgent projects in the portfolio that need to get started. And they do because they have committed and motivated project managers and stakeholders who want them started.
This leads to more and more work being started.
In the article you don't address this entirely predictable dynamic in project organizations, and that dynamic alone will significantly reduce the impact of the great ideas you have shared.
Thanks for the comment and appreciation. You did add a great point that I indeed didn’t put on the spot. It’s the upstream version of the point I made that to start something new there’s already a lot found becomes a trickier conversation because of more conflicting priorities.
The same dynamics essentially also exists in those earlier stages. I think that’s a way of looking at it. What you think?
I would agree. Much of the ideas you share help with the "start of projects", however they don't eliminate the cause of parallel work (the tsunami of delayed projects washing over the newly started ones).
Maybe we can start talking more about the negative sides of organizing work as "projects".
I will be writing about it soon-ish. Projects are not a good fit for ongoing Software development. Need a better approach, and I'll share what has worked for me.
One way or another, I generally feel like one of the keys is to make a distinction between acknowledging some work as potentially valuable and thus become an option but then have a clear point of commitment to when it s truly going to start developing.
But in my experience the situations like the case described I’m afraid are not for organizations working as projects. In fact, the case is not from a project-based org, but one that in principle work with products. Now, it’s true that part of the problem seems to be sales-driven push, which one could argue is a kind project, but still the point remains that I’m experience this goes beyond project-funded delivery systems…
There are some great insights and advice here.
- Probing as to why more work is being asked to understand where leaders are coming from
- Making work visible. This alone is a great insight, after all "You can't manage what you can't see"
- Setting priorities together with leaders
- Triaging ongoing WIP work-in-process
- Clarify what the teams are optimizing for (you call it delivery system)
However there's a blind spot in the article. Nowhere do you mention the concept of a project, and the process of getting projects approved and their usual delays (average of 60% in my data at two large SW companies).
This project-driven management alone can cause huge amounts of parallel work.
At a company I worked we had 150 projects ongoing for about 120 engineers. Why? Simple! When a project is started it is assumed it will finish on time. But they don't (see above). However there are other important and urgent projects in the portfolio that need to get started. And they do because they have committed and motivated project managers and stakeholders who want them started.
This leads to more and more work being started.
In the article you don't address this entirely predictable dynamic in project organizations, and that dynamic alone will significantly reduce the impact of the great ideas you have shared.
Will you address this dynamic at some point
Thanks for the comment and appreciation. You did add a great point that I indeed didn’t put on the spot. It’s the upstream version of the point I made that to start something new there’s already a lot found becomes a trickier conversation because of more conflicting priorities.
The same dynamics essentially also exists in those earlier stages. I think that’s a way of looking at it. What you think?
I would agree. Much of the ideas you share help with the "start of projects", however they don't eliminate the cause of parallel work (the tsunami of delayed projects washing over the newly started ones).
Maybe we can start talking more about the negative sides of organizing work as "projects".
I will be writing about it soon-ish. Projects are not a good fit for ongoing Software development. Need a better approach, and I'll share what has worked for me.
One way or another, I generally feel like one of the keys is to make a distinction between acknowledging some work as potentially valuable and thus become an option but then have a clear point of commitment to when it s truly going to start developing.
Interesting. Looking forward to read about it.
But in my experience the situations like the case described I’m afraid are not for organizations working as projects. In fact, the case is not from a project-based org, but one that in principle work with products. Now, it’s true that part of the problem seems to be sales-driven push, which one could argue is a kind project, but still the point remains that I’m experience this goes beyond project-funded delivery systems…