Service Level Agreements (SLAs) are often used to establish customer commitments to sustainment requests. Such commitments should focus on areas which have significant financial consequences to the business if they are not achieved. Work groups have to manage a variety of assignments and priorities (change requests, problem reports, maintenance requests, and hot fixes) in order to support such SLAs. Processing these items at prescribed rates and flow times are key to meeting these SLAs. Some of these work items are date dependent, and some are not; their overall job mix, and the natural issues and constraints that arise during processing, must be managed effectively and efficiently to achieve the throughput that they need to achieve SLAs.

Ideally, the pace of deployed solutions can be organized to match the demand from customers. In this way, flow-based solutions strive to depart from time-boxed approaches that many agile software projects are migrating to, though both attempt to insulate the delivery of value from the large variability of  enhancement, maintenance, and support requests which supports most systems deployed in field use.

One of the challenges which both approaches share is determining how to manage a hierarchy of requirements that first emerge from coarse story-telling by the customer.  Because of this, sustainment work rarely achieves the tight specifications as that found in manufacturing, but managing this variability for a deployed system more achievable in situations where something is working and has to be fixed or changed, as opposed to an all-new development activity, in which nothing may be working yet.

To satisfy and work under an agreed-to SLA, work is typically distributed to separate service queues for sequential processing, and each are given performance targets. Each of these queues usually has one or more designated individuals who are responsible for working the set of issues allocated to that queue.  The hand-offs through these queuing mechanisms can be thought of as batons being passed in a relay race.

In this environment, you should not inject unbalanced work beyond these queue sizes into their system, because it really impacts predictability, and increases the time required in just managing work in progress. Instead, work should be 'pulled' by the queue servers when they have capacity to perform the work. These queues thus provide a basis to track the flow of work, and recognize common patterns and deal with them over time.

Expedites are still sometimes necessary to meet an SLA provision, but the overall impact is minimized by only allowing one expedite into their system at a time. Outages, which also occasionally arise in their world, can also be managed through assessments of the impact to their business, and when they arise, can result in a reshuffling of the work overall.