Guerilla Project Management Interview

Transcription

1 Guerilla Project Management Interview Putting Brakes on a Rocket: Managing Velocity, Reward, and Risk at Intel To listen to and download the audio file, please visit: Russ, welcome. Thank you. I appreciate the opportunity to talk with you this morning. Russ, give us an overview of your role as a Senior Program Manager at Intel and describe to us the primary business goals you help Intel achieve. Okay. So I ve had the opportunity to work in multiple capacities as a Program Manager at Intel. I m very fortunate that way. So I came into the company as a New Product Development Program Manager where I led large new product development teams for multiple generations. Then I had an opportunity to work with our Mergers and Acquisitions team to be an M & A Integration Program Manager where I really led the integration of various companies into Intel from a systems and tools and practices perspective. I also have had an opportunity to work on our infrastructure as an Infrastructures Program Manager developing enterprise-level tools that we ve brought into the company. And then finally, come to my current role as a Business Practices Program Manager. And from a business school s perspective, each one of those roles has a different set of goals. So certainly from a New Product Development perspective, it s all about making sure we achieve our revenue, gross margin sales, market share, and goals that we have as a company. From Mergers and Acquisitions, it s really making sure we effectively combine the cultures and practices of the two companies that are being integrated. When you move into the infrastructure piece, it was really all around increasing our productivity through better collaboration and communication across our teams. We re distributed globally. So we rely a fair amount on our infrastructure to become more effective and efficient there. And then finally in the Business Processes Program Management piece, it s really about working smarter and learning new ways of doing our work so we can decrease our development cost and increase our efficiencies. Page 1 of 15

2 You say that, Managing a program at Intel is like strapping roller skates to your feet and a rocket to your back: once they're on, it s ready, aim, launch. What are the challenges of leading programs at Intel? [Laughs] Okay. Actually that analogy was an analogy somebody gave me when I was interviewing for the job here at Intel. [Laughs] And I took that comment pretty lightly until I actually got into the job and I quickly understood exactly what he was talking about. But just like any other company or organization, there's never a shortage of challenges here at Intel. I think the biggest adjustment that I had to make as I moved into this company was to understand what it really meant to work for a market leader. So in previous companies that I was in, I wasn t working for a market leader necessarily. They really didn t act that way. But when you are working for a market leader, especially in the technology industry, you're always pushing new technologies. And you re always trying to decrease your development cycle time so you can get those technologies to market faster. When you combine those two, you're always dealing with a large amount of risk that you have to contend with. So that requires a combination of innovation and cycle time speed that gives you a competitive advantage. Particularly here at Intel. So again, we re always trying to be first to market with our latest technologies. However, when you look at that combination as you're trying to put more and more new technologies into a product, and you're trying to get that product out to the market on a faster and faster cycle, that risk level goes up dramatically. So you have to be able to learn how to manage within that environment. That was probably the greatest learning that I had to come to terms with as I moved into the company. And how do Intel project managers balance innovation, market leadership pressure, speed, and risk? Yeah. So let s probably take each one of those separately. So first of all, from an innovation perspective. As a market leader, we are always trying to set pace of innovation and technology development. So if we re following the pace then we become a market follower. If you re setting the pace, then you have the opportunity to be a market leader as long as you have the compelling technologies and innovations. But we don t provide the entire solution. We rely on many development partners to actually develop the whole product that we re trying to develop. So that means we have to help our partners maintain that same pace. What that puts us into then is really a lot of Page 2 of 15

