Unearthing Your Project’s Delays

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 only been with the organization for 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 pm that day.

“I need to understand what happens when you folks receive a project. I'm planning to graph the project timeline on the whiteboard, okay?”

One of the senior developers, Ellen, asked, “What are you going to do with this information?”

Cliff thought that was a strange question, but he answered. “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.

“And then?” Ellen asked. “What will you do with this information?”

Cliff was puzzled. “What do you mean, do with the information?”

Ellen sighed. “Are you going to fire us?” she asked.

“No, that's not my intention at all,” Cliff said. “If you're all working hard, why would I fire you?”

The team looked at each other. Teddy, the tester, said, “We've heard rumors…”

Cliff said, “Look, you know that I'm under pressure to ‘make you perform better',” he said. “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.”

Ted said, “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.

“Thanks,” Cliff said. “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 said, “We have UAT. That takes 2 days.”

Cliff asked, “For everything, regardless of the size?”

“Yup. It doesn't matter if it's something that took us two weeks or something that took us 30 minutes. First, we put in a request for UAT. That takes two days. Then they take 30 minutes to test, and not with production data.”

Cliff looked at her. “Not with production data?”

“Nope,” she said. “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 said, “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.

“Tell me more,” he said.

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. “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 said, “I'm not sure you started late if management and then your PO didn't tell you to start the project,” he said. “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. “How long was that time for this project?”

“Six months,” Ellen said.

Cliff whistled. “That's a long time,” he said.

“You bet,” she said. “We started off behind.”

“Okay,” Cliff said. “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. “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. “You need all the political capital you have to deal with these problems,” she said. “I'm not sure you could have taken this as your first quest.”

Cliff smiled, “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.

“And, I bet it's the same thing with UAT and Deployment?”

The team nodded. Teddy said, “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.”

“Have you measured your full cycle time?” Cliff asked.

Ellen said, “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. “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 asked, “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.

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 chart like this so you can measure your real cycle and lead times, and show people where your delays are.

2 thoughts on “Unearthing Your Project’s Delays”

  1. Pingback: Possible Organization Changes for a Product Approach (Part 5) – 1

  2. Pingback: Why Minimize Management Decision Time - Business Agility Conference Global

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: