PROGRAM EXECUTING case studies in project program and organizational project management

298 CASE STUDIES CHAPTER SUMMARY Name of Case Area Supported by Case Case Type Author of Case Program Strike Zone Distribute Program Information, Engage Program Stakeholders Critical Incident Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul Program Map Manage Program Architecture, Manage Component Interfaces Critical Incident Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul Using Tools on a Mercedes Direct and Manage Program Execution Issue - based Case Sabin Srivannaboon and Dragan Z. Milosevic 299 The Program Strike Zone Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul AJ ELECTRONICS AJ Electronics is an electronics manufacturing company, specifi cally founded to produce a measurement device for the healthcare industry. Known as a small but reliable company, AJ Electronics has customers in different regions including Europe and Asia. These days, their product brand is getting more popular as a result of relentless efforts of the management team to continuously improve their business in almost every aspect. Last year, the company revenue soared by more than 5 million. Considering the company size, this is a big growth. The manage- ment team is extremely happy about it, and wants to see their business continue to thrive. At the beginning of this fiscal year, the management team discussed additional improvements they could make to their business. Because AJ Electronics is a program - driven company, one major challenge is definitely in the program man- agement area, where its Achilles ’ heel is in the monitoring arena. So the company formed a team to study a number of monitoring concepts, and decided to change the ways their programs were monitored and controlled to improve its efficiency. To be more specific, they wanted to introduce the “ program strike zone ” concept to every major program in the company. THE PROGRAM STRIKE ZONE The program strike zone, also known as the bounding box, is an effective tool used to track a program ’ s progress toward achievement of the key business results by identifying the critical success factors of a program. The key is to build the measures of a program that are important to the company, and then allow the team to function freely within those boundaries. In other words, the program team is empowered to plan and execute the program as long as the program meets the requirements or threshold approved by management. This program status is usually 300 CASE STUDIES represented by green G. However, if a critical target or limit is or is about to be compromised, the situation must be brought to the attention of the governance councilmanagement. These statuses are usually represented by yellow Y or red R, depending on the severity. The program strike zone is intended to foster excellent communication on program objectives, expectations, and status throughout the program life cycle from program initiation through program closure. Equally important, the tool is used to focus team and management attention on the critical program issues. Therefore, the specified conditions should be clearly stated, objectively mea- sured, and understood and agreed to by both the program team and management at program initiation and each major review until the program reaches closure. The zone should be maintained and updated as necessary to reflect the current objectives, expectations, and critical program issues. If appropriately executed, the zone will provide useful and timely management guidance for better program monitoring and controlling purposes. AN EXAMPLE OF THE PROGRAM STRIKE ZONE In implementing the program strike zone concept, AJ Electronics requested that every program that forecasts more than a certain margin percentage incorporate the zone with its plan and address the zone in every major review meeting. Figure 16.1 shows the program strike zone of one of these programs at the design and verification phase. Program Executing Process 301 Discussion items 1. What are the major benefits of the program strike zone — major advantages, and disadvantages? 2. What are important criteria to identify critical success factors and their thresholds? 3. What are major challenges in implementing the program strike zone concept? Value Proposition • Program review if target market changes significantly • Fast and accurate measurements G G Business Strategy Alignment • Support solutions for Network Element Manufacturing Test G Product Features and Functionality • External tunable laser input • Three receive data electrical outputs G R Customer Driven Milestones and Schedule Target Threshold • Customer review of initial specification Nov 3, 08 Nov 10, 08 • Customer demo Feb 3, 09 Feb 10, 09 • Customers review of final specification April 9, 09 April 16, 09 • Prototype available April 13, 09 April 23, 09 • Prototype delivered to customers May 26, 09 June 9, 09 • Final system delivered to customer Sep 1, 09 Sep 15, 09 G Y Y G G G Financial AssumptionsForecast Target Threshold • Projected Program Spending: FY01 1, 580K 10 or 160K FY02 1, 664K 10 or 170K Total 3, 244K 10 or 324K • Forecasted Orders: FY02 8.6M ⫹⫺ 15 G G G G G Y R Progressing well Heads up Help needed Figure 16.1 An Example of the Program Strike Zone 302 The Program Map Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul TRAINING Ken Sanford is a senior consultant at Titan consulting fi rm. He is recently hired by a small company that sells sensors and electronics platforms to conduct program management training to its senior staff and managers. The training is in a work- shop format, which particularly emphasizes a concept of program management for improved operations competence. The training is a five - day session. Ken has already spent two days talking about the program management framework, and the strategic aspects of program management and its tools. Today, he is planning to address the operational aspects of program management tools. One of the tools on his list is called “ the program map, ” which is an enabling device for managers to reach an objective or a program deliver- able. He plans to give the audience hands - on experiences in developing one. WHAT IS THE PROGRAM MAP? The program map is a tool that provides an illustrative overview of the program, which includes cross - project dependencies on a horizontal timescale. The map includes the critical deliverables of each involved project team throughout the program life cycle, where it uses arrows to represent the dependencies of cross - projects. The goal of the map is to enable the program team to understand the deliver- ables and dependencies among the project teams on the program. The mapping of deliverables from one team to another helps the program team to determine and fully understand the cross - project dependencies that exist on the program. The key steps in building the map are as follows: Step 1 : Prepare information inputs e.g., key elements of the program strategy and requirements, project managers ’ input, and knowledge of the program technology. Step 2 : Identify primary project deliverables from the program WBS PWBS and the detailed requirements. For each deliverable, document the critical information Program Executing Process 303 needed for the mapping process — deliverable name, time to develop the deliverable, and dependencies required to complete the deliverable. Step 3 : Create vertical partitions that represent the lowest level of schedule tracking that will place on the program days, weeks, months, or quarters. Create the horizontal axis that represents the different project teams involved in the program. Then, enter deliverables for each project team into the horizontal lanes, matching the expected timescale on the vertical partitions. Continue the mapping exercise until all program deliverables are entered on the program map. Step 4 : Build cross - project dependencies by using the arrows to connect indepen- dent milestones with dependent milestones. Cross - project dependencies will determine the sequence of development, interfaces, and responsibili- ties, as well as the initial timeline. THIRD DAY OF TRAINING Ken: It ’ s almost 9:00 AM . I think we should start the session. What we will cover this morning is a tool that is called the program map, which I also briefl y explained yesterday. The instruction of how to create the map is in your folder. I hope you had a chance to study it last night because we are going to do an exercise about the map today. Table 16.1 Cross - project Dependencies Project Teams Major Deliverables Cross - project Dependencies Expected Completion Date Software development 1.1 Power control software NA Workweek 1 1.2 BIOS NA Workweek 3 1.3 Software verify report 4.1, 4.2 Workweek 8 Hardware development 2.1 Hardware design files 1.2 Workweek 4 2.2 Hardware verify report 4.2 Workweek 8 Enclosure development 3.1 Enclosure design files 1.1 Workweek 2 Manufacturing 4.1 Manufactured enclosures 3.1 Workweek 4 4.2 Manufactured circuit boards 2.1 Workweek 6 Product test 5.1 Test case 2.1 Workweek 5 304 CASE STUDIES Now let ’ s assume that you guys are managing a program initiated to introduce a new type of electronics device. Because of its complexity, the program consists of multiple project teams; namely software development, hardware develop- ment, enclosure development, manufacturing, and product test. Each project team is expected to produce major deliverables at different times. And these deliverables may have cross - project dependencies. Here is the summary. Discussion items 1. Construct a program map of the given information in the case. 2. What are the major benefits, advantages, and disadvantages of the program map? 305 Using Tools on a Mercedes Sabin Srivannaboon and Dragan Z. Milosevic BACKGROUND RollingSys is a privately held corporation that provides computer solutions to help customers design, build, deploy, and manage next - generation numerically controlled tool machines. These products require a lot of customization, resulting in each order being organized as a program. For this reason, the products are well known and have earned many outstanding awards. RollingSys has seen an increase in orders from Asia and Europe, which puts a lot of pressure on their six program managers. After a long discussion, a deci- sion was made to hire Keith Richardson, an experienced program manager. Mick Beggar, the director of the program management office PMO for RollingSys, prepared a plan for Keith to transition to the new job, including familiarizing him with RollingSys ’ s program management system. Following is part of the famil- iarization relating to the strategy and program management tools and metrics. Taking part in the discussion are Keith; Mick; and Charles Waters, a longtime program manager. ALL ROADS LEAD TO THE BUSINESS STRATEGY Mick: I want to make something clear from the very start. RollingSys ’ s choice and application of program management tools, like all managerial processes and actions, is driven by the business strategy. Therefore, we should fi rst talk a bit about RollingSys ’ s real strategy — not the company ’ s public relations ’ word on strategy — but such things as the company ’ s strategic uniqueness and what makes it successful. As director of the PMO, I often interpret the strategy of RollingSys to my pro- gram managers. So, at this time, I feel obliged to put on the hat of the director of PMO and explain the business strategy. First of all, RollingSys is unique in terms of breaking down the components of the business and understanding what makes it successful and what doesn ’ t make it successful. Our products are often recognized as the best products on the market. If you think of an airplane 306 CASE STUDIES seat analogy, they are in the fi rst class section . Also, the ability of RollingSys to get customer input makes a huge difference. What our customers want to use the product for often becomes clear through the ability of the company to get engineers in front of customers. Most of the functionalities of RollingSys ’ s products are actually used by customers. Our business is moving from the old traditional “ here is the computer we build ” to “ what are the features you need in the computer we are going to build? ” Moreover, we have repeatability across different product lines. The repeatability allows the company to shift the pro- gram manager from one product line to another with an adequate understanding of performance criteria and his or her responsibilities. This makes us unique and is a factor in our success. What, then, is RollingSys ’ s business strategy, and what is the role of program managers in the context of such strategy? RollingSys is often a fi rst mover, so it is technology innovation and to be fi rst in time - to - market. In that con- text, the program managers are responsible for more than just getting from program start to program fi nish. They are required to deliver the program on time, meet all the objectives of the program, and are responsible for business results. Therefore, you are expected, as any other program manager, to be a very visible and seasoned business manager aligning your programs with the strategy. Keith: That having been said, can we now talk about tools? I would like you to take an example of a program and tell me how using specifi c tools in that program helped make it successful. Give me the background of the program. MERCEDES Charlie: I suggest using a program called Mercedes as an example. The cus- tomer had all sorts of requirements, one being the program name. They said, “ In our country, a Mercedes car is the ideal of high quality. We want this pro- gram product to be of high quality, like a Mercedes car. In order for you to keep our high - quality expectations in mind at all times, let ’ s call this program Mercedes. ” Basically, they wanted to have a capability added to RollingSys ’ s existing product. RollingSys got an opportunity to win a large competitive sale in Spain if the program was delivered on the particular date. So, RollingSys formed a team to execute this program. I was the program manager for it. The program went from conception to completion in eight months, which is not normal. It is probably the best example of how our process works at optimum. On top of that, it brought the company several million dollars in revenue to date. In RollingSys, managers believe that the program was successful partly because it used all the tools of the program management knowledge base that are available at the company. So there is a belief that the program management system as a whole works very well here. Program Executing Process 307 SELECTING AND APPROVING A PROGRAM Keith: Can you explain what strategic tools were used in Mercedes to make sure that it was well aligned with RollingSys ’ s business goals and strategy? Mick: RollingSys uses both strategic and operational tools, divided per major program activities. But there is a word of caution here. Typically, program man- agers would not be involved in the development of strategic tools. Generally executives do them. However, each program manager needs to know them well because he or she will use them in communicating with executives about pro- gram status. The whole alignment process begins with the strategic plan and continues with portfolio maps and the business case. RollingSys ’ s practice differs from some companies in, for example, the business case. The strategic plan drives the alignment. In other words, it is a tool or mechanism to ensure the quality of the alignment in RollingSys. RollingSys ’ s strategic plan usually includes the product roadmap, technology roadmap, customer technology roadmap, and the business model for the next three years. It addresses things like mission, objectives, long - term strategy, market size, segmentation, competition assumptions, and market share. In par- ticular, the product roadmap proposes products within the three - year time frame and addresses those currently in development. For each product, it includes start and completion dates, milestone dates, total nonrecurring expenditure, and the three - year sales forecast. RollingSys ’ s strategic plan drives its formal portfolio management process, where programs are prioritized in terms of the program portfolio needed for customers and for the business. Mercedes is no exception. It was a program selected from the product roadmap and prioritized in the portfolio process, and its implementation was sped up by the customer requirement. Generally, executives focus on the strategic plan to analyze the growth plan and determine what the right markets are for the company, where the company is the most successful, and where the customer gets the greatest value for the products. Then, the programs are planned in alignment with the strategic plan over the next three years with their expected sales and profi t dollars are identi- fi ed. By looking at them, we are able to see the growth from different direc- tions, such as its existing business extend or upgrade, new products in new markets, and pure technology transition. As a result, the importance of certain products becomes more obvious than others. Then, depending on product com- plexity, market pressure, and other signifi cant factors, programs are initiated and selected into the program portfolio. We don ’ t really use any specifi c tools for the selection of a program into the portfolio, but there is a lot of discus- sion. Once a program is selected into our portfolio of programs, we use several 308 CASE STUDIES types of a tool called a portfolio map to display all our selections. Each one has different parameters on the x and y axis, for example, net present value x axis. The portfolio map helps us to balance the selected programs by visualizing all of them, comparing them, and seeing where we have to intervene to achieve product balance. This is very important for our organizational success. Now, we begin to develop the business case for programs close to their imple- mentation time. Some companies, as I said, use the business case differently than we do. They use it to select programs into the program portfolio. We use it to approve a program for actual implementation in the concept phase. If we do a good job using this tool, i.e., the business case, we will give the go - ahead to run good programs, and kill poor programs. So, the business case tool is of make - or - break importance to our program success. Choose a poor program, and you are kind of doomed. Choose the right one, and you are given an oppor- tunity to succeed. Our program managers tend to be assigned to a program shortly after a concept is approved, and are responsible for the successful com- pletion of the program. They will make trade - off decisions on features to make sure that the plan is actually aligned with its objective. PROGRAM PLANNING Keith: Once you select a program into the portfolio and a program manager is assigned to execute the program, what tools did you use to ensure the quality of the alignment during the program planning, and how did they contribute to the program ’ s success? Charlie: A lot of tools were used in Mercedes. First, a tool called the pro- gram strike zone was used. The strike zone is simply a set of agreed upon program critical success factors and business results established to help execu- tives and program managers monitor the programs by specifying quantitatively the boundary conditions under which the program can operate. Metrics such as time - to - market, target market, net present value, and key milestone dates were included in the strike zone. In Mercedes, the priority success factors were schedule, features, profi tability. You see here how the business strategy i.e., time - to - market shapes the program strike zone, making schedule its fi rst priority. Simply speaking, it was our primary alignment tool and it helped me to develop a program plan and, at the same time, make sure that the program met the business needs. By doing all this, the program strike zone contributed to a successful program. During a one - day workshop called Map Day, the core team developed a program map, which is a tool showing critical cross - project dependencies related to the program schedule and the critical deliverables of each project Program Executing Process 309 team throughout the program life cycle. The program map was used for two things — to do a preliminary program work breakdown structure PWBS and a preliminary master program schedule. Actually, the critical deliverables went into the PWBS, which then served as a guideline to project teams to develop their project WBSs, which I took back and, after a thorough review with project managers, merged into a detailed PWBS. Based on the critical cross - project dependencies from the program map, the initial program schedule was developed. Once the master program schedule was completed, it was decomposed into the seven project schedules. In this way, a hierarchical schedule with two levels was obtained — the fi rst being the master program schedule, the second being the project schedules. In terms of scheduling, standard project management tools were used for the master program schedule and the project schedules. The business strategy of being the fi rst in time - to - market had a key role in determining which tool was chosen. PROGRAM MONITORING AND CONTROL Keith: What about tools used for monitoring programs? Charlie: One of the tools we use is called the program dashboard. The dashboard is a management tool visualizing the status of programs, by using red, yellow, and green indicators. Red means management intervention is needed, yellow means warning, and green means that the program is progressing well. Tools like the dashboard and the program strike zone are commonly used everywhere in the organization to help executives communicate with program managers. The executives want to see if the programs are still aligned with the business strategy, and determine if any corrective actions are needed to recover them from mis- alignment. In many instances, when there ’ s an issue that pushes the program out of the success criteria limits, one of the program indicators will turn red. Then, executives and program managers will have to develop corrective actions andor adjust the success criteria limits. In Mercedes, we also used the program review, which is a tool used to commu- nicate program progress or to involve senior management when they need to step in and make some tough decisions. We used the periodic program reviews in addition to the phase gate milestone reviews. Lastly, a mandatory tool we use is the wiggle chart. The chart anticipates the expected rate of future program progress, focusing on predictions of major program events, like milestones and program completion. Let me show you an example see Figure 16.2 . 310 CASE STUDIES The vertical axis shows the team ’ s predicted completion date for a specifi c pro- gram milestone, for example the engineering release or product ship release, while on the horizontal axis we can see the actual date the prediction was made. The beginning point on the horizontal axis is the time when the schedule baseline is prepared and the high - level program milestone dates are marked on the vertical axis. After the beginning point, the program work is kicked off, and the horizontal axis represents the actual program timeline. The team reviews progress regularly and makes milestone predictions. By connecting all predictions for a particular program milestone into a line, we can obtain the milestone trend line. Should the line go upward, the program manager would know that there is a milestone schedule slip. Delivering the program milestone on time would produce a horizontal line. If we estimate an early program milestone completion, the trend line would go downward. Although it is effective in predicting milestone progress, the chart is even more effective if used to develop actions required to eliminate any potential deviation from the baseline program milestone schedule. In general, the wiggle chart acted like a compass, helping in Mercedes by warning us early of potential schedule slips so we could take corrective action and navigate toward success. Just imagine navigating the troubled program sea without a compass 1012001 4601 5601 6601 7601 8601 9601 10601 11601 12601 1602 2602 Weekly Updates 10152001 10292001 11122001 11262001 T ar get Dates 12102001 12212001 172002 1212002 242002 2182002 Program wiggle chart Engineering release Product ship release target Likely product ship release wrisk days Product ship release limit Figure 16.2 The Wiggle Chart Program Executing Process 311 METRICS Keith: I read somewhere that man is a tool - using animal. In Mercedes, you seem to confi rm that. Now, what about metrics? Could you please elaborate more on the topic with regard to balancing the program and company needs, and how they helped the program succeed? Charlie: Program performance is mostly measured by the ability of the pro- gram to meet major milestones, such as the launch target date. Since RollingSys wants to be a fi rst movertechnology innovator, other metrics are important, but not as important as schedule metrics. But there are some differences among programs and the metrics they focus on. For example, in Mercedes, the priorities of metrics were schedule, features, gross margin, PI profi tability index, development expenses, manufacturing costs, market share, and staffi ng levels. The schedule was so important that progress was measured by the ability to meet the milestones and delivery date, together with the feature sets requested from customers. In parallel with sat- isfying customer needs, the company ’ s bottom line is of primary concern. So executives use the program strike zone to specify the boundary conditions that match the company ’ s business needs, like return on investment ROI, in the form of the PI, or profi tability index. The other metrics such as performance to development cost, manufacturing cost, and market share were of second level of importance compared to time - to - market, feature set, gross margin, and PI. Overall, what I am trying to say for Mercedes is that customer needs, time - to - market, and feature set are balanced with our business needs — which is to make money, to be brutally honest. We combined those things together and cre- ated the business results. That also has another loud message: our metrics, like tools, were driven by the business strategy. We did this properly, and metrics contributed to the program ’ s success by letting us know if we were heading to success and should stay the course, or if we needed to take corrective action. Discussion items 1. What strategic and operational tools were addressed here? How were they used differently? 2. Explain the alignment process at RollingSys. 3. List the major advantages and disadvantages of the fact that program manag- ers tend to be assigned to a program shortly after a concept is approved, not at the beginning. 313

