light bulb image next to podcast titleAdvances in PM Part I: Value

February 3, 2016  |  Time: 1:02:45  |  Subscribe in iTunes

Heads down on getting things done, project managers often forget (or are left in the dark about) the underlying purpose the projects they are assigned.

Even more, they are rarely told of the value of the project.

Projects are investments. PMs are investment managers, managing a dynamic scope that changes the value that is produced.

And there are ways to evaluate, monitor and manage the changing value.

Listen in and let Mary Ann Lewis, Robert Stewart, Stephen Devaux, and Michael Hannan give you the insight, the high value concepts that help PMs be more than task masters, but value managers.

Listen online or read the full podcast transcript below.

About the Speakers

portrait of Stephen A. DevauxStephen A. Devaux, MSPM, PMP

Analytic Project Management

Steve Devaux, MSPM, PMP, is President of Analytic Project Management, Boston, MA, a PMI Global R.E.P. founded in 1992. Major corporate clients include Siemens, BAE Systems, Wells Fargo, Texas Instruments, Wyeth Pharmaceuticals, MIT Lincoln Labs, iRobot, L-3 Communications, American Power Conversion, and Respironics.

Devaux’s newest book Managing Projects as Investments: Earned Value to Business Value came out from CRC Press in September 2014. He is also the author of Total Project Control, the second edition of which was published by CRC Press in March 2015. He contributed chapters on his new CPM metric, critical path drag, in two 2013 books: Project Management in the Oil and Gas Industries and Handbook of Emergency Response. He is the author of numerous articles and PMI webinars, and a frequent speaker at PMI Chapter meetings throughout the US. He also authors a blog on advanced practices in project management several times a week at

Over the years, he has taught graduate project management courses at Suffolk University, Brandeis University and University of the West Indies/Barbados and in Executive Education programs at Bentley University and UMass/Lowell.

PMIWDC Presentations:
Managing Projects As Investments: The Benefits Of Computing Critical Path Drag And Drag Cost.

portrait of Michael HannanMichael Hannan, PMP

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.”

portrait of Mary Ann W. LewisMary Ann W. Lewis

SAVE International
President and Government Liaison

Mary Ann W. Lewis is the president and the government liaison of SAVE International, the professional society for the Value Methodology.

She spent her career promoting value-improving practices and construction management. Ms. Lewis managed Black & Veatch’s Water Program & Construction Management Practice. She co-founded Lewis & Zimmerman Associates (1982), the Construction Dynamics Group (1983), and CDG International (1991-UK), which were sold in 2004 to ARCADIS. She worked for two U.S. Congressmen early in her career.

She is a trustee and former chair and director of the nonprofit Lawrence D. Miles Value Foundation. Ms. Lewis is a Fellow of SAVE International.

PMIWDC Presentations:
Value Engineering (VE)

portrait of Robert B. StewartRobert B. Stewart, CVS-Life, FSAVE, PMP, PMI-RMP

Value Management Strategies, Inc.
President / CEO

Mr. Stewart has nearly 30 years of experience in leading Value and Risk studies for a wide variety of public and private clients. He has also authored three books on the management of value and risk and developed the Value Metrics Process for VMS. He is a Fellow of SAVE International and currently serves as Chairman of the Miles Value Foundation and is Vice President of Communications for SAVE International.

Full Podcast Transcript

0:00:03 Kendall Lott: This episode is a bit of a departure from any we have done because we focus on more technical aspects of project management. It may be good to listen a second time with pen and paper, and with a willingness to do some follow up learning on the topic because we have PM words, so many words. Value engineering, critical chain, analytic hierarchy process, critical path, drag cost, value breakdown structure.

0:00:24 KL: Our guest had so much to say on the topic from the elements of initial scoping through project controls to the newest risk management techniques to portfolio management, that we ended up making two episodes: Advances in Project Management Part 1 and Part 2. We think that the underlying principles, however, are both important and accessible to all of our PM listening community.


0:00:47 KL: As PMs, we get to focus on the techniques that keep us functioning within the iron triangle, and we use the softer skills to manage teams and keep stakeholders happy or at least at bay, but we don't often ask or get told what the value of a project is. All of those project management steps, those resources, the final output design, and all of the timing to get a product to market, affect the plan value of the product or service. Without a specific value, why would stakeholders, investors, and executives undertake projects? No implicit project value, no need for project managers.

0:01:22 KL: So today's podcast is all about value. What is the value of a project? How do you increase value? And what is the value of each component of a project? Cost is a factor, but value is much more than the mere dollars expended. It's about the return that is expected. I spoke with four experts who maintain that understanding the true value of a product, or the project that supports it, and being able to measure it in a useful way can greatly enhance the success and yes, finally, the worth of a project. The theories, tools, and methodologies we discuss here take you way beyond the iron triangle. So fasten your seatbelts and listen up.


0:01:58 Speaker 2: 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:02:11 KL: Mary Ann Lewis is the President of SAVE International, the premier international society devoted to advancing and promoting the value methodology or value engineering. Previously, she was a business owner in value engineering and construction management in both the US and the UK.

0:02:28 Mary Ann Lewis: Value engineering is a systematic approach to improve projects and products and processes. Now, value engineering was created at General Electric by a fellow named Larry Miles who was in the procurement department. He was an electrical engineer, and at the end of World War II, there was a shortage of materials and manpower, so he had to come up with a way in order to make their products, and he boiled it down to functions. What functions do I need to perform, and how else can I perform them? With what other methods or materials or processes? 

0:03:08 KL: He means what functions his product has to do? 

0:03:10 ML: Correct, the functions of the product...

0:03:11 KL: The functionality of a product? 

0:03:12 ML: Correct. And so, he devised this approach very simply to say, "Give me an active verb and a measurable noun, and tell me how am I going to perform this function?" And this is what sparks the creativity. This is what makes value engineering different than other practices. It drives innovation because you're boiling something down to its very simple elements. So when you've got a multidisciplinary team looking at something, and they don't all have the same background, they don't all have the same disciplines, it's easier to get them to think in very simple terms. So, a pencil, for instance. You might say, "Well, it's a tool to write words, or it is an instrument to draw." But those are activities. Those are not functions. The function of a pencil would be to make marks, and that's how you boil it down. Once you do that, you then start brainstorming and understand there are lots of ways to make marks.


