[MUSIC] Hello, and welcome back to Part Two of UC Irvine Extensions Project Management Penalties discussion. I'm Stephane Muller and I'm the Director of Business Programs. Today we will be discussing budgeting and scheduling projects. Let me introduce our expert panelist. Please meet Marty Wartenberg. He has spent over 40 years managing companies and projects in the areas of aerospace software, promotion product development, oil field instrumentation and pharma research and development. Next we have Neil Sahota. He's an IBM master inventor and ecosystem engagement manager in the IBM Watson group. Finally, we have Karen Nguyen. She currently manages Kia Motors Americas Enterprise B to B portal consisting of 70 dealers facing system. Thank you, everyone for your participation today. Let's begin. First question today. For a new project manager what is the most important part in creating a budget? >> I, I think what, one of the first things you do when you create a budget is never give your boss a number when they say it's only a budgetary, I won't hold you to it. That's fraught with danger as many Dilbert cartoons will, will tell us. To me the most important thing is to take the time to at least build a first cut at a work breakdown structure and do a, at least get a cut at doing a bottoms up estimate before I build a budget. We can't jump into numbers too quickly before we understand the scope of the project and how much it will cost. And I think we need to force our own bosses to give us the time, to take to spend the effort to at least, and I, I'd like to build at least the first cut WBS before I give anybody a budgetary estimate. >> Thank you. Carrie? >> And similar to as you know, budget is closely tied to a statement of work deliverables. Requirements is so important specially when you're working with enterprise globally, nationally to really, really understand what it is and even as a seasoned project manager and you know this, Leon and Marty, sometimes projects can be so intense and so hard that it's really hard for you to define requirement especially early on in the stage. So, I would try to, I rely a lot of those on the technical expertise in that area and then my core team to really understand the requirements very well before you even begin the budget. And then when you do the budget to go back and have a second phase, and do the comparison between requirements and the budget. Because once you start the project you're going to realize the scope, it's inevitable, will continue to grow and it's your job to make sure that not only do you have to deal with budget, you deal with scope, you deal with time, you deal with all that. So I would very, very, again, closely pay attention to the requirements and what the contract calls for. >> Thank you. Neil? >> I would, I would add on actually that understanding the trade offs. As a project manager, you need to understand what the trade offs are for the budget. You're going to find that you never have enough money to do everything that you want to do and the team would like to do. And you gotta understand where the value comes from, what's really important for your customer or for your client. And I've seen too many times where you go through the budgeting process and you go through the iterations to refine it but there's a, the numbers, the number you hear, and so what the project manager sometimes will do is try to, you know, we call it cutting the bone. Basically cutting out things that you actually need to make the project successful, actually deliver the value trying to do. Rather than coming back and saying look you know here's the tradeoff and by doing this, this is what's at risk. And I think that's the really crucial part for being a project manager in the budgeting process. >> Thanks a lot. My second question, starts with Marty. Can each of you discuss the most accurate estimating you have seen and why? >> Well, I worked on a project where I came in on a, on a very, very large multi million dollar project within about a $15 something, final cost. But it was a letter contract, which meant we negotiated the price after the contract was over. So that, so the most accurate is to wait till the project's over, accumulate your costs, and then go back. because you know the least at the beginning and the most at the end. But what, in terms of methodologies. We teach several different methods, an alocus method, parametric, bottoms up. What I've been finding over the last few years is using some of the agile methods of range estimating. The poker card approach is turning out to be as accurate as some of these other methods that we've been pushing, analogous or historical. So I've been moving towards multiple approaches. I never come up with an estimate based on one approach. I'll do a parametric estimate and then I might do an analogous. Or I'll do a bottoms up and then I'll compare it with historical data and if they're close enough, I'll take the higher number. If they're wide apart, I'll reexamine all my suppositions and all of my inputs, to see what, what mistake did I make? >> Thank you. >> Yeah, that's way too intense for me, Marty. [LAUGH] For a more simplistic answer for that, in my experience, I do think that it's a industry, right? If your defense, if you're in bureaucracy, energy, those things are, budgets are more accurate and to the T. But when you're in a different industry like mine, not that budget's not important, I think that we focus on other things, and so how I deal with accurate budget is I do monthly accruals. So, every month, and you sit together with your project managers and your finance person and you look at what you've spent so far. And you try to accrue of what you've spent so far, and then what you're going to spend the following month, and then you do this month by month until you get to the end of project and then we are held accountable from our organization, our parent company from Korea as well, to be as close as possible to those accruals. So you can't accrue, for example, if you know your next deliverable is in design, and you know you're going to spend a 1.4 million, but you came in about 700,000, that's not good estimating. And it's really important to estimate that not only for me, specifically, not only do I look at the span or the year to date, month to date, I also look at similar projects and projects I have done the previous years so that I can have a good estimate where is it trending. As far as what's coming and risks, I take all that into consideration. >> Thank you. >> Both, both good answers, both good perspectives. We actually leverage a lot of our lessons learned. So we actually have tens of thousands of projects that we pulled upon. We actually have very detailed estimating models that are both top down, bottoms up. And, it's, we've become a science, at least within IBM, to do that. The, the other thing is, even when we do something new, or something unexpected, we still try and apply those type of models, to see how we can leverage, best leverage them. One of the key things though is, we add an element of risk management actually to the estimation process. So there's actually a separate risk management group that their job is to actually question how we're doing the estimates and kind of force us to say, are you really doing this right, are you taking any shortcuts, did you think about this? And that's proven valuable, especially given the size, scope and complexity of some of these projects. If it is actually a very large, complex project we'll actually run Monte Carlo Simulations. So I've actually worked like on, on proposals where we look at what we're proposing and we'll come back and we'll be told, well, you might have a 90% you'll be successful, you might have a 9% chance you'll be suc-, successful. And kind of re-swizzle based off of that. So I think a lot of good stuff, definitely leverage lessons learned for estimating. >> Thank you. My next question is when creating a WBS, do you use phases or deliverables and why? >> Like many answers in project management, that depends. If you're in an aerospace company, under military contract there's a null standard, 881c, that drives what the WBS will look like for your deliverable, whether it's a weapons-system, what kind of platform it is. In commercial world, in construction and software, we tend to do it by phase because that's how we think. Starting out with the initiation or prototype, pre-prototyping or analysis and then, flowing it from left to right unless you're an Arabic country where you go right to left. And flow the work. The pro, the WBS will float from left to right. The benefit of that is it allows you to convert it to a schedule fairly easily. You can actually float chart it on your whiteboard, and move, move it around and put lines between it and you actually have a good pertinent work that you can develop quickly. There are other benefits to doing it by deliverables, and you can, you can again, as long as you're not working in the military, you can combine the two and come up with the best of both worlds. Whatever makes sense for your project. >> And we talked about stakeholders earlier on. Because of the various stakeholders and the ability to satisfy those stakeholders and everybody. And you talked about people, right? Everyone have different needs. I do both. And for the executive top down, I do phases. They don't want to hear deliverables. They don't want to hear complains. They don't wana hear anything. You talk about deliverables especially in IT development in Agile. You state your deliverables and where you're at, and then for the core project team you stay, I'm sorry, for, for top down, for executive you state phases where you're at. And for the project teams you have to state deliverables, and people accountable for those deliverables, because again, that goes back to managing budget, managing schedule, managing risk. >> I'm going to steal Marty's thunder a bit, I think it depends is the perfect answer, and that's, that's what we do. We use what makes the best sense. And I think this also ties back to the actual planning approach that's really going to drive how we really created WBS. And sometimes it is by phases, and sometimes it is by deliverable if the, especially if that's what the client or customer is looking for. Or it could be by something else like, if you, we, we do merger acquisition work. We actually tend to do it by business function, so again, I think it just depends what makes best sense for the project as well as your stakeholders, consumers of the information. >> Thank you, Neil. Can you please discuss one of the most common pitfalls project managers make when creating a schedule for the project? >> Of the many pitfalls probably one is not taking into account the precedent relationships and the constraints. For example, I've, I've had project managers because a, assembly people were available,. They scheduled assembly work before the parts arrived. It was convenient, or if I have a four story building and I have the fourth story rented, I am going to build the fourth story first. Forgetting that there are certain relationships that are natural constraints and there are legal constraints and not taking into account all of the constraints. A, building a constrained schedule is basically worthless, because it can't happen. Assuming that you have all the availability, all the people you need exactly when you need them. And you can drop them off your project when you don't need them anymore. So I think not taking into account the actual constraint on you legal, natural, logical and, though some by government regulation, will, will screw up a schedule badly. [SOUND]. >> So my advice, always as a season project manager, is always to go back to the basics, and a lot of times, especially for even seasoned managers. I think just scheduling in itself is a nightmare and I would say, to understand, first and foremost, before you do a schedule is the format. Depending on your company, your client, your industry and especially your organization, what format did they use. So we had a project that is so huge, it's an enterprise to build 70 retailer facing systems and we had over a 180 pages worth of chart. And months and months of work and keeping up with it and as you know chart is just tedious. But even in the end, it's useless because no one understands it. Nobody knows how to read it. My organization definitely do not go by Gantt chart. So we had to quickly go back and do it in Excel or do it in Word. I think, most importantly, you should ask yourself first, what is easiest for your organization or your stakeholders or your clients, as far as receiving deliverables or phases or schedule. So, I think that is key. >> I, I'll chime in and say that there's an old adage in project management. Plan the work, then work the plan. And I think it's the second half that kind of gets lost at times. Unfortunately some project teams look at, plan the work as just an exercise they have to do, like a checklist item, and then the project plan becomes like vaporware, just put on the shelf and forgotten. They're not actually working the plan. That's one of the things I, I would always advise, especially when it comes to scheduling is that when you put the plan together it's not just meant to be a thing you have. It's something you need to be able to actually execute against, and I think, as Karen was talking about, it's gotta be readable. It's gotta be kept up to date. It's gotta have the dependencies. But it's gotta be something that the entire team will actually use. Because that's really going to be your blueprint for executing the project. >> And I want to add to what Neil said, keep in mind, I think, first and foremost. And I think Neil mentioned it. Throughout your entire projects, every single project needs to have this value. What we're doing for success is value. So whether it's in budgeting, in schedule, that is key. And you want to show value because that's how you earn your trust and ultimately win your project. >> One other thing, when we teach scheduling in our classes, it is always a shock to our students. I don't know why it is, but it is, when we show them that when you are calculating duration, which is the toughest thing for project manager to figure out that how long should something take, and we teach our students that you have to take into account, not only the availability of the people,. If you have a 40 hour task and you're only available 20 hours, it's going to take you two weeks and you better schedule two weeks. But also the efficiency of the work force, and that if you don't take those things into account, you end up with a non-realistic schedule. And I think I've heard students tell me that just that little tidbit of information [LAUGH] makes life worthwhile for them. >> Thank you. My last question for the group is can each of you speak to quality and what effort you dedicated to a quality management plan? >> That's a tough question because outside again, outside of large aerospace projects, I have never really done a quality management plan for a commercial type project. What I concentrate on from the quality aspects of a project are developing the metrics, and I, I look, I look at two kinds of metrics. One is the exit criteria, success criteria metrics. How do I know my project was successful? From a business analyst point of view I have a set of requirements. How do I validate, verify that or test for the requirements that they've been met? The second thing I look for is what in aerospace is call, is termed technical performance measurements, TPMs. These are measurements that you measure, just like we measure schedule. We know where we are. We measure how much we spent. Well, performance measurements are, how do you measure the quality aspect of the project, that third element? And this, we find in a lot of projects is underused. People don't track. So you can deliver on time, on budget but what you deliver is waste. So, for me quality is basically that I'm tracking the values part of the project, the quality aspects. >> For me, quality is what I try to do is I do multiple layers of validation and testing. And so what I do is, and especially in the IT world, where what I do is, I have my technical team, do a first wave especially off shore, first wave of QCing. And everybody knows my standards, and this goes back to leadership, right? And using your project manager role. So I expect the quality, is all tested and fully validated before it comes to our team, which is obviously the onshore and the core team. And then from there, because time is such a factor and everything is so busy and especially when you're dealing higher up in the executive seed level, you don't have the time with them. So what we try to do is use their let's say directors or national managers and we sit in the room and we do what we call a group UATF, found that very successful. So this is after the first wave have been validated from a technical perspective. Then we go in and we look at the high level of the technical and then we evaluate the business. Again, it goes back to value. So after you look at the testing completion, you look at it. Okay, that's, that makes since from a value perspective. Since the project, I usually run my project on Agile, you can quickly make a change without impacting cost if you can and that's what we tend to do. And once everything's good, we do it per milestone. And everything's good, then we move on. And that's how I know that it's quality. So you have check, so think about it, it's like check points. So you know that you have met those criteria. >> We actually always have a quality management plan. I mean, we, we kind of have to when we're working with partners or clients. The quality of management is, I think beyond just like simple metrics and things. It's something that you need to outline like Karen was saying in terms of like inter reviews and things. But he also helps us align expectations with the actual work, right? If, if you're like a retailer that's looking for a game changing mobile app, you know, you're looking for features x, y and z, like Marnie was saying, you can deliver x, y and z, but if the color scheme you use is neon green and hot pink, what's really the value again for the, for the, for the users, right? I mean it's going to be unreadable. So it's those kind of little things that, you know, I know that's the extreme case but it's kind of those things required it come into play. because at the end of the day you want to be able, you want to produce something that people will actually use. >> Thank you very much. Thank you, panelists, for joining us today. This has been a great discussion. That's it for part two of the project management panelists discussion. We look forward to next time when we will be discussing managing project risk and changes. Thank you for joining us. [SOUND]