3 parallel or concurrent development where many things are being developed at the same time. And this is where the program management model really comes in. so we do use a program-based development model where we tie all those concurrent development efforts together into multiple projects, and at the program level we re focusing on the integration of all the interfaces, integration of all the solutions, keeping everybody at the same pace, and keeping everybody focused on the market goals. So that s the innovation perspective. If you look at it from a cycle time speed perspective so trying to decrease cycle time as we go through it it really starts with a streamlined life cycle model. So if you look at our life cycle model, it is very streamed. It has four phases and only five primary gates as you go through. So I ve had the opportunity to actually benchmark our systems with other companies, and I was surprised to actually see a lot of companies [Laughs] actually have many more stages and many more gates. My personal view is from a program manager the more gates you put in the path between product concept and a product launch, the slower that team is going to have to go through that. So I m fortunate that we have a very streamlined cycle. And I can spend a minute trying to describe what that life cycle model looks like. So I said we have four phases. Those being: Exploration, Planning, Development, and Production. And within those phases, we have the five gates, if you would. So, the Exploration phase has two primary gates. And again, when I say gates, these are really business decision checkpoints. They're not execution and operational checkpoints. So in Exploration it starts with Concept Approval. Do we have the right product concept? Then as we re exiting Exploration we have Development Investment Approval. This is where we look at the product-to -product concepts from a business perspective. As we come out of Planning, we have an Implementation Plan Approval. This is where we take a look at our Integrated Program Plan based on the concept and business case we had developed. Coming out of the Development phase we have Ship Readiness Approval. This is where we evaluate the solution that was developed, take a look at our supply line, our factories are our factories ready, and is the customer base and the market ready? And then finally at the end of the Production phase is Product Discontinuous Approval. And that s where we very methodically decide when we re going to end-of-life a product and bring the follow-on product to market. So having a streamlined decision process or decision framework is good, but there's another piece of that. And if you're driving high-velocity programs you really need a good guidance system to ensure that that program stays on course. So for many years, I ve used the tool that I call the Program Strike Zone, where it really lays out the critical business success factors for the program. Page 3 of 15

4 And I m not really talking about the KPIs, the Key Performance Indicators. Those are typically more operational from our standpoint. These are things like, what are our market share goals, what are our gross margin goals? What is our launch timeline? What are the financials supporting the program? So they're really business-focused success criteria. Now the key in the Strike Zone is, we ve got a couple measures. For each one of those business success criteria we have a target. A very clear target, measurable target that I as a program manager can lead the team to try to achieve. But we also have a set of thresholds for each one of those that extend that target. And that in effect gives you a set of guardrails that a program manager can manage a program. The key there is having that threshold. Because if you ve only got a target, you're forever having to go up the management chain for approval when things change. And they always do. So by having a guardrail, you ve got decision boundaries to where you know what decisions you can make as long as you're operating within those boundaries. You have your empowerment boundaries. Many times I hear program managers talk and complain about not being empowered. Well, this gives you the empowerment boundaries because you clearly know what success is. And then finally, it gives you the risk boundaries. So you know as long as you're operating within those boundary conditions of your business case, when you start going past that the risk then potentially comes unbearable and you may have to make some decisions. And then finally from the risk perspective if you're again, a market leader in the technology side as I ve said, you re dealing with a lot of risks. So you have to accept that high level of risk that you operate in. so that means you do have to accept many of the risks that you normally would try to manage out of a system if you're at a lower tolerance risk environment. But at the same time, you probably want to try to uncover as many risks as you can. So you want to be really, really diligent on risk identification. Take us through the Rattlesnake Program as a case study where we can see these different pressures that you tried to balance at play as well as the approach that you have adopted for your program management. Well, as it turned out the Rattlesnake codename turned out [Laughs] to be a poor decision, maybe? I don t know. [Laughs] But the Rattlesnake Program was the second program that I managed here at Intel. It was a New Product Development program. To describe it, it was really a dual microprocessor server system where the product went into datacenters. So everybody Page 4 of 15

