In the previous post, Whom Are You Delivering To?, we pondered some questions about service delivery. Those questions can bring about some clarity and stimulate improvement.

Now imagine someone who delivers to you did the same to understand their service delivery. How would that help you?

Jack’s Story

Jack was considering a new project. One of his options would involve some eCommerce functionality.

It turned out another business group in his company had already delivered something similar. That group’s codebase was well-refactored and included a service layer and API Jack could reuse. Two products were already using the API. Jack would only need a few new features built and exposed through the API.

Jack’s project success would depend on the eCommerce team’s delivery.

The team had a reasonably deep Kanban method implementation. They understood the two-point commit, measured their flow and drilled lead times by work item type. They could forecast their delivery.

Jack said, 90% delivery guarantee in 20 days? I can contemplate making promises to my customers based on that. (Jack’s group would have to include their own value-adding work into their delivery estimate.)

This story didn’t have a happy end. Jack’s project had another dependency. The group providing it was different. All they could “forecast” was, their Product Owner would still be prioritizing the backlog where Jack’s API requests would be among hundreds of user stories. Jack couldn’t trust their delivery. He had to make a more expensive make-versus-buy decision.

Some Questions to Ask

• Who is delivering to you?
• Do they know about it?
• Do they know your delivery expectations?
• Do they measure their delivery capability with your expectations in mind? (E.g. if you expect a fast turnaround and they measure velocity, answer No, you’re measuring different things.)
• If there is a gap between their capabilities and your needs, what can they do to close it?
• Can you help them?