Please help with, writing a 2-3 page written case analysis on the case (pg. 417 The Program Management Office) that provides an overview of the situation and directly answers the questions provided at the end of the case.

• Begin your case write-up with an executive summary of the situation and critical issues.
• Integrate PMO concepts, such as PMO value proposition and assessment process

Trust Corp is a specialty instrument company in the U.S. cell phone industry. Six years ago, Trust Corp introduced a breakthrough product to the market, leaving the competition in the dust. In the high-technology industry. product advantages over the competition are short-term unless followed by the continuous stream of equally good products. Since Trust Corp has not had another successful new product introduction, the company saw a decline of business in the last five years. While Trust Corp was developing and introducing a few lackluster products, the competition caught up, the market slumped, and Trust Corp sales dropped significantly. The company's annual sales were $360 million in 1998 , but only $130 million in 2004. As a consequence, management began focusing on cost cutting. especially in Trust Corp's information technology (IT) group. The general feeling was that too much money was being wasted on poorly scoped programs that resulted in scope creep, delays, and late cancellations. There was also a feeling that the establishment of a program management office would help put IT's ducks in a row, terminating poor programs earlier and saving money through efficiency improvements. Saul Cognito, the chief information officer, put together a team led by Barry Senders, a longtime program manager, to study the feasibility of creating a PMO. After the team spent some time working on the problem. it suggested going forward with the establishment of the PMO and hiring an experienced program management officer from outside the corporation. Peter Deerling, a former program management officer in the group of a much larger and more successful company named Stellar Corp, was hired. Saul's plan was to first organize a series of meetings between Peter and major stakeholders to further promote the PMO as a vehicle to increase program success. His second goal was to get input from the stakeholders. A summary of one such meeting, attended by Saul, Barry, and Peter, follows. THE REAL PURPOSE OF THE PROGRAM MANAGEMENT OFFICE The first thing Saul planned was to collect data based on Peter's experience with the PMO at his previous company. He wanted to know whether it helped the success of program management and, if so, how. He also wanted Barry to hear Peter's story because Barry was an influential stakeholder who would have a major role in shaping the PMO to be program manager?friendly. Barry was a longtime program manager at Trust Corp and was respected enough to be vicwed as the voice of program managers. In addition, Barry helped Saul develop a plan to establish a PMO before Peter came aboard. Therefore, Saul let his ally. Barry, ask the questions. Barry had already heard a high-level story about Peter's PMO while interviewing him for this job. It was interesting, but Barry wanted more details. Barry: Can you tell me about the history of the PMO at your previous company, like how it started and was developed? Peter: I believe that to truly understand a PMO, one has to fathom the organizational context. Therefore, I'll begin with the background of Stellar Corp. The company is one of the leaders in North America in specialty manufacturing and has more than 10,000 employees. It started about 50 years ago and at the time I left, it was operating five major manufacturing plants and one parts manufacturing plant in North America. The company has several business units, which are supported by the IT group, including verticals like the infrastructure division, and the support competency center. The PMO was established in the company about seven years ago. Overall, it was seen as an important means to create a common and standard language, where program teams could use program management tools, processes, and methodologies. Prior to that, we did not have any standardized ways of using tools or sharing the program management methodologies. Some program managers followed the policies and procedures much more closely, and programs became more successful as a result. However, some progmam managers didn't follow them closely enough and did things their own way. Sometimes they were successful, but many times programs required rework late in the development cycle because something was missing. We needed the PMO to standardize our practices. Saul: I feel that I need to interject, because that answer seems commonplace. If I understand it right, one of the PMO's purposes is having program managers adhere to the policies and procedures in order to increase program success. Don't take me wrong. but we want to learn from you what aspects of the PMO bring success and what is just company folklore. Peter: The purpose is to increase progmam success. Beyond that, the PMO is viewed as a business function whose job is to develop. implement, and continuously improve progrum management processes and tools. That solely is infmastructure to Competencies of Project Managers and the Project Management Office 4 impeove program perfocmance in order to help the company achieve its business objectives. That was made clear by the senior management in the PMO founding charter-show that improved practices and processes improve business results. Saul: Okay. But how did you make it happen? Peter: I'm going to try to approach this from a different angle to help you understand. To achieve its business objectives, the PMO includes working with the community of program managers on how to develop processes (and tools to help enable the process), how to provide training, mentoring. and coaching, and how to implement those things, all with the simple purpose of making our business better. In addition, the PMO is a governing approval body to evaluate and determine if programs should go forward from one program phase to another. In other words, programs need to get approval from PMO committees or officers in every major milestone to be able to move forward. We got very good at terminating poorly defined, planned, and executed programs. THE TANGIBLE CONTRIBUTION OF THE PROGRAM MANAGEMENT OFFICE Barry: I am afraid that my thought process needs more details to fully fathom the concept. For example, what were the specific benefits of running the PMO? What success did the PMO bring? What was the PMO's return on investment? Peter: I want to try to avoid theory and explain it all by means of the company bottom line. I think that the PMO can really make a difference with its contributions. For example, the PMO develops and installs the standardized process. It makes programs shorter, cheaper, and faster, meaning increased productivity, which translates into lower cost, better sales, and higher profits. But management wanted to know the return on PMO investment. So, we had to take a micro view of the operation and spend a huge amount of time trying to provide our executives with an accurate return on investment value for the PMO. I mean, something like how many dollars we get back for every dollar spent money. We proved our case by making money for Stellar Corp. We proved that money. We proved our case by making money for Stellar Corp. We proved that what senior management wanted from us, we figured out it was a one-sided approach. There are so many intangible benefits you simply cannot quantify. THE INTANGIBLE CONTRIBUTION OF THE PROGRAM MANAGEMENT OFFICE Peter: Let me give you another example. At times, we needed to make sure that we did use case analysis for programs correctly, and we were struggling with end-user surveys for determining the wants and needs of the infrastructure users. CASE STUDIE In my opinion, they were full of leading questions. "Would you like to have this capability that can do this and that for you?' Those kinds of surveys gave us mislending data. Wrong decisions were made based on those answers. "Oh, they like this capability." we heard many times. But when push came to shove, you could not really implement it because, for whatever reasons, customers we had surveyed did not want to use it. The PMO helped drive common end-user surveys and use case development. Stellar Corp's end-user surveys now help make better decisions about the infrastructure feature set and its use, and this increases worker productivity. But for figuring the PMO retum on investment, we needed to determine how much money was saved because of the PMO's help with enduser surveys. We were not able to determine that. Sometimes, things do not look black and white, but rather gray. That is the world of the intangible. Barry: Aren't there too many intangibles that our executives wouldn't like? Peter: Lots of the PMO benefits I see come from tangible dollars, like I explained. but many of them are intangible, like having a common process, having a common standard language, and having a common understanding of what program management is. We used that in a program business case, for example, so that we were all on the same page, thinking about the same thing. We used that to identify risks before they became problems, so we were much more proactive. One of the real big bencfits was improved communication so that we could do more upfront planning and avoid more crisis or reactive management later downstream. All those things create intangible benefits that were difficult to quantify for the PMO in time-to-market speed that can be attributed to improvements created by the PMO, is not as tangible as it looks. There is no doubt that they can be roughly estimated, but many question their accuracy or see it as splitting hairs. So I expect to see that the PMO contributes to the organization as a business solution, looking at the big picture from the business level, and providing tools, policies, and procedures for the individual program level. THE SCOPE OF THE PMO Saul: What does the PMO do now and what will it do in the future? Peter: I've written down the PMO's duties. Essentially, the PMO does what it was originally charted for. I can summarize what the PMO does: - Process standardization: This means that the PMO organizes the company's program management practices by standardizing the program management elements: - Processes - Procedures Competencies of Project Managers and the Project Management Office 4 - Metrics - Tools - Vocabulary - Personal development: This includes organizing the career development aspects for the progrum manager: - Competency set development - Training - Mentoring - Coaching - Consulting: This means that the PMO organizes delivering program management consulting services to programs to increase the effectiveness of our program management practices. - Program reviews: The PMO is a program governing body that organizes, reviews, and approves: - Program phase/gate decision checkpoints - Major program milestones - Program audits - Program infomation: The PMO organizes and standardizes data and information to support: - Program reporting to senior management and other key stakeholders - Information technology system I want to emphasize two points. One is to pay attention to the word "organize." This means that the Stellar Cocp PMO only organized all these tasks. For this, the PMO borrowed human resources from functional groups, because the PMO did not possess its own resources. In fact, the PMO had only two administrative assistants and me. For example, to organize the development, deployment, and improvement of a company's standardized program management process, the PMO would borrow program managers from functional groups, and form a team. The team members were doers-developing, deploying, and improving the process. The second point was that exactly this approach and the chosen scope of the PMO were also contributors to the success of Stellar Corp. Barry: You did not mention how you decided what the PMO would do and what the PMO would not do. Can you tell me about that? Peter: Stellar Corp struggled a lot with that choice. They benchmarked PMOs in several companies and saw different versions of the PMO application. Some PMOs only cared about the standardization. Another managed all programs in the company. Yet another PMO in a big consulting company was virtual in nature because they had sites in different cities, and because their business units (profit/loss centers) were strongly independently minded, they established a PMO on the web. The more PMOs Stellar Corp benchmarked, the more they believed in what they saw. The major factors influencing the decision about the scope of the PMO are the company's business strategy and organizational culture. For example. the company with the virtual PMO pursued a strategy of independent business units, so what they wanted of the PMO was to develop a common, standardized process and make it easily available to all business units. That's all. The organizational culture was such that the PMO could not even check or ask business units if the process was used. If they tried, the answer would be along the lines of, "If we need further help. we'll call you." So, in my previous company, we did the same. We asked ourselves two questions: - What does our business strategy need the PMO to do? - What kind of PMO will our organizational culture tolerate? Answers to these questions pretty much shaped our decisions about the scope of the PMO. I think these answers about our PMO scope of activities helped us to develop more successful programs. ORGANIZATIONAL LOCATION OF PMO Barry: What organizational structure, location, and size made Stellar's PMO successful? Peter: The Stellar Copp IT department had about 20 full-time and 20 to 30 parttime program managers. Their jobs were to manage programs in their verticals (functional groups), supporting all business units as assigned per the program charter. Formally, the program managers are not located in the PMO, but in verticals. Depending on their experience and knowledge, some of them are very powerful, exerting full control over the program and making all major decisions. Others, typically less experienced, act more like program coordinators, collecting and bringing information to their vertical manager to make all major decisions. How is the PMO structured and who does it report to? The PMO is structured in a simple way - the head of the PMO or, as we called it, the program management officer, is responsible for the work of the PMO. That, of course, was my job. The officer had two administrators to support him. That is all. It was very lean, as the organizational culture dictates. Also, part of our business strategy is to be cost leaders in the industry. So, we had to have a cost-effective PMO. Let me show you the organizational chart (see Figure 21.1). Saul: Okay, let Barry and I read the chart, and if we make any mistake, Peter, jump in. Peter: Agreed. Competencies of Project Managers and the Project Management Office 4 Saul: A program manager reports to his or her division, i.e., a vertical manager. Then, the division manager reports to the CIO, who in turn reports to a VP of the company. A program manager has that direct line relationship with their division manager but, at the same time, there is an informal dotted line relationship to the PMO because the PMO helps develop, deploy, and continuously improve all the processes and tools that they use. So, Peter what you show here on the chart is the organizational structure that helped Stellar do... stellar programs, if you will. A lean PMO that does not own any program managers. Verticals own them-pretty simple! Peter: Exactly. Barry: Were there any problems in terms of establishing the PMO? Peter: Resistance to change would definitely come to the top of the list because we never had this role and function before. So there was some tough resistance for some time, especially from the divisional managers who were worried about the division of power. First, some people doubted if the benefits of having the PMO for the organization were significant. So communication and support from the ClO and vice-president who served as the sponsor was key. Second, I think we were struggling at first with how to establish the standardized process. My job at the PMO was to ask program managers to make sure that they understand our business strategy and to use our procedures to align their programs with the business strategy. At first, I did not know how to ask those questions, and such a standardized procedure did not exist. That caused a lot of dissatisfaction among senior managers and program managers. But a few of us put our heads together and developed the standardized procedure for it. After that, I saw no resistance. Saul: Okay. I have another meeting in five minutes. We will meet again. In the meantime, I want you to understand that you guys have to have a plan for any anticipated and unanticipated resistance. When it comes time to spend money on building the PMO, we want to look prepared for success, and I want all players in this company to know we are prepared. That is, Peter, why I hired you and that is why. Barry, I chose you to help Peter. Clear? Peter and Barry: Clear! Discussion items 1. Based on the business you are in, would a PMO add any value? Why or why not? 2. Suggest a plan for dealing with any anticipated and unanticipated resistance. What can the company do to lessen resistance