5 knows us as a microprocessor company but we also develop entire systems that we sell into the market with our microprocessors. So this is one of those examples. A set of circuit boards, certainly an enclosure with power and cooling capabilities. A lot of software in these systems, and then of course peripheral devices. Both ourselves and from other vendors. So that meant multiple new technologies were currently developed. So we internally, we re developing a lot of new technologies. But as I said earlier, we also rely on a lot of other development partners. So we had a fair amount of external development that was going on very well. It was a multimillion dollar program, so that was all internal investment. So Intel was funding this development effort, 14 month development life cycle. So that was really from concept to product launch. A little over a year. And then our time-to-market target, which is always a primary business target for us, was that we needed to get this product out to the market six weeks prior to the launch of the associated microprocessor. And the reason why that six weeks was so critical is that we needed to get this system into the hands of the original equipment manufacturers that would then put their own software in it, put their own add-in cards, and so forth, to customize it for their particular brands. So that s what the program was all about. I ll go through the life cycle and kind of explain how we balanced the various aspects that I ve talked about. So in Exploration phase, early exploration, we re looking at multiple concepts. So this is where we look at the available technologies, product architecture concepts, understanding how the product will be used and the user experience, and then balance that against the market needs that we have researched, how it fits with our internal roadmap of products, and then also how it fits with the business expectations. That s really what the Concept Approval is all about. On the Rattlesnake Program we had two product concepts that were approved at that point. So they were approved and we were charged with going through the rest of the Exploration phase. That meant trying to narrow it down to a single concept and then putting a business case together as you come out of the Exploration. So that was the Development Investment Approval. So at that point in the program, we did have a single concept that was selected. We did have a business case around that. And this is also the first time that we look at risk from a holistic perspective. Holistic in that we look at market, we look at technology, and we look at business risk. In that process in the Approval meeting we tend to look at what we call the top 10. So we may have many risks that we have identified, but now we re trying to cull them out to the program level and identify which are the primary risks that we think we re going to need to deal with. At this point, we had seven high-risk items associated with the program at this point and then three medium that we d presented out to our customer. So, a fairly high-risk Page 5 of 15

6 program at that point. But based on that and the business case, we did get approval. Business case was approved, and the product was added to the roadmap. What's significant there is in this business decision as I described funding was then committed. So, that meant nothing else in the portfolio of products could be funded at that point until we at least get through our Planning phase. And then the piece that was added to the roadmap, that meant that our customer base now had visibility to that program. So, increased expectation from the customers at that point. From a risk perspective we were given resources to go work the various risks as we went through the Planning phase and, see what we could take out of the system, what we could put in place to actually mitigate some of those risks. So as we went through the Planning phase we developed our integrated program plan and presented that out at our Implementation Plan Approval. Our plan was approved based on the tactics of the program. We still had three potential what I now call showstopper risks that remained. So all of those were critical to the business success, and they were all external risks associated with external vendors. But the term showstopper takes on a different meaning at this point. So they're definitely high risks in that they presented significant potential impact on the time-to-market and market acceptance goals of the program. But it also meant that there was no response or contingency plans in place. So if we were going to move forward, we were going to accept these risks and the fact that these were external risks actually increased the overall risk of the program. So when I said you have to learn to live in a risk-taking environment at Intel, these risks were accepted, the plan was accepted, and we were given full funding, and resources were committed to the program. So, high-risk was actually accepted by our management team. That s the difference. In other cultures, other companies I worked in, I would not have been given approval that that point. I would ve been asked to go work those risks out of the system, most likely. Yep, yep. So as we then moved into the Development phase, and many months between our Plan Approval and our product launch, and no decision checkpoints in between that. So this is where we tend to go to a more operational mode where we have monthly program reviews. In the program reviews, we ll take a look at our execution progress-to-plan on a monthly basis. So, how are we tracking to our plan, what issues are we dealing with? Continually looking at our business goals, and how we re tracking to those, and our success criteria. This is where I, on a monthly basis, pull out that thing called the Program Strike Zone, which is really our business case in metrics form. That s reviewed with our senior management. And then constantly reviewing our current state of risk. Page 6 of 15

7 This is where it gets dicey from a risk perspective. So even though I m working in a high-risk tolerance company, that doesn t translate as you go through the Development process. So as you move further and further down the Development process and into the Development phase of the life cycle, a couple things happen from a dynamic perspective. First of all, the severity of that risk impact greatly increases as you go later in the life cycle. That s because your potential consequence grows. So you continue to invest more and more hours and money into a program. So you ve got a higher and higher degree of sunk cost. And at the same time, you also have a potential for a lot of rework if something goes wrong later in the life cycle. Couple that with the ability to respond to something that happens. So you ve got less and less time to actually respond to a risk event as you go through the life cycle. So because of that, your risk tolerance at the program level has to continue to go down as you get closer to product launch. And that s one of the main things we actually look at at product launch is, what is the overall risk? We always have risk, but can we balance the potential plus side with the amount of risk that we think we re going to now carry into the market? So as we went through the Development cycle on Hemlock, about eight months into the Development phase of the program, the program was canceled. One of the showstopper risks that I talked about actually was realized. It was an external vendor, external development partner that experienced the risk. Based on a lot of meetings and discussions, the decision was made to actually cancel that program that far into the Development cycle. I want to talk a little bit more about the decision to kill the program. What was the basis again for the decision at the end? And what were the challenges that you and your team faced when making this tough decision? Okay. Well in short, the basis for canceling the program was because the business case supporting the program completely fell apart. I ll give you an example. So, the failure of the development partner to meet the schedule. When they looked at the impact to that from their side they were showing about a three month slip. And since their piece of the product was critical to our launch, that meant our launch would have to slip three months. So if we go back to the Strike Zone that I was talking about, a couple things would happen there. First of all, our launch date would go red. The second thing is we had a business success criteria around market share. And increasing market share one year after introduction. We had targets there. It s clear if you took that first three months out of a product launch, you were going to not realize that market segment share. So that went red. The other piece is if you had to carry your development team for another three months, your program budget, program financials would ve gone through the threshold as well. Page 7 of 15