0:04:19 ML: What you're trying to do is to improve both the performance and the cost.

0:04:24 KL: So let's back up to performance. I can see that cost function. You've figured out the functionality you want, and you can see, "How can I do this most cheaply?", and part of that...

0:04:32 ML: No no, not cheaply. Let's take that word out of the conversation here. "Cheap" is not what you're driving for. It's the right cost. You may find that you need to add cost to that product to get the performance that you want.

0:04:44 KL: So when I say, "Make marks", we haven't talked about performance. That's a function.

0:04:48 ML: That's correct.

0:04:48 KL: And the product maker says, "Indeed, I wish to make marks." Where does the performance conversation come in.

0:04:53 ML: Well, this is where you get into the conversation of value.

0:04:56 KL: Okay.

0:04:56 ML: And the value is determined by the customer, by the user, by the owner. Whoever is going to be using this product, this project, this process. You need to understand from the client's perspective what's driving it. Now the client may say, "Well, is it the initial cost that's driving my project? Is is the life cycle cost? Is it the schedule? Do I wanna win an award for this?" You have to understand what's driving the project, and that's a key part in the preparation phase, so when you're discussing the value of it, the value... You're determining that by its performance. What is the performance requirement that I am looking for to meet my objectives here? 

0:05:35 KL: So, there's no other information that comes in on the making marks? 

0:05:39 ML: Then you determine what is the use of it? How will I be doing this? Where am I going to be using this? Is this for a blackboard? Is this for paper? Is this chalk that I want my kids to write on the driveway with? Where am I going to use this? How am I going to use this? Who is the customer for this? And you look at all of those parameters.


0:06:04 KL: How is performance defined in value engineering? 

0:06:06 ML: It's defined by what you're reviewing so for instance the performance of a missile is going to be very specific that requirements have been defined by the Department of Defense as to how and when and where and why they would use that missile and those drive the performance. So every project, every process has it's own performance measures that are determined by the owners team and in some cases you're going to find as you're defining functions and discussing this that you can actually improve those performance measures. Or you can say, " Why is this a performance measure at all. Why is this in here? " Challenging is part of the process.

0:06:53 KL: So talk to me about the process, so how do we walk through that methodology? 

0:06:55 ML: So, just to say, there are three things that separate this from other management practices, are function analysis, two, it's done in a multi-disciplinary team and, three, it follows a step by step job plan.

0:07:14 ML: The six-step job plan is pretty straight forward, we've got three major phases. Preparation, the workshop itself, and then the follow up writing the report and determining how you're going to accept, reject or defer decisions on what you wanna do. Within this you have the information phase, you gather all of the information that you can about this project or process, then you create cost models. You wanna understand where is the cost being expanded based on the cost I have right now at this point in time? And you determine where that high cost is. You look at it from Pareto's perspective and say, "Okay, 80% of my cost reside in about 20% the elements of this product." Those are opportunities for improvement and for cost savings. Then you do function analysis with the team. You understand what the functions are. Everyone agrees "Yes, these are our functions", and then you classify them, this is a basic function we need to provide this or this a secondary or unnecessary function and once you've done that it prompts again the brain storming. It prompts the idea generation and and the creativity and everyone throws ideas out.

0:08:34 KL: Is that the workshop period? 

0:08:35 ML: This is all in the workshop. Yes.

0:08:42 KL: So how does the brain storming get structured around this? 

0:08:44 ML: Well you're looking at these functions and your deciding how else can I perform that function to improve the performance or to reduce the cost or do I need to add cost to this project that I'm not going to be able to achieve the performance and the functions I want at the cost that we have now identified here. We need more money and so once you've identified the functions and related the cost and the worth to these things, you have a lot of information to start brain storming.

0:09:19 ML: Then the team together, collectively, brain storm ideas. Once you've got them all out on flip charts or you'll see them projected onto screens. Then you go back and you start judging those ideas. Whatever scoring system you want, one to five, one to 10 on how well they meet your project value objectives. And once you've ranked them, develop them. Develop them into idea that are logical. You can define what's the original concept, what's my proposed change, what are the advantages and disadvantages to this idea, what are the costs and schedule implications related to this and what's the back up to demonstrate that I've got a good idea here? 

0:10:07 KL: Do you do dependencies that some of these functions can only occur if another function has? 

0:10:11 ML: Yes. We frequently use a tool called a FAST diagram, Function Analysis System Technique, and it's a way to model all of the functions that you've identified so that you can read from left to right, how and why. Why am I doing this? And if you can't read these functions left to right, right to left, you know you've got mismatches here. And when you read up and down they're the wins; when I do this I need to do this and when I do this I need to do this.

0:10:42 KL: And this allows you to do what? 

0:10:43 ML: This allows you to see if you've got unnecessary functions floating around in here this allows you to say, "Do I really need that function. Can I eliminate that? Will anything change if I eliminate that? Will anything change if I eliminate that step?"

0:10:58 ML: The team will then document all of their ideas in a report. On the last day of the workshop, you typically invite back the people who are the stake holders of the project, the owner, the designers, whatever they are. There's a multi-disciplinary team right there and you present the ideas to them.

0:11:16 KL: So what you have when you're done is a design document, requirements document? 

0:11:20 ML: No. No. You have a value engineering report.

0:11:24 KL: Okay.


0:11:24 ML: You have a report with a lot of alternatives in it.

0:11:28 KL: Okay.

0:11:29 ML: And it's a basis for decision making.


0:11:36 ML: The benefit to all of this is that it's fast, it may take a couple of days, it may take a couple of weeks at the most for a much larger, more complex project. But it's fast. If you've got the information and the right team in the room, you are able to generate ideas and make decisions in a very quick time frame.


0:12:02 KL: From the engineering report decisions are made and now what do you have? 

