Unearthing Your Project’s Delays
Measure and Visualize Your Real Cycle and Lead Times
Cliff, an IT Director was concerned. One of the projects was a mess. It didn’t seem to matter how much or how little the team had for requirements. The team never seemed to release enough on time.
Cliff had been with the organization for only four weeks. Yet, that team seemed to have more trouble than any of the other teams. He finally felt as if he had the trust of the VP and had figured out—at least a little—how to get things done here.
He’d just returned from meeting with Sandy, his VP. Sandy was frustrated and was ready for him to fire everyone and start with a new team. Cliff was pretty sure the team wasn’t the problem. He needed to understand what the problem was — and fast.
He decided to create a picture of how the team worked and where they had trouble. He asked the team members to gather in the meeting room at 3 p.m. that day. The conversation went something like this:
💬 Cliff: I need to understand what happens when you folks receive a project. I’m planning to graph the project timeline on the whiteboard, okay?
Ellen, a senior developer spoke up.
💭 Ellen: What are you going to do with this information?
Cliff thought that was a strange question, but he answered.
💬 Cliff: I want to see where your time goes. Every time I walk by, I see you all busy at work, but you seem to have trouble releasing.
Ellen nodded. So did everyone else.
💭 Ellen: And then? What will you do with this information?
Cliff was puzzled.
💬 Cliff: What do you mean, “do with the information?”
Ellen sighed.
💭 Ellen: Are you going to fire us?
💬 Cliff: No, that’s not my intention at all. If you’re all working hard, why would I fire you?
The team looked at each other. Teddy, the tester chimed in.
🗯 Teddy: We’ve heard rumors…
💬 Cliff: Look, you know that I’m under pressure to “make you perform better.” I am not sure it’s a function of your performance. I’m pretty sure we have a system problem. Let’s see if we can understand what the system problem is.
🗯 Teddy: I can tell you the system that’s causing us problems. It’s Deployment. We have to wait a week from the time we finish something until it’s deployed. It doesn’t matter how large this thing is, it’s always a week.
Cliff went to the whiteboard. He put a sticky marked “T5” at the right end of the whiteboard. He wrote “Deployment” above the sticky.
💬 Cliff: Thanks. I was planning to start from the time we give you a project, but we could start from the release and work backward. What happens before you deploy?
💭 Ellen: We have UAT. That takes two days.
💬 Cliff: For everything, regardless of the size?
💭 Ellen: Yup. It doesn’t matter if it’s something that took us two weeks or something that took us thirty minutes. First, we put in a request for UAT. That takes two days. Then they take thirty minutes to test, and not with production data.
Cliff looked at her.
💬 Cliff: Not with production data?
💭 Ellen: Nope. We’ve given them access to our production data, but they won’t use it. So, they don’t really test what we developed.
💬 Cliff: Wow, this is worse than I thought. You do have a system problem. You have several system problems.
He wrote T4 on a sticky and labeled it T4. He put it to the left of the T5 sticky.
💬 Cliff: Tell me more.
The team graphed the rest of their project’s process. It was worse than Cliff had expected.
The beginning of the process was okay. The VP and Cliff’s peers decided which projects to do at T0. The team received the project at T1. Cliff wrote “Mgmt’s decision time” between T0 and T1.
Then came a time that Cliff wasn’t so sure about — the time between the time the project was put on the team’s backlog and when the team started. Ellen had some data there.
💭 Ellen: Our previous product owner always had more we had to do on the previous project. That’s one reason we started this project late.
💬 Cliff: I’m not sure you started late if management and then your PO didn’t tell you to start the project. That’s what I mean by a system problem. If we want you to start a project, we should reduce — as much as possible — the time between T1 and T2.
He paused.
💬 Cliff: How long was that time for this project?
💭 Ellen: Six months.
Cliff whistled.
💬 Cliff: That’s a long time.
💭 Ellen: You bet. We started off behind.
💬 Cliff: Okay. I’ll say “PO decision time” there. Tell me more about the UI experts.
The team explained they weren’t allowed to do any UI by themselves. They had to go to the UI group and ask for people. Because their project wasn’t as important as other projects, they got new people all the time — who didn’t understand their project.
The team iterated with the UI folks, which wasn’t horrible, but it wasn’t the same people all the time. They had to ask every time they needed a UI person.
Cliff looked aghast.
💬 Cliff: I’m sorry. I thought you folks were okay, just having deadline trouble. I didn’t realize this was the problem. I should have paid more attention to you at the beginning.
Ellen smiled, more a wry grin.
💭 Ellen: You need all the political capital you have to deal with these problems. I’m not sure you could have taken this as your first quest.
Cliff smiled.
💬 Cliff: A quest, indeed! Okay, let’s finish this. I assume that you find problems in the UI and they find problems with your code?
The team nodded.
💬 Cliff: And, I bet it’s the same thing with UAT and Deployment?
The team nodded.
🗯 Teddy: It’s even worse. If UAT finds a problem, we always have to wait another two days. If Deployment finds a problem, we have to wait another week before they come around to us again.
💬 Cliff: Have you measured your full cycle time?
💭 Ellen: Yes, let me bring up our data for cycle time over the past three months, including UAT.”
She hooked her computer up to the projector and brought up the project’s page.
💭 Ellen: Two months ago, our average cycle time was only four days. But something happened last month. I don’t know what. Instead of UAT taking just two days, our request time jumped to four days. Our average cycle time is now eight days. And, don’t get me started on deployment.
💬 Cliff: Did you try to talk to anyone about this? I’m asking because I think there’s something fishy here, and I want to know who I should talk with first and who I should talk with later.
The team and Cliff discussed options about who was open to working with him and the team, and who the team had had trouble with in the past. Cliff took a picture of the whiteboard as a basis for discussion with Sandy.
Cliff made an appointment with Sandy for the next day. He brought his picture of the chart, cycle times, and lead times over the past three months. Once Sandy realized what was happening, he demanded a meeting with all of his directors to solve the problem.
Takeaway
I have yet to meet a team that didn’t want to succeed. Often, the system — the way things work in the organization — conspires against them.
If you have delays in your system, consider a lead and cycle time chart like Cliff made so you can measure your real cycle and lead times, and show people where your delays are.
About the Author
This story was originally published on October 11, 2018 on the author’s website.
