In several IT organizations I’ve worked prioritizing IT work often takes some of the following characteristics. Capacity is completely consumed by large-scale transformation initiatives. Other work is often prioritized by whoever has the right connections with the CIO, or is able to yell the loudest. Maintenance, business as usual, and other business and technology related operational issues are either completely ignored/delayed, or completed under the radar with as little oversight as possible. Investment and training is either completely off the books, or rarely done. Sometimes, leadership tries to put a better system in place to help them prioritize these various internal/external demands. Often these systems comprise of complex prioritization mechanisms/frameworks where various attributes of a project (e.g. business impact, complexity, etc.) are used to force rank different projects against each other to come up with what the next piece of work should be. Clever customers quickly learn how to game the system, and pretty soon every project comes through as the one needing to be done next.
Kanban offers an alternative to the above scenario. When an organization is delivering software in a way that provides stable performance it becomes to possible to allocate portions of that performance to different profiles of demands. In other words, A Kanban system allows an organization to get out of the prioritization game, and get into the allocation game. An organization using kanban will have a number of teams/departments delivering a limited number of work according to the capacity limit (wip limit). This capacity limit may be expressed in user stories, features, use case scenarios, enhancements or whatever those teams recognize to be meaningful units of work. Regardless of what these capacity limits represent the inventory limits can be further allocated according to the overall objectives of the organization.
Having these preset capacity allocations make it much easier for various factions and competing needs to make decisions around what work should be completed next. As an example, a blue chip organization should probably be spending at least 30% of its capacity on business optimization activities, and perhaps 20% of its capacity on large-scale IT transformation projects. Imagine now that introducing a new large-scale business transformation initiative would cause the organization to be unable to reserve 30% of its capacity for these operational activities, and cause its capacity for transformation projects to bump up to 40%. In this case the new large-scale business transformation initiative would be deferred until an in-flight one had completed. Another option would be to allow the various transformation projects to start could sharing the capacity allocation to each other. Of course capacity allocations are not meant to be set in stone, but would require a higher authority/escalation to reset. In this way the question "what kind of business should I be in?" Is separated from the question "what should I do next with my available capacity?".
Some sort of governance mechanism should be in place to periodically reset capacity allocations amongst different business channels, different programs/projects.
..