Chapter 17 PROGRAM MONITORING

AND CONTROLLING PROCESS The central interest of this chapter is the program monitoring and controlling process. To monitor is to measure a program, whereas to control is to fix what- ever problems we have once we measure the program. We offer cases in two different industries: the information technology field and the mobile service industry. There are three cases in this chapter — two critical incidents and one issue - based case. 1. I Have Only Three Minutes a Month I Have Only Three Minutes a Month is a critical incident that talks about the importance of a progress report for program management and its brevity. 2. OSSOP OSSOP is an issue - based case that focuses on monitoring and controlling programs using a dashboard approach. The case also describes a guideline for program classification, which can be further discussed. 3. That Which Is Not Earned Is Never Valued This critical incident case discusses the Earned Value concept for moni- toring and controlling program status. Particularly, it shows an example of the unsuccessful program where the earned value concept was applied without a deep understanding of the way it worked. 314 CASE STUDIES CHAPTER SUMMARY Name of Case Area Supported by Case Case Type Author of Case I Have Only Three Minutes a Month Progress Report Critical Incident Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell OSSOP Monitor and Control Program Risk Issue - based Case Sabin Srivannaboon That Which Is Not Earned Is Never Valued Monitor and Control Program Performance, Program Schedule, and Program Financials Critical Incident Sabin Srivannaboon