8 So that brought the program budget to a red. Combination of the higher program budget, decreased market segment share, brought our profitability index past the threshold. So some key business success criteria surrounding the program or driving the program all went red. [Laughs] So the decision is still difficult, but at the same time it s easy. The difficult piece gets into the emotional piece. You ve invested many, many months and many, many person hours into developing this. So you get emotionally tied both as a program manager and as the management team. You re invested in this thing. So it s really about, do we go forward or do we cut costs where we re at? That s a tough decision. But when you have a tool like the Strike Zone, it makes that decision actually easier. Now from a team perspective, it was a bit devastating, as it always is. Not everybody on your team s really understanding the business case surrounding it, right? I ve got a team of very confident technologists that really don t want to deal a lot with the business side of it. That s my role as the program manager. And then all of a sudden you're telling them that your program has been canceled. That is tough. But fortunately, we did have an alternative that we were working in the background for a bit. Because we saw the trend, we understood the risks, we actually had somebody in place at this vendor s business that could give us almost a daily update. So we knew they were slipping, we just didn t know how much. So when that activity was becoming visible, our senior leadership team actually kicked off a secondary effort that was going on in the background to say, Hey can we take one of the existing products we have out there that this new product was going to replace, try to add some of the key features that our customer base was looking for to at least get something out to the market even though it would be ideal, but deliver something to our customer base for this, basically, product launch. So with that decision we also had the opportunity then to refocus this team to now go work the alternative. So yeah, a bit devastating, because so much was invested, but again we had marching orders to go get something else out as quickly as possible. So that s kind of how you manage through it from a team perspective. You ve got to have a vision, you ve got to be able to make the decisions, and you ve got to show strong leadership skills in a situation like that. I think that s one of the areas at least in project management, and I m not sure about program management training and literature that doesn t get a lot of coverage from the perspective of the mindset and of that program manager who s going to have to go through that process of walking the team through that tough decision, and really making sure that you don t get sucked into all of the emotional dynamics of that entire process of killing a program. Page 8 of 15

9 Yes. You're absolutely right. And this is one of the key differentiators that I find as people move maybe from a technology role into a program management role, or from a project management role into a program manager role is the ability or the skills and competency in the leadership space. It s not about mechanics at this point. [Laughs] And it really seldom is about the mechanics at the program level. You re leading a team of people, and you're really assuming the business aspects for your business unit manager for that program that you're on. So you have to take on a different set of skills and competencies. And that s kind of one of things that separates people that are going to move into the role that haven t been able or haven t had the opportunity to broaden their skill base. Talk to us a little bit more about the fallout from the decision to cancel the program. Yeah, the fallout. When I present this story to an audience, I usually answer those questions more with a question. So I ll kind of answer that this way. So, first question I ll tend to ask the folks is, So what do you think? Was this program considered a success or a failure? And usually I ll ask for a show of hands, and most of the time I ll get a split. About half the people thinking it was a success, about half the people thinking it was a failure. Now, from a program manager s perspective, you're managing the business. So when I give them that piece of it, it becomes clearer. Many, many more people now realize it was truly a failure. Because we failed to achieve the business results from that perspective. So, the second question that I ask is, So what do you think happened to the program manager? Well obviously I survived, I m still working for Intel. What I didn t expect was being rewarded actually for managing correctly within a high-risk environment. This is where I really learned a lesson about the culture. Because we did take risk, we managed the risk accordingly, and we actually got rewarded for managing appropriately. Next thing I asked is, Well what do you think about that business unit manager that actually made all those decisions first of all to fund this program, resource the program, knowing there was a very high level of risk going through it, and then ultimately having to cancel that program? And again, [Laughs] mixed response. A lot of people think, Well he was given the special program. [Laughs] Other folks think, He was probably promoted. It was really the latter. This person also did exactly what he was expected to. He kept his management chain informed all the way through this of course, but he managed appropriately within a risk-tolerant organization. And this gentleman really went on the fast track from a management perspective and went up the corporate ladder very quickly. Page 9 of 15

