THEMES OF PROGRAM case studies in project program and organizational project management
258 CASE STUDIES
CHAPTER SUMMARY
Name of Case Area Supported by Case
Case Type Author of Case
KUPI Methodology
Critical Incident Sabin Srivannaboon,
Dragan Z. Milosevic, and Peerasit Patanakul
The Bounding Box Boxes You
Project and Program Management Foci
Issue - based Case Sabin Srivannaboon
259
KUPI
Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul
KUPI BUSINESS
Founded in 2005, KUPI is a start - up company in the high - tech manufacturing industry that provides a variety of build - to - order products. Because of the industry
nature, new products are constantly being updated, and the slow movers usually get left behind. While other companies in the same market are struggling with
the economic downturns, KUPI Business surprisingly grows fast. This is thanks to the management team, whose vision it is to encourage and cultivate new ideas
for business and process improvements. One important factor contributing to the company ’ s rapid growth is the organizational strategy, which directs the company
to seize market opportunities whenever possible. Fast delivery is one of the com- pany promises. This strategy works fairly well. In fact, a little too well because the
company has grown unexpectedly too fast.
Recently, demands for KUPI products have risen over 150 percent. Although this is good news, the company ’ s capabilities can ’ t keep up with the rising demands,
especially at peak periods. In attempting to deal with the growing demands, the company has created several more requisitions for customer service to take care of
all new orders and customer relations. However, challenges in integrating various works among different functions are still overwhelming. That is because KUPI ’ s
build
- to
- order products require intensive assembling processes, which involve
a number of people from electrical engineering, mechanical engineering, test engi- neering, and manufacturing, just to name a few. Each function possesses different
specialties needed to carry the products to the final assemblies. At the moment, the work for each customer account is pretty much in sequence, following one silo to
the next until the product is ready see Figure 13.1 .
The need for interaction among departments is minimal because of the way the products are originally designed. However, as the demands increase, so
do the product complexities. This requires more and more interaction across the organization, which is difficult for KUPI ’ s current structure. Plus, the existing
operations worked fine only when there weren ’ t too many customer accounts.
260 CASE STUDIES
Now things are starting to fall apart. Just a week ago, multiple deliveries slipped, and the problem seems to be continuing.
John Rossman is the director of engineering at KUPI. He is concerned that the problem will soon become a company - wide crisis. He knows things will
go south if there is no change in the company. But he isn ’ t exactly sure what changes are needed. Changes in organizational structure to facilitate the com-
munication and decision making? Changes in operations process to speed up the manufacturing? Or something else? The list keeps getting longer, and every
solution seems workable.
One fine Sunday, John goes out for a walk and finds ads about program man- agement training on a billboard. “ Program management for improved business
results: the coordinated management of interdependent endeavors to achieve a set of business goals. ” After reading the description of the course and short explana-
tion about program management, he thinks program management may be what he ’ s been looking for. With joyful excitement, John can ’ t wait until Monday to
discuss this idea with his peers.
Discussion items
1. Do you think program management is an appropriate approach? 2. What would be your recommendation? How would you approach the problem?
Function A Function B
Function C Request
Product
Figure 13.1 The Company ’ s Current Work Structure
261
The Bounding Box Boxes You
Sabin Srivannaboon
Generally, a number of organizations perceive a program as an exceptionally large, long - range objective that is broken down into a set of projects. A project,
in contrast, is a specifi c and fi nite task to be accomplished. Although these defi ni- tions have been widely used and adopted, some companies twist the concepts to
suit their needs and culture. This case study takes a look at a leading manufac- turing company, where project and program management are uniquely defi ned
in a totally different way from what seems to be generally known; yet they are very successful. Perhaps the success comes from a clear distinction between the
tactical role of project management and the strategic alignment role of program management.
THE STORY BEGINS . . .
It was 7:50 on a Monday morning. Bill Stevens was waiting in the lobby of Megatronic, a leading manufacturing company in the Southwest. Bill has been
recently hired as a project manager with certain conditions. He was very excited and at the same time a little anxious.
Soon after he arrived, he was introduced to a number of people in the com- pany, one of whom was Mike Fritz, the director of programproject management
at Megatronic.
Mike : Welcome to Megatronic I hope your fi rst day is going well so far. Bill: Defi nitely, it is my pleasure to be part of Megatronic.
Mike : The pleasure is actually mine. You know in your case we had six people interviewing you, and they all agreed that you were the best man for the job.
You have a great deal of work experiences as the project manager for elec- tronic platforms in the past, which I believe will benefi t our company a lot. So
we ’ re all pleased to welcome you here.
Anyway, let me make it clear again at the beginning. You will start here with a title and salary of project manager . However, as we already informed you,
262 CASE STUDIES
you will work in the role of program manager . And in six months, if you learn our program management and platforms, and successfully transform yourself
to a business leader; we ’ ll make you a program manager. If we see things dif- ferently in six months, we will let you go. In other words, you have six months
of trial period. Is it clear?
Bill : Yes, it ’ s clear. Thanks for this excellent opportunity.
These were the conditions that were causing Bill ’ s anxiety.
BACKGROUND
Megatronic is a multi - million - dollar company, which sells all kinds of meas- urement equipment such as probes and oscilloscopes. The company employs
over 12,000 personnel worldwide and has its corporate headquarters in the southwest area. The headquarters campus alone has more than 4,000 employees,
and operates two major product lines of the company: Measurement Kits and Video Scopes.
The headquarters campus has three major entities, which include Manu- facturing Mfg, Sustaining Engineering SE, and Product Lines PL see
Figure 13.2
. Manufacturing and Sustaining Engineering are cost centers, where the majority of the work is running operations Mfg andor sustain-
ing the competitive products SE. On the other hand, Product Lines are
profit and loss centers. The programproject management department is a major office that upports all three entities with specific initiatives projects
and programs.
Major Efforts: Production Line Down Situations, Cost Reductions, etc.
Major Efforts: Day-to-Day
Operations Major Efforts:
New Product Introductions
Sustaining Engineering
Product Lines Manufacturing
Figure 13.2 Organizational Structure
Themes of Program Management 263
PROJECT VERSUS PROGRAM
Soon after he started, Bill was assigned to work on his fi rst program. He was not a novice project manager — Bill had almost fi ve years of project management
experience. But it was his fi rst time working as a program manager. Things were different here from where he used to work. He decided to call a meeting with
Mike to clarify his roles and responsibilities.
Bill: Mike, thanks for your time. I know you are very busy. Mike: Not a problem. How can I help you?
Bill: First of all, I am wondering if there are project and program management documents that I can look at. I want to learn more about them. It seems like
project and program management here are different from what I know.
Mike: We do have project and program management policies. Yes, you can fi nd them in our data base. But let me also walk you through these documents.
As you know, Megatronic is a strong time - to - market company. So what we have created here is to facilitate the speed of our projects and programs.
At Megatronic, a program is an effort that produces new products to the market. We call it an “ NPI ” New Product Introduction, whereas a project is
anything else that is not an NPI. Simple — just like that. Therefore, programs are usually a new nomenclated product, which, for example, provides better
performance than the existing one, and we are going to sell it to our customers by a different product name. Projects, on the other hands, include sustaining
efforts, cost - reduction efforts, product conversions, or anything that does not produce new product nomenclatures. That ’ s why we ’ ve created two differ-
ent policies, program management policy and project management policy, to address these efforts differently. So it is pretty black and white when we talk
about programs and projects here see Figure 13.3 . I would also add that NPI is our top endeavor because of our business nature. So, when they are fi ghting
for resources or priorities, programs almost always win over projects.
Bill: That is quite an interesting defi nition. Program management here is differ- ent from what I know, which is the conventional defi nition, where a program is
usually defi ned as a collection of interdependent projects with a common goal under integrated management see Figure 13.4 .
Programs Projects
Figure 13.3 Megatronic ’ s Program and Project Relationship
264 CASE STUDIES
In my previous company, the program manager was responsible for ensuring that the overall program structure, and program management processes ena-
bled the component teams to complete results. He or she usually interacted with each project manager to provide support and guidance on the individual
projects, especially to convey the important relationship of each project to the bigger picture of the organizational objectives. The program manager, how-
ever, did not directly manage the individual projects.
Mike: That ’ s also a very well - known and proven effective concept. But here things are unique. We tailor the concept to suit our culture and product types.
However, the similar thing is that we expect our program managers to look at the big picture and focus on the strategic alignment. The bottom line is we need
to deliver new products to make money. Completing programs in time thus is a must. We have a policy for program management, which is called “ 1103. ”
This policy defi nes requirements and spells out authorities for the introduc- tion of new products designed and manufactured and branded “ Megatronic. ”
Projects, however, are different. They are more of the tactical efforts, and may not need to be perfectly aligned with our business strategy.
THE BOUNDING BOX CONCEPT Mike: Let me further explain it. Program management creates common lan-
guages used throughout the organization. A program manager here is a business leader, not a technical leader. You don ’ t have to be a technical guru, but you
must know how to communicate with people around you. Our goal is to accom- plish desired business results, not just to get the job done within the time, cost,
and performance requirements. Not simply just the “ triple constraint. ” We have to think more of a business success rather than a fi refi ghting type of work.
In order to achieve that goal, we have a concept, which is called a “ bound- ing box. ” The box refers to boundaries, requirements, and limits established
by management at program initiation and validated during the chartering phase by the program team headed by the program manager, and reviewed and
Program Project 1
Project 2 Project 3
Figure 13.4 Conventional Relationship between Program and Projects
Themes of Program Management 265
approved at the charter review. The program team is free to plan and execute the product development program as long as the program meets the boundaries,
requirements, and limits in the bounding box approved by management. If the box conditions are violated, the program will be considered “ out of bounds. ”
And if this is the case, the program manager will have to initiate an out - of - bounds review with the program stakeholders and sponsor. For many examples
here, programs are primarily for time - to - market. So their schedules are the top priority in the bounding box. The schedule conditions and boundaries will be
very tight with less room to make any mistake. On the other hand, cost and scope can be sacrifi ced in order to make the schedule happen.
Bill: That ’ s an excellent concept. In my previous company, we didn ’ t have it. We used only phased - gate reviews for our new product development process.
Mike: I see. We kind of combine them here. The bounding box concept also helps encourage communication among the key players, including stakehold-
ers and program sponsors. It supports quick decision making and resolution of issues and problems at the appropriate management level and with the appro-
priate amount of documentation. Let me give you some examples of typical elements that might be bounded in a program.
Market size Financials
Schedule Alignment with strategy
Customer requirements Required technologies
Resources Speed of any technology development
The elements in the box should include the critical success factors, which should be scaled to scope and complexity of program. Equally important, the
elements should be as objective and measurable as possible. For example, schedule and cost metrics can be direct quantitative metrics. You noticed that
the box involves all metrics that are of a business nature and the person respon- sible for those metrics is the businessperson — the program manager.
The tightness of the box depends on a number of factors such as risk, size of the opportunity, potential strategic impact, skill of the team, and under-
standing of the market. The team and approvers from management, mostly major stakeholders and sponsor, determine the range of conditions that
defi ne the bounding box.
Bill: That ’ s somehow related to the stakeholder management, the activities a business initiates to manage the relationships with its stakeholders.
● ●
● ●
● ●
● ●
266 CASE STUDIES
Mike: Correct. The box concept depends heavily on the agreement among stakeholders.
Bill: What about the out - of - bound review? Can you explain it a little more? Mike : The program team has the freedom to execute the program within the
range assigned to each applicable element. Whenever the program is pushed and out of the specifi c limits, the out - of - bounds review is mandatory. Examples
of the review may include the fact that a schedule slips more than four weeks, especially in time - to - market cases, or crucial components are no longer avail-
able from the suppliers, in some new product introduction cases.
Please note that when the bounding box status is presented at reviews, colored dots are used for each metric in the bounding box to denote status of that
metric; green refers to a progressing well status, yellow refers to a heads - up, and red means that immediate actions are needed.
Bill: Well, what about the project guideline? Is it similar to the program
guideline?
Mike: The guideline for projects, called “ 1104, ” is typically more fl exible than the program guideline. In particular, the bounding box is not mandatory. Feel
free to use it, but it is not required. Many project managers use their own spreadsheets to track their efforts. Some use the bounding box, or adapt the box
concept. It ’ s your choice.
Besides, project milestones are not as strict as program milestones. That is because projects focus more on execution success, like implementing some-
thing, rather than business success, which is being the fi rst in the market and making money. Also, loose milestones mean less time to prepare documenta-
tion. Therefore, in running a project, fl exibility is a luxury you have. But of course, when it comes to making a trade - off decision, programs always have
higher priority and get more resources and attention.
Bill: What about the out - of - bounds review for projects? Is there anything simi- lar to this?
Mike: Yes, we have a project review meeting. It ’ s usually held at the beginning of each accounting period AP. A project manager will provide project status
to the sponsor and key stakeholders. Major items that need to be addressed in that meeting are:
Brief project history goal, start date, expected completion date, and resources needed
Project deliverables for each accounting period Project expenses update labor and materials
Expected issues and problems
● ●
● ●
Themes of Program Management 267
Help needed, if any Activities last month
Activities next month
Keep in mind that we also have the program review meetings. They are usually held in the second week of each AP, or one week after the project review
meeting. The agenda is pretty much the same.
Bill: Now I have a better understanding of program and project management here. Thanks a lot. I will get back to work and do my best
Discussion items
1. What did you learn from this case? 2. Compare the project and program definitions at Megatronic with those more
generally known concepts. Which conceptdefinition is more effective in your point of view and why?
3. What are the keys to a successful bounding box approach? 4. How does the out - of - bounds review help avoid “ big surprises ” ?
5. In what circumstances should boundaries be adjusted? What may happen
when boundaries need adjustment?
● ●
●
269