CULTURAL ASPECTS OF case studies in project program and organizational project management

20 CASE STUDIES CHAPTER SUMMARY Name of Case Area Supported by Case Case Type Author of Case Engineering Culture at Beck Functional Culture Issue - based Case Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon The Jamming Culturally Compatible Strategy Critical Incident Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon 21 Engineering Culture at Beck Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon IF JIM SAYS SO Jim Traddell, director of a PM Offi ce, and the project initiator, led the meeting with the consultant. He made every effort to look decisive, as he dictated the con- clusions of the meeting to the scribe. Raja James was Jim ’ s partner. He was helping Jim on this project, par- ticularly on the aspects of the culture. The team wanted to learn more about the engineering culture at Beck. To obtain the information, the meeting with an engi- neer at Beck was arranged at a local restaurant around the corner. Raja was about to leave the office to meet his informant. BACKGROUND Beck operates in an environment that abounds with rapid and discontinuous change in demand, competition, and technology. Even worse, that information is often not available, obsolete, or inaccurate. The company is founded in 1946, and its primary income comes from projects. Annual income is approximately 800 million, with 4,000 employees. Disequilibrium, along with perpetual and discon- tinuous change makes all competitive advantages temporary. Organizational units are loosely coupled with a lot of entrepreneurial behavior. Any advantage is tem- porary, contributing surprise and fl exibility to Beck strategy. In this industry, risk is viewed as a factor upon which to capitalize, and the trick is that succession of fl eeting advantages lead to higher performance. ENGINEERING PRIDE Tippie Anne, the 34 - year veteran and engineer, showed up at 11 AM in front of Bombay restaurant for the lunch meeting. After pleasantries were exchanged, Raja invited Tippie inside where the aroma of curry dominated the air. As they helped themselves to an abundance of Indian food, Raja took the fi rst step: “ We ’ ll have to cut to the chase. Let ’ s start the interview now, as we both are very busy, 22 CASE STUDIES and I would appreciate fi nishing by 12 noon. ” Raja announced his intent to focus on the professional part of the lunch. Tippie agreed with his idea, commencing a conversation. “ Jim Traddell, one of my good friends, asked me to tell you my story of Beck ’ s culture. Personally, I don ’ t like to begin interviews with the word ‘ culture ’ because it tempts interviewees to become theoretical. But this interview is an exception. ” Raja replied, “ Thank you. Then, let me ask you, how do you do things around Beck ’ s now and how did you used to do them? ” Raja hoped that using this simpler language would inspire Tippie to speak about culture in easier terms. The conversation went as follows: Tippie : Well, we have a habit of calling ourselves “ engineers, ” which we are. Perhaps this is in protest to having no such name 20+ years ago when Beck was small and had no real fi nancial power. Today, for comparison, the new Beck is 4,000 employees strong and has 900 million cash at hand to purchase other companies. Nowadays, everybody respects us as engineers. If you talk to senior managers, engineering managers, and workers, you ’ ll see for yourselves, how much these folks esteem us. Not that other specialists are not held in high regard as well, but when in the past our company would negotiate products, engineers would not be always seen as an important part of the negotiating team. Surprisingly, at old Beck our product sold without engineers around. But not for long. The old Beck valued MBAs. If one desired to get ahead, he had to get an MBA degree. Engineers were engaged almost like mercenaries. Yes, I am telling you the truth. Don ’ t laugh there, Raja. The newly minted MBAs, mostly second - rate engineers, would prepare business plans for new products, the NPV Net Present Value and PI Profi tability Index, mostly what we call today derivative products — routine stuff. Of course, they embel- lished the products, hired engineers like “ mercenaries ” and business thrived. As I said, though, not for long. Once the substance was sold out, the derivatives didn ’ t sell and there were no new breakthroughs products new to the world and platforms products new to the companies, the business sank into the red, resulting in years of suffering. The new Beck was in the making for years and the senior managers spent a lot of time creating project culture. Those platforms and derivatives products helped employees come about. Managers as well as workers understood that Beck would not survive if it didn ’ t have high - value products. Those high - value products must be designed and developed by engineers and, they were. That ’ s why they are respected and held in high regard, which is why they are feeling engineering pride. DESIGNERS TO COST Raja : I heard the terms “ design to cost ” and his cousin, “ cost to design, ” men- tioned many times at Beck. Would you please explain them to me? Cultural Aspects of Project Management 23 Tippie : These proud engineers from the new Beck are very different in one respect from the engineering guard of the old Beck. Namely, current engi- neers are much more cost conscious, so their skill is much higher and the cost attitudes are essentially more developed. For example, the new ones always design products with the cost in mind. So, the fi nished product price must be one - fi fth of a set of corresponding prices of spare parts. These proud guys have a different beginning policy. Theirs is “ design to cost ” as opposed to the old Beck ’ s “ cost to design. ” These two differ as two philosophies of life but their names are similar. The former means that fi rst the target product prices must be established; then the product is designed backwards. The desire is to fi rst obtain the real product, component, and feature prices, then determine spare part prices. So, we have developed a tool called Kano ’ s maps, which tells the price of each feature, thus we know which combinations of features really make money, and which don ’ t. The latter cost - to - design approach implies that engineers fi rst design the prod- uct, then, they fi gure out the price, which the customer may consider overly high. Once product price is a known component, feature and spare prices can be calculated. While the former approach is proactive and customers love it, the latter is reactive and customers consider it obsolete. Sometimes, customers view the cost - to - design approach as a way to rip them off. Skills requiring the design - to - cost approach are markedly higher than those demanded by the cost - to - design approach. Plus, customers like the former approach because it immediately tells the price, and gets their business from others. Sometimes, customers consider the cost - to - design approach not suitable for knowing the target product price suffi ciently early. This skill, that engineers at new Beck have and those at old Beck did not, offers our organi- zation strategic market opportunities. In particular, we see new markets and customers become available, and we think this is another good reason to feel like proud engineers. Not so long ago, we got a call from a wholesaler who could turn around 1,000 pieces of one of our products with certain features. We consulted our Kano ’ s map, and we learned that the asking price was right. CUSTOMER - CENTRIC Raja: I would like to learn how customers impact your engineering culture. Tippie: Our engineers try very hard to be customer - centric. I know it sounds like a buzzword, but it is very precise in what it wants to denote. As in the old Beck, and in many other companies, we didn ’ t ask the customer what 24 CASE STUDIES they wanted in new products. We assumed by doing that, we would become customer - oriented. Rather, we developed whole arrays of processes and tools that pointed toward seeking out what the customer exactly wanted. The bottom line of being customer - centric is being able to help translate what customers precisely want of the product design. For that, we fi rst used tools of survey design, customer segment, and custom visit documents to understand what customers wanted before the work began. Note that sometimes customers do not know what they want. So, our engineers designed all of the tools and processes to help them fi gure out what customers asked for. Then, in the design stage, we may use Quality Function Deployment QFD or rapid prototyping, to give design features customers long for. They have a long experience of working with customers ’ people. For insta- nce, they sit on joint development teams with customers, or use lead users ’ concepts to reveal what future products would look like. Our engineers are trained to stand in front of customers. You know, psychologists get trained how to talk to patients and elicit meritorious information; they are only college grads who get this education. No engineers get this kind of training. We at Beck spend thousands of dollars to prepare engineers to be comfortable talking to customers and becoming customer - centric. RUN TO THE END Raja : What else distinguishes Beck culturally from others? Tippie : One thing I should mention as unique to us is our motto of “ run to the end. ” Namely, in old Beck, our fi rst priority was to secure new business, and a concern for producing a product at times fell through the cracks. So, as a consequence, acquisition of the business really mattered, and implementation of business suffered. Obviously, more attention was paid to the front end of the order process, rather than to the back end. At times, we did not know where this product was in the production cycle. As a further consequence, all kinds of promises were made to customers to bring the business in, usually forgotten easily in the production stage, and that was considered “ normal ” and ethical. Customers, anyhow, felt cheated. The new Beck does not tolerate this. We worked very hard to show our engi- neers that all products are made equal. So, the customer has every right to know how long down the manufacturing line their product is. And, hence “ run to the end. ” We put a lot of effort into eradicating this ugly habit — not only to know the product production status but where it will be the next day, in the next two days, until its completion. We, in other words, care about any product in production and show it. Raja: Give me an example. Cultural Aspects of Project Management 25 Tippie: We had a big wholesale customer in China. Thanks to this approach, we followed the product and its life cycle. So, this customer called us, and told us that market shifted away and two planned features didn ’ t sell. We were at the third quarter of the project ’ s life cycle but we managed to drop the two features. Raja: What other ways of doing things around Beck are unique? Tippie : We are a typical high - velocity company around the area. So, we have many ways that we share — the rewards, matrix organization, decision making, etc. — but those I described make us who we are. Raja still had several questions he wanted to ask, but an hour had passed. He had no choice but to thank Tippie, and leave the restaurant. He had another appoint- ment at 12:30, the second lunch meeting he needed to have for today. Discussion items 1. List major definitions of the culture mentioned in the case. Analyze them and tell what is unique in each. 2. What do you like and dislike about Beck ’ s culture? 26 The Jamming Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon SCENARIO 1: JAM WITH THE COUNTERPART An executive fi ve - member team was formed to manage a small but global com- pany. Because they were allowed to choose where they wanted to live, the team spread across Finland, Denmark, Sweden, and England. Although each member was multilingual, they spoke in English during their weekly teleconference. Every month the team met at one of the company ’ s divisional headquarters and spent the next day with the managers from that division. Members were encouraged to be part of every discussion, although their individual roles were very clear, so that interaction on a day - to - day basis was unnecessary. Even though the team never went through a formal team - building process, its emphasis on an agreed team mission, shared business values, and high performance goals for all members made it a true model of a well - jammed multicultural team. SCENARIO 2: THE NPD GAME When the team members fi rst went to work on a product development project in a small high - tech company in the United States, it appeared that they would forever be at odds over every aspect of managing a project. A few projects and many fi ghts later, however, a German, an American, a Mexican, and a Macedonian looked as cohesive as any other team. As they marched through their projects, they acquired an in - depth knowledge of each other ’ s cultures and project management scripts. Not only did they know each other ’ s religious holidays and eating habits, but they also reached a point of accepting American concern for cost tracking, German obsession with precise schedule management, Macedonian dedication to team spirit, and Mexican zeal for interpersonal relationships. The road to their masterly jamming was not paved by deliberate actions. Rather, it evolved from patient learning, many dead ends in their interactions, and the need to be successful in their work. Cultural Aspects of Project Management 27 JAMMING The situations described here can be called “ jamming, ” — a strategy that sug- gests the project manager and the counterpart improvise, without an explicit mutual agreement, and transform their ideas into an agreeable scenario for their work. In this sense, they are like members of a jazz band following the loose rules of a jam session. “ Jazzers ” jam when they begin with a conventional theme, improvise on it, and pass it around until a new sound is created. This strategy implies what is apparent in the executive team scenario 1 — all team members are highly competent. Such competency enabled them to fathom the counterparts ’ assumptions and habits, predict their responses, and take courses of actions that appealed to them. Another condition was met for jamming to work with the executive team, in particular, understanding the individuality of each counterpart. A counterpart ’ s fluency in several scripts clearly meant that he or she might propose any of the scripts ’ practices. Knowing the individuality then meant anticipating the practices. That the counterpart was analyzed as a person with distinct traits, and not only as a representative of a culture, was the key to successful jamming. However, there are intrinsic risks in the use of the jamming strategy. As it occurred in the initial phase of the high - tech team scenario 2, some counter- parts did not read the jamming as recognition of cultural points, but rather as an attempt to seek favor by flattery and fawning. Although the team never faced it, it is also possible that jamming may lead to an “ overpersonalization ” of the rela- tionship between the project manager and the counterpart, characterized by high emotional involvement, loss of touch with and ignorance of other team members, and reluctance to delegate. Jamming ’ s basic design may not be in tune with all cultures and may not even be appropriate for the execution by teams composed of members with vary- ing levels of competency in other people ’ s project management scripts. While in its early stage of development the high - tech team members ’ varying levels of competency were a significant roadblock, their further learning and growth got them over the obstacle. Still, the number and intensity of cultural run - ins that the team experienced before maturing supported the view that this strategy tends to be shorter on specific instructions for implementation and higher in uncertainty than any other unilateral strategy. However, its plasticity may be such a great asset to multicultural project managers that many of them view it as ideal in the development of a culturally responsive project management strategy. Discussion items 1. In what situation would the jamming approach work well? 2. What are the pros and cons of the jamming approach? 29

