Delivery mode

This is the third of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:

1. Iron Triangle management
2. Process models
3. Delivery mode (this post)

Despite the many complexities of software work, we are always working in one of two modes:

• Discrete project
• Continuous support

By discrete project mode I mean a mode of operation in which an organization creates a special initiative that exists for a defined period of time whenever it needs to achieve a set of related objectives, such as creating a new software application or upgrading the routers on the corporate network.

In contrast, with the continuous support mode of operation, the organization maintains a stable team to support each technical asset (such as the corporate network, a business rules engine, a COTS CRM package, or an ETL product) or suite of applications (such as the suite of applications that support consumer lending in a financial institution) throughout its lifetime. The size of the team may grow or shrink depending on the level of work needed to support the asset or applications at any given time, but the organization does not start a new project for every set of objectives pertaining to the asset or applications.

An advantage of the discrete project mode is that resources and people can be concentrated to achieve objectives of significant scope at the times the extra effort is needed, leaving those resources and people free to do other work at times when the particular assets or applications do not require intense attention. Disadvantages include the cost and delay of project initiation and close-out, the logistics of managing resource demand, and the lower effectiveness of temporary teams as opposed to stable teams.

Advantages of the continuous support mode include the development of dedicated teams that have a deep understanding of the assets and applications they support, avoidance of project initiation and close-out overhead. Disadvantages include team boredom with supporting the same assets or applications for an extended time, and the logistics of managing resource demand as no asset or application requires the same level of support at all times.

Typically, a corporate IT department carries out several different types of work. The department is responsible for maintaining the technical infrastructure, for production operations, for supporting shared technical assets, technical support, integration of COTS packages, management of interfaces with external business partners, information security, and application development. Some of these activities are naturally suited to the discrete project mode and others to the continuous support mode.

A company that provides software-based services or that sells a software product also has its own internal IT department that supports the same kinds of activities as any internal IT department. In addition, the company’s primary business operation involves software development, delivery, and support. Many software companies find the continuous support mode more suitable than the discrete project mode for managing the ongoing development of their products and services.

A relatively recent idea is the notion of continuous beta. The continuous beta model recognizes that any application is a living artifact that is never “finished” or “complete.” As long as the application remains in use, it is subject to modification. Only when the application is retired from production or withdrawn from the market can we say with certainty that no further modifications will be needed.
The continuous support mode of operation is a natural fit for continuous beta products. To date, these have mainly included Web-based social networking applications and e-mail services.

Many other types of applications, both commercial products and internal corporate applications, could be built and supported in continuous support mode. The key decision points are the frequency with which updates are made and the time-to-market that can be supported, given the realities of putting a release together. If an application remains fairly static once it is in production, then the value of maintaining a dedicated team for the application is questionable. If an application has to be updated frequently to keep pace with changing business needs or customer requests, then the continuous support mode may be more cost-effective than the discrete project mode.

There are implications for management. With discrete projects, most of the activities described in the PMBOK are necessary. With continuous support, the activities associated with starting up and shutting down a project are not needed. If continuous support is used in a situation that does not call for a fairly steady level of modification to the application, then there will be (possibly excessive) overhead for resource allocation activities, as well. Continuous support has to be applied where it makes sense; if resource demand is variable due to the nature of the asset being supported, it will remain variable even if we shift from discrete projects to continuous support.

There are implications for metrics, as some of the conventional metrics depend on the existence of a discrete project that has a defined (or expected) scope and an ending date. Any metrics of the general type, “percentage complete,” depend on having a stable definition of 100%. With the continuous support mode of delivery, there is no predefined scope to be completed. Requests are added to the team’s work queue at any time. In the context of continuous support, this does not represent “scope creep;” it is simply normal.

Furthermore, budget allocations are not lump-sum amounts intended to pay for a discrete project or a single release; they are recurring allocations that cover fixed costs over time. For these reasons, there is no meaningful way to track percentage complete of scope, of schedule, or of budget.

With a continuous beta product, the definition of “complete” is that the product is no longer used. That is certainly not the intent of tracking “percentage complete” on a development project.

Certain metrics associated with adaptive development are also sensitive to the delivery mode. A popular metric designed for the time-box process model, velocity, requires a target level of scope to be defined. Although the scope is subject to change, at any point in time there is a planned scope. Observations of velocity are used to create a burn chart that shows progress toward the project’s goals. A burn chart either shows the amount of work completed (burn up) or the amount of work remaining (burn down).

In a continuous support operation, the “scope” constantly changes as new work is added to the work queue at arbitrary times. If the team has the appropriate level of capacity to deal with the average rate that new work arrives, a burn chart tends to look like a jittery line moving more-or-less horizontally across the chart. Therefore, a burn chart cannot tell us anything about “progress” with continuous support mode, although it might be useful as an indicator that the team has too much or too little capacity.

Summary

I think that many of the decisions we might make when managing software development and support activities should be informed by (a) the approach to the Iron Triangle, (b) the general sort of process model in use, and (c) whether we are operating in a discrete project mode or a continuous support mode. When people assume or believe they are doing things in one way when in fact they are doing things in a different way, they may make choices that lead to confusion about progress, status, cost, or delivery effectiveness.

Since people have a tendency to apply the wrong labels to things, it is important for us to be able to recognize by direct observation which approach to the Iron Triangle is actually in use, which process models are actually in use, and which delivery mode is actually in use. If we just go by the labels, we may choose metrics that do not give us meaningful information to support management decisions.

Because of the numerous variations and branded alternatives, and the emotional attachments people have with their favorite frameworks and methodologies, the question of process model is often the most challenging one to answer accurately. Yet, because of the significant impact Iron Triangle management has on everything else, it is not sufficient to look solely at the process model to determine how best to manage and measure the development and delivery activities.

Whether you see any merit in this model is up to you to decide. In future posts, I will probably refer back to these ideas about Iron Triangle, process model, and delivery mode, so I wanted to have this material available so that I won’t have to repeat it again and again when discussing related topics such as metrics.