Program Management as in the Case of the Electronics Industry

0

+++ Program Management – Requirements for Top IT Support as in the Case of the Electronics Industry +++

By Johann Strasser                                                                                                                Read article in German

Were you hoping for a practical example after reading our article ‘8 Tips for Successful Program Management’? Well, here it is.

Concerning the example of the electronics industry, you will learn:

  • what requirements need to be fulfilled in program management in general and
  • which roles are essential to success.

What is more, you will learn about a suitable IT solution for this environment. We will introduce you to solutions to the following issues from the electronics industry:

  • feature and release specifications
  • team and component coordination
  • collaboration between program manager and sub-project managers
  • control and early-warning system
  • communication within the program

Complex programs with countless sub-projects require you to stay on top of the crucial data. In the case of internationally distributed program teams, it becomes even more difficult. Under these premises, there is only one way to keep the crucial data in view. You need appropriate IT support.

Find out more about applied program management in our customer solution addressing International Product Development at KARL STORZ – Read now.

Distinction between the Terms Program Management and Multi-Project Management

  • We view a program as comprising multiple interdependent projects. All these projects serve to achieve an overall, and often complex, goal. In many cases, one would be able to say that a program is a master project with many subprojects.
  • In contrast, we define the term multi-project management. It comprises all projects of one organizational unit implemented concurrently. You will find the odd content dependency. But the main dependency between these project is that they draw on the same resources.

Interested in multi-project management? Read about 7 Crucial Success Factors.

Roles and Requirements in Program Management

According to the PMI standard, program management requirements include:

  • Schedule alignment
  • Resource coordination
  • Overall risk management
  • Joint change control
  • Other operational tasks

Special Download: Benefits of MS Project Server / Project Online to the MS Project Standard

Please click here to download the PDF and learn why you should prefer the server over the client version.

The following roles are essential:

The PMO

From a PMO standpoint, the requirements for program management are identical to those of multi-project management. Revert to standards, which have hopefully been set already. Ideally, this would also include software support adequate for this business case.

But by all means, clarify whether the PMO is also responsible for the sub-projects of a program. Or whether the program is considered as a whole. This can differ from case to case.

Looking to set up a PMO? Read our insightful article describing how to be successful in this!

The Program Manager

The program manager carries operational responsibility for the program. The program team – primarily composed of sub-project managers – supports him or her in this. In addition to the tasks of a project manager, this role has to identify dependencies and interfaces among the sub-projects. Central and active management of these dependencies and interfaces is a further responsibility.

The Program Office

Beyond that, it is advisable to establish a program office for large programs. This body supports the program manager in planning, controlling and winding up the program.

The program office has a particular responsibility: It needs to establish the company’s internal standard project management method for the projects in the program. Standardized structures and milestones in the sub-projects are an essential point.

Thereby, the aggregation into the program plan can be depicted properly. The same goes for the return of the targets from the program plan to the sub-plans. Depending on its design, the program office can also provide:

  • sub-project managers or
  • operational support for the latter.

The Sub-Project Managers

The sub-project managers control one or several sub-projects. They report directly to the program manager.

It is their responsibility to:

  • supply the program manager with sub-project plans containing valid data
  • actively contribute to program control in their area
  • accurately observe the dependencies within the program and report variances in good time
  • update their plans in accordance with the program targets

The schedule coordination between sub-projects in particular occurs mainly through central program management. Individual arrangements between sub-project managers are less frequent. This approach gives you better control over the effects on the program as a whole.

Our tip: Use a rough schedule as a control mechanism for the program. It will help the program manager and the steering committee to keep track. You will be able to recognize variances and their impact on the program at an early stage. Quick response becomes possible.

Program Start: Feature and Release Specification

The complexity of programs becomes clear when looking at the electronics industry. In this field, you have to coordinate features and releases across sub-projects.

The product you develop tends to consist of many different hardware and software components. Various teams develop these components separately. At the end, they are integrated.

On the other hand, development and integration do not take place in one go with the complete range of functions. They are carried out step by step across several development and delivery stages with defined functions across all components.

A program starts with the specification of features that make up the utility of the electronic device. For instance, a mobile phone includes an alarm clock an internet browser, and WLAN. Music playback is also possible.

A release plan defines:

  • which feature will be provided or tested
  • in which development stage or
  • in which intermediate release.

Some product developments have release plans with several hundred features. Their fifty or more delivery dates extend over a year or more.

Program Management as in the Case of the Electronics Industry 1

Figure 1: For testing, features have to be delivered in different releases

One feature usually affects several components built in different teams. That is the underlying reason for the complexity.

For instance, the mobile phone alarm clock requires a user interface to set the time. The set time needs to be saved and registered as an event. At the appointed time, the loud speakers have to produce one of the selected melodies.