10 And then, last question I ask is, Well, what do you think about this development partner that really failed? And this is probably [Laughs] the folks that took the harder hit. Because ultimately, they lost multiple generations of Intel business because of this, because we lost the trust in them. So they probably took it harder than anybody. And that s another piece you never quite think about is you're actually bringing a team of organizations and people with you as you're taking on risk. It s not just you as an organization, you're asking other organizations and other people within those organizations to operate the exact same way. And now everybody obviously is equipped or has the capacity to be able to handle being in that type of partnership, and having that kind of stake. So it s a really interesting case study to show that as a program manager, you have to take that into account. That maybe the vendors or partners that are with you may not have the same culture. Yes. That s one of the things you absolutely look at. Because everybody wants to be a partner with Intel, because of obviously [Laughs] the numbers we generate and so forth. So it s very profitable to be a partner of Intel. But what they don t realize is what that entails. And a bit piece of this is the risk and the speed and the expectations from a technology perspective. So ultimately, that comes back to the program level and the program manager to make sure that, Okay. We ve made a commitment. Am I actually, or is somebody on my team actually consistently managing our development partners as well? That becomes a separate project within the program. Just like we have internal projects hardware, software, validation, all those others you also have the external projects that involve our development partners that are managed at the program level. Well, what is amazing to me about this case study is that at a place such as Intel, in a competitive environment, it is easy for an organization after a program cancelation like this to just decide, Let s just get rid of a bunch of people and blame people, and give some sacrifices to the gods of [Laughs] projects or programs. [Laughs] And then say, Okay we solved the problem. And I think what the lesson to me here is, is that it s not about the actual cancelation itself or the actual decisions that were made. To me, it s about how you handle the process as a program manager and for example, in the case of the business unit manager or director it s how you conduct yourself, how you work through your own emotional kind of baggage and dealing with the status, and with how your status is going to be affected or undermined. You know, the uncertainty of the situation. And you guys have shown that to me, for me it just confirms that it s not necessarily about what decisions you make, although that is very important. How you behave and show up as a person is also very critical during the crisis. During this really very difficult situation, I can imagine. Page 10 of 15

11 You're exactly right. The human element takes over completely at that point. It also shows what I m trying to demonstrate is a true culture of risk-taking. So we hear a lot about, You must allow people to fail occasionally, and sometimes reward failure. So, a lot of organizations talk the talk, but they really don t act that way. Because at the end of the day if something like this happens as you said a lot of people would be fired. Including the program manager. Or they would be let go, or they d be given these special projects. Not the case. As long as you're managing smartly, doing the things that you need to do, it really is a culture that walks the walk as well as talks the talk from a risk-taking and rewarding failure perspective. And you know, and I think that s important to credit the culture. I really think that is important. But I also think that we should also credit the individuals in this particular dynamic. For example, like yourself as a program manager. I mean, you have gone through your own internal struggles throughout this entire process, I can imagine. And how you have managed yourself, how you have managed [Laughs] your internal dialogue and your fears, your concerns throughout that entire process. And we can only think just by the result that you must have really handled yourself in such a way that showed your leadership. I don t know. I m probably not the best person to speak to that, but I can share with you that it was getting clearer and clearer that we probably were going to cancel this program. I was very scared. I really thought I was probably going to get fired. Because that was more of the environment that I worked in prior to coming to Intel. I think if that would have happened, I think I would ve been fired for it. So [Laughs] I was pretty nervous. Yeah, I can imagine. I really thought it was probably the last program I was actually going to manage for Intel. But I was pleasantly surprised. Yeah, because I think what I find in other situations as well is sometimes what you're thinking about internally, how your fears, your concerns are at play causes you to make some really bad decisions. [Laughs] Because you re sometimes acting out of selfdefense and survival mostly, because you have that threat response. But in this particular situation, you must have really been a very strong program manager. And despite everything that s going around you, you stayed the course. And I think those guardrails that you talked about must have given you the confidence that as long as you are focusing on those business goals and those I love the way you called them the decision boundaries must have kept you on track. Yes, exactly. Two things to your point. The most difficult piece from a leadership perspective when it was clear that things were unraveling was maybe a third of the team, I was actually diverting to looking at this new solution, kind of in the background. The Page 11 of 15

