I’ve started working in a very different organization, in a very different culture, and I see the same problems. For those who don’t know yet, I have moved to Indonesia and work for Bala Keselamatan, better known internationally as the Salvation Army. My task is to help the organization that oversees the Salvation Army hospitals (yes, 6 of them) and clinics (17, I think) become more effective and get more done with less. “Doing the most good,” in other words.
When I came here, I hoped (or maybe bet) that my knowledge of Lean and Agile would be helpful. I’ve seen similar problems here as I did with clients back home. In this blog post, I want to discuss one of these problems: long lead times in important projects.
Yes, I wrote “important” projects. It really stumped me at first. But then I realized that I’ve been in many important, urgent projects with long lead times, even in another industry and world. I have two examples from my current situation in very different scales, both involving different numbers of people. They are concrete examples, and you can probably relate them to your context and situation quite easily.
The Projects
- The first project is about clearing out the final details on how two organizations should be separated. There are many discussions, decisions, and meetings to be had, involving many people (4 teams of 6-8 people each).
- The second project is much smaller: we (4-5 of us) need to clear up some misunderstandings around a project run at one of our hospitals for the mother organization of the Salvation Army, so that they know where and why we spend our funds this way.
For both of these projects, a number of common factors are the same:
- These projects are very important (the word “paramount” has been used a couple of times).
- They are urgent but on different timescales (months for the first case, days for the second).
- They are staffed with people who have a lot of other things to do.
All in all, the perfect setup for success. Don’t you agree? And after you don’t, stop and think for a while.
You’ve been in these projects.
Right?
Right?
Right, sure you have.
Me too.
So how do projects like these look then?
How We Work
What ends up happening is not very hard to figure out:
- Person A starts to work and then hands stuff over to the next person. Person B, in turn, doesn’t have time right now… so after a day or two (or hour or two, take your pick), picks the task up and realizes that he didn’t really understand where A left off, so an urgent email is sent to clarify the situation.
- Sadly, Person A is involved in other things and after a day can explain what he meant and send a more comprehensive answer to B. Now B understands but has an important conference the rest of the week. On Monday, B can give answers and now can send it on to C.
- C has been wondering what’s taken so long. As C reads the proposed actions, he realizes that A and B are focusing on the wrong things. “Why wasn’t C involved earlier?” C thinks angrily and sends a quite angry email to both A and B: “We should meet and discuss this! My next week is pretty busy but after that…” C sends the email and then storms past A and B’s desks on his way for a coffee.
Just writing that made me angry. It’s just stupid, don’t you agree? But still, this is how many discussions and decision-making processes are run, both in Swedish and Indonesian companies I’ve worked for.
Lead Time
In processes like the one described above, the work is not being worked on much more than it is actually being worked. This, of course, has a dramatic and damaging effect on the lead time to complete the work. Try this very simple exercise, if you dare, on a whiteboard next to you:
- Draw a line across the entire board. For extra measures, mark it with dates (or weeks even).
- Write “Working” above it and “Waiting” below it, to the left.
- Now plot where the task has been by doing a staple diagram of sorts. You’ll end up with something like this:
Now, for the fun part.
- Measure the length of the line as it’s in the “Working” area. It doesn’t have to be exact but enough to prove a point.
- Draw a new similar diagram below and plot only the “Working” time on the diagram.
- You’ll end up with something like this (I’ve even added a little waiting time in the beginning, I’ll get back to that later in the post):
In true Switch-spirit, we now have visualized information and hence “found the feeling” or felt the pain that’s needed to improve. We’ve also “posted a postcard from the future” to show how fast it could go. Now, the only question is, how?
Oh, this exercise is a very simple form of Value Stream Mapping. You can do much more advanced versions of this, but it’s seldom necessary to get the point across.
How to Get to Better
Ok, here it comes. My solution to this age-old problem. I’m planning on releasing this as a book later this year, but you can read it now. Please don’t spread it since I want to trademark it. It’s really big news:
- Find a time when everyone can work in the same room together.
- Work on it until it’s done.
- Done!
It’s also known as “Go in a room and get it done” or “Sit together - work together”.
Sorry, I was being ironic there for a while. But one could ask oneself, as one (being me) has done from time to time: so everyone knows that this is bad, so why does this still happen?
Why is This?
By now, most of you probably have left me since I’m just ranting. So for you there in the corner still reading this… this is a bit of a puzzle, right? Because everyone knows this. Manning an urgent and important project with already busy people will lead to really hard scheduling and that, in turn, will hurt the lead time. Badly.
Still, this is the common way of doing things. “I want you to engage in this project also”, “We’re pulling people from other projects to create a task force to make sure that…” You’ve heard things like these.
Effective versus Efficient
I think it’s because we’re all too often focusing on keeping people busy and efficient. Don’t miss Dan North in this excellent talk on effectiveness vs efficiency.
This, by the way, goes both for organizations but also for individuals: we want to be busy, right? It’s super boring to have nothing to do. And I don’t look important either. And we want our people to be busy, right? They cannot just sit around doing nothing, now can they? It’s better that they do something than nothing. It’s simply not efficient if they are not busy.
That statement is perfectly true. Consider the case of writing code. As it turns out, the hard part is not typing. It’s understanding each other. A software company is not selling “keystrokes per minute.” They are selling finished (features in their) software that people are using.
“Working Software” is software that users are actually using. Until it’s in use it is truly useless.
When I first introduced a colleague to Mob Programming (quite simply: a whole team, one room, one computer, one keyboard, one screen - working on one thing at a time), his response was correctly:
“But that’s just not efficient!”.
If I could think faster, I would have responded:
“No, but it’s very effective.”
Priority
Another thing that doesn’t help the poor people in processes like these is often the lack of clear priorities. I’ve heard about a big bank in Sweden that had 15 projects that were top prioritized. That’s 15 projects that we should work on first. I’m not sure that’s even English. Surely only one project (person, thing, or whatever) can be the first?
I’ve also worked at a Swedish insurance company that, in one project, had so many PRIO 1 items in the backlog that they (wait for it) introduced PRIO 0. Yes, PRIO 0 is even more prioritized than PRIO 1. Surely this will redeem the situation? It did not, and pretty soon they had about 20 PRIO 0 items in the backlog too.
With a lot of things that are highest priority for teams and people, we’re making it very hard for them to know what to do. In many situations, it really doesn’t matter: they are making someone disappointed anyway.
Google defines “prioritize” as:
designate or treat (something) as more important than other things.
It doesn’t say a thing about giving priorities 1, 2, 3 and first doing all the 1’s and then all the 2’s. No, it says: “treat something as more important than other things”. Yes, some things will have to wait before we start to work on them. But, then what we actually work on is more important and hence it will be a better use of the time we put in.
Corey Ladas introduced me to a tool called priority filters. With this, we visualize our priorities from less important all the way up to “so important that we’re actually working on it now”. I like that definition much better than PRIO 1.
What I Will Do Now
I think it’s better, and much more effective (as well as efficient in fact) to wait until the time is right to do this project. When we reach that point, we can explain to everyone involved why this is now the most important thing we can do right now.
That’s why the second version of my simplified value stream map had a waiting time in the beginning. In order to be efficient when we do get together, it might be worth waiting a while first.
Then we go into a room and get it done. We bring the people that we need to make the decisions we need to make and we get the work done. Or at least as far as we can given the constraints we’re given.
Going into the room without important decision-makers, in other words: without the authority to make decisions, is a waste of time. The work will not be done. It will only be started. We want to finish stuff. Not start stuff.
It’s not “the more you start, the more you finish,” it’s “the more you finish, the more you finish.”