Nội dung

74 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS tered that he was getting so much help and attention from someone as experienced and as busy as Norman. Norman had hired Larry, and Larry had no allies in senior management. Larry felt like he was in a lose-lose situation. He had been spending his family’s long-term savings for months before taking the position. He needed the job and couldn’t afford to just quit. As an experienced, well-educated project manager, Larry felt deeply disrespected, almost violated by his superior’s actions. He also felt that Norman was interfering with his ability to be a good people manager for his team. Finally, being a quietly religious man, Larry was also paying an emotional price, as he felt he was essentially being forced by his supervisor to lie to the customer. In digital electronics, there are circuit elements called buffers that store information to be used later. I believe that individuals have pain buffers in which they store the kinds of issues Larry was raising. Allowing people to release their pain buffers in a useful way is a skill I feel a manager/leader should have. When Larry seemed to have emptied his pain buffer, I asked, “Anything else?” Only after waiting for his response, a shake of his head, did I then say, “It’s good to know how you feel, but how does Norman feel?” Larry looked at me oddly, as if that was a question he had never considered. It took a while, but Larry finally decided that Norman (1) wanted things to go well; (2) was trying to help; (3) didn’t understand how Larry felt; and (4) might be open to input if it could be presented in a way that seemed helpful in getting things done. Then I asked, “Anything else?” I waited impassively for his response. Only when he shook his head did I go on. “Is there going to be an opportunity to speak with Norman about this?” “We’re so busy. I don’t see how,” Larry replied. “My advice is to look for that opportunity, that significant emotional event that can be a cathartic moment that opens Norman up to this input. That will allow you two to get somewhere.” Eventually Larry thanked me and drove off into the night. A couple of weeks later, Larry called me to relay the news that American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 75 he and Norman had talked after the customer visit. The customer had discovered the company was behind but, instead of blowing up, had rationally requested that the situation be gotten under control and was reviewing closely with Larry a recovery plan that would allow the new scope feature to be added with a small extension to the schedule end date. Turns out the customer had a little schedule margin to play with, and he really liked the extra feature that marketing had pushed into the design through Norman. Norman wasn’t 100 percent convinced of what Larry was saying, but he had agreed to do things differently moving forward. For example, Larry would be the sole contact with the customer; Norman would talk with the customer only during visits. Any phone calls from the customer to Norman would be returned, but with the statement “I will write down your concern and have Larry get back to you on that,” geared toward putting Larry in the action position. Norman had agreement from the customer on this approach. The customer just wanted performance. Norman would get fifteen-minute face-to-face status reports from Larry twice per week, and Larry would send interim e-mail synopses of any important events. “Can it work?” I asked. “I think it has a chance,” Larry replied. “How do you feel?” “Much better,” he said. “I’m not thinking I’m going to get fired anymore, at least not today!” “How about Norman? Does he seem more relaxed?” He paused. “Yes, that would be a good way to describe it.” It seemed everyone had benefited from Larry’s willingness to communicate honestly and openly with his boss. TACTILE Analysis Larry eventually was able to extricate himself from a bad situation because he connected his actions with his core values and was able to gain at least Norman’s cooperation. Overall effectiveness was improved as each man focused on his role. > Transparency: Larry’s boss was acting about as non- American Management Association • www.amanet.org 76 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS transparently as possible, and he was interfering with Larry’s ability to act transparently with his customer and team. Larry took a risk with his action, but there is now at least a chance for success. > Accountability: Early on, neither Larry nor Norman was accountable in this story. Larry ultimately found an acceptable way to create mutual accountability between Norman and himself. Sometimes timing is everything. > Communication: Larry needed to build the common ground with Norman that would allow him to do his job without constant interference. To get there, he needed to understand Norman better. I do not believe that direct confrontation without some sort of catalyst would have worked. Indeed, research mentioned in For Your Improvement: A Guide for Development and Coaching, by Michael M. Lombardo and Robert W. Eichinger (Lominger International, 2006), indicates that direct confrontation doesn’t often lead to improved relationships with bad bosses. A better approach is to build common ground and then add to that going forward. > Trust: There may never be huge trust between Larry and Norman, but it appears that Larry has started the process toward at least being respected by Norman. Trust between the customer and the team should be improved immensely going forward. > Integrity: Larry had to find a way to stop violating his own sense of integrity, to be allowed to tell the customer the truth in the areas that had been left vague or where outright distortion had occurred. > Leadership: Larry would never have been able to drive needed culture change within his project; he had ceded control of his job to Norman. His later actions displayed the right kind of leadership to at least give him a chance for success. > Execution results: Larry’s project would have been an absolute failure if nothing had changed. Now there is a chance for Larry to show his skills, to validate the faith his company put in him by hiring him. American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 77 Expectations Pyramid Analysis By communicating with the customer early about adding scope as it affects the original schedule, Larry and Norman now appear to be working together for the good of all. Hiding that information would have eventually caused someone to play the blame game, likely with bad consequences for Larry, the lowest person in the hierarchy. That would have been a lose-lose situation for all: bad for Norman, the customer, Larry’s company, and the project team. Your Management’s Expectations: Schedule Many organizations keep two sets of schedules for a project. One schedule is shown to the outside world; the other is the schedule that the team is driven to meet. Of course, the due date for the internal schedule is more aggressive, often much more aggressive, than what is shown to the outside world. On the surface, this makes a certain kind of sense: undercommit and overperform. However, management often forgets the choices this drives employees to take, as the following story illustrates. Tale from the Project Management Jungle: Three-Team Winner Cheryl, a program manager for a defense electronics firm in the western United States, was assigned a complicated development proposal. The proposal would require expertise from several companies in order to win. She went into the project with several strikes against her success. First, there was an entrenched incumbent company, which had done a decent job on the prototype design effort. Consequently, Cheryl’s company heard about the proposal late in the process and then delayed approving the large expenditure likely needed to win. Thus, she was under a great deal of schedule pressure. Also, Cheryl’s company was not considered to have much expertise in being a prime contractor or in building competitive teams to take on the big contracts. Finally, it was also considered expensive and was frequently late with its designs. American Management Association • www.amanet.org 78 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS What she had going for her was the company’s strong reputation within the industry for building good technical solutions, as well as for honesty. No one in management at Cheryl’s company expected her to win; that was why they had assigned the proposal to her. Cheryl used her strengths in team building and analysis to craft an effective process of recruiting other contractors for her team. The standard defense-industry approach often views the proposal team-building effort as essentially a way to guarantee percentages of the contract amount and as a political process of gathering subcontractors with needed constituencies in various parts of the government procurement or technical community. Often, the result is that team member companies are given additional tasks in which they have little expertise in order to make sure the company gets its percentage. Frequently, little time is actually spent in ensuring that the various companies involved fit together into a cohesive team. Cheryl took a different approach. She was aware of the schedule constraint; in fact, that is what made her realize her approach would have to be different to win. She held all the required reviews, but they were streamlined because of the time constraint. She spent an inordinate amount of time early on with potential partners interviewing potential teammates. At reviews, she received criticism from her management for doing so, playing into her existing fears that management was going to micromanage her, especially given the time constraint. Cheryl made the decision to reveal to her management as little as possible about what she was doing. She told potential teammates that she wanted a team united toward the goal of winning the contract, emphasizing both what they could expect from her and what she expected from them, noting that her company had not set a percentage target for itself, and adding that she wanted to interview them for their specific expertise. She also emphasized that the partners would have to furnish the right people for the entire seven-week period of the proposal effort—that the proposal team would really be a team, not a collection of experts dropping in for a day here or there. American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 79 When the team was assembled, she treated the members all the same, not condescending to or marginalizing the subcontractor representatives. She deliberately receded into the background in a technical sense, allowing the experts furnished by the subcontractor teammates to have their turn in front of the various management reviews and ultimately in front of the procurement review team at the oral team presentation. To the amazement of all, her team won. TACTILE Analysis Cheryl combined a great success with a huge miscalculation. Ultimately, her career didn’t thrive in this organization because she did not balance all three sides of the expectations pyramid. > Transparency: Cheryl wasn’t transparent with her management, a mistake many project managers make. However, she was very transparent with the potential partners and her team. It is thus no surprise that she ultimately had a better relationship with her subcontractor team members than she did with her own management. > Accountability: A key part of her teamwork strategy was establishing mutual accountability with the subcontractor partners. > Communication: Another critical component of her teamwork strategy was establishing open communications with the subcontractor partners. Under time pressure, she did not do the same with her management. > Trust: Trust developed within the proposal team and was the biggest reason why the company won the contract, a significant piece of business in a new business area. The selection board commented on the apparent trust within the proposal team as one of the keys to its victory. In contrast, Cheryl did not build trust with her management team. > Integrity: Cheryl’s approach with the proposal team was one of immense integrity. The team absorbed that into how it worked together. American Management Association • www.amanet.org 80 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS > Leadership: Cheryl believed that in order to succeed she needed a culture that was different from her company’s standard approach to new proposals, and she created that culture. This belief, along with the time pressure she was under, led her to believe she had to isolate herself and her team from management. She used the schedule pressure as justification. > Execution Results: Her team won—and it won in the right way—with everyone involved feeling that the team had accomplished something great. Cheryl describes this as a peak performance moment in her career in terms of the accomplishment itself. But she goes on to say that, after losing the next tough proposal, her management, still perhaps angry about her actions with the winning proposal, made it clear she was no longer wanted in the organization. In many ways, Cheryl seems conflicted and damaged by that time in her career, but she learned some things that proved useful later. Expectations Pyramid Analysis Cheryl, rightly or wrongly, made the calculation that her management would not support an approach that it saw as too touchyfeely. She capitalized on the fact that the partners were hungry and would likely cooperate. Also, she displayed integrity and her other values to great benefit with her team, but not, obviously, with her management. She did little to build support with her management and peers, and that ultimately led to ineffectiveness and her eventual departure. Note that it wasn’t enough that she managed the other two sides of the Expectations Pyramid well: she did exhibit outstanding and innovative team leadership, and her customer loved how integrated her proposal felt and as a result awarded the contract to her team. Without strong performances on all three sides, however, this talented project leader was left wondering what had happened to what she thought was a career peak performance event. If the value system of your management is different from your value system, it is better to find a way to avoid highlighting the difference, while still finding a way to do what you think is right, lest you suffer Cheryl’s fate. American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 81 Your Management’s Expectations: Cost Management wants a little margin, a little risk buffer. Thus, many organizations keep two sets of cost estimates for a project, much as they do with schedules. One set is shown to the outside world; the other is what the team is driven to meet. Of course, the internal cost estimate is more aggressive—often much more aggressive—than what is shown to the outside world. Like the double set of schedules, there is a surface logic to this: once again, undercommit and overperform. The problem is that this makes you feel like a liar and also makes you feel that management is persecuting you as it tries to get to the truth. Management, in turn, thinks you are trying to defeat its reasonable desire to establish the correct cost target. That is why, without evidence to the contrary, it will try to slash some set percentage, be it 5 percent, 10 percent, or more, from your budget. Knowing that it is likely to do this, you may add a little something extra here and there and get caught talking out of both sides of your mouth. This is frustrating for everyone involved. Read on for a different approach that will leave you feeling more honest and will produce better results than you may be used to. Tale from the Project Management Jungle: Single Entry Schedule-Keeping This tale concerns my experiences with a microprocessor core design team, The Gang That Could (Finally). Microprocessors enable our modern age, as they are found in virtually any application (e.g., automobiles, computers, and industrial controls, to name just three) where controlled decision making can be turned into an algorithm. A microprocessor core, without getting too techno-geek, is the key building block for the overall microprocessor. This enables a variety of customers to add custom capabilities that differentiate their particular microprocessors from the rest while still using a standard core. I was brought into the organization after a corporate-wide search for a project manager who would bring an approach that American Management Association • www.amanet.org 82 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS yielded results without using too much unnecessary process. The core our team designed was going into a microprocessor sold by a business unit, which had a management structure separate from ours. To make it even messier, that business unit had a corporate customer that was going to use the microprocessor in a competitive consumer market. Thus, there was a lot of pressure on the managers above us in the food chain. Because I was new to the semiconductor business and to the culture of the group, I spent most of the first week or so chatting with people, explaining a bit of my philosophy but mostly asking them for their views on the way previous projects had been managed. I used that information to tailor my subsequent approach. In my first week, I discovered a piece of good luck. The design manager assigned to the project—we’ll call him Nitin—was friendly and open and had high emotional intelligence as well as analytical intelligence. Nitin had not been part of my original job interview list, so we had not met before I arrived. Early on, Nitin and I agreed that we were not going to keep two sets of books, that it was better to tell people the truth as we saw it and refuse to give in to their pressure. In that decision was the calculation that I had credibility based on the corporate search that had brought me there. Also, Nitin was well liked by our management food chain, and he knew it. Nitin and I did not agree with the schedule date required by our customer. We also refused to start any design work until our schedule and budget were finished. The project labor budget basically came from the task loading of the schedule. As you can imagine, eventually Nitin and I were called into the offices of our organization’s senior management for what were once broadly called “Come to Jesus” meetings. (A more appropriate term for these sessions has not yet become commonplace. Perhaps “Dad—or Mom—Behind the Woodshed” or a variation will catch hold.) These types of meetings typically are meant to shake some sense into the employee so as to prevent some horrible event that no one wants to undertake (like the employee’s removal). First was a review with Bobby R., a design VP who in the past had been responsible for many successful designs. Second was a American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 83 review with Julius K., the top VP. We were careful not to appear arrogant. We started all these conversations with, “We are not trying to be obstinate. While we work out the schedule that everyone can support, we just don’t want to start work and take on needless cost.” We were subjected to great scrutiny, but neither Bobby nor Julius had a problem with our approach, and they supported us. I have always felt that you shouldn’t live through the impossible, then have them kill you for failure. If they are going to be tempted to kill you, let it come when you are at your strongest. As we will discuss further in this chapter and in Chapter 6, the project ultimately was extremely successful, finishing the exact day that we committed to. Nitin and I held out for what we thought was right, and ultimately that action was best for all stakeholders. We delivered a realistic schedule that our team could support, a robust product that was ready well before the rest of the microprocessor so that our management team got enormous credit, and a product that worked well ultimately for our customer. We satisfied all three sides of the Expectations Pyramid. TACTILE Analysis Nitin and I fortunately had similar value systems and were able to use them to guide our actions through a difficult situation. > Transparency: Nitin and I were completely transparent. We explained what our approach was and why we were doing what we were doing, and we always asked for input. Management appreciated our openness. Turns out they were tired of getting beat up by this customer and had been looking for a different approach. > Accountability: We held ourselves completely accountable for the results we generated. We were honest enough not to start work early when that violated our sense of how to run the project. > Communication: We established good communication with all stakeholders. They didn’t always like what they heard, but that shouldn’t be your first priority. Ultimately, you want them to American Management Association • www.amanet.org 84 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS be happy with the results, but they cannot dictate how you get there. That is why they hired you in the first place! > Trust: Because it was clear we weren’t hiding anything, trust went sky high. Management trusted us because we were open to its input. Again, not always liking what he heard, the customer nevertheless trusted that what he was hearing was true. > Integrity: We showed high integrity in our honest and open approach. > Leadership: This is an example of the right kind of leadership. You are not required to go along with scope, schedule, or cost goals from management or anyone that don’t make sense. Of course, you disagree at your own peril. You have to be right! > Execution Results: We felt a certain amount of pressure after these events, because we were on the line. But aren’t you always? And in this case we were doing things right from our point of view. I’ll take that situation any day over, say, Larry’s, as described earlier in this chapter. Expectations Pyramid Analysis Once management saw that we had done our homework, it did not push for two sets of books, on either cost or schedule. Once management sees that it can trust you, its risk-avoidance behavior, such as asking for two sets of books, goes away. Subsequent requests for resources were much better received from our management, as well. A better overall relationship ensued. Succeeding in the project management jungle is a feat that requires you to balance seemingly endless and contradictory priorities and to get disparate factions with sometimes competing agendas to focus on one goal—the team’s overriding goal. But perhaps the trickiest task of all is managing your management’s expectations so that you do not just find success in one project but build a career. Keeping the TACTILE values at the forefront of your decision making will ensure that you manage your stakeholders’ expectations and thrive in the process. American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR MANAGEMENT 85 You’ve addressed your customers’ and your management’s expectations, but you’re not done yet. You still have to manage your team—and the team can make or break you, as we’ll see in Chapter 6. American Management Association • www.amanet.org CHAPTER 6 The Triple Expectations Pyramid and Your Team MEETING AND EXCEEDING THE EXPECTATIONS of your teams—helping them win—is the best way for you to generate positive business results for your organization. That’s where the results are created, after all (see Figure 6-1). What’s required? Many people think a take-charge attitude is best, that you have to tell people what to do. Not me. I find that today’s worker prefers as much autonomy as possible within a structure, a framework—we might even dare to say a process, albeit one that is as simple as possible. Your job is to match that framework to your team and the work it is doing. 86 American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 87 Figure 6-1: Team Expectations In that spirit, what is it your team expects of you? Simply, it expects you to: > > > Listen to team members in the areas that matter to them. Help them to meet their own work goals. Lead them in the effort to establish and meet the overriding team goal. Of course, doing these things will make your management and customers happy, as well. Then all your stakeholders’ expectations will finally merge into one path that leads straight to the apex of the Expectations Pyramid. The following stories are personal. I have left myself in them because leading teams is the most personal part of being a project manager, and I want you to feel my experience as closely as it can be communicated. Your Team’s Expectations: Scope Scope is a touchy subject with your team members. They often assume that you and management will let the scope increase in order to satisfy the customer, causing the team to do extra, unplanned work. The following story turns that assumption on its ear. American Management Association • www.amanet.org 88 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS Tale from the Project Management Jungle: The WoodSorting Yard I worked as a co-op student for four semesters at a paper mill in my home state of South Carolina while in engineering school at Clemson University. Co-op is short for cooperative education, in which a student alternates semesters at school with real-world experience. This wasn’t just any paper mill that I worked in. At the time, it had the widest Fourdrinier in the world. The Fourdrinier is the basis for most modern papermaking. It accomplishes all the steps needed to transform a source of wood pulp into a final paper product. These machines run very fast and are very wide, generating huge economies of scale. But my first task was not with the sexy Fourdrinier. Rather, it was to design the new control panel for a totally different part of the paper mill, the wood-sorting yard. I was a nineteen-year-old college sophomore. I had finished three semesters of college, only one of which had included engineering classes. I had never flown in an airplane. I knew next to nothing about paper mills. I certainly did not know how to design a new control panel for the wood-sorting yard. The wood-sorting yard is the front end of a paper mill, the area where the logs are sorted by size, quality, and whatever other criteria are used. The logs are dumped in the top of a collection of conveyor belts, and then it looks like—if you were a fly on one of the logs—the log ride at an amusement park, except that these are real logs that would easily crush you if you somehow fell into the sluices. So, how to get the information—the scope or performance criteria—I needed to design the new control panel? I started by finding the sorting operator. Sorting operators in wood-sorting yards have a tough job. Imagine sitting for eight hours per day, five days per week, in a noisy, scary, wet environment, with headphones on to prevent deafness, constantly hitting buttons to sort logs all day, only occasionally getting up to use huge gaffe hooks to untangle jammed logs. The sorting operator, Darrell, acted like he didn’t see me, but American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 89 eventually he motioned me into the quiet room just off the sorting floor. He glared at me, clearly not impressed. “I’m here to design your new control panel,” I started hopefully. “Uh huh,” Darrell said, his initial impression clearly unchanged. I showed him the plans from the engineering files. “This is the current drawing.” He glared down at the drawing. “That ain’t righhht,” he drawled. “Oh.” In the most dismissive and derisive tone possible, Darrell said, “Follow me,” and he went back out to the floor. He picked up a broom. Darrell stood in front of a rusty control panel that was clearly in need of replacement. The panel was several feet across, with one hundred or so buttons. “I have to take this here broom and start the thing like this.” He used the broom with his right arm to simulate pushing a button far from where he was pushing other buttons with his left arm. “That’s what the last college boy left me,” Darrell said with another glare. “He dint have the fust idea how to design anything anybody could use.” Somehow I had enough sense to say, “Well, how would you like it designed?” “What?” Darrell yelled crossly. “Why don’t you tell me what you want it to look like,” I said. His response was a snort, a long glare, and a jerk of his head back toward the quiet room. I followed him, and we started designing his control panel. After a couple more sessions, it was done. A few weeks later, Darrell had a brand-new stainless steel control panel. His broom went back to being used for sweeping. TACTILE Analysis This is an example of a young person who had the right instincts and enough sense to follow those instincts but who would not have articulated that well at the time. Realize you may be in a similar situation and let your instincts guide you. American Management Association • www.amanet.org 90 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS > Transparency: I was totally transparent with Darrell. I hadn’t learned how to be any other way. > Accountability: By asking Darrell for his input, I demonstrated my accountability and held Darrell accountable for the results. I doubt he complained about “that college boy” again. > Communication: Again, I didn’t know any other way to act. My open, direct approach inadvertently disarmed Darrell. > Trust: Trust, however unlikely, came because of the approach taken on the first three characteristics. > Integrity: Try as he might, Darrell couldn’t see any reason to not cooperate. Darrell saw a wet-behind-the-ears young kid he didn’t like, but my personal integrity came through. And he evidently did want a properly designed control panel. > Leadership: This is an example of creating the good local culture needed to solve the issue at hand. > Execution Results: The desired results were achieved: a functional new control panel was designed that had the scope needed, and it was done by gathering information from the informed team member, at the same time paying dividends on his motivation. Expectations Pyramid Analysis Darrell almost surely had low expectations of me coming into our encounter. By taking the seemingly simple approach of asking for his input and by giving him some control over the outcome, I inadvertently hit on just the right way to overcome Darrell’s expectations bias. I also met and even exceeded his needs in terms of scope—not the scope that an engineering student thought he needed, but what Darrell actually needed to better perform his job. The rest of this chapter concerns my experiences with the microprocessor core design team The Gang That Could (Finally), first mentioned in Chapter 5. A microprocessor core is the key building block for the overall microprocessor; it enables a variety of cus- American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 91 tomers to add custom capabilities that differentiate their particular microprocessors while still allowing them to use a standard core. The team of very talented engineers I worked with had previously never had a successful project in terms of meeting scope, schedule, and cost, which to them had always been someone else’s concern. To them, success had been designing great microprocessors, without the discipline good project management can bring. They were very inwardly focused. Their view of success did not include enabling the success of other stakeholders. Many technical teams, without leadership, view the world in this simplistic way. Quite often, this hinders the dissemination of the technology they create, exactly the opposite of what they would like to see. The next three stories are really just facets of one larger story. I will provide only one TACTILE Analysis and Expectations Pyramid Analysis, at the end of the third story. Tale from the Project Management Jungle: The Gang That Could (Finally)—Scope Because I was new to the semiconductor business, my first task was getting to know people. I did this by explaining my philosophy and seeking out their views on the way previous projects had been managed. As described in Chapter 5, I was met with good luck in the form of the design manager assigned to the project, Nitin, who was friendly and open and who had high emotional as well as analytical intelligence. In addition, while disheartened and overworked in an effort to finish the previous project, the team was at least willing to talk with me. One of the more vocal team members, Sandra, called me out in a meeting. “You PM guys always promise the customer whatever he asks for; then we are here trying to do it 24/7 and get beat up when we fall short.” Several team members pounded me in this way. I didn’t take it personally. Instead, I listened and tried to understand the world they lived in every day. Eventually, Nitin and I found ourselves in the office of our internal customer (the microprocessor project manager), Elliot. American Management Association • www.amanet.org 92 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS After handshakes, Elliot took twenty minutes to talk us through a short PowerPoint document that covered what looked like highlevel basic requirements for the microprocessor cores for which we were responsible. Due dates were also shown. He asked if we had any questions. I had a couple. “Can I look at the requirement document, see how many open areas there are?” Elliot glanced at Nitin, who nodded as if he knew what was coming. Elliot smiled slightly at me. “You all develop the details for your work, not us.” I see. How convenient. I then asked, “How did you arrive at those dates?” Elliot smiled and said, “Don’t worry about that. These are your dates. Okay?” Not okay, but we shook hands again and left. Nitin and I went back to the design center. Remembering Sandra’s admonishment, I said, “You know the tasks, the team, the work better than anyone. Right?” Nitin nodded. “Are there holes in the requirements document, things we have no idea how we are going to get done?” Nitin smirked a bit. “Sure.” “Considering that, can we make those dates?” Nitin shook his head. “I doubt it.” “I thought so,” I replied. “So we’re in trouble?” “No more than normal,” Nitin said. “Would you like my advice?” He nodded. “You will never be stronger than you are now at the beginning of the project. Right?” Nitin nodded. “Why live through the impossible and then have them kill you?” “Yeah?” he said. “Why don’t we figure out what scope we can deliver by the end date Elliot is demanding and commit only to that date/scope combination?” American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 93 Nitin smiled. “Tell me more.” We talked off and on for several days, then went to the team leaders with an idea to work with them to analyze the open scope items and to create a milestone schedule with enough detail (a milestone every two weeks) that it would allow us to convince ourselves and others that we weren’t sandbagging—that is, trying to pad the schedule. The team somewhat skeptically agreed. Your Team’s Expectations: Schedule As mentioned in Chapter 5, many organizations keep two sets of schedules for a project. The internal, aggressive one is what the team is driven to. Of course, the team knows that the other schedule exists. This immediately creates a trust barrier. Team members assume that if you will lie about that, you will lie about other things. Your team resents being managed this way, and it underperforms when managed this way. Read on for a different approach. Tale from the Project Management Jungle: The Gang That Could (Finally)—Schedule “Elliot, we can’t commit to any other date,” Nitin said. “This is our date.” Elliot shook his head at us as if we were deranged. “Unacceptable,” he said. “I, or more likely my boss, will be talking with Bobby and Julius.” Bobby and Julius were the senior VPs for the design center we worked in. Elliot’s reaction was not unexpected. The date we came up with was later than his required date by a couple of months. Our date was based on reasonable assumptions about the existing scope and the unresolved scope items, made by people who were actually going to do the work. We did not (as many people assumed) sandbag the dates. The end date was still quite aggressive. Nitin and I developed a multistep approach. The next step was a kickoff meeting with the team leaders. We told them what Nitin and I expected of ourselves—how we intended to help them remove roadblocks—and what we expected of them. American Management Association • www.amanet.org 94 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS For the detailed schedule, we told them that each of them was going to create, update, and ultimately own his or her sub-schedule, which fed into the unified team schedule. Their schedules should show the name of the one person assigned to each task (no multitasking), with tasks lasting no longer than two weeks. We told them we were going to have weekly team meetings that emphasized team problem solving, not status reporting, and encouraged them to come to the meeting prepared to bring up and solve problems. We showed them the one-page form we wanted them to fill out and bring to each team meeting. They were skeptical, but less so now that our stance on the end date had not resulted in our removal. As word filtered through the building that management and the customer were not rejecting our approach, Nitin and I began to see more positive energy from the team. This only increased as we hit one milestone after another. Your Team’s Expectations: Cost It is axiomatic that costs always increase on a development project anytime they are re-estimated. Cost is what your team represents to anyone looking at your budget. The team knows that many project managers will assume that the easiest way to lower cost is to get each team member to work more hours. Seems like basic math, right? But this approach demoralizes the team as it chases the proverbial carrot that the project leader seems to hold out of reach. The team will assume that of you unless you find another way to generate the needed business results. Tale from the Project Management Jungle: The Gang That Could (Finally)—Cost As previously mentioned, we held weekly team meetings with the task leaders, with each task leader bringing his or her own onepage report to the meetings. The information in these reports was all that we allowed to be discussed in the team meetings. One input we asked for was unforeseen new tasks. We hoped that, armed with this information early, we could forestall the American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 95 adding of a huge number of new designers (read: cost) throughout the project. Designers are precise people who want to do everything right. This is a great attribute, unless you define the word right in terms of perfection. I prefer excellence to perfection. In lieu of any other way of analyzing situations, engineers and engineering managers will almost always err in the direction of more, not less. More tests, more tasks, more, more, more. All this, of course, adds cost and delay to the project. Task leaders frequently ask to add new tasks to the schedule. This almost always means the addition of more people (cost) to the project, because every individual contributor’s time is almost always fully (or more) planned. In response, I started asking a series of questions. First of all, I never questioned whether the task needed to be done or acted as if I were a technical expert. I only asked what the impact of doing that task would be: to the nearest milestone, to other team leader’s tasks, or, occasionally, to the end date. I asked the questions in such a way as to stimulate discussion among the team leaders. As a result, most of the required new tasks went away, and, if the new task really had to be done, we generally developed a way to work around any added delay. I took this approach because I wanted to teach the team leaders how to get out of their cubicles and work together, but it also served to keep costs down and to prevent impacts to the schedule. None of the business types ever complained to me about cost. Schedule was critical, scope was important, and cost was actually the least important of those three criteria on our microprocessor core development project. What were the results? Simply fantastic: > > > > > We never missed one of our milestones. We hit our two schedules on the days we’d committed to. Our design center VP was congratulated for the success in Julius’s staff meeting. Nitin and I went on to promotions and bigger assignments. The process we put in place enabled the team to tape out five more cores on time, long after we were gone. American Management Association • www.amanet.org 96 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS TACTILE Analysis Some of the managers involved still use these approaches on current projects in the various companies they work for. This demonstrates the business results—ongoing for years—that are possible when the right values are applied effectively. > Transparency: We were totally transparent—not only with our team but also with everyone else. For example, we kept only one set of schedule books. The initial list of milestones we came up with in conjunction with the team leaders never shifted. We told our customer, our management, and the team the same final commitment date, and it never shifted. The team knew everything we told management. > Accountability: All the team members knew what was expected of them and what they could expect of others. Accountability went all the way to the design center VP, who himself told the team in a kickoff meeting that he was there to help if needed. Later, when he actually did so, the team’s morale soared. By creating an accountability culture, Nitin and I dealt with a tendency to vagueness that many people use to create plausible deniability. Vagueness in dates, vagueness in requirements, vagueness in many things is how some people (deliberately or otherwise) place you on the hook. > Communication: We worked hard to create an environment where the right information got to where it was needed as quickly as possible. > Trust: Trust bloomed in this environment. People began to enjoy their jobs and working with their teammates. One senior designer told me, “Finally, I can sleep at night.” Another said, “So this is how this project management stuff is supposed to work.” > Integrity: The team members got to the point where they just believed whatever Nitin and I told them. The customer and our management did also. Everyone was able to relax in that environment. > Leadership: We created the desired culture change. American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 97 > Execution Results: The results were as good as anyone could have ever expected—and took less actual work than the team was used to. Expectations Pyramid Analysis By creating a TACTILE environment, we were able to exceed our team’s expectations. The team worked hard, but, more important, they worked smart. They were able to achieve work/life balance and still meet the corporate goals. Our management was quite happy with us, as was our corporate customer. Using the Triple Expectations Pyramid In Chapter 3, the Expectations Pyramid was used as a graphical illustration to show that the expectations of your customer, management, and team—the three key stakeholder groups—are critical. Expectations management requires that you determine the desires, wants, and needs of your three key stakeholder groups— your customer, your management, and your team—so that you can craft a solution that leaves them all satisfied with you and your project’s results. The R.101 case study in Chapter 3 showed how to summarize the expectations of the three stakeholder groups. This chapter and the preceding two illustrated the concepts by focusing on one stakeholder group per chapter. But how can you integrate all this into a successful project? First, your chance of success will be higher if you pick the proper project. For that, you need what I call a black box project. A black box project has clear inputs (requirements) and outcomes (deliverables and dates) that you advertise, but inside the box you are allowed to implement your approach without interference. What kind of projects are the best candidates? Important projects, like the microprocessor cores discussed in this chapter, where management was open to change because of past lack of success. This point was made to me in the Q&A phase of a talk I gave, and that person was absolutely right. What would constitute an improper project? These are projects American Management Association • www.amanet.org 98 MASTERING THE EXPECTATIONS OF KEY STAKEHOLDERS where management or the team leaders are sure they are already correct, where nothing will get them to agree to change. Once you have the right project, evaluate it using the Expectations Pyramid format. Let’s use The Gang That Could (Finally) as an example. > Customer Expectations: TGTC was a microprocessor core for another internal corporate customer. This customer used our core in a microprocessor that it in turn sold to an internal customer in a completely different part of the same large corporation. Their customer sold the ultimate product into a very competitive consumer marketplace. The ultimate customer had a bad history with my new organization, as did our internal local customer. Elliot, our internal customer, was the program manager for the microprocessor unit. He expected a continuation of the poor schedule performance from earlier projects. Elliot had no real concern for our costs, as they were not directly billable to any cost account he managed. He expected to be able to keep the requirements liquid and vague so that they could be changed at the direction of his customer or as his engineers figured out certain approaches. Both sets of customers—Elliot and his corporate-level customer—acted on their worries about poor performance by trying to dictate dates to us that had considerable management reserve built into them and by trying to micromanage us. > Management Expectations: From the time the project was approved, my management chain felt tremendous heat to perform for this corporate mega-project. That is one reason it conducted a corporate search that ultimately wound up with me as project manager. It expected a difficult project and worried that a failure might destroy careers. It also worried that the destroyed careers might be theirs. > Team Expectations: From previous experience, the team members expected a chaotically managed project, characterized by unreasonable dates, fluid requirements, and heavy pressure from management. They also expected project management to be a non-value-added waste of time and extra work. Nitin and I decided from the beginning to tailor the approach to the team members American Management Association • www.amanet.org THE TRIPLE EXPECTATIONS PYRAMID AND YOUR TEAM 99 and to tell them that good project management wasn’t extra work; it was the work. As their worries failed to materialize into reality, increasingly the team began to cooperate with what we were doing, and our approach eventually became the project culture. > Results: TGTC finished (“taped out,” in the semiconductor design world) to the day that we’d committed to, amid great fanfare and happiness. Nitin and I were ultimately promoted, as were some in our management chain. No one lost his or her job. Next, choose your personal approach on the basis of a set of characteristics by which to manage. Use my TACTILE list, or modify it as you see fit. The key point is that you need a connected philosophy by which to lead. Otherwise, you will get lost when the going gets tough. Remember Larry’s sad fate, recounted in Chapter 4. In Chapter 2, we talked about soft and hard skills. In an effort to combine the two, I defined strong skills as the ability to use any robust process—like Lean, Agile, or Six Sigma—combined with the ability to get results through people. Take a look at your strong skills. Seek input from others on your effectiveness, and fix what you think needs fixing. Before actually implementing this approach on your own project, take some time to reflect on what might go wrong and create plans with your team for how to deal with these eventualities. Chapters 7–11 examine the five key phases of a project—Initiating; Planning; Executing; Monitoring, Controlling, and Reporting (as mentioned in the Introduction, reporting is a key addition for me); and Closing, from the perspective of several pitfalls you may encounter on your way to success. American Management Association • www.amanet.org This page intentionally left blank PART IV: Avoiding Pitfalls in the Five Key Phases of a Project American Management Association • www.amanet.org