12 other two-thirds of the team, I had to keep them motivated towards keeping this solution [Laughs] going. Because we needed many of those pieces even for the alternative. So I couldn t really let on to them that we were heading towards cancellation at that point. So from a leadership perspective, that was probably one of the tougher things that I ve ever had to manage through. Two different sets of people at that point, and with different visions and goals of what we were trying to do. And the other piece is to your point with those business goals clearly understood one of the key takeaways I d like to have people understand here is that I was in a partnership situation with my business unit managers, my product managers, and technologists that were on the program. So many times, I d hear program and product managers talking almost adversarially about the technologists and about their businesspeople. That is the wrong attitude to have. This was very much a partnership situation with these folks. And it was really about those business goals. Clearly all focused on the business goals, all trying to achieve it, all trying to do a different piece of it, but in partnership. You know, I always say that building those relationships in times of peace, it s like an insurance policy for when things really start going south. It s those relationships that keep things going and keeps the partnerships going. Otherwise you start getting that finger-pointing, blame, and people want to just protect themselves. but that partnership and relationships which take a lot of time and a lot of effort, and [Laughs] it s really not very sexy or exciting to talk about the project Yeah. and program managers [Laughs]. But it really comes down to what eventually saves the day, in my experience. Yeah. I like that. Build your relationships in [Laughs] times of peace. [Laughs] That s a great way of saying it. Because it s not always peaceful! [Laughs] [Laughs] No. well I mean, there's so many people in a program like this that have the potential of losing their status like you said, losing their jobs. And we re not talking just at the program level but the higher-ups. Because there's so many people that have their names attached to the program. And they don t want to tell a story about cancelation and a failure. So you're not only leading the fate of your team or yourself, but also an entire hierarchy above you. And again, how you conduct yourselves in that time of crisis make the world of difference. So I really appreciate you sharing with us this case study. Because this is the kind of stuff that we don t hear about, we don t read about. [Laughs] We only hear about the successes. But nobody wanted to talk about, what did they go through? Because that s where the lessons are, really. Page 12 of 15

13 Yes. Yes. This is truly my greatest failure. [Laughs] [Laughs] But look at you now! The question is not having gone through that experience and really embodied those lessons. Somebody could talk to you about those lessons and could tell you about what to do. But in this particular situation, you really felt those lessons in your gut. And they will stay with you forever. And to me, I can t imagine or I can t help thinking that probably your later successes have to do with some of those lessons you learned. Yeah, you re absolutely right. These were some of the greatest learnings that I got from this program about managing a program, managing the business on a program, leading a team of people, and then just the value of the relationships and partners. Absolutely some of the greatest learnings were from this case study. Russ, summarize for us some of the key takeaways you would like our listeners to take away from our conversation. Yeah. I think we talked through some of those. I think the first one is that the innovation and time-to-market speed can absolutely offer great rewards, but if you're in that type of environment you really have to have an organization that embraces that level of risk that you're going to take. And don t punish failure. You really have to reward failure. Because you are going to get the spectacular failures as well as the spectacular success. Second I d say if you're in that type of environment or actually any type of program environment you have to have that guidance system that I talk about from a Program Strike Zone perspective. Because it allows you an over-the-horizon view of the business case that you're trying to deliver. And it allows you the opportunity to proactively make some of your decisions instead of reactively making it. And again, if you couple that with good risk management, that is also what risk management is about. Being able to make good proactive decisions versus reactive firefighting. And I think the third key point is the point that I made about viewing your work with your business managers, your technologists, and marketing folks as a collaborative environment and a partnership in order to maintain and deliver that risk-reward balance for any program that you're on. Russ, talk to us a little bit about the key ideas for your book, Program Management for Improved Business Results. Okay. Well, thank you for the opportunity to actually talk about that a little bit. So our intent really, when we decided we were going to write this book, was to create something that was really practice-based. And describe how programs are actually managed. And first of all, what is a program? And how are they different than projects, or how are they related to projects? We felt there were too many books that actually provided a lot of theory but no practice. So that was the real intent behind that. And that really drove into three areas. Page 13 of 15