0:12:06 ML: You have an accelerated schedule for design. In my opinion because...

[overlapping conversation]

0:12:11 KL: Some well selected functionality too.

0:12:14 ML: Correct. You have well selected functionality. You have agreement. You have all of the steakholders in agreement that, "Yep, were making these decisions. We've done it together. Now the decisions to implement are not based with the value engineering team. They are based with the design team, with the owner.


0:12:36 KL: You discussed this in the context of product, but you also said it was good for projects and process. Did that come along later, or how is that used? 

0:12:45 ML: Processes to take a look at how are things working. What is the process for my design? I have seen applications where there is a design program. This is how we do design. These are the steps along the way.

0:13:01 KL: Mm-hmm.

0:13:02 ML: And we've done value engineering studies in those to say, "Okay, how can you accelerate that? How can you eliminate steps that are no longer necessary in the current world order of designing something? And you can look at the process. One interesting one I thought was an example of a knee surgery. A group of doctors and nurses did a value engineering study with a certified value specialist, and they looked at the whole process. How do we schedule those patients? How do we do the pre-op? How do we get them into the surgical suite? How do we physically do every step of that knee operation? And then how do we get him back out into post-op, into recovery? And this study saved not only time, but it created a new surgical tool for the knee surgery...

0:13:55 KL: Oh wow.

0:13:55 ML: Which then became patented as a result of this and it streamlined the whole process.


0:14:07 KL: Where is this being used now? I know we talked about it for it's use with government? 

0:14:11 ML: It's used everywhere. Government and industry. There are many very large corporations who use this all the time.

0:14:20 KL: What does it take to become a value engineer? 

0:14:23 ML: SAVE International has four components to our mission. The acronym we use is PACE: Promote, advocate, certify, and educate. And under the certification component Certified Valued Specialists, CVS, have achieved several levels of experience, training, education.

0:14:51 KL: I felt like I needed to find a way to tie value engineering into project management, so Mary Ann suggested we put in a call to her colleague Robert Lewis. Rob, a PMP and member of the Portland Chapter of PMI, got his first certificate in value engineering when he was only 19 years old. He is President and CEO of Value Management Strategies Incorporated, in Escondido, California. And serves as Vice President of Communication at SAVE International.

0:15:19 ML: Rob. It's Mary Ann.

0:15:22 KL: And Kendall Lot.

0:15:22 Robert Lewis: Hi.

0:15:23 KL: And this is Kendall Lott.

0:15:25 KL: We reached out to you to talk just a little about the role or the intersection of project management value engineering. If that's something you find at all interesting to tell us about.

0:15:36 RL: So, of course, the box lays out the various elements of project management, which of course include cost management, scope management, quality management, time management, and so forth. But the one thing that is conspicuously missing is value management. Every project manager worth their salt is familiar with is triple constraint.

0:16:02 KL: Right.

0:16:02 RL: So time, scope, and cost. And if you want something fast then probably the other two are going to suffer and so on. So when you start layering on risk and quality and communications and all the other various things that project managers have to juggle, it really gets down to you can't do everything 100% really. So we have to make decisions throughout the lifespan of a project. How do we balance these things? How do we know what a good tradeoff is in terms of all these different pressures that we have as project managers? And really a good project manager ought to be driving value into the project, not only by managing those things, but also making decisions that are balancing the various tradeoffs involved between those elements.

0:17:06 KL: So would the project manager be an active participant in defining value, or questioning the performance metrics? Not the metrics, the performance characteristics? 

0:17:18 RL: Sure. The project manager is certainly going to have an important role in making decisions that drive value into projects. However, there not necessarily the ultimate decision makers, right? So to finish that, the project manager plays a central role, but there really not the customer.

0:17:35 KL: Right.

0:17:36 RL: And they of course are being measured on metrics that are quite different. And if the pressure is on time that they made biased decisions based on expediting the project and sacrificing cost and scope. Really you need, in these types of projects, you need a very balanced platform to make informed decisions and to get the various stakeholders and alignment, and that's really where value management needs to play a central role.


0:18:13 KL: Okay. So why is it beautiful? You both are acolytes, or maybe high priests of this, [chuckle] I should say. What is so beautiful here? 

0:18:22 RL: To me, the interesting and most fascinating element of value methodology is the notion of function, and focusing, really asking why, rather than what is it? Really, why is it there? Why is this important? Is there a different way to do it, rather than just accepting at face value that, okay well, here it is. How do we make it more efficient? It's really asking, going much deeper, and trying to understand why is it this way? I think project managers tend to really be champions of projects, but they may not always be in the right position to challenge the basic premise of a project.

0:19:10 KL: And they have no incentive to, necessarily.

0:19:12 RL: Exactly.

0:19:13 KL: Cancel my project please. [chuckle]

0:19:15 RL: I hired one of my folks involved in a transportation study last week, and the number one alternative was to essentially cancel the project because the function of the project really was not necessarily in alignment with the purpose of the project. And of course, project managers don't like to hear that [chuckle] for various reasons.


0:19:41 RL: But I think any project manager that's professional, and is willing to do what's right for the customer would embrace this. Especially if you start asking these questions at the right time, which is when these projects are conceived, then it could avoid embarrassing situations further along the road. I think we don't ask "Why" enough. We just assume we understand why, when we really don't. I think that tools, such as value engineering, help organizations really dig deep, and challenge basic assumptions, and we need more of that.


0:20:24 KL: With value engineering, we get to ask why this project is happening, thus, what the value is. The technique allows us to scope project outputs to plan for the product design that maximizes value, and shapes the project plan. As Rob said, we may be champions of projects, but not in a position often, to think about the best value design. And that's key for value engineers. Ask the question of value at the design and conception phase. To learn more about SAVE International, visit their website at


0:21:07 KL: But what of the value once the design is set, the project is scoped, and the project manager and team are up and running? It struck me that we are not just talking, "Are projects delivered?" But what is the value of the investment of resources? I wanted to learn more about maximizing value once the project is undertaken. So, I reached out to Mike Hannan, founder and principal consultant at Fortezza Consulting, and a frequent guest on the Project Management Point of View. As expected, he had a strong line of reasoning on the topic.

