Multi-Project Management and Programs - The Project Group

1 downloads 187 Views 410KB Size Report
It is important to always maintain an overview in multi-project management, ... deals with the requirements of optimal s
Multi-Project Management and Programs Requirements for optimal IT support - e.g. in the electronics sector Author: Johann Strasser, TPG The Project Group

It is important to always maintain an overview in multi-project management, especially in complex programs with numerous sub-projects. This is even more difficult when it comes to internationally spread program teams. Keeping an eye on success-critical data such as milestones under these conditions is only possible with suitable IT support. A rough schedule plan is the suitable control tool for the program. With its help, the manager and steering committee can maintain their overview. Deviations and their impact on the program are recognized at an early stage, enabling a fast response. For many programs, the speed of target achievement is a decisive factor for success. Based on an example from the electronics sector, this describes a possible solution for program management, which is also suitable for multi-project management. This article deals with the requirements of optimal software for program management, summarizing several projects, which are interdependent and all serve to achieve a superimposed and frequently complex goal. In many cases, one could also say that a program is like a main project with numerous sub-projects. According to the PMI standard, the requirements to program management entail: - the coordination of schedules, - the coordination of resources, - overlapping risk management, - collaborative change management - and other operational tasks. In contrast, the term multi-project management encompasses all simultaneously processed projects in one organizational unit. Apart from some contextual correlations, this mainly incorporates dependencies for commonly used resources. We will only concentrate on schedule-related program management using an example from the electronics sector. (Note: outside of German-speaking countries, the term multi-project management is usually covered by the terms program management and project portfolio management).

www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en

Roles and requirements in program management From the perspective of a PMO (Project Management Office), the requirements to program management do not differ from those to multi-project management. So these standards, which have hopefully already been set, can be incorporated. This should ideally include software support suitable for this specific application. However, we still need to clarify whether the PMO also has to deal with the sub-projects of a program, or whether the program is regarded as a whole, something which must be differentiated on a case-to-case basis. The program manager carries the operational responsibility for the program, whereby he is supported by his program team, primarily composed of the sub-project managers. Apart from his duties as a project manager, he must further identify, as well as centrally and actively manage the dependencies and interfaces among the sub-projects. The program manager carries the operational responsibility for the program, whereby he is supported by his program team, primarily composed of the sub-project managers. Apart from his duties as a project manager, he must further identify, as well as centrally and actively manage the dependencies and interfaces among the sub-projects.

“For large programs, it would be advisable to establish a program office, which supports the manager in the planning, control and completion of his program.“

The tasks of the program office also include the establishment of the internally specified, uniform project management method for the program‘s projects. In this case, one of the most important points is the uniformity of structures and milestones in the sub-projects. This permits the clear depiction of both the aggregation in the program plan and the specifications to be returned from there to the sub-plans. Depending on the specific design, the program office can also provide sub-project managers or operational support for the same. The sub-project managers control one or several sub-projects and report directly to the program manager. Their responsibility is to supply the program manager with sub-project plans containing valid data and to actively contribute to the control of the program within their department. They have to accurately observe dependencies within the program, communicate deviations promptly and update their own plans in accordance with the specifications from the program. Here, especially the schedule-related communication between sub-projects is effected mainly centrally via the project management and less remotely between the sub-project managers. This permits better control of the impact on the entire program. Apart from the standard of the PMI, the requirements to program management entail the coordination of schedules, the coordination of resources, overlapping risk management, a common change management and other operational tasks.

www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en

Program start: Specification of features and releases If we stay with the electronics sector image, program management deals with coordinating features and releases over and above sub-projects. The product to be developed usually consists of many different hardware and software components. These are individually developed in various teams and integrated at the end. However, the development and integration do not follow in a single step with a full range of functions. This is executed incrementally during several development and delivery stages with defined functions across all components. The features bearing the benefit of the electronic device are specified at the start of the program. A cell phone, for example, will feature an alarm clock, an Internet browser, WiFi and possibly a music player. A release plan defines which feature or which interim release is to be made available and tested at which stage of development. Some product developments have release plans with several hundred features and fifty or more delivery dates covering more than one year.

Figure 1: For testing purposes, features must be provided in various releases

In this case, a feature will usually appear in several components, which are created by various teams. This is the real reason for the level of complexity. The cell phone’s alarm clock, for example, requires a user interface to set the time, which needs to be saved and registered as an event. At this stage the loudspeakers are supposed to issue one of the selected melodies. Put together, this requires at least five or more components, which are affected for interim delivery with a functional alarm clock. In total, this may amount to a hundred components developed by twenty teams. Each of these teams must provide their contributions together on the planned release dates.

