3

I just finished reading "The Phoenix Project" and really liked it. One of the things it talks about is "Hand Offs" between resources.

It says that "Wait times for a given resource is the percent it is busy divided by the percent it is idle". So an 80% busy resource has a wait time of 4 units. While a 90% busy resource is at 9 units of wait. And a 99% utilized resource is at 99 units of wait for a new item needing work at that resource..

We have serious wait time issues at my company when tasks transfer between teams. Basically each team is busy with their own work and the work from another team has to wait on that team's priorities. (Only in very extreme scenarios is something "expedited".) And I am planning to add more hand offs in our process in the future!

Reading this made me think that perhaps I had found a possible answer to our issues. So I wanted to find corroborating sources for this concept before I suggest it to our CIO.

But when I went to google I found very little literature related to this concept that is not connected to "the Phoenix Project" (or computer science queuing theory).

Is this a management concept that comes from "The Phoenix Project"? Does it have a name? Does it actually work? Are there any case studies to show success or failure?

I am also interested in how this can actually be done. (Do you really tell the teams to plan on watching YouTube for 20% of their time?)

More Detail:
My company has hundreds of internal product. As we move to a microservices environment, changes will be needed to those services that will not always align with the schedule of the team that knows how to make the change.

I plan to introduce a "pull request" system. Where the team that needs the change to the microservice, codes the change as a pull request. Then which ever team that the microservice belongs to can merge or reject the pull request.

But even pull requests take time. (They need reviewing, testing, releasing etc) So I am trying to find a way that I can reduce the wait times of the team that makes the pull request without also adding a lot of disruption to the core team of the microservice in question.

Improve this question
2
  • I'm not sure that the metric is anything other than a proxy for Little's Law. More importantly, what's your real question? How to optimize slack? Whether 20% is too much or too little? Or something else? The question really needs a little more clarity IMHO.
    – Todd A. Jacobs ♦
    Commented Dec 27, 2019 at 21:51
  • @ToddA.Jacobs - I added more details. Hopefully it adds the clarity needed.
    – Vaccano
    Commented Dec 31, 2019 at 18:29

3 Answers 3

Reset to default
3

There are a lot of theories that go into The Phoenix Project. Queuing theory is the underpinning of most everything else. It is very old (origins in 1909) and is used to great success in almost every industry from factories to computer science to retail. I don't know if there is any type of systems theory out there anymore that doesn't include some aspect of queuing theory. Speaking of which, Systems Thinking is another topic worth looking into. Again, it has a lot of history and tons of industry clout. As Andrii mentions in their answer, Goldratt's Theory of Constraints is also worth looking into and is well-vetted. Lean was also built on this and those the foundations and Lean Management Systems is specifically a management theory around it. If you or your boss is looking for theory to back up The Phoenix Project, if those don't satisfy the need, nothing will.

Now, it is also worth considering that your CIO is probably busy and under plenty of pressure. Having those theories in your back pocket (even just being able to name them) is helpful, but may not be the approach that convinces them. Something really short followed by something very tangible may be the way to go. I really like Henrik Kneiberg's Utilization Trap Exercise. After that, I'd look at Kanban or Lean for first steps. In both, you don't change anything at first - you just visualize your process and start measuring wait times, cycle times, and throughput. Then you start targeting changes and see how it impacts those measurements. Pull systems, as you mention, are critical to both.

Improve this answer
2

One of the possible answers here is planning and monitoring (actually nothing new to project management)

TLDR: plan your journey, check yor location and plan (the more frequent you do so - less surprises you have), adjust your direction.

So, to handle the situation it is worth to have a set of triggers to activate a subsequent team. Basically in task tracking tools these tasks-triggers called as a blocker for some "initial" task for another team. The closer you are to the trigger more accurate time for the next team start you can provide and request resources of subsequent team.

P.S: probably it could be also useful for you to read about Theory of constraints.

Improve this answer
1

I faced the same doubt in the past but today, researching the subject again, I found a good article that explains the concept in detail and references another article the explains the origin of the formula.

So, in sum:

Is this a management concept that comes from "The Phoenix Project"?

No, it comes from queue theory applied to manufacturing

Does it have a name?

It is a simplification of the Kingman Equation

Does it actually work?

It does, but it models a very particular case. It's value is more ilustrative than a precise formula.

Are there any case studies to show success or failure?

I understand it is vary important in manufacturing, where "The Phoenix Project" drinks from.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.