8.2 Where to start

8.2 Where to start

The assessment of the current situation and an educational campaign are always good starting points. Even if you think you know what the problems are and how to address them, you need to begin with an assessment of the current situation. Besides the obvious gathering of information on the current strengths and opportunities for improvement, the undeclared purpose of the assessment is for all the stakeholders to achieve a common understanding of what the problems are and what can be done about them.

Achieving a common understanding of what the problems are is not a minor accomplishment. As mentioned with respect to mental models, one should never assume that everybody sees the same problems or confers them the same significance.

The charts in Figure 8.4 show the disparity of responses given by the senior executives and project managers of three global organizations to the following three questions:

  • Do you have problems coordinating your project portfolio?

  • Do you have a document describing the functions and role of a PO?

  • What is the most important obstacle in deploying a PO in your organization?

click to expand
Figure 8.4: Different perceptions of realities at ABB, Ericsson, and Saab. (Source: [10].)

The disparity of responses within a given organization reflects the different understanding and perceptions of the respondents. The lack of a common understanding about the problems the deployment of a PO should solve could not only undermine the efforts but also result in missed opportunities if the alternative diagnostics turn out to be true.

Don't assume that everybody is at the same level of understanding or has the same knowledge you have. Albert Einstein once said, "It's not that I'm so smart, it's just that I stay with problems longer." If you have spent some time thinking and reading about the problems of multiproject management, it is highly likely that you have insights into the problem that people who have not done so do not have. This could be addressed by means of an education campaign aimed first at showing the problems associated with multitasking, coordination across multiple projects, the use of overtime, and so on. Whenever possible and avoiding assessments that sound like criticism, the campaign should be linked to actual problems experienced by the organization. Once people are aware of the problems and the mental models have started to surface, the organization is ready to move to the next stage.

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.