This means: An intermediate release with a working alarm clock will affect at least five or six components. Overall, you may have a hundred components developed by twenty teams. These teams have to deliver their joint contributions by the planned release dates.

Program Management as in the Case of the Electronics Industry 2

Figure 2: One feature affects several components delivered by distributed teams

The Challenge of Coordinating the Program

The affected teams are increasingly scattered all over the globe. They are allocated to their company’s programs according to their skills.

For this, you should use a work breakdown structure reflecting the responsibilities. Hence, components are planned in separate sub-project or component plans structured by features.

Plan your components in separate component plans structured by features. This will help you keep things in view.

The sub-project manager is usually also responsible for the assembly or component. Some companies have feature managers on top of this. The latter have the responsibility to plan and control the implementation of a feature across all components and releases.

The Challenge of Managing the Program’s Resources

The complex dependencies pose a constant challenge for resource management.

You might also like our 7 Measures to Improve Program Management.

Whenever component delivery dates shift, this has repercussions. The related test or integration task in another sub-project needs to be rescheduled, too. However, you will not want to do the resource planning for individuals at the level of the program.

Better arrangement: The program manager and the sub-project managers agree on deliverables.

Agreeing on deliverables supports the cooperation between program and sub-project managers.

If you want to find out more about resource planning, check out our article with valuable tips for resource management!

The result is that you do not plan resources at program level. All you plan are contents and target dates in the form of milestones. Naturally, these arise from the availability of resources in the sub-projects. Again, the sub-project managers control this availability.

Establishing a Control and Early-Warning System

First, you have to design the release plan for the steering committee well. On the one hand, you should match the releases and the increments of the deliverable features.

On the other hand, you have to retrieve the completion dates from the component plans affected by the features.

After all, you want to have an overview showing:

  • all deliveries required for one release
  • from all components affected

Here is what it should tell you: Will all partial deliveries from the component plans take place by the planned release date?

Design your component plans accordingly. You want one standardized completion milestone per feature and release.

Central for component plans: one standardized completion milestone per feature and release.

You have to roll out the targets from the release plan to these milestones. Vice versa, the actually planned dates need to be reported back to the release plan.

Watch out: Sub-projects should not be linked to each other. The linking should occur solely via the release plan. This permits the steering committee to check the dependencies and scheduled dates at any time.

This is the only way to implement an efficient control and early-warning system for program management.

Bottom-Up and Top-Down Communication in Programs

A suitable software solution highlights the differences between the target and the actual situation in both

  • the release plan and
  • the component plan.

Learn more about Program Management Solutions in Product Development and R&D.

To achieve this, milestones from one plan are displayed in the other plan.

In the image below (Figure 3) the steering committee can see a variance: Release 1 will include an early completion of Component 1.

The situation is different for Release 2. This time, the plan for Component 1 reports an exceeding of the target date to the program manager’s release plan.

Program Management as in the Case of the Electronics Industry 3

Figure 3: Top-down and bottom-up communication in the program as a key success factor

Clear Data Responsibilities and Time Saving

A bidirectional program management solution is clever for one reason. Neither party alters the data of the other. The milestones are displayed in the other plan at the push of a button. This is for information only.

The information serves as a basis for communication between the responsible parties.

Thereupon, both parties can change their own plan. All project managers remain in charge of their own respective plan.

The ideal software provides data without changing the data structure of the other roles.

Neither their own nor anybody else’s data are changed. This is paramount for the acceptance of a software solution. In addition, this method saves time. For the communication becomes much more target-oriented.

Read our corresponding 8 Tips for Program Management now for more insight!

This ping-pong game between top-down and bottom-up communication between the levels is an important success factor in program management. The appropriate software can provide the vital IT support.

A good example of this type of software is the Microsoft Project Server. With the suitable extension, it lends itself well to program and multi-project management.

And it is not just dates you can exchange between projects but also other information such as:

  • work
  • costs
  • textual information

Conclusion – Program Management in the Electronics Industry

This article has introduced you to:

  • requirements in program management that need to be met in general
  • roles which are necessary for this

They include the PMO, the program manager, the program office and the sub-project managers.

As in the case of the electronics industry you have found out how to:

  • start programs using feature and release specifications
  • coordinate teams or components via a work breakdown structure
  • facilitate the collaboration between program and sub-project managers
  • establish a control and early-warning system
  • optimize the communication within the program using the appropriate software.

Do you have any questions? Or is there an essential point you feel we have missed? Please let us know in the comment area below. We are looking forward to your feedback!

Final tip: Subscribe to the TPG Blog Newsletter now and never miss another blog post.

 

print this article

Share.

Leave A Reply