0:21:37 Mike Hannan: When you start looking at what the return on investment figures are for projects... Of course, a lot of projects are hard to measure in hard financial terms. But if all you do is look at the success and failure metrics, you see that industry, after industry, projects return fewer than two-thirds successful. If you think about that, if that were your own investment portfolio, more than a third of your portfolio is delivering a zero, or negative return. But you're still investing billions and billions of dollars across industry after industry, because of, presumably, the great return you're getting. That suggests to me that there's massive amounts of impact for the projects that actually do succeed. Otherwise, why would it be worth it? 

0:22:20 KL: Why would it be happening? Right. It's offsetting the one-third negatives.

0:22:23 MH: If you think that it's that important, it's that valuable, imagine if we could get the success rates from 60 odd percent, to 90 odd percent. That'd be an instant 50% boost in ROI right there. In addition, if we could improve speed, and get projects done faster, and improve the throughput of reliable project completions; and even getting down to the task level, and getting the team trust, and the single tasking discipline, and all sorts of other things, to really drive speed. If you think of that in investment terms, you're basically just saying, "How soon before I can get the return on my investment?" If I can get it in half the time, and then use that return to channel to the next project, then keep that wheel going, then you bubble that to the portfolio level, and say, "Well, if I get a $100 million investment portfolio, generating return in half the time." Then, I can over that investment to the next wave of projects.

0:23:20 KL: If you think of a portfolio manager as someone whose job is to maximize return on an asset class, but looking at the products coming out of the projects as assets that they have to get with a cost on the front-end, right? 

0:23:30 MH: It's pushing that narrative to its inevitable conclusion. We've always been investing in projects. We've always had portfolios of projects. We just haven't really had portfolio management discipline for projects. So, if we can actually focus on the value generation, and return on investment calculations, and all the myriad formulas that the financial world has come up with to help us figure all that out, and manage it well, projects can generate massively higher returns. 

0:24:00 KL: So you'd have to be able to have some good metrics and measures around that, so that PMs are performing to that type of measure.


0:24:11 MH: One of the excuses that's often given is, well, how do you put a dollar value on a branding project? 

0:24:17 KL: That's a good question.

0:24:18 MH: Well, what about a project to modernize a big IT infrastructure? We might not really see hard benefits for a while. Or maybe, the only near term benefits are, it's easier to hire a developer in some new technology than something that's dying, right. We save money on the maintenance cost of some old system, that's just harder and harder to maintain. But no matter how it is, the point is, if you can't get some sort of value assessment, then you're not doing your job. We've always been faced with this challenge.

0:24:50 KL: Right.

0:24:50 MH: Right? We can't really define the things in terms of profits as much as mission impact. And mission impact is inherently fuzzy. But we still have to make these decisions. The army has to decide which weapon system investments are gonna be the best ones to protect our country.

0:25:06 KL: When I think of normal asset valuation, we think of the risk of getting the weapon system right. Is it going to be the one that performs the duty that it needs, the kind of power that it needs to be able to project, right? But when we see it from project management, we're not asking sometimes, is the product itself at risk for being valuable in the market? We're asking, what is our risk for being able to actually produce the product? 

0:25:28 MH: Correct.

0:25:28 KL: So, it's almost like we're already being put inside the little glass jar, that somebody else is selecting.

0:25:36 MH: Yeah. In fact, we as PMs typically are being told, "Look, we executives have already made the right value decisions, by picking whichever projects, and setting the right schedule, and locking in the right scope to maximize value. You just execute." And of course, the reality is, as we execute, the value equation could shift and change. Take the weapon system example, there's a Comanche helicopter that was conceived in the '80s, as a stealth helicopter, to penetrate the Soviet threat. Well, in the early '90s, the Soviet threat diminished somewhat. That program wasn't killed until the early 2000s.

0:26:13 KL: So, that's what I would start calling 'bureaucratic drag'. What is the cost of institutionalization of projects? [chuckle]

0:26:19 MH: You pick a stock that you're sure is gonna go through the roof, and instead it tanks.

0:26:22 KL: Yeah.

0:26:23 MH: And so, psychologically, you want to hold on to it because selling it means you're admitting failure. I think that happens in projects too. If we kill the project, it's like admitting we goofed or... Well, why can't it just be sort of a normal healthy thing? 


0:26:40 MH: If we all agree projects are investments, then collections of project investments constitute a portfolio, and we all agree that we want to maximize the return on our investments, well then it almost doesn't matter, what you throw into the mix as long as it's effective toward that objective. If you have a collection of projects that apply variations of agile methodology that speed things up, that means the project will finish sooner... Potentially. It means the investment dollars are tied up for less time. It means, not only might you maximize the return because of the speed, but you might be able to channel those dollars that you just freed up into the next project, and get more value churning. I'm thinking ROI. I'm not just thinking speed 'cause we like speed.

0:27:30 MH: And I think if we can train PMs to always think about that unifying metric, we're gonna unleash all of that untapped value, that is hiding there in failed projects and in the single-minded binary mentality of success and failure projects, as opposed to more or less value from a project.

0:27:56 MH: How could we as PMs, on almost any project environment generate the biggest jumps in ROI. One is just that value mindset with the tools and techniques Steve Devaux talks about with maximizing value of the project as we execute, right. Kind of a cool attribute of Projects As Investments, unlike many other types of investments where we're kind of stuck with whatever we get. The other one is, anything that boosts speed, and helps you arrive at the project completion date sooner so that you can release investment funds and get to the next. So then that tool improves throughput of projects, has a massive impact on ROI.

0:28:34 KL: Just in case you haven't heard this term, throughput measures the rate of output and therefore quantifies how fast you can develop products.

0:28:43 MH: If I double throughput, I could have a 300% ROI boost. If I triple throughput, I could have a 500% ROI boost. The numbers are just massive. If we assume that the successful project also equals a project that delivers a lot of ROI, rather than just comes in within plan, then in my mind, the only big thing left to really tackle, is making wiser investment decisions from the get go.

