BraindumpDiscussion on CR Prioritization and Requirements Clarity
Summary:
- There is confusion about the timeline for requirements delivery, leading to claims of long wait times.
- Requirements may be deprioritized and moved to a backlog without proper communication to stakeholders.
- A prioritization process was implemented to focus on the top ten critical Change Requests (CRs) for each business line.
- A capacity model is necessary to assess resource availability for delivering the prioritized CRs effectively.
- Ambiguity in requirement specifications leads to issues during design and testing phases, necessitating revisions to the CR.
Content:
point that we completed a sheet as well, and why there is a perception sometimes that something would take three years, two years. Sometimes they even say you were saying nine months, but they would sometimes even say they've been waiting for this requirement for three years, but not knowing that they've deprioritized the requirement. It wasn't flagged as a top priority. It went to the backlog. And now when they get pressure, maybe at commercial Expo, and somebody then remembers, but we needed the CR and the CR was going to do one, two, three, four, five, then they'll claim and then they'll say, yes, but we logged it with IT.
We're waiting for IT to deliver. Then only after that happens, they would then tell us, okay, make this a priority. But meantime, it was sitting on the backlog. So I think it's just an important perspective to also... Yes, yes, yes. So it was not part of the top ten, but that refers to a capacity limitation or however you see that. Yes, because they, actually when we started out in FY26, we had a bucket of in excess of 400 and odd CRs. We then went through that list. We said, okay, across the lines of business, let's identify what are the top ten for each of the lines of business, which of those ones is cross-functional and so forth, and then we will deliver according to that.
And then we make commitments, IT, what are we going to drop in Q1, Q2, Q3, Q4, based on the maturity of where that CR was at. So that's how we kind of cleaned up that backlog. And then we moved into the cycle of, so this has been since the beginning of FY26, we then adopted this, we're going to do the top ten, but obviously knowing that we still needed this proper, like I was saying, a capacity model to underpin the demand because even if it's 10, 10, 10, 10, to your point around the 120, we might not even have sufficient resources to deliver the 120 because let's say all of the 120, they're on the same system demanding the same expertise and, you know, dev work to be done from that same one Amdocs system, for example.
Right? The majority, 80% of the 120, it's Amdocs. And then every time we get there, we're going to hit that bottleneck, which then goes into the, let's look at how do we now cycle through that top priority. Okay. Important view. Thanks. Thank you. That's all you wanted to add? Anything else? No, we wanted to add as well, I think the one that is on the requirements side. So remember, thank you about the requirements. They log a CR and still get the URSs or their requirements documented somewhere. So sometimes those requirements, business as well, is not clear on the requirements or that they want.
And sometimes it goes as far as we go to design and development. And when we test, we start doing BA with business, then they start mentioning that, oh, but it looks like this is not what we asked for. And when you look at the requirements, they did sign for the requirements. And when you look at the design, it's aligned to the requirements. And then that CR now goes back to requirement stage where now business can come back and change certain requirements and then we have to redo the CR. So sometimes that is part of where business actually that the requirements were not clear or that they logged the CR and they were left.
And then by the time Anika try and deliver this as the business owner, she's not clear of what the requirements were, but we end up delivering. And then when it's supposed to be accepted and implemented, then a different view comes through. But then we don't change the CR number. That's the thing. We still use the same CR number and the requirements can change and then we implement. Yeah. OK, thank you. Thank you. Good, good, good contributions. Thank you very much. Anything else? No, that's it. Thanks, Cooper. That's it. Thanks. Thank you. Thanks, Blessing. Bye. All right.
- There is confusion about the timeline for requirements delivery, leading to claims of long wait times.
- Requirements may be deprioritized and moved to a backlog without proper communication to stakeholders.
- A prioritization process was implemented to focus on the top ten critical Change Requests (CRs) for each business line.
- A capacity model is necessary to assess resource availability for delivering the prioritized CRs effectively.
- Ambiguity in requirement specifications leads to issues during design and testing phases, necessitating revisions to the CR.
Content:
point that we completed a sheet as well, and why there is a perception sometimes that something would take three years, two years. Sometimes they even say you were saying nine months, but they would sometimes even say they've been waiting for this requirement for three years, but not knowing that they've deprioritized the requirement. It wasn't flagged as a top priority. It went to the backlog. And now when they get pressure, maybe at commercial Expo, and somebody then remembers, but we needed the CR and the CR was going to do one, two, three, four, five, then they'll claim and then they'll say, yes, but we logged it with IT.
We're waiting for IT to deliver. Then only after that happens, they would then tell us, okay, make this a priority. But meantime, it was sitting on the backlog. So I think it's just an important perspective to also... Yes, yes, yes. So it was not part of the top ten, but that refers to a capacity limitation or however you see that. Yes, because they, actually when we started out in FY26, we had a bucket of in excess of 400 and odd CRs. We then went through that list. We said, okay, across the lines of business, let's identify what are the top ten for each of the lines of business, which of those ones is cross-functional and so forth, and then we will deliver according to that.
And then we make commitments, IT, what are we going to drop in Q1, Q2, Q3, Q4, based on the maturity of where that CR was at. So that's how we kind of cleaned up that backlog. And then we moved into the cycle of, so this has been since the beginning of FY26, we then adopted this, we're going to do the top ten, but obviously knowing that we still needed this proper, like I was saying, a capacity model to underpin the demand because even if it's 10, 10, 10, 10, to your point around the 120, we might not even have sufficient resources to deliver the 120 because let's say all of the 120, they're on the same system demanding the same expertise and, you know, dev work to be done from that same one Amdocs system, for example.
Right? The majority, 80% of the 120, it's Amdocs. And then every time we get there, we're going to hit that bottleneck, which then goes into the, let's look at how do we now cycle through that top priority. Okay. Important view. Thanks. Thank you. That's all you wanted to add? Anything else? No, we wanted to add as well, I think the one that is on the requirements side. So remember, thank you about the requirements. They log a CR and still get the URSs or their requirements documented somewhere. So sometimes those requirements, business as well, is not clear on the requirements or that they want.
And sometimes it goes as far as we go to design and development. And when we test, we start doing BA with business, then they start mentioning that, oh, but it looks like this is not what we asked for. And when you look at the requirements, they did sign for the requirements. And when you look at the design, it's aligned to the requirements. And then that CR now goes back to requirement stage where now business can come back and change certain requirements and then we have to redo the CR. So sometimes that is part of where business actually that the requirements were not clear or that they logged the CR and they were left.
And then by the time Anika try and deliver this as the business owner, she's not clear of what the requirements were, but we end up delivering. And then when it's supposed to be accepted and implemented, then a different view comes through. But then we don't change the CR number. That's the thing. We still use the same CR number and the requirements can change and then we implement. Yeah. OK, thank you. Thank you. Good, good, good contributions. Thank you very much. Anything else? No, that's it. Thanks, Cooper. That's it. Thanks. Thank you. Thanks, Blessing. Bye. All right.