Chapter 3 PROJECT MANAGEMENT

PROCESSES This chapter presents case studies of issues related to concepts in Chapter 3 of the PMBOK ® Guide , namely the project management processes in which a pro- cess is defined as a set of interrelated actions and activities performed to achieve a predetermined product, result, or service. There are four issue - based cases in this chapter. 1. Special Session Special Session is an issue - based case that generally describes different project management process groups, defined in the PMBOK Guide , including Initiating, Planning, Executing, Monitoring and Controlling, and Closing. 2. Waterfall Software Development Waterfall Software Development is an issue - based case which centers on the waterfall model for software development projects. In this case, six com- mon phases of the model, including its limitations, are discussed. 3. Extreme Programming Extreme Programming, an issue - based case, talks about a methodology that is intended to improve software quality and increase the responsiveness of the software development organizations to changing market demands. The process has the iterative nature of the development, which facilitates con- tinuous feedback to maintain management visibility of the project status and budget consumptions. 30 CASE STUDIES 4. Do You ZBB? This issue - based case presents one technique of project estimation and the selection process, known as zero - based budgeting ZBB. It provides an example of applying the ZBB concept to everyday life; in this particular case, getting a degree while still balancing the work needed with life. In compari- son, a strategy is expressed in terms of a bucket of money that a business unit wants to spend making the strategy work. In the process of selecting the proj- ects, their estimates therefore should be equal or not exceed the bucket sum. CHAPTER SUMMARY Name of Case Area Supported by Case Case Type Author of Case Special Session PMI ’ s Project Management Process Groups Issue - based Case Sabin Srivannaboon Waterfall Software Development Software Development Model Issue - based Case Osman Osman Extreme Programming Software Development Model Issue - based Case Mani Ambalan Do you ZBB? Select Project Issue - based Case Rabah Kamis