0:29:12 KL: So, let's talk about that. So, you've narrowed this part of our discussion down to better selections. So what tools would we have at that, and what does the PM draw on it? 

0:29:19 MH: A couple of very interesting approaches had been around for a few decades. My favorite one is called the Analytic Hierarchy Process, AHP. Now what it basically does is says, "Look, we understand that a lot of the decision factors that go into picking project investments have hard to measure financial impact or non-financial benefits." And so how do we do an apples to oranges assessment on that and tie it back to some hard value numbers.

0:29:49 KL: Kind of like you're branding example.

0:29:51 MH: Mm-hmm. And so what AHP basically does is say, "Okay. Well if your top five decision factors for choosing projects include some ROI, hard financial ROI measures, maybe even some cost measures, like affordability-type considerations, and then maybe strategic value, morale building value, market positioning and things like that. Well then you can actually force decision makers as a group to go in and say "Well, would I rather have this branding project or $10 million in my company's bank account today? Would I pick this brand name value over this other project option?"

0:30:33 KL: Or back to opportunity cost.

0:30:35 MH: So does pairwise comparisons for each one. And so if you had...

0:30:39 KL: What do you compare it against though, when you say pairwise? Is each one A to B, A to C, A to D? 

0:30:42 MH: Each of these five factors would be compared against one other one at a time. When we were looking at this project idea, and we're comparing it against the alternatives, how do they rack and stack pairwise? 

0:30:53 KL: Yeah.

0:30:54 MH: And do those pairwise comparisons hold consistently and logically across the board with strength? And if a model can tell you that, then you have much better sense of what your investment choices are, and what's going to be the most valuable mix.


0:31:14 KL: We still haven't gotten to the issue of how do we understand the value of a project? 

0:31:18 MH: So, again a lot of this is going to be hard to measure and subjective but the AHP has an interesting little option. Let's use a fun example.

0:31:25 KL: Talk to us.

0:31:26 MH: Your investment decision is which restaurant to go to tonight, and it's a group decision. So let's say there are five friends trying to pick the restaurant, and so you all say "Can we at least agree on what matters in this decision, what are the key decision factors that matter?" Okay, well there is affordability, there's location, there's ambiance, maybe there's wine list, and reviews of the quality.

0:31:50 KL: Something about quality, yeah.

0:31:53 MH: And so, again, we'll say, "So for you Kendall, do you prefer ambiance or the wine list?"

0:31:58 KL: Right.

0:31:58 MH: And you'll say what you preference is in that pairwise comparison, and how strong that preference is.

0:32:03 KL: Right.

0:32:03 MH: And you'll go on down the line until you pairwise comparison...

0:32:05 KL: So we knocked out the methods of comparing them first right. We rank those.

0:32:10 MH: Then we also might say is "Would you rather have a great wine list or a $100?" Right. Would you rather have great ambiance or $100? 

0:32:19 KL: So it's important then after you got this list, that you compare it against an actual cost of doing it, or making the decision, which in this case might be the value of the meal? 

0:32:26 MH: Mm-hmm.

0:32:26 MH: And so that way you basically say "Well we can't sell branding."

0:32:32 KL: Right.

0:32:32 MH: For some dollar amount. But we at least tested our logic against this model and against dollar thresholds to come up with a pretty good proxy. And if we'd rather have a million dollars in our bank account than a branding project, but we'd rather have the other five projects instead of a million dollars, that tells you something.


0:32:56 MH: I think organizations fall down in another key area. 'Cause even if you had that initial selection process optimized, a lot of times we pick projects without much consideration on our internal capacity to actually execute them. And so understanding our capacity to execute and not just "Hey, do we have experience with this sort of project?"

0:33:17 KL: Right.

0:33:17 MH: I think we have qualified guys around. But what if the qualified guys are busy with five other projects? If we can actually begin to establish a drumbeat of execution with regular throughput, then we'll have a much better sense of what our capacity to execute the next project is, and where it should be staggered into the mix.


0:33:41 MH: I think we should have a value optimization score. Not just how well are we executing within planning constraints, but how well are we optimizing value? 

0:33:49 KL: Right.

0:33:50 MH: And plot that in the mix as well. And then we can begin moving resources around based on that exactly. Sometimes that could well be "Hey, are we falling behind schedule?" But falling behind schedule only if it's hurting value. Right, and usually it will, but not always. Until we get better at just calling it 'must haves', 'nice to have', 'desirements', whatever, and actually understand value contribution for the additional dollars and schedule we are consuming to deliver that scope, then we can just say "Look, this is really high value, and if we fall way behind schedule and we get to the point the whole project is going to deliver zero value unless we just deliver the minimum viable, okay fine, we'll just deliver the minimum viable." But if it's "Look, if we need an extra two months to deliver these three or four extra features," that could double the value of the project. Now that might have been listed as 'high priority desirements' or something like that, but the point is, it's high value.

0:34:47 KL: But PMs were more trained to think about, to the extent we think about this at all, cost. So I'm a PM. In fact I'm charged, I get it. I'm an investment manager and I have tools, I have better deliver value. And they have selected my project, I'm in the portfolio, apparently.


0:35:08 KL: And now the value engineers have come through and told me that the product which instead of just a spaceship, is now a specific kind of spaceship with a certain amount of metal and plastic a certain kind of design, right. So I know now what the real scope really is, now I start working. And I'm single tasking, got my people excited, so how do I engage in this model and in what way? 

0:35:28 MH: So then if you actually have all the techniques, and tools, and discipline, all figured out and your executives have paved the way with good selection decisions, and all the rest of it, well then the only real job you have is to gauge whether the value equation has changed. So we already have been taught to measure changes in our cost baseline over time, so...

0:35:48 KL: Yeah. Yeah.

0:35:49 MH: Projects are risky and their execution is variable, and all sorts of unknowns happen, and Murphy's Law strikes and...

0:35:56 KL: Yeah.

