8.3 Incremental deployment

You don't want to spend 18 months discussing how to deploy a PO in your organization, because in that time you would have lost your opportunity and the naysayers would have demonstrated that nothing but their way of working actually works.

An incremental deployment methodology is a deployment approach in which the total change project is divided into a series of short, intensive cycles of implementation, each of which delivers a tangible business benefit. There are several reasons for recommending an incremental approach rather than an all-at-once deployment. First, project managers are doers. They enjoy action and they want to see results. You are not likely to keep any momentum, nor raise any excitement, by talking about processes for a long period, so you need to scope the amount of change to be introduced to fit their attention span. Second, any innovation or change requires an assimilation period. The incremental approach provides the time necessary for this process of organizational learning to take place between consecutive deployment increments. If this time is not allowed, as in the case of all-atonce deployments, it is likely that many changes will pile up, one over the next, leading to frustration and rejection of the initiative under the pretense conveyed by the line "we are too busy to change". Third, an incremental approach prevents the common tendency to overengineer technology solutions while substantially shortening the time to the arrival of business benefits.

The first thing to do is to produce a blueprint of what the PO would look like: What responsibility would it have, what type of culture will it foster, what kind of tool or tools would be used? The level of detail of the blueprint should be such that it allows the purpose and operation of the PO to be communicated to management and other stakeholders and that it provides enough contextual information so that consistent decisions can be made all along the way.

The blueprint is also an excellent technique for managing expectations. The blueprint will allow you to disarm those that might paralyze the project with untimely demands about one functionality or another. The blueprint will allow you to respond to the requests by saying either that the requests have been considered and will be done in due time, or that they will be incorporated into the blueprint for prioritization.

Once the blueprint has been drawn, it is time to decide which tool or tools will be used to support the PO processes. Many would argue that in order to decide which tools to use, it is necessary first to define the processes they will have to support to the last level of detail. My experience is that tools such as the ones described in Chapter 5 provide a generic platform for portfolio management that could be adapted to many different processes; furthermore, a tool that cannot be adapted should be discarded automatically, since a tool that fits today's processes like a glove might not be useful for tomorrow's processes. The reason to move swiftly on this is that most of the processes need automated support. If everything needs to be defined before proceeding to tool selection, there will be an impasse of 6 to 12 months before the deployment will start.

With the blueprint completed and the decision on the automation under way, it is time to prioritize the order in which things will be done. The order of implementation should take into consideration the following:

Business priorities;
Technical dependencies;
Political needs.

The guidelines listed below [11] provide advice on how to approach the planning and management of the deployment project to prevent "improvement burnout" and paralysis-by-analysis:

Use concrete business objectives to drive the prioritization of the implementation process.
Divide the implementation into a series of nonoverlapping increments, each of which enables tangible business improvements even if no further increments are implemented.
Ensure that each increment implements everything required to produce the desired results (i.e., software functionality, policies, processes, training, and measures).
Scope the increments so that each can be implemented in no more than 4 months.
Use the results of each increment as a basis to adjust the blueprint and plan for the next increment.

A key aspect of the proposed approach is the combination of quick results and cumulative learning periods, so organizations shall not try to compensate for delays in the deployment of one increment by concurrently initiating the next one or by packing more features into the next increment than what can be accomplished in a 3-month period. Long or overlapping segments defeat this purpose, as they invite the same problems that plague most all-at-once implementations and work against the goal of providing cumulative episodes of learning.