[MUSIC] >> Hello and thank you for joining us for a final segment of the project management panelist discussion. My name is Stephane Muller and I'm the Director of Business Programs at UC Irvine Extension. Discussion today will feature managing project risk and changes. Lets meet our expert panelists. Please meet Marty Wartenberg. He has spent over forty years managing companies and projects in the areas of aerospace, software, commercial product development, oil field instrumentation and farmer research and development. Next, we have Neil Sahota. He's an IBM master inventor, an Ecosystem Engagement Manager in the IBM Watson group. Finally, we have Karen Nguyen. She currently manages Kia Motors Americas Enterprise B2B portal consisting of 70 dealers facing system. Thank you everyone for your participation today. Let's begin. My first question is have any of you lead a project with no formal change control process? Please explain your experience. >> In a, in a lot of small to medium size companies, they don't have a formal change control board or the concept of CCB or management change board. And what I've tried to do is implement for the project, a project change management procedure. You have to be able to manage change. I've introduced change control pages where when my customer says, I'd like you to make a change, I hand them a chance to write it up and they'll remind me that you work for me. So, I said, okay, I'll write it up. And I want to get an agreement and would you like to sign it? And nope, well, let me remind you again you work for me. Well, okay, I'll sign it and I'll put a note that you and I discussed this change. It's called CYA, you've got to cover yourself and you've got to make sure that you make and you need to make the change difficult. If you make changes too easy and you allow changes to occur on a regular basis, then you're going to get changes on a regular basis. So you have to sort of force your client, even though you don't have formal CCB and formal change management to at least think about that fact that, yeah, we have to look at the, we have to evaluate the impact of the change. Then we'll come back and tell you and if you choose to approve it, we'll put that in writing and we'll put it into the baseline. >> And I find that even small or big, I think within your own team, within your own division, you may not have change order actually change control. And what I do is the number one thing I look for when I come into a project is, is there a standard operating procedure? Is there a technical style guide? Is there some kind of workflow? If they don't have it, that is the very first thing I do. I do that and then I translate it to a combine board, right? A combine board is something that it tells you by milestone and then deliverables. So the reason I do that is not necessarily basically, covering for myself, it's really to have a consensus where everybody follows that procedure and you can guide that procedure. Something where everyone knows, okay, this is the process that you're supposed to do. Whether you're making changes, whether you're adding to the requirements. That is what I do to help with the scope. >> Thank you. >> Look, I mean, today, there's always a formal change management process and that's, just how we do business. We won't, if there's, we go into a situation like a client doesn't have one, we'll actually install one. But if I look back to the start of my career back in the cowboy days of project management. Yeah, we there's, was often no change processes, no formalize or even informal. But I quickly learned that at the very least, you've got to document what's been going on. Put it in an email and then shoot everyone a copy of it. And I understand that, you know, there's, there's small projects, there's small organizations. Speed to market might be a critical thing. You don't want to waste time on a lot of, you know, bureaucratic processes that might slow you down. But even in those cases, you gotta figure out what those small things are, because you just cannot escape doing a project without some sort of change manager process in place. >> Thank you very much. My next question is can any of you speak to rescuing a troubled project? Please tell us about your experience. >> The companies I worked for, we call, we call that thing parachuted into a, a hot fire zone. [LAUGH] You know, basically you're thrown into a project, because the project manager was fired and the project's a disaster and you're told you gotta recover it. My experience always and what I will always do is stop the project for a couple of days depending on the complexity and size of the project and say, we're going to evaluate exactly where we are. We're going to go back. You think we're 70% done and we've completed 22 of the deliverables. What have we actually done? So the first thing I'll do is actually do a assessment to determine how bad off are we and then I'll take it to the next step of saying, okay. Here's what we have in terms of time and money how much scope can we take out and still and be able to deliver and it being useful. And again, you get a, a lot of push back from your sponsors. because they still want everything and you can't have any more money, you can't have any more time. Well, life isn't about like that. If there's a realism, you can't pull a miracle out. So again showing what the realism is of the situation that, yeah, we've spent 70% of the money, but did 15% of the work. That means either make more money or we start pulling scope. >> And restoring a project is more common than people think, because project management is very volatile and it's always changing at every phase. And so, I had one where I was just hired into a division and the company was going from flash-based technology to HTML5. And for those of you who are doing course development or training, what that means is that you're converting something to a desktop to a tablet, so that, because our world today is, and you can go anywhere. You can go to a paint shop and then they have a tablet, what you can do, even Home Depot. Right? You can do everything on a tablet. So that's what we're trying to do in our retailer world is to convert that to tablet. So they can take their tests, get their knowledge, get their credit all right there. So what we did, what I did to rescue that project is it was one of those most riskiest and intensive projects I've ever been in, just because, especially in automotive. You can't have a product out in market, a car out in market and technician and sales consultants, don't even know the product. Right? Like, so can you imagine the risks? So here it is. We have all these courses out there that is not ready to go into development. So what I did was I pulled all of the vendors together. I believe there's 15 of them and they pull all the technical and they're all over the world and all over the US. And then we would just have a daily scrim, every day quickly. Just describe where we're at, and then an afternoon, what I call tactical meetings issue and resolution, what's the issue, what's the resolution? And I will break that into pieces, and I will level, like, high priority, and we will go through that one by one, one by one, until it gets solved. And then eventually, that we got the course out. >> Excellent. >> Well, I think we all have a disaster story in our back pocket. We actually had a project working with a client where lot of, lot of mistakes were made up front. It was not scoped properly, improper standard requirements, client didn't fully understand what they wanted or needed. Unfortunately, there also been commitments made to their shareholders very publicly about when, about dates and things like that. And the, the project went red really quickly. It was literally hemorrhaging millions of dollars a month. And I got, after six months, I got called in to lead a tiger team, come in and do the, you know, get back to green. Planned with the client. And again, doing a lot of things that like, Karen and Marty are talking about. But that's only one piece of the puzzle that I saw, right? You know, can you figure these things? How can we get it back on track? Another thing I realized was, how do you rehabilitate the project team, right? They've been living for six months in this nightmare. You can't just say, like, well now we have a better plan, now we understand what's going on. You know, good luck guys, it'll be a lot better now. That's just not going to work, right? And because we just didn't stop the project and say, we're going to scrap everything and start from, over, you can't just re, replace everyone on your project team. So one of the things I actually had to, focused on was, how do I rebuild the confidence of these guys that, it's literally has been shattered? That, you know, they, they saw, you know, people get the Standish Group's KS report, the top ten reasons why project fail. They saw seven of them. So, really sat down, work with the team. It, it took probably about a good six weeks worth of work and coaching them. And showing them what we're really doing for them to understand that we aren't not just gon, it's not just a plan to get back to green. It's something, it's meaningful, and we want to help you guys be successful and get that confidence back. And luckily, we were able to do that and turn things around. >> Thanks a lot. Marty, can you describe a time when communication between you and your stakeholders broke down? How did you try to remedy the situation? >> When you have a lot of stakeholders, it's almost guaranteed that you tend to concentrate on the ones that are most supportive of your projects, and you tend to ignore the ones that are negative. And those are the ones that usually cause you your problems. And so, you know, when you build your stakeholder register, you, you're careful, in stakeholder matrix, you're careful to know how often you'll have to contact these people. So, there are times when, when they start to break down, you may move somebody who may be a once a month report to once a week. Or get them more involved, or take the extra effort. A project management the role is very, you know, as Neil said, we're cheerleaders sometimes. Sometimes we have to be a little bit more autocratic. Well, sometimes we have to be the social interface between the project team and the stakeholders. And so, my approach is always to get them involved. I'll make the effort, I'll go to them and talk to them about what's going on on the project, and apologize, of course, if our communications are broken down. But again the, the best thing is not to let it happen, is to maintain your stakeholder communications plan. Keep that up to date. Make sure that people, you, and you follow up with them, make sure that they are getting inform, the information they need when they need it, and that you're ha, having sufficient time. I guess one of the things in the PMBOK, and we tell our students when they're taking the PMP exam, the question's asked, how much time does a project manager spend communicating? Don't try to memorize the answer, just pick the highest number. It's 80 to 90%. That's the project manager's job, communicating. And communicating with stakeholders is a major part of that. >> Thank you. Neil, can you talk a little bit about when you identified risks in a project, and when it was important to develop a contingency plan? >> Hm. That's, that's a good question. Again, every project is inherent with risk, and I, I just want to make the point that risk is just an uncertain event. It can be a negative impact or a positive impact. And we tend to overlook the positive impacts. So recently, I've actually been working on a merger acquisition project. And, one of the things that we actually brought up with our client was, there's this risk that people are going to leave. And, you know, okay, yeah, we get that, but that's going to happen anyways. Well, as with any organization, you get a lot of tribal knowledge build up, so if you start losing key people, what's going to happen? And so, the contingency plan was really to build in this kind of retention pool, that if we thought the key researchers were going to leave, or they did leave, we had a pot of money we could pull out and offer them incentives to stick around. Conversely, I also said that, you know, as you're merging your business processes together, you know, you're, you're basically trying, you, you should, their approach was, we'll pick whichever one we think works best, right? I said, I get that, but you're missing out on a positive risk that maybe both processes are, are not so good. Maybe it's an opportunity to develop or implement a new haul, a new third process. And for that, again, you need to come up with a contingency plan on how do you identify that. And if that if you see that opportunity, how do you actually take advantage of it from a resource and schedule standpoint, as well as the cost? And that was actually something that they hadn't even, hadn't even thought of. And as we were actually going through that process, a lot of things that were broken on both sides actually wound up getting fixed when the company got combined, because we actually took time to do that. >> Very good, thank you. Karen, can you talk about a time when you experienced scope creep on a project, and how you get things back on track? >> I think all of us can experience scope creep in every project. As a good project manager, what you need to do is control and minimize those scope creep is the inevitable. And I think Neal mentioned about trade offs, right? Sometimes if you have a scope creep, you have to really determine if you could do those trade off, and if it is still within constant time, because those are probably better value, right? I mean, in when you originally set forth in the requirements, those value come into play that you probably missed in the beginning. So how I handle scope creep, a perfect example is, we, when we launched that enterprise, it was for desktop and tablet. And we did not have sufficient budget to call out for mobile. And the enterprise was so fantastic ly built from a UI front and from a UX, which is the user experience, that they wanted to translate that to mobile. Can you imagine telling the executives, well, we cannot have that? So, Marty says, communication is key. And how I handle that is, the worst thing you want, because you're already in a volatile situation, and the worst thing you want is to have them rally and said, we want this, we want this. So what I do is, I call the, I break the stakeholders separately. So I break, I break it with the exec, the executive team, the vendor, the business unit. So, and then I communicate those separately from different messages. Whether it's in writing or whether in verbal, you try to explain that. And then. Because it's good value, we also capture it for later release. And that is actually a good opportunity for you to come up with a statement to get funding for next year to enhance that mobile. >> Thank you. My last question today is why have you found it so important to document your lessons learned on a project.? Well, I probably should go last on this one. But I have found, unlike a company like IBM or Boeing, that makes a great effort in capturing lessons learned and having a database where these could be pulled out by other projects, most organizations it's buried. Or by the time it's done in a multi year project, or even a year project, the people that caused the problems at the beginning are no longer there. Nobody wants to talk about lessons learned, I want to get off to my next project. So what I've adopted, again like Karen, I like to use Agile a lot, and Agile methods are at the end of each sprint, which could be 10 to 20 days worth of work. We have what's called a retrospective, so we have a lessons learned every couple of weeks. And this way, what we learned that we did right or we did wrong, we could actually implement on the project we're working on, not just for the next project. So I've adopted the Agile approach of retrospectives on my regular projects, whether it's traditional or Agile, and though, I don't do at the end of a project, a big lessons learned, it's an accumulation as the project rolls along. Thanks a lot. Karen? >> And like I mentioned before like Marty says, not a lot of companies have lesson learned, and a lot- not a lot of project managers have lesson learned, because that's icing on the cake, and that requires a lot of writing and a lot of work. I would love to have a more sophisticated company that focuses like, Neil, I'm sure you have slew a of that. We don't have that. And like I mentioned before, as a good project manager, it is your due diligence to try to do that. Even though that's not the culture, that's not the company, but because you are certified as a project manager you know that that's something good to have. So I use lesson learned in two folds. One, is to help other project managers and your colleagues, to do projects better in the future. I'm open to sharing good knowledge and good databases. And two, is to, it's like a case study, it's to really advertise to others, this is what it really take, this is what's behind the scene to get this end goal. And so what I do is, I wrote I had the team write probably a 15 page lesson learned. And it is, again, back to stakeholders because you don't want this to just be your side of the story. So I asked my senior project managers to go to each user community, the technical group, and ask them for lesson learned. The project manager and ask them, the executive, the sponsor, so it's a collective group of, like I said, case study. And I find that to be very helpful and also for the organization. As a matter of fact, I think Microsoft wants to do a case study on this particular project and they have asked us, actually just yesterday, if they could do that and so. >> Thank you. Ian? >> I think great points here, and lessons learned should definitely to be an ongoing process through out the project. The, I think the real value of documenting though, is if you're starting a new project, right? The, the team and I, we get together, looking at the scope, looking at, trying to work out what the requirements are. How do you leverage that past thing? because if they're not documented and the documentation is not usable, you're going to rely on tribal knowledge. And that's the big problem is then, are you talking to the right folks, or even aware of who the right folks are? And I, I've walked into a lot of situations where, I've actually heard from people they're like, we're doing this and maybe you should talk to so-and-so, or talk to that person, you start finding out a little bit more, a little bit more, a little bit more. And in some cases it's not the first time, like the, they may have tried to do this particular project even. But it's all, again, a ethereal out there. It's, people memories fade over time, they're maybe opinionated, the perspective might be that slanted. You don't get the full scoop and you might wind up making same mistakes that were made before. So that's I think the real value, again, document and lessons learned. We also document in a way that it's actually consumable by people. >> That was insightful, thank you everyone for a great discussion today. That's it for our three part Project Management Panel Discussion Series. We hope that you learned a lot from our expert speakers. Thank you for joining us. [SOUND]