0:35:56 MH: We're all familiar with that sort of stuff that affects our planning constraints. Well, what about the value side though too? So what's going on to either offer opportunities for greater value delivery, especially if we, say, deliver a little early or avoid a delay or something like that. But then also, would there be a reason to go way over budget to deliver even more value, assuming we have additional budget to do it? Or should we... There's so much additional time pressure placed on us to achieve value much sooner, but if... What would be the benefit of cutting a big piece of scope, even if it angers a few key stakeholders and makes them all red in the face? 

0:36:37 MH: And so I really like the dramatic example that Steve Devaux has put out, he talks about an immunization program that is designed as a hedge against the risk of an outbreak, like a pandemic, occurring. And there was no reason to believe it would occur, but it would be nasty enough if it did that we'd probably be wise to have a well-funded initiative to get some immunizations going or something like that.

0:37:02 MH: Well, and we're going along that project and we're monitoring our cost baseline, let's say the EVM metrics look great, we're ahead of schedule, we're under budget, all the scope that we'd promised has been delivered. But all of a sudden, an outbreak occurs. Well now, you gotta start thinking, "Well, part of my scope in this program was like a big training project, to make sure the people immunizing did it right. And if they don't do it right, they could kill people." But they'll probably kill far fewer people than are gonna die anyway if we don't get this thing out here soon. The question is, how do you make that assessment? Do you even have the information to optimize that decision? And that's a tough one, right? In that case, the value isn't just ROI dollars, but lives saved. But as dramatic as an example as it may be, I think it highlights the key optimize-as-you-go challenge that we all have to embrace.


0:37:58 KL: What makes this system actually work? Because maybe I'm old school on this, but I'm thinking there must be some sort of data that has to move around this cycle to show that something is working, 'cause we're talkin' about change. So things keep moving. So how do we do that and what can PMs do to be engaged in it? 

0:38:13 MH: So that's a good news, bad news scenario. Because the good news is, a lot of what we need to make this happen, we do have in place. So even things as fundamental as critical path analysis with some value assessments on top of it make this work. We demonstrated now that critical chain, which essentially is just your resource loaded critical path across a multi-project environment, right, across the portfolio, can tell us what is limiting the gain in throughput. And so we can optimize the whole project execution environment across the portfolio around those throughput limitations. Great. We've demonstrated that at the task level, we can speed things up with some interesting Agile and Lean techniques.

0:38:53 KL: That's where the PM gets to step in. The other ones sit outside the PM. They may be informing, or informed by. But they don't own that barrier removal. Or they don't own it, identifying it necessarily.

0:39:04 MH: I think if a PM was armed with tools that fed that information, they would march immediately to the executive PMO Director's office and say, "We're missing an enormous value maximization opportunity here."

0:39:17 KL: Okay so we need those tools.

0:39:19 MH: As with any good idea, the tools come later. But again, the good news is we're not reinventing all the fundamentals of project management. We're building on the foundation that's there.

0:39:27 KL: So how does this go forward? What's the call to action here? What should PM look out for here? 

0:39:33 MH: I look at it more as a "How could a PM lead the charge?" I think there's some very interesting creative things that PMs have always done to get around the tool limitation, to get done the things we need to get done. But again, I think if you start with the mindset that "Yes, this is a portfolio, and portfolios are here to deliver maximum ROI", not just maximum value. And so, if we become ROI maximizers instead of just people who decide that benefits realization is a good idea, or value in generic terms, "Yay, I'm delivering more value." Well, if you deliver... If your project is supposed to deliver $100 of value, and you doubled it to 200, that's fantastic. But if you invested $1 million to get there, your ROI stinks either way.


0:40:24 KL: So what do you call all this when it's all said and done? 

0:40:27 MH: I'd call it the 'ACCLAIM method'. It stands for the Advanced Critical Chain Lean Agile Integration Method. It's gotta build on the things that drive up throughput, reliability, speed of task level execution and then add things like better selection, the value engineering concepts we discussed, some of the critical path, value, breakdown structure stuff. All of that, we'll see.


0:41:00 KL: Mike's position puts the PM back in charge of understanding and acting on the questions of value of a project. Our next guest takes that a step further. You may have noticed that Mike mentioned the name Steve Devaux a few times during our discussion. It made me think, "I need to talk to this guy." President and founder of Analytic Project Management, a training and consulting company in Bedford, Massachusetts, Stephen Devaux is the author of books and blogs devoted to project management and total project control. Of all the experts I've spoken to on PM point of view, I believe Steve wins the prize for the most Wikipedia links. His seminal ideas on value and the resulting acronyms have made their way through numerous threads in the wiki environment. Mike spoke about Projects As Investments. Steve tells us how to measure it. I reached Steve at his home in Massachusetts on a stormy November day.

0:41:53 Stephen Devaux: Hi, Kendall.

0:41:54 KL: Hi Steve, is it raining in... Well you're in Boston, right? 

0:41:58 SD: I'm in Boston. It is cloudy not raining yet.

0:42:02 S2: Do tell us, your background wasn't initially project management was it? 

0:42:05 SD: I was a school teacher, English and Social Studies, and instructional designer. Then I segued into corporate training. Then I went to a company called 'Project Software and Development Inc.' And they made very high end project management software and I learned more about project management the first day I was working for them [chuckle] than I had in years of doing project management, and I also absolutely fell in love with project management.


0:42:45 SD: Every project is an investment whether we care to recognize it as such or not. We invest money for resources in order to do a project which we expect will have greater value than the cost that we have invested in it.

0:43:07 KL: Let me interrupt with that then, because to me that's what we all understand to be true. This is classic iron triangle work, scope, schedule, and budget. Meeting your stakeholders' expectations, and of course performing to quality, and all of it adjusted for risk. So, tell me what made you go beyond the iron triangle.

0:43:24 SD: What made me go beyond it and develop and crystallize my ideas is teaching mostly corporate classes, year after year, and having people in all kinds of industries, pharmaceutical, nuclear power, DOD, software, they all ask certain questions. And it dawned on me that the answer is always, "You should be doing what is going to give you the largest delta between the cost of resources and the value you're going to get out of it."

