I take the liberty of answering your question. :-)
The Mikado Method is primarily to make code changes to existing systems, and it shines in situations where you have a lot of entangled dependencies to keep track of. We've mostly used it for just that when implementing new features, or just changed the way things work, as in refactorings/restructurings. This is what the book is about.
We have also used a Mikado-like dependency graph to keep track of things needed for e.g. deliveries, but this is not in the book.
A friend and former colleague of ours has used it for organizational change. This is not in the book either.
We strongly believe that dependency graphs are good for making models of the world that help us understand how things are connected and to act upon that information. We encourage you to try the next time you have a problem. Software development, deliveries, refurnishing a room, or something completely different. :-)