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