0:44:03 KL: So why is this different? 

0:44:05 SD: Okay. The new insight is that all the factors, three from the triangle, or four if we include risk, we need to quantify these things. And if we quantify them we can actually have formulas that will tell us what the right decision is based on the decision's impact on scope, schedule, cost, and risk.

0:44:36 KL: So tell me how you haven't just reinvented earned value management.

0:44:39 SD: Earned value is a wonderful technique, but earned value is a technique that deals with cost. Every earned value system that exists is based on resource usage and budgets. The old terms from the DOD, 'budgeted cost of work schedule', 'actual cost of work performed', etcetera, these are all about cost. And as I say at one point in my book, "Anyone who doesn't understand the difference between cost and value is hereby invited to play in a poker game."



0:45:23 KL: So take me to the value, what is it that goes inside TPC, Total Project Control? 

0:45:29 SD: Okay, so we have three sides to the iron triangle, by the way I feel that we need to change the iron triangle to the golden triangle because it's all about the gold, and who ever has the gold rules.

0:45:41 KL: So what do we do to our formulas to get there? What do I need to measure? 

0:45:45 SD: Okay, well the first thing is that with an investment, which a project is, when we start out. We never know, for certain, what the value is going to be and obviously, many projects are undertaken that never provide any value or they may provide zero value, or often they provide less value than they cost but any investment can turn out badly. Because investments are always about the future. So what we're working for really is not ROI but it's really expected value, if you will, expected ROI. In fact even when the project finishes we do not know often what value this project is going to produce. If we develop a new cell phone, for example, we may have to come back after five years and see did we in fact succeed in creating something that gave us value, and how much did it give us. We won't know for a long time. However, the expected value we're going to get is always gonna be based on the scope of work we do, and the scope of the product. So both product, and project scope to use the PMI terms, the cost of the resources to do it, and the amount of time.


0:47:07 KL: I loved your phrase, "We're not kidding, time is money."

0:47:11 SD: Absolutely, and yet the vast majority of projects leave the value of cost of time as an externality, that's the economic term for it. An externality is something that is left unquantified in any investment or endeavor, and it is a known fact that if something is left unquantified it will be treated as if it is zero. When they make me world commander, Kendall, one of the things I'm gonna do is I'm gonna insist that, as part of this initiation documentation for every project, it will include, not just what is the target date for completion, and I avoid using the term 'deadline' which I think is a terrible term. What will the cost be in reduced expected value if the project is completed later? And what will the added value be for each unit that it's finished earlier? This way the project team who are working in the trenches and who are the people who understand what adding or, subtracting scope, or putting on some additional resources. What impact that might have on schedule, they are the ones who can make such decisions and see opportunities, but they usually never have that information.

0:48:36 KL: So what I'm hearing is still that you're saying there's more elaborate cost function than we often think about. I'm not hearing the value equation yet.

0:48:43 SD: Okay, let me take an example from my book, Managing Projects as Investments. One of the examples I choose in there is that we are making a remote controlled, Softy the Snowman, [laughter] who we're going to bring out in the stores for Black Friday, the start of the holiday shopping season. The day after Thanksgiving. For every day or week that we are later than Black Friday we are going to take a serious hit in terms of our sales and in terms of our revenues. Until come the 1st of January basically, no one's buying Softy the Snowman for their grandkids anymore then. So we've taken a huge hit on our revenue and...

0:49:28 KL: So what you do is you convert the loss value into a cost function, and then make sure that's included when someone decides to add something, or something happens to increase schedule time.

0:49:38 SD: Exactly. It's a delay cost. And it should always be stated as the delay cost beyond a certain date. If the expected monetary value for finishing the day after Thanksgiving is $10 million, how much are we going to lose for every day, or for every week after that? 

0:49:57 KL: This is fascinating to me, Steve. Tell me if I've got it right. You could have a project manager who says, "Hey listen boss, I've actually figured out a way to slash our costs in half. We're gonna add two weeks to the schedule. But listen, forget the two weeks of normal cost. I'm gonna save you so much more than those two weeks, in terms of cost. If we buy this one piece of machinery, I don't have to use these, other pits of labor." And the boss says, "Great, so 14 days and a million dollars a day, just cost me all of the value of the product."

0:50:26 SD: You've got it exactly. In addition, something else. Let's suppose we... Our scheduled is flipped and so we're not going to deliver until the 7th of December. If that's gonna cost us a million dollars a day for 14 days, that's 14 million dollars. Now we have done something that project managers complain is one of the hardest things for them to do, which is to justify, additional resources.

0:50:51 KL: Right. [chuckle]

0:50:52 SD: But if we see that the choice being 14 days late at a million dollars a day, or to go out and spend $3 million for additional resources on our critical path. Would you rather lose three million or would you rather lose 14 million, if by spending those three million, we can pull the schedule back in by 14 days? 


0:51:21 SD: If we finish our Softy the Snowman and get it in the stores before the day after Thanksgiving. There I can look out my window and see shoppers out there in the mall where people are already shopping for their holidays. So even though the boost we will get from being earlier than that day is not as great as the loss from being later. Nevertheless there is almost always value in finishing earlier. If we know what the work is, we know the cost of time. And we know what the impact is going to be on the critical path. Then we can make a, quantified, monetized decision in terms of pulling schedules early.


0:52:13 KL: So talk to me about your function's critical path, drag, drag cost and true cost.

0:52:18 SD: We need to talk a tiny bit about what critical path analysis, also known as critical path method, what it is. Now activities that are not on the longest path of what is called 'total float', or in Microsoft Project is called 'total slack'. Total slack is the amount of time an activity can slip without becoming the critical path. So it's the amount of wiggle room we have on activities of the critical path. As far as stuff that's on the critical path, what does critical path analysis tell us? It tells us that the total float of the critical path activity is zero. So, isn't it interesting Kendall, if something is not critical, it quantifies it beautifully for us. If something is critical, the methodology tells us zero.