www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en

Figure 2: One feature appears in several components provided by distributed teams. The challenge of coordination in the program In this case the affected teams are ever more frequently spread across the entire globe and are involved in the company’s programs in accordance with their skills. In order to ensure good coordination, a plan structure, which also complies with the responsibilities, would be advantageous. Components are therefore usually planned in internal sub-project plans or component plans organized according to features. The role of the sub-project manager is usually adopted by the person responsible for the assembly units or components. In some companies, there are additional persons responsible for features, whose task is to be included in the implementation planning and control of the features in their area of responsibility across all components and releases. The challenge of resource management in the program The complex dependencies also result in a permanent challenge to resource management. If the delivery dates of components are postponed, the waiting test or integration procedure within another sub-project will also have to be postponed. The associated topic of assignment planning for the individual resources, however, should not be settled at program level. The program manager should therefore arrange delivery items with the individual sub-project managers instead. This means that only the contents and deadlines in the form of milestones and not the resources are planned at program level. However, these are a natural result of the availability of the resources in the sub-projects, which must also be controlled by the sub-project managers. The structure of a control and early-warning system Firstly, the central release plan for the steering committee must be designed correctly. On the one hand, the various development stages of the deliverable features are assigned to the releases, while on the other hand, this requires the completion dates from the component plans affected by the features to be recorded. It is therefore necessary to maintain an overview, which displays all deliveries from all affected components required for a release. This overview should display whether all sub-deliveries from the component plans will follow on the planned release date or not. www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en

This also requires the component plans to be designed in such a way that a standardized completion milestone is ultimately detectable per feature and release. Specifications from the release plan must then be rolled out to these milestones and vice versa, the actually planned deadlines have to be reported back into the release plan. Please note that sub-projects should not be interlinked at this stage! Sub-projects should only be interlinked via the release plan, so that the steering committee is always able to control their dependencies and deadlines. This is the only way to implement an efficient control and earlywarning system for program management. This is outlined as follows: “Bottom up” and “top-down” communications in the program A suitable software solution graphically illustrates the target/actual differences in the release and component plan by inserting the milestones into the other plan respectively. The steering committee will, for example, view the following image to see that Release 1 features the early completion of Component 1. However, in Release 2, the Component 1 plan will report a delay in the specified deadline to the program manager’s release plan.

Figure 3: “Top-down” and “bottom-up” communication in the program as an important success factor Clear responsibilities regarding dates and saved time The clever aspect of the bidirectional program management solution described above is that one party cannot change the data of the other. Milestones are inserted into the other plan at the push of a button for information purposes only. This information then serves as a communication basis between the responsible parties. Any necessary changes can then be made in the division’s own plans. Every project manager maintains control over his own schedule. Neither his own nor third-party data are changed. This is crucial for the acceptance of a software solution. This procedure also saves time, as communication can follow specifically targeted lines.

www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en

This ping-pong game consisting of “top-down” and “bottom-up” communication between the various levels is an important success factor in program management and is easily supported by suitable software. With an appropriate extension, Microsoft Project Server is easily applied for program and multiproject management. Apart from deadlines, other information can also be randomly exchanged between the projects, such as work, expenses or text information.

------------------------------------------------------------------------------------------------More professional articles You may also be interested in the articles “How to reduce resource conflicts“ and “strategic and operative resource management“ on http://www.theprojectgroup.com/en/professional-articles or stay tuned and register for our TPG BLOGINFO Newsletter on http://www.theprojectgroup.com/blog/en

The author: Johann Strasser Following several years’ experience as a development engineer in the automotive and energy sectors, Johann Strasser wor-ked in the field of project management for ten years as a self-employed consultant and trainer. During this time, he was a project manager for software projects in the construction sector and managed scheduling and cost management for large-scale building projects. He has been working intensively with Microsoft Project ever since the first version was released. Johann Strasser also authors articles for a variety of journals and is a recognized speaker on all project management related topics. Contact: [email protected]

www.theprojectgroup.com [email protected]

TPG is a registered trademark in the European Union and in the United States of America.

Copyright TPG The Project Group All rights reserved 02/ 2016 (v1.0)

www.youtube.com/tpgtheprojectgroup www.twitter.com/tpg_com (@tpg_com) www.theprojectgroup.com/blog/en