April 4, 2016 | Time: 1:00:30 | Subscribe in iTunes
In Advances in Project Management Part I we looked at how PMs are really investment managers. In this episode we extend the discussion to look at techniques in getting the value achieved.
From risk-based analysis of the WBS to determine the effectiveness in enhancing value of each project activity, to the project leadership needed to unleash the power of the team in delivering products, to accepting and demanding that some of the accountability for project value belongs with others beyond the PM, this episode looks at the next level of getting value out of projects…beyond the PMBOK®.
Listen online or read the full podcast transcript below.
About the Speakers
Fortezza Consulting, LLC
Principal Consultant & Founder
Mike Hannan is Founder & Principal Consultant at Fortezza Consulting, a management consulting firm whose innovative techniques help organizations achieve dramatic improvements in project portfolio performance. Mike brings nearly 25 years’ experience as a Consulting Executive, IT Project Portfolio and Program Manager, Process Engineer, and Software Architect, and still doesn’t know what he wants to do when he grows up. His background in Project Portfolio Management (PPM) started at NASA in the early 1990s supporting large, complex initiatives such as the International Space Station and High-Performance Computing & Communications (HPCC) programs. Since then he has managed and consulted on $500M+ project portfolios, and trained CIOs and other senior executives in Federal Civilian, Military, and Commercial environments. He is also the author of the recent best-selling book, “The CIO’s Guide to Breakthrough Project Portfolio Performance.”
ICT Management Office, JGC Corporation in Yokohama
Japan General Manager
Dr. Tomoichi Sato is General Manager of ICT Management Office at JGC Corporation in Yokohama, Japan.
Born in Tokyo in 1956, he majored chemical engineering at Tokyo University. He stated his carrier in JGC as a process engineer, and later became schedule engineer/project manager/PMO member in the plant engineering and the IT development fields.
Since 2007, he privately started research work on PM theory and established a theoretical framework called ‘risk-based project value (RPV) analysis.’ Using this framework he has published a series of academic papers in domestic and international journals. In 2009, Japan Industrial Management Association awarded his first article as the best research paper of the year. He obtained doctor degree by his study in 2010.
He also teaches PM courses at Tokyo University Graduate School and Hosei University.
He wrote several Japanese books about PM, time management, advanced planning & scheduling, bill of materials (BOM) and supply chain management.
Blog: http://brevis.exblog.jp/ (mainly in Japanese).
Organizational Project Management Improvement Consultant
Joseph A. Sopko, PMP, MSP, P3O is an organizational project management improvement consultant, trainer and a joint recipient of the 2013 Shingo Prize Research Award as a contributing author to The Guide to Lean Enablers for Managing Engineering Programs.
With over 25 years of active project and program leadership experience in large and small organizations, Joe has served in a wide range of operational and project leadership roles both during his career in the US Navy and in the commercial sector, including eight years as an organizational improvement consultant at Siemens.
For the past ten years, Joe has had considerable involvement in organizational project and program management infrastructure development and improvement initiatives including global standards development and advisory committees with PMI, APMG and ISO.
0:00:05 Tomoichi Sato: When we successfully complete an activity, then expected value of project will increase.
0:00:14 Michael Hannan: The system knows its own capacity better than a manager of the system. And so if you allow the system to govern in its own pace of work, you will get much better flow.
0:00:22 Joe Sapko: If you run a program like a project, you'll have a lot of nice, shiny stuff.
0:00:28 Kendall Lott: We know that project management does not begin and end with the PMBOK. As we develop new insight into risk, teamwork, systems, and communication, and as our technology advances, our planning and execution needs change, and so must our approach to project management. For this podcast, I spoke to three practitioners and thinkers coming at projects from three different points of view on the subject of risk, teams, and programs.
0:00:51 Speaker 5: From the Washington DC chapter of the Project Management Institute, this is PM Point of View, the podcast that looks at project management from all the angles. Here's your host, Kendall Lott.
0:01:03 KL: Sato Tomoichi is a lecturer at Tokyo University as well as a full-time employee of JGC Corporation, the largest engineering contractor in Japan, where he oversees IT development activities. He has written extensively on risk in terms of maximizing the actual dollar return on project investment. I was able to read a couple of his fascinating, but yes, academic and somewhat technical papers, about risk-based project value. I realized I needed him to walk me through the concepts, so I spoke with him via Skype at his office in Yokohama.
0:01:32 TS: I was doing a feasibility study of projects. My first assignment was a calculation of DCF, discounted cash flow method, and evaluation of NPV, net present value. So DCF is based on a concept of time value of money. Today's $100 later on is not the same value because there is interest rates. So we build a spreadsheet of a project cash flow and estimate revenues in the future.
0:02:13 KL: Right. This is the opportunity cost of where you could have spent that money elsewhere or saved it for interest, right?
0:02:20 TS: That's correct.
0:02:21 KL: And this is a really common discussion at the entry level of finance and economics.
0:02:27 TS: Yeah, that's correct.
0:02:27 KL: What's fascinating is you don't hear project managers talking this way.
0:02:35 KL: What did you run across as a trigger for additional thinking here?
0:02:39 TS: My idea about the concept of risk-based project value analysis was driven by one question from my university professor. Do you know the blue light LED?
0:02:53 KL: Yes.
0:02:53 TS: Yeah. That was invented by Dr. Nakamura in late 90s.
0:03:02 KL: That's Nobel prize winner Dr. Shuji Nakamura, one of the physicists who won the prize for inventing the blue LED light while working for the Nichia Corporation. This is a big deal. Blue LEDs are used in a host of devices, from energy-saving light bulbs to the backlit screen on your smartphone. Dr. Nakamura left the company a few years later and eventually sued them over his earnings for that invention. With millions of dollars in profit at stake at the time, the question of "How much value do you ascribe to project activities?" became very important. In 2005, Dr. Nakamura was awarded over $8 million, at that time the most ever paid by a Japanese company to an employee for an invention.
0:03:41 TS: My university professor, he asked me on my comment on this matter, and how do you evaluate the research activity in the entire product development project? That was really good question, I thought. So the entire project brought over $1 billion to the company. But how much was the value contribution by Dr. Nakamura's invention?
0:04:18 KL: Your research has led to a whole discussion about using this math for decision-making. What's the underlying idea here? We use net present value with activities, or we go beyond that now?
0:04:30 TS: Of course we had to go beyond that because DCF method did not tell us how to evaluate the activity's value contribution to a whole project. And after thinking a few weeks, I found that if we can introduce risk probability of failure to the evaluation or into the formula, then we can derive a value contribution of one activity to entire project. The core idea here is as we conquer risk of failure by each activity, when we execute one activity, that activity may be associated with some sort of risks of failure. And when we successfully complete an activity, then expected value of project will increase. And that increase is the measure of the activity's contribution.
0:05:47 KL: Now, does this imply that that's only for risk-mitigating activities? Or is it the sheer act of completing the project plan? So now there is less unknown, right?
0:06:00 TS: This applies to all the necessary activities to accomplish the project.
0:06:05 KL: Are we looking at critical path activities then?
0:06:08 TS: Not only critical path activities, all the activities. Because during the project planning phase, we define the scope and then develop WBS and then develop network activities. The activities we identify is necessary activities anyway, that's within the scope. And any activity are associated with risks, to some degree. Some of them are quite easy and very little risk. Some of them are very difficult, with high risks of failure. Like invention of LED device, that was quite high difficulty. So very high risks of failure. And once it is developed, and if it's commercially on production or manufacturing, then selling itself is not very difficult; that means risks of failure are fairly small. So in this way, we can decompose an entire new product development project into value contributions.
0:07:26 KL: We're basically asking inside the company to to act like a market. What is the value of each activity that they're choosing to undertake, choosing to invest in? In which case, they've probably priced it accurately.
0:07:40 TS: Well, costs and the price are two different things, as you know. And cost of research and development is a cost of testing apparatus and equipment and raw materials and so forth. These are costs. And of course, the payroll for researchers, they are also costs. But normally, we don't know the price, so to say, of that activity. Here's one dilemma: A project is a chain of activities, starting from research, and then development, and then preparation of manufacturing, manufacturing and marketing, and so forth. Now, if any one of this chain fails, then effect will not complete and they cannot get any revenue from that project. So mathematically, it's a kind of multiplication. If something is zero, then total value is zero.
0:09:03 KL: So walk us through your garage example. I thought that was a really good one. In brief, the idea of a two-person, two-activity project. I thought that was a nice way to help us understand it from a project management perspective who are not thinking in a financial perspective.
0:09:19 TS: Yeah, garage company of two people. And one guy is an engineer who made up a brilliant idea, and he thought he could build a new fantastic product with only $2,000 or so. And the other guy is a very practical salesperson, and he's pretty sure that he can find some customer who will purchase product that price of $10,000. Now, the engineer is not really sure he could really build the product because this is his first attempt, so he may think the success will be 50/50. And the sales guy is 90% confident that he could sell. And in this case, the entire project is comprised of only two activities. One is manufacturing with $2,000 investment upfront. And the second activity is sales activity, which is virtually no cost because only some phone calls and perhaps some traffic costs, and that's negligible. And if they can successfully build the product and find a customer, then they can get $8,000 margin, right?
0:10:51 KL: Right, $10,000 minus the $2,000 in what you call costs.
0:10:54 TS: It's simple. So the question is, what is the fair share between these two guys?
0:11:00 KL: Walk us through it, explain the fair share.
0:11:03 TS: Suppose they are at the middle point in their project. That means now, the engineer could successfully invent the new product. But sales man just started to find customer. The risk probability of failure of sales activity is 10%, because sales guy was 90% sure. That means expected revenue at that moment is $9,000 instead of $10,000. But that moment, they will have already spent $2,000. That means expected revenue, $9,000, minus initial cost, $2,000. So the real value, based on the risks, will be $7,000. That is the risk-based value.
0:12:08 TS: At the starting point, the expected revenue will be only $4,500, because manufacturing activity has 50% probability of failure. That means $9,000 half, means $4,500. However, they have to put $2,000 for their initial investment, for purchasing parts and materials. So $4,500 minus $2,000 makes $2,500. That is the risk-based project value at the initial point of the project. So the project's value starts with $2,500, then it increases after completion of successful manufacturing to $7,000, and finally, it will go up to $8,000.
0:13:13 KL: Does this take us to pricing mitigation strategies? If we could properly see the risk and have it reported, presumably we could say, "Here's where to add another $1,000 to your $2,000 cost, but you're gonna make that $7,000 much clearer earlier in the project. Instead of at the midpoint, you can see it earlier in the project."
0:13:36 TS: Yes, yes. What you are saying is a factor which I call "marginal cost sensitivity."
0:13:44 KL: Ah. All financial and economic analysts live in the margins. So marginal cost sensitivity is the change in the effect of reducing risk compared to the change in the increased cost. That is, for every dollar you put in, you get more value from the reduction of risk. And that measure is a measure of sensitivity.
0:14:05 KL: How does it drive decision-making so that someone has a higher return, either increased revenue or decreased cost, on a project?
0:14:15 TS: Well, at least at the planning phase. And if we can apply RPV analysis, then we can find optimum allocation of our budget to maximize the project value. So rather than, say, A or B type of decisions, allocating a limited budget and resources to that optimum allocation... Like the garage company case, right?
0:14:48 KL: Right, right.
0:14:49 TS: So if they can put $4,000 instead of $2,000 for two sets of parts and materials for the new product, then risk probability of failure will decrease to 25% from 50%, and the entire project value will increase.
0:15:10 KL: And that's the difference.
0:15:13 TS: Yeah.
0:15:15 KL: And for any of you that have listed to part one of this series, 'Advances in Project Management,' you will catch the connection with Steve DeVos' work on the golden triangle, where measuring and acting on the fastest way to get to market may be meaningful in driving up project value. In this case, decreasing risk of the unknown by completing tasks faster, that is making the outcomes known, may increase project value. The product of service has more time for productive use in the market.
0:15:42 KL: So how should people approach this? Let's make this practical for project managers. How can we apply it, and is there a shortcut?
0:15:49 TS: A shortcut? At least we need some tool to calculate the relationship between risk and activity budget and entire project value. It's not very complicated, but at least we need some sort of calculation tool. And next, we have to identity most cost-sensitive activity. That means small amount of additional budget will dramatically decrease the risks or dramatically increase the project value. And then we will focus how to mitigate that risk.
0:16:34 KL: It's kinda funny, scale matters here. On a large complex project where there are billions of costs and potentially billions obviously in value available, this would make a lot of sense.
0:16:47 KL: If you want to engage with Tomo-san on these topics, risk-based return on projects and risk-based project values, you can email him at firstname.lastname@example.org.
0:17:09 KL: If you've listened to some of the previous podcasts, then you've probably come across Mike Hannan. He seems to eat, breathe, and dream project management, and he keeps coming up with novel ways to view project management methods to improve process and overall organizational outcomes. For this episode, we talked about improving performance through single tasking, enhanced teamwork, and capacity planning.
0:17:28 MH: A lot of us might have seen studies about how much more productive we are when we're not multi-tasked or task-switched. They show almost a doubling in speed when you can single-task versus when you're bouncing from task to task.
0:17:44 KL: So let's define single-tasking real quick.
0:17:46 MH: Well, it's very simply just executing a task in a focused manner through to completion. And so a good analogy I like is, if you look in the business world and professional world, it's almost hard for most of us to imagine what that looks like because we're interrupted so much. But if you think about a well-run school, and you think about the whole organizing principle around that school is having a teacher teach a lesson through to completion before you move on to some other class, where the same thing then would happen. And so if an angry parent, or the mayor, or the governor, or any other important VIP, would call up angry and demanding to speak to the teacher when class is being given, there's no chance that that would happen.
0:18:33 KL: Their call doesn't get put through. They don't anticipate being those...
0:18:35 MH: Right. Somebody answers the phone, but it sure as heck isn't gonna be the teacher. The teacher's teaching. And so if this is something that is not advanced management science, it's something that's existed for hundreds of years, this model, then why can't we have it in everyday business world?
0:18:53 KL: Hold it. PMs learning about tasking and focus as a technique from the primary and secondary education industry? Yes.
0:19:01 MH: And so, what I began to do is think, "Those lessons typically are like 40 minutes through to completion." I have a prayer of single-tasking that if I'm a teacher. If I'm a student, I have a prayer of staying focused through that. So I thought, "Well, maybe 40 minutes." If we were to break tasks down off a typical two or three weeks that you might see on a Gantt chart, say, in project space, and get granular enough where I don't have to plan a million granular tasks, but when I get to the point where I'm ready to execute, especially in technical arenas like software development, then the individuals organizing their work begin to break it down in their heads, and they begin to break it down in a pretty granular way. Sometimes, a couple hours. Could even be something like 40 minutes, like a school. Maybe worst case, half a day or a day. Either way, much more likely to single-task that than a two- or three-week task on a Gantt chart.
0:19:57 KL: At least earlier in the project management body of knowledge, a typical example was given that you would break things down to the level of granularity that you could actually work and understand. They often refer to 80 hours, two full-time weeks. How is this different or the same, or is this comporting with that?
0:20:14 MH: So this is a further break from that. Break down from that.
0:20:17 KL: Break down from that, you're going down.
0:20:18 MH: So you would never get out of the planning phase if you had to break everything down to the level of granularity I'm talking about. And so it's a good rule of thumb to say 80 hours for planning purposes. That's specific enough. We don't want a project plan with 14,000 tasks; it'd become unmanageable. So for planning purposes, that's good guidance and it's perfectly sufficient. From an execution point of view, I have to break it down further before I can handle it. And so if I'm breaking it down anyway, and I have it in granular pieces, not only can I single-task it, but now I can begin to treat it as something that can flow.
0:20:56 MH: And we have a whole enormous, vast body of knowledge on how to improve flow. We have all sorts of things from lean. We have all sorts of things from the theory of constraints. We have queuing theory. We have all sorts of interesting management science on how to improve the flow through a constrained resource. And so if my constrained resource is my technical developer pool, and I have things granular enough that I can single-task it, which should make it much faster, and I can flow it better, and I can use flow principles to maximize, then the rest is relatively straightforward. I just have to make sure that these granular tasks are visible on a task board. I have to be able to monitor the flow across that task board from things that are on the to-do list, to things that are in process and things that are done.
0:21:51 KL: So flow has a lot of different meanings, and I think one of them has to do often with an emotional state. The idea that I'm hitting my best. They talk about flow as in when you're in a cycle where time slows down and you're...
0:22:00 MH: Yeah, you're just in the zone. [chuckle]
0:22:01 KL: You're in your zone. Then you talk about flow, the ability to move through the tasking. I think there's some semblance to what you're talking about here.
0:22:07 MH: For sure.
0:22:08 KL: But is this to manage it? Am I looking at this as the individual or the manager getting to see it?
0:22:13 MH: Well, everyone needs to be unified in a common purpose. Well, if I have complete transparency to any level about what's going on, well, then think about that. The team needs it most. The team needs to organize itself and execute things in a coordinated manner. The manager needs to make sure that's happening.
0:22:31 KL: So is this about the communication or the doing, though?
0:22:33 MH: Both.
0:22:38 MH: If you're a good manager and you have your thumb on the pulse, you have to constantly ask questions like, "Okay, where are we? Who's doing what? Are we stuck on anything? Are there any issues? Can we overcome them? How might we?" Well, a lot of those questions could be readily answered if all of our work is actually on a board.
0:22:56 KL: So you're still using something like a Kanban or...
0:23:00 MH: Kanban boards are probably the most typical one you hear.
0:23:03 KL: Kanban, a quick primer. Toyota Company's technique to perform just-in-time delivery, and now part of the intellectual development of lean processes. The Kanban or signboard process links getting resources very directly from production to the consumption of those resources. This works up the supply chain to trigger rapid response to changing demand. It's a pull, not a push, system.
0:23:24 MH: The Kanban also suggests certain aspects of flow. And while there's nothing wrong with those, I think I've found some ways that can take it even higher. If you try to execute two-week tasks or three-week tasks off of a Gantt chart, which is perfectly appropriate from a planning point of view, they tend to be pretty chunky. So not only are they hard to single-task for that length of time, but if you're gonna try and manage them as a flow, then it's kinda like if you had a bucket of rocks and you dumped them out, and you tried to direct where the flow of rocks go, but they bounce around and land on your foot, they're hard to manage. If those rocks are broken down into sand, then I can pour a bucket of sand out with great managerial control. I can direct that flow. I can govern that flow. I can stop the flow, start the flow.
0:24:13 KL: This is the flow of conjoined pieces of work?
0:24:15 MH: Yep.
0:24:16 KL: Okay. So somebody still has to keep them unimpeded or defended, right?
0:24:20 MH: Exactly. If I can look on a board and it says I've got 30 tasks open, being work.
0:24:27 KL: [laughter] And they're mine, or I'm the manager?
0:24:30 MH: Let's say it's a team. Okay? You're the manager. Okay? You got 30 tasks open. But you only have 10 guys. Are they single-tasked?
0:24:40 KL: When are they due?
0:24:42 KL: Which ones come first? Are they all due now?
0:24:44 MH: Well, they're working 30, but there's only 10 people. So we have a very clear visual way to see when single-tasking is starting to break down. And I can see for whom it's breaking down. So I can go to the individuals that have 10 or 20 tasks open and say, "What happened?" And they could say, "Well, yeah, the single-tasking stuff is great, it's a good concept, but the big boss showed up and dumped three tasks on me. And then the angry customer called and dumped two more on me. And... "
0:25:13 KL: "One of my teammates didn't do the job and has made it my problem." [chuckle]
0:25:16 MH: Yeah. "Joe got stuck on something and I felt like he needed help, so I helped him with his task and I had to take that on." And then the manager now can say, "Okay. Well, of those problems that occurred, that impeded flow and distracted you from single-task focus, what are the most impactful ones that if I were to solve, even just one, that it would get rid of as much of that as possible?" And if it's talking to the boss down the hall that dumps tasks and say, "Okay, I need to give that individual a little walkthrough on how this all works." If it's the angry customer, well, that's kinda like the angry parent calling the teacher.
0:25:52 KL: And he plays switchboard.
0:25:53 MH: Well, I need... Right. I need somebody in front of that teacher to take that call now. The customer can't talk to the developer now.
0:26:02 MH: One client ran with this so hard so fast that they realized that the biggest impediment was the managers themselves who couldn't restrain themselves by stopping by, asking how things are going.
0:26:19 KL: They've been trained that communication matters.
0:26:22 MH: Sure does.
0:26:22 KL: And that's how you keep everybody moving in the Gantt chart. In fact, we say in the PMBOK, "90% of a project manager's job is communication."
0:26:28 MH: Sure.
0:26:29 KL: Right? And we're saying, "No. We've got to decide what actually matters here." And it sounds like single-tasking is the thing.
0:26:35 MH: Well, and we're channeling the communication in a different way. We're saying, "Look, if you're breaking all these tasks down anyway, workers, and if you don't mind taking the extra five seconds and putting them on a board so we can all see 'em, and people can grab a task when they're ready and begin working it, they're assigning it to themselves with that level of autonomy, well then, the questions of, 'Hey, who's working on what?', you can just check the board."
0:27:06 KL: So is it a function of autonomy?
0:27:07 MH: Good management and good team autonomy, you need them both. If you have just team autonomy and no good management, then the inmates are running the asylum.
0:27:17 MH: Again, to make autonomy work, we have to have some structure. And whether it comes from a good plan or just the manager saying in the morning, "Here are our priorities for the day, guys." Something that sets the priority, structures the work, organizes the work, so that the people who have to go execute it have an easy time just pulling the top priority task from the top of the list and working it.
0:27:46 MH: I trepidatiously went into my first client, where this was all new and fuzzy still and I hadn't really ironed out all the wrinkles, and I said, "Look, guys, I'm not asking for 40-minute tasks or two-hour tasks. Just give me something that's ideally less than a week, and if you can, a day."
0:28:06 MH: So we started off that way, and I started talking to one of the tech leads, and I said, "Hey, I noticed that you break your tasks down into two hours for you and your team. Why is it worth it to you to spend that extra overhead?" And he basically said, "Well, in the past, I've been the bottleneck. I am the senior tech guy around here. Everyone comes to me with all their problems and questions. I'm the fastest developer. When something really has to get done, it gets dumped on me. And as a result, I ended up putting out fires and I'm the choke point. I see guys on my team sitting idle, waiting for me to solve problems for them, and I haven't been able to work my way out of it. You've now given me a way to work my way out of it. Because if I can break tasks down into something granular, I can farm out a healthy chunk of 'em, keep my team busy, focus myself on the truly challenging aspects of it that are more interesting to me anyway." He actually sets aside an hour of every day breaking tasks down and organizing work for himself and his team. And he feels like he recovers that hour tenfold.
0:29:16 MH: One of the challenges with knowledge work is we have a hard time, as managers, or even individuals in the process, seeing what's going on. And so that's why we end up spending so much time asking each other, "Hey, who's got this task?" And, "What's the status of this?" And, "How's that going?" But if we can just visualize it, not only who's doing what and how things are, but we can also visualize how it's flowing. So an analogy I use in my head is if I wanna boost the flow of water in my plumbing system in my house, let's say we got a big family that showers every morning or... Not only killing the hot water but killing the flow, I might have an easy time visualizing how to improve flow.
0:29:57 MH: If I get a wider diameter pipe all throughout my house, I don't have to see the water flowing through it to visualize easily that I'm gonna get more flow. Now, I might not get more flow, especially if there's some choke point somewhere. And then so I can see it, if my whole system is two-inch pipe, but there's one section that's only one-inch pipe, I can immediately visualize that my system is not gonna flow two-inch. And I can further visualize that if I replace that one small section of pipe, I will boost performance of the whole system immediately.
0:30:35 KL: There's a method you have underneath here, the ACCLAIM method, which implies some level of agile and lean and...
0:30:41 MH: So there are certainly critical chain components, for those who're familiar with that.
0:30:45 KL: So the critical chain components are things like...
0:30:48 MH: So critical chain was the method that really first drew everyone's attention to the importance of single-tasking. I think some agilists are coming to that now. Agilists originally didn't talk about flow; they're starting to now. But to take it to the point where you're actually pinpointing where the single-tasking is breaking down, that's where you can combine some of this agile and lean stuff with the critical chain requirement for single-tasking, and then look at it as a flow. And you can look at how to maximize flow at the task level, how to maximize flow at the project level, and then just overall portfolio performance above that.
0:31:23 KL: What's the lean component you're pulling on here?
0:31:25 MH: So there's a few aspects of lean. One of them is just, hey, lean is all about improving flow through a multitude of tools in the tool kit. I've picked a few select tools out of that tool kit, one of which is what lean calls "visual management," so we talked about visualization. One of them is what lean calls a "pull system." So that's the notion that if you try to push work onto a system without fully understanding its capacity at that moment, you will invariably guess wrong how much work it can handle.
0:32:00 KL: Right, how much it can take on.
0:32:02 MH: And so if you think of the example of being online at a bank, you don't know which teller is gonna be free next to take you, and you don't really care. You don't wanna wait on one line behind one teller, you wanna wait on the combined line because you just wanna be next. You're next, and whenever someone's ready, they'll signal you they're ready and you'll walk up to them. So they've actually set something that we've known for decades, but the pull system aspect of it is, "I, the worker, will pull the next piece of work into my cue when I'm ready, because only I know when I'm ready." So the system knows its own capacity better than a manager of the system. And so if you allow the system to govern its own pace of work, you will get much better flow.
0:32:55 MH: You have to tie this back to the actual project portfolio to make it meaningful. And so it's great to say, "Hey, we can jack up speed dramatically." But if there are some larger impediment in the way, across our entire project portfolio resource pool, then it will kill all the benefits to the speed. So I think of it as accelerating toward the stop light.
0:33:18 KL: Right.
0:33:22 MH: So the big thing is what a lot of project management people call "capacity planning" for your portfolio. I call it "project staggering." So it's a way to actually organize just the right number of projects that you can handle. If you've ever seen those traffic lights on the on-ramps to highways, especially rush hour, the concept there is we don't wanna put more onto the system than it can handle. And if we try, we're gonna really degrade performance rapidly. And so if we can do a few modest things to slow a few people down in order to protect the overall flow, then we wanna do that. And so if we get that working even half well at the project level, we're only throwing more projects onto our resource pools when we know they can handle it. Or we at least have some sense, we've got some math, we've done some analysis...
0:34:17 MH: We've made this work. If we can do that, then we can have full faith that the higher-level flow is happening.
0:34:28 KL: I'm struck by something you said. You said, "The system knows what the system needs." Perhaps we don't view the system broadly enough. Maybe the system should include, your requirements constantly change. Instead of seeing that as change, as in a difference of what we have now for which the system was built, the system accommodates that. And if there would be a way to take differences of the requirements into this system itself as part of the flow...
0:34:56 MH: That's a cool idea. I like it. [chuckle]
0:34:57 KL: You're structuring the input side on a continual basis.
0:35:02 MH: Yeah, you're checking the inputs based on the value side of the equation and how it's changing.
0:35:08 KL: We would have to find out how to get the people in the system to know that's what they need to be doing, and then let the system do it. You have to create the motivation. The tellers have to know their job, in this case, the requirements people, and know that they're supposed to call on the next person. They have to be motivated to be in game here, but it's a new kind of teller. It's a different workforce inside that same operation.
0:35:26 MH: Yeah. I'm nodding my head vigorously. [chuckle]
0:35:29 KL: He's nodding his head vigorously.
0:35:36 KL: So where does it go from here?
0:35:37 MH: There is enough out there that's common sense, but just not common practice. There are enough agilists who understand some of the team autonomy stuff, they're starting to understands some of the flow stuff. There are enough good project managers who understand the importance of discipline planning to then feed the execution. But I think there does have to be some kind of recognition that the status quo is not acceptable. There has to be almost a little bit of a revolution saying, "There must be a better way."
0:36:06 KL: He calls this the "accelerated system for project portfolio ROI excellence," or the ASPPIRE method. To learn more about Mike's methodology, you can get a copy of his book, 'The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean' at amazon.com.
0:36:35 KL: Joe Sapko is an active practitioner and trainer of program management. He is well-versed in organizational project management and has worked extensively on the topic with PMI, having served on the review board for 'Implementing Organizational Project Management: A Practice Guide' and authoring a white paper for PMI entitled 'Organizational Project Management: Why Build and Improve?' He's also a proponent of a system called "Managing Successful Programs", or MSP, which is the British standard for program management. In this system, organizational transformation is key to recognizing the benefits that projects are intended to deliver. I called Joe at his home in Pennsylvania.
0:37:13 JS: Joe Sapko.
0:37:14 KL: Hey, Joe. This is Kendall, calling about some organizational project management. Cut right to the chase. I really didn't know anything about this British system and I wanted to know more.
0:37:24 JS: Yeah, MSP started off many years ago at the Office of Government Commerce in the UK. It's the same people who brought out PRINCE2.
0:37:33 KL: That's PRINCE2, as in Pojects in Controlled Environments, another British methodology.
0:37:39 JS: One of the things that they noticed was that the projects were starting to deliver better but weren't really delivering the benefits that they were intended to do. So they dug a little bit further and realized that what was missing was program management, and all the aspects of organizational change and transformation that had to happen, as well as benefits delivery. So they came out with MSP back in 1999, and it's been around as a good tool and standard ever since.
0:38:14 JS: I got involved in program management in the Defense Department, and there, it was a given on what a program was. There was just more of a structure than anything else. And then when I got into the commercial sector, there was this mixture of what a program was. It seemed like just a complex project. And when I first was introduced to MSP, I took it because I wanted to learn how the commercial sector was running programs as opposed to the Department of Defense. And the only course that I could find out there was MSP. Then when I took it, it's just me and everyone in the room, we all looked at each other, "This is what we're not doing. We're focused on doing the work but not on the benefits of it." And when you think of things in a lean context, what you're worried about is not the fact that you're just getting the work done. Are you getting it done in the most efficient way to deliver the benefits that all this stuff is intended to do? So we end up with a value stream. And how's that value stream managed? How's it enabled? Are people adopting the thing? So I had the problem. And then MSP ended up being the solution. Then later on, PMI came out in 2006 with their standard. And I could see the alignment between the two, but MSP always looked at organizational transformation as the core of the programs.
0:39:39 KL: Part of what we're discovering as I talk with some of the other people in these new areas of advances has really been around not just doing better project management, but almost to the purposes of project management, and that's around getting these benefits. What's causing us to think that projects don't have benefits?
0:39:55 JS: Yeah. For instance, you implement a new IT system like SAP or Oracle, and the next question is, why'd you do it? So if you take a look at the fact that the implementation went extremely well, that's good project management. So it went live on time, all the features worked, and everyone's happy, and you met the scope delivery exactly as planned, on time and on budget. That's considered a successful project. Now, the next question is, are you now the best run company that you're supposed to be because you implemented these tools? And that's where a lot of people say, "Well, not really. Yeah, everything worked, but the features weren't exactly what we thought they were. And we got training to do, and I've gotta hire five more people. And a lot of people don't really understand what it is, and all the data we used to get is now in a different area." All these sort of things. That's organizational transformation that has to happen.
0:40:57 JS: It has to take this new capability and actually use it. And when they use it, are they getting the outcomes they expect? Is the data more available? Do they have more information than they had before? Is it telling them the things they wanna do? And then based on those outcomes, what benefit were you supposed to derive from that? So maybe they wanted more information about some part of the organization performance. Well, now they have it. Okay. Did it help? And what did they do with that information? If the information actually improved the organization and maybe increased their market share or their profitability, or in the public sector, delivering better, more improved service, and maybe in health care, improving the health of the people that they're serving, that's the benefit.
0:41:55 KL: So I heard two different things in there. It sounded like there is something about identifying what is the benefit that was created, in this case the availability of data, that ultimately leads to dollars. But is the program a way for us to see, collect, to modify, control, manage the benefits? Or is the program the way that we drive organizational change?
0:42:13 JS: The approach that MSP takes is that it's both of what you mentioned. It's both transformative... Because if you were able to deliver the benefits, then why did you need the new system? So there's some realization that you needed to change the system that you had to something new. Well, okay. If that alone doesn't deliver any benefits, you just changed everything. Now, are the people using it the way it was intended, and are they getting the results that... Is it doing what it was intended to do, that was the outcome? Now, that's not a benefit yet. That's just, "Okay, all the reports are coming in, and the data looks exactly what we expected as an output from this new tool." Now what are you doing with it? Why did you change the old tool? What was wrong with the old tool?
0:43:03 JS: So obviously, there was something that needed improved capability to get these outcomes. Now that you have these outcomes, you should be able to have better business performance based on that. There's always change involved in programs, because you're creating new, enabling capabilities. And when you change something, now people have to use it, and it's different from what it was before. So that change has to be managed effectively. Take the inverse of that. Let's say I just did the project side of it. I went live, everything was fine, we had a party, and everybody on the team left. Now, where's the organization? You just destroyed everything that they were used to, you gave us something new, and now they can't find anything. Even though it's capable of doing it, you didn't transition it well.
0:43:53 KL: So if you don't have a way of using that new capability, it doesn't become a benefit. It doesn't become valuable. And the only way to do that is to see this as a change of the organization that's receiving the output of the project.
0:44:06 JS: Yeah, that's the context of a program, as opposed to a project.
0:44:15 JS: What happens, every time we talk about this in front of a PMI crowd, they say, "Now, MSP starts off in their definition of a program saying that it's an organization." And more than once, people from a PMI background say, "No, no, no, no. It's a collection of related projects." Now, if you think about this, if you create a program starting from the projects, now you're trying to figure out where you're going to use them. So there's a very high probability that you may have the wrong projects there because you weren't starting with the end in mind, you were just starting with a lot of projects.
0:44:49 JS: If you look at it as an organization that was given a vision of what we needed to be in the future state and what we were intended to get out of all this, and then say, "Well, okay. To define that vision, what benefits will we get out of this?" "Oh, we'd have increased market share, increased profitability, better healthcare." "Okay, okay, great. Now, can we do that today?" "No." "Well, what's missing? What capabilities will we need to deliver those benefits if everyone used them properly?" "Well, we need this process and these tools and whatever... This building and this equipment." "Okay."
0:45:24 JS: So the gaps between the current state and this desired new target operating model is where the projects come from. So in MSP, you go from the vision to the benefits to the projects, whereas... The same thing could happen in the PMI standard. But the way it's explained is you if started with the projects first and figure out a better way to manage it, then what happens is people can't really tell the difference between what a program is other than a complex project.
0:45:55 KL: The projects feed a critical success factor of some sort. And if those aren't in place, it won't matter.
0:46:00 JS: Right.
0:46:01 KL: So it's a real call to select the portfolio of what has to be changed and then what has to be built as projects, before the investments even begin.
0:46:09 JS: Right. And you just mentioned an important word there, the portfolio. So when this all starts is that the portfolio is deciding whether the business as usual is acceptable or not. If it is, then there wouldn't be a lot of programs. You'd just be doing the work and you'd just maintain where you're at. Now, let's say the market gets stressed for one reason or another. So one of the things might be, "We have to maintain our profitability, or we have to lay off people." "So how are we gonna do that?" "Well, we can't do it doing the same thing we did back 2007. We have to figure out a different way of doing things, whether it's lean, six sigma, improving our project prophecies, or new tools, or new capabilities, or whatever. It may even be hiring more people."
0:46:55 JS: So that's what you would take a look at as far as the project side of it. But it starts from the portfolio. The portfolio is going to define a need for change. And to actually orchestrate that change, they would create a program. The program would then take a look... It's being chartered to deliver this transformation from a low-producing organization to a higher-producing organization. And this is where, in the OPM3 or CMMI world, this is where the assessment comes in.
0:47:27 KL: He just referenced two maturity models. Organizational project maturity, OPM, from the Project Management Institute, and capability maturity model integration, CMMI, from Carnegie Mellon University.
0:47:43 KL: Programs are often sold, and in fact, often described as an issue of economy of scale, in a sense. We can share resources, build common standards, common templates, that actually programs are ways to drive down the cost of doing this suite of projects. And you haven't mentioned that at all yet. You're really seeing it as, "No, they're the ones that actually... " It's not even just collect benefits, it's very specifically "drive the change."
0:48:05 JS: Right. One of the things I learned and I tell people is if you run a project as a program, you'll almost always be fine. You might have a little more overhead than you expected, for instance, around the transition point, make sure everybody's using everything and you might hang around longer than you expected, but you'll get the benefit. If you run a program like a project, you'll have a lot of nice, shiny stuff. And you may have built all the wrong stuff, because it was never targeted for the benefit and the lean way of getting there. It was targeted with around somebody's perception of what someone else might need.
0:48:47 KL: I need a program when I need change. Really, there is not another justifiable cause for a program other than a need for change in the way you're seeing this.
0:48:56 JS: Right. I've done a lot of new projects, and we always use NPV for our business model.
0:49:02 KL: Net present value of the project stream with a breakeven point. Okay.
0:49:05 JS: Right. For instance, I create a new product. And if I introduce it on the first of July, like I said I was going to, manufacturing will then start producing it, and then sales will sell it, and I have an expectation of making $20 million in sales, let's say, and that's gonna give you some positive return. However, say the project takes a year for me to make that new product, and I wanna sell it for four years. If the project team doesn't hang around, the only effect they have on the NPV is the fact that they're building the new product to a certain specification that marketing thinks we need. The program is really with marketing. Did they accurately understand the market need so that they gave you the right requirements? Because you can have a perfect project and you built the wrong thing, in which the NPV will be zero or negative.
0:50:02 KL: So let me ask then, a project manager should really always be asking, "What program am I in?"
0:50:07 JS: Right. And this ties back to Steve DeVos' concept of PMV. Let's take a new product development model again. Let's say I deliver on that product on the 1st of July, and I get $20 million in return in sales. But what if I delivered it 1st of June? And I'm first to market instead of third to market? I may get $40 million in revenue.
0:50:31 KL: Is it that the project manager should be aware of those expectations more than own them? Because they only own producing their product or service.
0:50:38 JS: Right. So what should be happening is the program manager who's sponsoring the project should be telling the project team, "By the way, if you pull this in two weeks, you will make us another $20 million. So if you have any ideas on how to accelerate this thing and get the same quality, tell me what the cost is, because I have a business case around acceleration." That almost never happens. And what I would hear a lot sometimes is, "Well, we're two months late, but that's okay. The customer was late too, so it didn't matter." Yeah, it mattered! [laughter] They may be losing $1 million a month because of that, but no one asked the question. If everyone knew that, they would have acted very differently around the execution of the project to begin with.
0:51:29 KL: So the big thing here is communication.
0:51:31 JS: Yeah, when you look at a lot of the perceived shortfalls of projects over the past 10 years, things like change in scope, lack of resources, a lot of these things are project sponsor owned. The fact that I don't have the resources I need to do the project, who'd give those to me? But the fact that the scope is changing... Well, the scope is changing, it's either because the market changed or the requirements were not right to begin with. So who gives me the requirements? Who does my chart? Well, if projects are running without the benefit of a program or portfolio management, you have no connection to business strategy. You have a lot of people trying to create something at best they think will solve the problem, but not really knowing for sure if anyone's gonna do anything with it. It's a push rather than a pull.
0:52:27 JS: MSP has a role called the "business change manager." The way programming MSP is governed is there is a program manager, there is what they call "senior responsible owner," which is essentially the program sponsor. And that person is usually part of the senior leadership team or part of the portfolio that created the program. The SRO is actually accountable. Whereas the program manager and then the rest of the team is responsible, the SRO is accountable to the C-suite or the benefit delivery and the success of the program.
0:53:08 KL: So they are the governance of the program manager? They govern the program management?
0:53:12 JS: Yeah. Right. Just like the program manager, when the program manager creates the project, the program manager is the project sponsor. So if the project is going into the week and they need to submit a change, well, who determines whether the change makes any sense? The project sponsor, which is the program. Does this help or hurt the program if I add these two features?
0:53:39 JS: In MSP, there's a third role in the program governance, and it's called the "business change manager." And this is something also the PMI doesn't have in it. PMI addresses this as stakeholder management. They realize the complexity of it and they realize that needs to be managed. But typically, the program manager does not come out of the organization as being changed.
0:54:02 JS: They're project and program experts, not operational experts. And sometimes, they don't have a lot of credibility in that area. So what MSP does in order to facilitate change... We talked about the program manager who's actually an expert in project-to-program management. We talked about the SRO who makes that connection with the business case to the portfolio and to the business strategy. The BCM is actually representing the user. Who is getting all this new stuff? So going back to the manufacturing line improvement, who's gonna own this at the end? In new product development, the BCM is often represented through marketing, because they're the ones that understand the market. So if I make this new product, what should it do? Because when the project's done, am I gonna make my sales? Or is the market gonna like it? Well, the BCM would worry about that.
0:55:07 KL: We mentioned risk and benefit earlier. We know about risk at the project level. But I'm thinking now, as I look at the projects as they are addressed or as they are required by the portfolio and as they sit within a change problem at the program, I see it almost as potential leakage of benefits. We run some risks at the program management level that the change isn't happening that allows the benefit to be accrued. How do you see the risk being handled in this model, and what can we say about risk?
0:55:35 JS: You made an extremely good point around benefits leakage because... Let's say the projects are running on time, but the market changes, and now there's a need for acceleration. So now, I need to get the project to deliver three weeks early, because we found out our competitor's actually ahead of us. Well, they're gonna go over budget. So where are they gonna get the money from? And is there a business case for that? So maybe my market share won't be any more, but I will lose the whole market if I deliver on time. So the project sponsor, who is the program manager, would say, "You know what? I'm gonna give you another quarter-million dollars to accelerate this thing, because that's the only way we're gonna preserve the business case that we have." So that's the program risk that the project wouldn't necessarily see.
0:56:30 KL: Have you looked at the role of value engineering? On the shaping... You mentioned something earlier about the scope of things and the expected return. Value engineering seems to be speaking to, what is the expected actual value of what we're really designing?
0:56:46 JS: Absolutely. And this is another program topic. If you did this at the project level, what would you do with that information? Yeah, you would find out that you need to spend another $100,000 or $200,000 to optimize the products. Where is the business case at? That's not what your charter said. Your charter said, "Delivered on July 1," the way I told it to.
0:57:08 JS: So when you look at things like systems engineering and value engineering and marketing, those are things that normally exist at the program level. When you're looking at things like sales and requirements management, those are things that happen at the project level.
0:57:28 JS: In MSP, there is a technique called "benefit mapping." There are some tools out there that actually which do this. We'll say, "Well, we expect 50% of the contribution to come from this project, 20% to come from this improvement, and another 30% to come from another improvement." So you can actually partition that up a little bit. And what happens in reality is what really happens. Sometimes it's better, sometimes it's worse. But at least you have some a priori view where the contributions were coming from.
0:58:02 JS: I think programs connect the dots a lot between what the organization is trying to achieve and the project work that's being done. And I think if we did that, we'd have a lot more focus on value. The projects, I think, would have a lot more meaning in your life. And quite frankly, I think this is a... This will help the economy right now, because we would be more value-driven and benefits-driven than we are as purely being cost-driven.
0:58:30 KL: From a risk-adjusted understanding of project activity, to seeing the team develop its own work plans, to understanding that the project manager isn't actually responsible for everything, our guests have led us on an excursion from the very inner workings of projects to the program and portfolio level. And our adventure isn't over. We have guests with more to say at the strategic and portfolio level. So stay subscribed to the podcast for 'Advances in PM Techniques, Part III', coming soon.
0:58:57 KL: Special thanks to today's guests, Tomoichi Sato, Mike Hannan, and Joe Sapko.
0:59:05 S5: Our theme music was composed by Molly Flannery, used with permission. Additional original music by Gary Fieldman, Rich Greenblatt, and Lionel Lyles. Post-production performed at M Powered Strategies, and technical and web support provided by Potomac Management Resources.
0:59:23 KL: PMPs who've listen to this complete podcast may submit a PDU claim, 1PDU in the Talent Triangle, Technical Project Management, with the Project Management Institute's CCR system. Go to CCRS, select "Education," and then "Online or Digital Medium" and enter provider code C046, the Washington DC Chapter, and the title, 'PMPOV 0027: Advances in PM Part II, Beyond the PMBOK.' Make sure to select "1PDU" under the "Technical" category at the bottom.
1:00:02 KL: If any of our listeners have comments about this episode or past episodes, or ideas for future guests or topics, please go to pmiwdc.org/contact and leave your comments there. Or you may contact me directly at email@example.com. I'm your host, Kendall Lott, and until next time, keep it in scope and get it done.
1:00:25 S5: This podcast is a Final Milestone Production, distributed by PMI WDC. Final Milestone.
About the 'Project Management Point of View' Podcast Series
© PMIWDC and Kendall Lott
This podcast series is a collection of brief and informative conversations between MPS President, Kendall Lott, and a wide variety of practitioners and executives. His guests discuss their unique perspectives on project management, its uses, its challenges, its changes, and its future.