0:53:14 SD: It should be telling us how much time is each item, work activity, constraint, whatever, delayed on that critical path, how much time is it adding to the project relation. We can have a 30-day activity that is on the critical path and we can shorten it from 30 days to zero at the end of the project that come in by only one day, because another path will become critical after one day. On the other hand, we might have a 10-day activity on the critical path, and if we can double the resources perhaps, on it, and shorten it from 10 days to five days, we will gain five days on that critical path. That's critical path drag, and it's is corollary is drag cost. How much is the number of days that an activity on the critical path is added, how much is it costing us? 

0:54:14 KL: This is marginal cost analysis. So, for this amount of work and these costs, I get this return. And now I need to know any adjustments to that.

0:54:23 SD: It is amazing once you start doing this, Kendall. How can you can see ways of spending $50,000 of additional resource costs, and save a million dollars.


0:54:37 KL: Think about that. Real math, based on stakeholders' needs that can produce a situation where more cost, might drive more value. Not just getting the project done on time, but actually capturing more value by driving the earlier schedule. That's a thing.


0:54:57 KL: You point out that few project managers would be inclined to recommend an increase in project spending, even if that overspend would return many times that amount to the customer or management sponsor. We're designed to go in, with the head down and go "I gotta have the hard conversation", as opposed to, "I have an opportunity."

0:55:15 SD: You're absolutely right. And there's one more thing caught up with this drag cost. What is the true cost of doing this item of work in a project? If that activity, and that work, is not on the critical path, its true cost is the cost of the resources to do that work.

0:55:38 KL: That's all it is. Because, it doesn't extend your project at all.

0:55:40 SD: Exactly. But, if it's on the critical path its true cost is the sum of the resource cost plus the drag cost. So, let's say that we have an optional activity in our project, it's not on the critical path, it's got 10 days of float, and it's adding $2 million of value, and the cost of the resources are $200,000. But, as the project moves forward, this activity gets delayed and it migrates to the critical path. And, now on it's on the critical path with five days of drag at $300,000 per day. Now, the drag cost is $1.5 million. And, in addition to that, there's $200,000 of resource cost, it's true cost is $1.7 million, it's only adding a million dollars worth of value. We should get rid of it.


0:56:50 KL: I asked him to take it a step further to find out how his value methodology works at the program level.

0:56:56 SD: Each of those projects in a program is adding value. And it makes a lot of sense to do the value break down structure for the projects within a program. What is the value they are adding? And figuring out ways that we can increase their value. There are certain projects that have vast value. In my book, I refer to them as 'Enabler Projects'. Enabler Project is, for example, a bridge to an island, and on this island we're going to build a luxury resort. But, before we can build a luxury resort we have to build a bridge to get the heavy equipment etcetera, etcetera to the island. The value of that bridge is equal, basically, to the value of the entire project. All of the luxury hotels and golf courses or marinas we're gonna to build on that island, and get revenues from, can't occur until after we complete that bridge, in addition to which, any delays in completing the bridge, wind end up delaying everything else. So, the delay cost... The value of the bridge is huge, and the delay cost of the bridge is huge, because it is an enabler project. And, if we can figure out a way to get that bridge done faster, it will allow us to start all the other revenue producing projects faster, and get going faster.


0:58:30 KL: How does this total project control methods work in an Agile environment? 

0:58:36 SD: Even if we're using Agile techniques, the fact remains, there is work to get done. There is, frequently with Agile, re-work that needs to get done. There is work that can get done faster, and there is delays in hand-offs. And ultimately the length of the overall project or program still winds up being the length of the longest path. Now, when...

0:59:04 KL: But, they don't plan that way, Steve. They don't actually plan it as a critical path.

0:59:08 SD: They don't plan it as critical path, but, what I'm saying is, critical path still exists. So, and it determines the length of a project. And, the length of the project is related to its value. I don't care how someone schedules their project, I don't care if they use Agile, if they use critical change, if they simply throw darts at a dartboard. They don't have to use critical path method scheduling, but, they need to be doing critical path analysis.


0:59:46 KL: Based on what you've seen with this new concept, which you've been working with for some time, and published on the last couple years, where do you see the future of project management? Are we in trouble as project managers 'cause we're not paying attention to this kind of stuff? 

0:59:58 SD: I think things are improving, and as an example in the last edition of the PMBOK Guide, they had two-and-a-half pages that had not been there in any previous version on what they termed 'business value'.


1:00:19 KL: For more on how to calculate actual value break down, look for Steve's books Managing Projects As Investments and Total Project Control on Amazon.

1:00:30 KL: There you have it. Business value in the process of project delivery. Value engineering design the output for its maximum value. Projects themselves should be chosen as investments for business value, and then, with critical path valuation, project themselves are managed for value. A charge to measure not just cost change, but value change. We have the PM sitting in the driver's seat. But this leaves us with more questions. Implicit in expected value is the nature of risk. That is, what is the probability of the expected return? What does the organization have to address at the enterprise level to enable these approaches? How is a portfolio itself constructed from a value perspective? And, what has to happen at the team level to make all this work? We get to these issues in Advances in Project Management, Part 2. Stay tuned, keep downloading.

1:01:22 KL: Special thanks to today's guests, Mary Ann Lewis, Robert "Rob" Stewart, Steven "Steve" Devaux, and Michael "Mike" Hannon.


1:01:33 S2: Our theme music was composed by Molly Flannery, used with permission. Additional original music by Gary Fieldman and Rich Greenblatt. Post-production performed at M Powered Strategies, and technical and web support provided by Potomac Management Resources.

1:01:48 KL: PMPs who have listened through this complete podcast may submit a PDU claim 1PU 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 PMPLV0025 Advances in PM Part 1, Value. Make sure to put 1PDU under the technical category at the bottom.

1:02:20 KL: I'm your host, Kendall Lott, and until next time, keep it in scope and get it done.

1:02:26 KL: If any of our listeners have comments about this episode or past episodes, or ideas for future guests or topics, please go to and leave your comments there.

1:02:39 S2: This podcast is a Final Milestone production, distributed by PMIDWC.

1:02:44 S?: 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.