14 The first is viewing program management as an extension of an organization s business management function. The fact that program management is really about the business. And to not think about it so much as an extension from a project management perspective. You really need to think of it from a top-down perspective, versus a ground-up. Second thing we wanted to bring into play is to explain how then program management actually differs but is directly related to the other disciplines. Like project management, portfolio management, and product management. How do these all play together from a program perspective? The third area that we focused on then was, Okay, the tools and practices for program managers to actually utilize in their jobs so, we ve got a lot of material in there that talks about practices. How you actually conduct yourself and conduct your team as you're going through a life cycle, and what tools and methods do you use. Not your typical project management scheduling tools and stuff like that, but more at the program level where you're focusing on business goals and integration, a lot of work output. And then finally I think the last piece that we tackled was this whole area of skills and competencies that you really need to consistently succeed as a program manager. So anybody can succeed, I think, on a one-time basis. But to really consistently deliver from a program management perspective you need a much broader skill base and competency that you get in typical project management training. So those are the key ideas that we wrote into the book. You also founded the Program Management Academy. What was the motivation for starting the academy, and what are some of the programs you offer? Yeah. So that s really been a [Laughs] growing motivation. The original motivation was to provide, really, a website and a means for people to reach us once the book was launched. So that was really the impetus. But as that started to actually occur, what we then created was a means to actually provide training and some hands-on support for people and organizations that were either wanting to increase their program management capabilities or move into that area. So it really then has grown into a training and support organization. Then the third piece of it is continuing to do research in areas that are problematic for companies and organizations and continuing our writing in those areas. So we released our second book earlier this year, which is really focused on the challenges of leading globally distributed teams. And it s entitled that Leading Global Teams: The New Management Challenge. So, providing a portal for people to contact us, providing a means for training and support, and then continued research and writing really, about the three motivations for the academy. And what are some of the programs you offer? Page 14 of 15

15 Well, we have a suite of both public and private training programs that we offer. So those are around program management and strategic management capabilities. We also support hands-on consulting and training, if that s what people are looking for. And within the academy, we actually have a community. It s a Linked In community where we ve actually linked up folks around the world to talk about program management and discuss it from a discipline perspective. What type of programs are you working on these days and what's next for you? Well, let s go back to Intel. So I m currently leading a couple programs. And they're really based on best practice research studies. So the first program is best practice research study on how to pull user experience knowledge into the product development process. So there needs to be a balance, we re learning, between technology push but a balance with user experience. So, developing our products based on technology and usage. So we re in that phase right now. We re collecting best practices from other companies, we ll pull that in. The second program is very similar. It s actually another best practice study that started two years ago. So it s much farther down the cycle. It s really focused on technology transfer. So, how do we more effectively transfer our technologies from our internal technology sources into our product development groups? We ve collected best practices, some learnings, and now we re in the Implementation phase, actually implementing them across the company into product development teams to make that technology transfer happen more effectively. Those two things are keeping me quite busy. [Laughs] [Laughs] And how can our listeners find out more about you and contact you? Best way to do it is contact me through the Program Management Academy. So that website is ProgramManagement-Academy.com. And a link to me personally and my is actually in the website there. But for those of you who don t want to go that route, it s Russ.martinelli@ProgramManagement-Academy.com. And check me out at Linked In as well. Russ, thank you so much for taking the time to speak with us today on the Guerilla Project Management podcast. I really appreciated it, and I look forward to future conversation with you again. I would love to talk to you about your new book, Leading Global Teams in a future opportunity. You re very welcome first of all, and thank you for the opportunity to speak with you again. Page 15 of 15