Hot Topics from the PMI Silver Spring Symposium

September 18, 2015  |  Time: 1:08:20  |  Subscribe in iTunes

We present a snapshot of some of the most representative speakers and topics from the Silver Spring Chapter's "Actionable Intelligence: Tools, Techniques and Templates for Project Managers" symposium in June of 2015.

With a field of 30 presenters, the symposium lived up to its promise of providing a valuable professional development event, and produced hours of discussion and learning.

From best reporting methods, to improved portfolio techniques and discussions on the role of PMs in producing more and being customer-focused, the symposium was a success and participants had specific tools that they could start using the next week “on the job.”

Grab a pen and paper, and have a listen to these 9 presenters sharing tips, techniques, new ideas and of course, tools--and then check out the chapter website at

Listen online or read the full podcast transcript below.

Collection of photos of children from Mary's Center, Share Our Strength, and Kaboom

Full Podcast Transcript

0:00:03 S?: You gotta start looking at meeting me, more than initially making your triple constraint.

0:00:08 S?: The point of this one page, is to show you how to get to the bottom-line, get what you need done, and get back to being productive in your work.

0:00:19 S?: I talk about the book answer, and I talk about how project's work. And when you're in Rome you do as the Romans do, when you are taking the PMP exam, you answer the way you're supposed to answer it. [laughter]

0:00:31 S?: The actionable intelligence symposium, second annual, and the word actionable intelligence says it all.

0:00:37 S?: Actionable intelligence.

0:00:38 S?: Actionable intelligence.

0:00:38 S?: 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 Lot.

0:00:52 Kendall Lot: Before heading off to PMI Silver Spring chapter's second annual symposium, actionable intelligence tools, techniques and templates, I sat down with chapter president Marcus Parker to ask him about his vision for this event.

0:01:05 Marcus Parker: The tools are where the meat lies. With our symposium, it's all about the hard-hitting tool, technique or template, from the thought leader who created it. We have 30 thought leaders in the areas of implementing tools, techniques or templates. Many of them are authors, many of them are the thought leaders in the field or the profession that they're speaking about. S, o the tool-kit is a tangible take-away that we plan on adding to, that's our body of knowledge for the chapter. The third annual symposium, we're gonna an additional set of tools.

0:01:38 KL: Again, give me the headline, when it's over what do you think your target is, what do you wanna be able to say about this? 

0:01:42 MP: Actionable intelligence was a wild success, and people were so moved and inspired, that they chose to do something different at their job on Monday.

0:01:54 KL: And why did you come to the symposium today? 

0:01:57 S?: Well I'm new to project management, so I'm hoping to gain some tools and techniques I can take back to my company.

0:02:04 KL: For this type of hot-topics best-of mixed tape, it would be natural for us to structure the narrative by knowledge areas of the PMBOK, looking at the stakeholder integration, scope, schedule, quality, risk, etcetera. And yes, that makes a lot of sense, but we didn't. Instead we've taken a selections of presentations, and organized them according to the point of view. We start with tools and techniques for project managers to optimize efficiency and productivity, as well as methodologies for coping with external stakeholders. Then we shift to the larger organization, and look at ways it can produce more throughput. Finally, we arrive at organizational strategy, and how to stay relevant in a fluid marketplace, communication, stakeholders, portfolio throughput, organizational structure and strategy. Those themes were all covered at the Silver Spring chapter's second annual symposium. We were there, and we present some of the key points in this podcast.

0:02:56 KL: PMs, listen through this once, to see if there's anything you'd like to learn more about, then you can go to the Silver Spring chapter website to get more specifics of the presenter, or of the tool.

0:03:07 S?: The tools and techniques are really useful, what they are providing. Some of the tools are which we are aware of it, but we are not using it. But giving an emphasis of how and showing them the proof that it works, helps a lot.

0:03:23 KL: Milestone one, Project Managers looking inward to their projects. Here we look at some tools designed to enhance project operations, and it's all about communication. The bulk of the 47 PM process is notwithstanding, 90% of a project manager's job is communication. Looking at the conference agenda, we see a lot of communication oriented presentations, and a few caught our ear. Lisa Hammer of Leadership Techniques, reminds us we must communicate, and then tells us to be aware of over-communicating. So what to do? She has an approach.


0:04:00 Lisa Hammer: So, if communication is so obvious and so easy, what's the problem? You absolutely can communicate too much, and you can communicate to the wrong people too much. So we have to think about who we're communicating to, and when we're communicating, and what it is we want to communicate. Its getting the right information to the right people at the right time. So we look at what the communication path... You all remember this formula, right? Any of you PMPs in here, n times n minus one over two. So if you have three people, you have three communication paths. If you have five people, five times four is 20, over two is 10, you have 10 communication paths. So that means if we go up to 10 people, do we double the communication paths? No, it goes up to 45. We're e-mailing, and e-mailing and copying, and copying your folder, and it's amazing how many people the information goes to.

0:05:03 LH: So, we talk about stakeholder management. As the project manager, you have to be in the sector. There has to be a single point of contact, one person who is responsible when things are happening. Alright, so we have this salience category, and we have the three areas of salience; power, influence and urgency. And what you wanna do, is you want to look at them individually, and think about your different stakeholders, and how much weight each of them has? So let's say we have this team, and you assign each of them a salience number. So the salience number can be one to 10, 10 is someone who has to have the most information, someone who is the most involved. Okay, now we'd like you to go ahead and put down how and where they need to be, again on a 10 point scale. So multiply your salience by your awareness, and divide by 10. So if you have a 10 and a seven, it's 70 divided by 10, is seven. You come up with a communication score. But basically, for anyone who has a communication score of less than six, then the frequency is four times a month. If they have a communication score of six or higher, then we communicate with them 20 times a month, which basically means daily. Now some people say, "You know what? This isn't always gonna work."

0:06:38 LH: Of course, it's not. You might have to modify it, you might have to adjust your if-stake. But the basic premise, is that you could look at the frequency and determine how often you meet with these folks. Now what you also wanna figure out, is what it is that people want to know? If I were to say to you, "I need you to build me a box." You might go off, and Janet, what kind of box would you build me? What would it be made out of? 

0:07:07 S?: Wood.

0:07:07 LH: It would be made out of wood. Okay. How big? Maybe, 12 x 12? Alright. Great. Well, I need that box for a hippopotamus to stand on. Will that work? No. So, we have to tell people the context of what we need, and a lot of times we wind up giving somebody a task and say, "Go off and do it," and not putting in context.


0:07:38 KL: What brought you to the symposium today? 

0:07:40 S?: Well, I'm also a PMP. I belong to Montgomery Chapter. It's a great way to get your PDUs, and to meet all kinds of great people for networking and those type of things.

0:07:49 KL: PDUs and networking. Excellent. And what did you take away from your first session? 

0:07:54 S?: First session, is that sometimes, you'll have someone that will communicate something that you've directly experienced, you've taken approach that some will have viewed as not the traditional approach, but you kinda validate it when you've taken a certain approach, when you hear, coming from the expert as, "This is the preferred method, or preferred path."


0:08:18 KL: You have communicated. The stakeholders are absorbing it, but they're focused on the wrong things, and this drives additional messaging and additional meetings, endlessly. Effective communication will drive project efficiency. It's not hard once you know how, and Laura Barnard of PMO Strategies has some tips, and of course, a tool.


0:08:41 Laura Bernard: Have any of you ever been in a status meeting where you had to provide some report to your executives, and you're about halfway though this meeting, and they are down on page 14 in the bottom right hand corner stuck on some piece of data, and you can't get them to come back up and focus where you needed them to be. And they're drilling down into these details of this report, and they're asking all of these questions, and you're thinking to yourself, "This isn't even relevant to what I'm needing from you. I need some answers, I need some help on something, I need a decision, I need you to take action," and they're stuck on page 14. You're not getting the outcomes that you needed from that meeting. It's over. You didn't get to your overall status, because they're stuck down on page 14 somewhere. You didn't get the decisions that you needed in order to take the next step on your project. Your problems are not getting solved. Who do you think is to blame for that? Who put that report in their hands? We do it to ourselves. We knew we needed something from them. We needed an action to be taken. We needed a decision to happen, and we didn't put that right upfront. Now you need to go back to your project team, and say, "Well, we had a meeting, but now we have to have another one." And I bet you, you're gonna have to have another one after that.

0:09:50 LB: I'd like to tell you that there is another way to do that, and I'm gonna show you what that looks like. We've simplified it such that, in one piece of paper, and I'll even show you a two-page version that you can use for this if you must have more detail. But we've got a lot happening in one piece of paper. Use the left half of the dashboard to get your point across succinctly. It lets you tell the story in words, this whole left hand side, and it's intentionally small. What's the summary? Bottom line upfront. This is your elevator pitch. Whenever you're communicating your decisions, make sure that you say, "Here's the outcome that we expect to happen, or that has happened as a result." Do not use this as an area to do finger pointing. The best thing you can do is be as factual as possible when you're providing the information. And if you stick to the facts, you really don't need to worry about who reads it. Item and action. We have a section called "Items Requiring Management Attention." Use this to manage your sponsors. IRMA means I want you to do something, so put it in terms of, "I want you to do something." Activity and benefit. What's the benefit that will be realized as a result of the activity that took place? So, let's talk about the right half of the dashboard.

0:11:19 LB: How many of you guys love metrics? Often times, the right hand of the dashboard that we use, can give you generally the same information the left hand of the dashboard could, but in a format that those that really need to see it differently, can process. So, this is for major points for us. We use deliverables and milestones, major points of progress. This is not the entire project schedule. Tracker set complete of deliverable milestone. You can include expected percent completes. These are all just samples of what you can use. Show plan versus actual, anywhere where you have metrics. This is what we thought we were gonna do, this is how we're tracking towards that. That piece of information, that comparison. Don't just say where you really are. I know a lot of you guys, when we do our project reporting, we just say where we are, but we've forgotten where we said we were gonna be. That information is really important, because you could be tracking ahead of schedule, and you've missed that opportunity to brag. But if you haven't, then that's an indicator that your leadership needs to be paying attention because somethings slipping, and why? Now you've got the people on the right hand of the side that label their metrics, they can look at their numbers, and they can see some pretty colors. They're gonna know what to do, they're gonna know where to act, and where to focus their energy.

0:12:34 LB: Teach your sponsors and your executives, that the colors are triggers for them to do something, whether it's pat somebody on the back because they had a green, or ask more questions, and ask, "How can I help you?" When they see yellow or red. Red might mean clear your calendar. So lets talk about issues and risks, often the reason that things turn red. Make sure that you're explaining what could happen to management so that they're not blindsided. When you talk about something in terms of an issue, here is what will happen if this is realized... Outcomes, impacts, that's what they need to know. So on the budget side, and this is again just an example of the kind of things that your leadership might care about. Be honest and current. If your budget information is three weeks old, it is not relevant, and you're confusing your stake holders. Make sure that when you're doing this, you're getting information that is current. It can become a tool that people use to manage the work, especially executives. It's not a one time thing for them to look at, it can actually be something they walk around with. Because now what you've done, is you've gone with want that executive to go talk to their boss, and they have all the information they need to do so, to get a summary of what's going on with that project. That's powerful.


0:14:03 KL: And did you do any of the break out sessions? 

0:14:04 S?: I did. I went to the one on running an effective meeting, and I just went to one on neuroscience, and how to be a better project manager.

0:14:13 KL: Who knew there was a project manager in neuroscience? 


0:14:15 S?: Exactly.

0:14:16 KL: Excellent. Thank you.


0:14:20 KL: Linking actions, content, ownership, and decisions across the minutes, allow for more effective meeting documentation, and improves your preservation of their record the PMBOK way. Reid Spearman or Dakota Consulting is the master when it comes to making the most of your meeting minutes.

0:14:39 Reid Spearman: Summarize important discussion. We're gonna talk about how to summarize discussion a little bit later, and capture action items. Please capture action items, capture them with the responsible party, and capture them with the due dates. So how do we do it? One possible way to do this, is to use a template. A template just helps you, because the steps you wanna capture, is already there right in front of you. And that kind of information that you need captured is basic information about the meeting. You need to capture decisions and/or information given. Action items we've talked about, issues and risks. And I'm gonna add to this, opportunity, identification and evaluation to risk identification and evaluation. Logistics, this is under basic information, the logistics of the meeting. How did it get put together? I would encourage you to have some sort of naming convention for your meetings, especially if you have serial meetings, call that meeting the same thing.

0:15:36 RS: Location. Why do I put physical or virtual? Why do I put a location on my meeting minutes? It's context for a number of things, 'cause they have a visceral memory of sitting there and doing something, and that just clues them in, helps them identify what this is about. And sometimes you tell them the location and time of a meeting, and they'll remember,"Oh, I remember what we did at that meeting." It's context. Start and end times are important for me as a quality manager, because what if I wanna do a time study? What if I wanna see how long are these meetings taking? Why are these meetings taking so long? I recommend that you list on your form everybody invited to the meeting. My form says, "List everybody invited, and then check off the people who come." So list... In this form there's a place for the agenda. If you have more items that are gonna fit in that little section, I would say, "See attached," and put a longer agenda as an attachment to the meeting minutes. But I'm also gonna ask you, "Why is your agenda this large? Can you really accomplish all those things in this amount of time that you have set?" When you look at your agenda items, when you look at your minutes form, it gives you clues. It gives you clues, and gives you information that you can use to better manage your meetings.

0:16:48 RS: I'm gonna also recommend that you tie the paragraphs under the decisions and information, that you tie those paragraphs to the agenda items. Action items. We've talked about getting the responsible party, getting that due date, assign responsibility. Track to closure. What I'll do is I'll number them, and then the next meeting I'll ask about the status. If it's closed, I'll know that it's closed. On the next meeting minutes, you will see that it got closed on the next meeting minute. So this is a couple meetings down the road, it disappears, it got closed, it got reported, it disappears off the list.


0:17:35 KL: Milestone two, Project Managers looking outward. The emphasis on communication takes us to the core of project success. Stakeholder management, alignment with customers, and internal and external expectations management.


0:17:54 S?: Even when the PM is not doing the risk process, they are risk managers, because the stakeholders have unwritten requirements, and these are the ones that can up end your project. It's about your emotional intelligence in working with stakeholders, specifically customers. David Offenkrantz of DAO Enterprises, gives you the decision tree a PM needs to walk the right path.


0:18:16 David Offenkrantz: I think that at the core of what we do, is making the best decision we can based on imperfect or incomplete information. Rich management, if you will, is at the heart of what we do. Every project I have ever been on, has always been essentially, "Here's your end date, back into it, figure it out. Because there is either, on the commercial side, there's some business driver, or on the government side there's a mission driver, that has some date out here that we need to hit. And so therefore, we are constantly facing that fork in the road, and trying to figure out what's the best course of action, or what risk mitigation we need to do in order to get us where we need to go.

0:19:08 DO: And it's not just how to handle the written requirements, it's the unwritten requirements. Those are the ones that you really need to find out. So stakeholder management is absolutely foundational of everything we do. We get customers that wanna go left, and their convinced left is the right way to go. And then we have as the evidence begins to mount, to be the ones to say "Well, maybe we should think about going right?" And sometimes the messenger gets shot. And sometimes it's about how we have that conversation, so that gets to emotional intelligence, or emotional closure. And a lot of managing stakeholders is about developing our emotional intelligence. So expand the stakeholder group to include not just the people writing the check, but how about the users of whatever you're doing, how about your project team, how about the hard core IT folk, they're all stakeholders. Alright, now let's go through your responsibilities. If your project, or mine is, rearranging deck chairs on the Titanic, how tied into the big picture are we? 

0:20:24 DO: It doesn't matter. There should be strategic linkage between what I'm doing and where we're going as an organization. If there's not, then I got a couple of options. One, I look for the linkage, and get it lined up. Two, I leave and go do something else. Three, I stay and ride it out as long as I can. So, the PMI Code of Ethics, if you are certified it will tell you, you should say something and do the right thing. I think that's the right answer, that's the book answer. I teach PMP prep courses. I talk about the book answer, and I talk about how projects work. And when your in Rome, you do as the Romans do, when you're taking the PMP examine, you answer the way you're supposed to answer. [chuckle] Where we often get trapped, and is this is a big deal with stakeholder management, is that we think it's up to us to tell the customer "You can't do this." It's up to us to lay out the options, and let them make the choice.


0:21:37 KL: We measure so many things as PMs, and it helps us to understand status, perform comparative analysis, and provides us data for allowing improvement in the ability to show that improvement. Phil Magrogan of Lockheed Martin asks "How good is your relationship with your customer, and more importantly, how would you know?" And yes, he has an answer, and a tool.


0:22:00 Phil Magrogan: How good is your relationship with your customer? And if I had to measure one person in this room to another person in the room and say "You're better than the other person in terms of relationship with the customer, how would we asses that? For performance reviews, how would we asses that?" More importantly, for customer relationship, how would I asses that so that I could show that I'm improving over time my relationship with my customer? So, I'm gonna put this into that medical motif, and say there's three ways to assess your relationship with your customer, your commitments to your customer. The first is self diagnosis. So if I asked you "How good is your relationship with your customer?" You would say "Pretty good". Is that the truth? It's your truth, it's what you wanna to say to yourself, it's what you want to hear from yourself, but it's your self assessment. The second one is the second opinion. If I were going to a doctor, I'd say "Let me get a second opinion, and see what that person thinks about it." In this case, the second opinion is gonna be from the customer. We're gonna actually go to the customer and say "What do you think about our relationship?" And do you think that the customer's perception of your relationship is going to be the same as your perception of your relationship? 

0:23:20 PM: The third one is group therapy. I hope you all love group therapy. We wanna to sit down with our customer, and have that conversation and have that dialogue, and say "Well, you said this about our relationship, and that makes me feel this way, and I think... " And okay, so we start having a good useful dialogue. The point is that there's an infinite number of dimensions, if you will, and the cosmos of how one might evaluate the relationship. For our purposes today, we're gonna reduce it to four simple dimensions; communication, business alignment, means how well you as the performer are lying to your customer's business objective? Do you understand their domain? I work for the GSA, which is all about buying and selling. Do I understand contract management? Do I understand purchasing? Do I understand supply chain? That's the domain that your GSA works in. Relationship. That's that little softer skill about how well we are able to stand in each other's shoes, how well we are able to empathize and sympathize with each other about issues that bother either one of us? This is not a one-way relationship. And the last mention is delivery. And delivery means, in the case of the performer, I really am delivering value that the customer cares about. I'm not just doing activity, I'm actually delivering something. So we wanna measure each one of those.

0:24:48 PM: We're going to start with self diagnosis, and that's what we're gonna do today. It is prescriptive, and it has some health maintenance facilities associated with it. Over time, we're gonna to change the prescription, until we really hone in and see a change in our behavior, in our relationship with our customer. So what I'd like you to do, is open up the tri-fold to that first page on Step One, Examination, and read each of these statements, and put a checkmark next to that statement if it is absolutely, 100% true. There's not most of the time, or all-but. If there's any exceptional thought in your mind, then don't check it. But let's say you finish the first dimension. "Have communication commitments been established and kept?" Meaning, do I have a regular time every week with you for 15 minutes, where I am communicating the status of my project? Do we have a regular, written weekly or monthly, or some other periodic engagement that's scheduled, and there's a structure to that communication? If it's ad hoc, then that doesn't count. Have all potential breakdowns been elevated appropriately? Are there things that my team is saying that we haven't shared with you, either because we're afraid of you, the customer, or because we don't think this is worthy of your attention, or for any other reason? 

0:26:18 PM: If there's a breakdown that the customer could facilitate if they were the perfect customer, any of those breakdowns that haven't been elevated, we haven't done that, then don't give it a checkmark. This is just a check of how free and open and easy are you in sharing not good news with your customer. Do I understand my customer well enough to speak on their behalf? If I'm not technically competent in the domain to stand in my customer, then I wouldn't check this. Okay, so you go through all of that, you get to the second step, diagnosis. Transfer the number. How many checkmarks did you give yourself; one, two or three? Transfer it all to a little thermometer, so we just get a gauge of where we are. And now let's take a look at some treatment options. What are some of the treatment options that might be available to help improve this single dimension? Should I develop a project communications plan where I didn't have one before? Okay. Here's where it gets real. Now write yourself a prescription. Based on the things that you said in the first block, and based on some of the suggestions that might be there. Think of one thing that you could do, that might improve that little thermometer. If you only checked two out of three boxes, then you're not perfect, that means there's room for improvement.

0:27:40 PM: What little thing might you do in that relationship with a customer that might improve it? Once we get through that, we then wanna go off and do it with our customer. This is where it gets a little difficult for some folks, they feel a little apprehensive the first time. They say, "Phil, I did it. I can see where some improvements are needed, I'm gonna go work on those." I say, "So John, when are you gonna go talk to your customer and do a little group therapy?" The customer filled it out. The customer wrote the tiniest print in the prescription area because he had a lot to say. So he brought it back and he said, "I had no idea." Well, that was the point. So now will you go back and talk to him about the prescription. And about what you and he together can do, because you make this better than all the big stuff, the contract value will come as a side effect.


0:28:41 KL: You've been in one session already. Did you learn anything? What was your take away? 

0:28:45 S?: It was about how to build trust, and to ask the right questions.

0:28:55 KL: Make a list of what you need to get the most out of your project so that you can improve on the next one, when you say, "Yes" to the boss, then throw it away. Mike Hannan of Fortaleza Consulting tells you what you really need to focus on at the root if you're in charge of getting your project done. Even when you have all the key success elements in place, you need buffer, but you have integrate schedule, scope and cost buffers simultaneously. Listen in to this novel approach, rooted in developing trust as a PM.

0:29:29 Mike Cannon: Who's actually ever encountered this term, Portfolio Reliability in Project Land? If you read the PMI Standard for Portfolio Management, Version Three, it does not mention it. But reliability is what I'm gonna focus this session on, mostly just because of time, 'cause I'm passionate about it, and I believe something must be done. So they ask 2,500 people all over the world, "Would you consider your project successful? What percentage of the time would you consider them successful?" And the high performers are defined as those who can achieve that level 80% or higher, that's like a B minus. So, B minus, is that a high performer? Apparently so in the Cam world. The other thing I'll call out is the average project success metric from all 2500 people. And they're all basically looking in the mirror, and say, "How good am I at this project stuff? And so I'll give you the answer to 2012, 64% of projects come in within plan, that was the definition. So again, we're like a solid D. This bothers me personally. So, I'm gonna show you some ways to jack this up at the project level, and at the portfolio level. Obviously, if we're gonna do portfolio, we can't just ignore what's going on with the levels below. I care about a lot more than just reliability. I care about all the things that make projects maximal ROI, maximum benefit.

0:30:52 MC: So I ask myself, and encourage you to ask yourself, all these questions. Could you rapid fire what you think would be things that would drive reliability in your projects? 

0:31:02 S?: Methodology.

0:31:02 MC: Good methodology.

0:31:04 S?: Good risk management.

0:31:05 MC: Good risk management. What about good requirements? What about good stakeholder management? 

0:31:11 S?: Change management.

0:31:11 MC: What about a well managed scope? Right? What about... [chuckle] We could keep going. I would say that no matter how long that list is, you also need something else. So let's say that long list, I'm giving all this to you, I'm setting you up for success better than I've ever done with any PM ever. Feel good? Perfectly qualified for this, everything's fine, there's just one little catch. The best PMs that have done the most similar project like this in the past, have needed two years with the team I'm gonna give you. I need it done in one. Now how do you feel? 

0:31:49 S?: Stressed.

0:31:50 MC: Stressed, but I'm giving you all this. So we still have an issue here, is the point, right? And this is reality, for a lot of us. These things happen all the time. So what you would presumably look for, is buffer from somewhere. And if I can't give it you in schedule, what are you gonna ask for? 

0:32:12 S?: Scope.

0:32:14 MC: Can we shrink the scope a little bit, relax that somewhat? I mentioned I'm gonna give you the same team, but do you have other resources on top of that, that could execute this? So we need some protection from failure. And once we have this defined invisible, we now have to manage it, because it's the only thing that's gonna protect us from failure. I might not be able to give you any schedule buffer at all in fact, I'm giving you negative on that. So, we've gotta find some way that this actually looks like it could deliver within plan. So, these are the four techniques. The term I use "Buffering" for the project level, sometimes is referred to as "Contingency" sometimes is referred to as "Management Reserve." Some organizations define it only as "Budget." In the Agile world, they basically default to scope buffers. Again, I've been a part of a lot of organizations that have done various techniques, that are very popular in the project management world, and have been endorsed by PMI that actually degrade these things. So I think there's something systemic with how we do project management that must be fixed.

0:33:20 MC: All right, so let me show you. I have to have some flex in at least one of these areas, correct? Ideally more than one. And in fact as a PM, you'll take it anyway you can get it. You're gonna poke and probe for how much flex you have wherever you can. So how does that look for Waterfall project? Well, the protection from failure would just look like this schedule buffer in here, pretty simple. On a scope buffer, which if for the 'AAgilista's' in here, you don't call it scope buffer, but you might call it backlog. You're gonna have these must have features in the first few sprints perhaps, and then you can have some nice to haves, that I can sacrifice, if needed. But if the buffer gets a little trickier, so I call this like the Olympic stadium project, "Apollo," was this type of project too in some ways. Basically, you've got tasks that are gonna take you all the way to the due date, and you can't sacrifice scope. In fact, what scope would you shave from the Olympic stadium? Seats? Bathrooms? Kind of hard to shave scope. So basically, you'd better have money to throw at it, like we did on the Apollo programme, to recover. Still, we have risk. And we have to have a way to recover risk within plan. If Murphy's Law strikes, you might have had the best risk matrix anyone ever saw, and the best way to manage risk anyone ever saw.

0:34:49 MC: But if you've no way to recover schedule, because the two days it'll take to even figure out the recovery plan, puts us two days over schedule. So, the buffering aspect regardless of risk, is pretty critical. This alignment thing is interesting, I've run into a number of issues, especially with my Agile customers... No actually, not the customers, with their Agile teams. The Agile team has forced them to list a bunch of additional features for their software, that they don't really want. They'll count it as nice to haves, and they'll make the list. But in the customer's mind, the moment the must haves are done, their project's done. So, there's not great alignment in a lot of cases with the methods that default to one buffer type versus another, is a conversation with a customer. My favorite example is a few years ago I was driving to the beach with my son, and I don't take sun very well all day. You can probably tell, especially with when I lost my hair. And so I can get there at noon, that's okay, it's a long day at the beach, if I get there at 1:00 or 2:00 PM, that's actually kind of better for me. Less time in the sun, still plenty of time to enjoy the beach. And so I went about my normal planning process the night before. I thought what time should I leave, and leave in some buffer for delays on the bridge, and all those sorts of things.

0:36:09 MC: And I thought well, we could probably get there round 1:00 PM or 2:00 PM. Of it gets really bad, we get there late, no big deal. Well, I neglected to ask one of my stakeholders what his definition of success would be. My son really wanted to get there by noon to see a surfing competition, and I was leaving at 9:00 AM, and it's basically a three hour drive, no buffer at all. Then of course I'm starting to break some laws, add risk to my project.


0:36:37 S?: Trying to satisfy the stakeholder. But the point is, my buffer selection and how much of it I select, is gonna depend on what the stakeholders need for a successful project. Well, let's move on to technique number two, this aggregation of buffers. So, by the way, the average stats for the average project task, it does tend to be a five day task, buffered with seven more days, to 12. Anyway, so my little example, imagine there's four tasks. That project schedule is 40 days, agreed? I have 20 days of work, although it's variable. So I can't really commit to 20 if I'm smart. But should I commit to 40? See, that's worse. What if, imagine this is not four tasks, but 100? And this one comes in 10 days, perfect. 10 days, perfect, 10 days, all the way to 99, first 99% of my programme is 100% on schedule. Murphy's Law strikes task 100, and I need more than that five days of buffer to protect the whole project. I've just made a 99% reliable project, fail. So there must be a better way. There also is this issue of not wanting to deliver early. What happens to people who deliver early? Studies show that 80% of the time, we don't dare. Because we believe we'll be held to that same limit metric next time. So I would argue, a a better way is take this variable work, convince your team with this trust we talked about.

0:38:10 MC: "Look, I'm actually not holding you to any commitment at all, I'm trusting you to run hard and deliver. I would like you to trust me to protect the project from failure, And put this schedule buffer on the end. If you need the buffer, it will be there for you. Do your best so you don't need it."

0:38:28 S?: Are you the client? 

0:38:29 MC: I'm the project manager.

0:38:30 S?: You're the project manager, right.

0:38:32 MC: But I have no trouble showing that buffer to the client. Turns out this approach has generated reliability improvement of typically double. Projects that suffer from 40%-50% reliability, get near the 90s. Alright, so again, hopefully simple concepts. All we've done here is aggregate risk, right? Like an insurance policy. A pretty simple, straightforward concept. How often does the customer really care about delivery of a task on a due date? 

0:39:01 S?: Not unless it's a milestone...

0:39:02 MC: It probably... Yeah, there may be a few milestones along the way that they care about. So with my example of driving to the beach, if I get 90% of the way to the beach and then my car breaks down, can I get credit for 90% of the project being done? It's a failed project, I can't get to the beach.


0:39:19 MC: So usually we argue about things that the customer doesn't even care about. Why not just buffer against the things that they do care about? Okay. There is this question, we talked about showing the customer, or an executive stakeholder, how big the buffers might be? Again, if you can get to the point where you've actually exposed all the hidden buffers and gotten rid of them, then this becomes a much easier thing to defend. If I commit aggressively and then fail, I will commit less aggressively next time. And so if I'm signing up for less, how much will I deliver? Less.


0:39:57 KL: Ouch. Planning to do less becomes the norm? That's something to avoid. This leads us to how the organization is designed for running projects, how it is itself organized, and the framework it has to manage the project portfolio. Our third milestone takes that point of view, looking from the organizational level to the projects. It's not about the individual project teams. We need to support those project teams by making them successful with other project teams. And with that, David Quinn of Mosaic Technologies Group, tells us how scaled, Agile framework, provides a structure for managing the complete portfolio of projects. It's all about alignment, alignment with strategic direction, technical ethics, value streams and business ethics.


0:40:45 David Quinn: It's not about individual project team, we need to be able to support those project teams by making them successful with other project teams. And so you're trying to figure out how do we get all these multiple projects to play well with each other? And that's where we see a lot of organizations struggling with Agile, is that capability to get everybody to play well with each other. So that we can still stay Agile, but look at it from a wider perspective, not just our own project team's perspective. Some of the inhibitors that we see for Agile, the dependencies on other teams, when you see the different iterative cycles, we're doing ours every two weeks. Another project's doing theirs every three weeks, another one's doing them every four weeks. That's hard to synchronize and get work done appropriately. But also when you're depending on other teams that are not using Agile approaches, that makes it more difficult to integrate and have those interactions going on. Well, one of the bigger ones is the lack of support mechanisms outside the project team. So, to address the problem, the scale Agile folks decided they need some sort of framework that takes the Agile from just the individual project team level, and brings it up to an enterprise level, that we can manage across project teams. And so that's where they started work from the scale Agile framework.

0:42:01 DQ: It is a public facing framework that applies different lean and Agile practices, to help organizations and project teams to function more effectively using Agile. And we've seen a lot of large organizations actually, making successful use of this. John Deere was one of the early adaptors. Wal, art has been picking it up. Citigroup, Citibank is been in it. Capital One is also one of the bigger ones that are making use of Scaled Agile Framework. Core values of the Scaled Agile Framework: They do worry about alignment. Not just aligning within the project team, but outside of the project team, and with the various business ethics and the technical ethics that are critical to a lot of our companies. They make sure that code quality is a major feature, and that's why you're gonna see how they grab different techniques from strong and extreme programming, and Lean and Combo to combine them into the Scaled Agile Framework. So one of major things with code quality is, they do believe in paired programming. Transparency is one of the biggest things also, because you need to be able to see across project teams, to make sure everything stays in sync.

0:43:12 DQ: It looks at the activities within your relations from three different levels. From the portfolio level, to the programming level, to the project team level. This is the big picture of the Scaled Agile Framework. But the Scaled Agile Framework is there as a framework. So therefore, we wanna make sure that we're tailoring to our organization specific needs. So let's start at the very top of the big picture, with the portfolio level. And what it is that, from an enterprise perspective that we're looking for, and what we're trying to deal with at the enterprise level. So first of all, the enterprise has to set a strategic direction that should be influencing all of the projects that we're working on. And so this is where we get into things like, we've decided that we're not just gonna create little computers on cell phones anymore, we're gonna put them into watches, and see if we can get people to buy watches that have major computers in them and everything. And so that's our strategic direction. And so now we're trying to align all the different projects that we have ongoing? To that strategic view.

0:44:20 DQ: We also have the technical ethics. What are those things that we need to fix, or that we're trying to address new technology changes out in the marketplace? And so those technical ethics are out there as well. A lot of what we try to address at the portfolio level, are these things called value streams. What is it that's gonna add the most value to us as a company, to us as a business, in order to meet customer needs, in order to grab more market and everything? So, we're looking at what are those things that we value the most to get into our products as quickly as possible? All this is maintained in a portfolio backlog. So the organization, the enterprise, as a whole, is defining what are those things that are key? And so in addition to now, the projects and programs are gonna have some customer requirements they need to deal with, our business ethics and our technology ethics now help fold into there as well. At the program level, we're trying to create our program backlog, which takes in both the user's requirements, as well as the portfolio requirements that are represented in the portfolio backlog, and try to figure out what do we need to release at various times into the market, to satisfy our customers' needs and everything? But by having our program backlog tracing back to the portfolio backlog, we're also starting to introduce things like requirements traceability.

0:45:50 DQ: Where would do our releases? From a program perspective, we talk about things in terms of releases, and we create these things called Agile Release Trains. And basically it would be, "Woo woo! Everybody come aboard!" It's trying to make sure that all of our projects are aligned together, trying to target an overall release that we're gonna do on a periodic basis. As part of our release planning session, we make sure that everybody on all the project teams, and all of our project owners are at the same meeting. So it's actually a two day event to come up with the overall release plan, as to what's gonna be worked on, in say the next six months release period. And so now we have everybody that's involved, meeting together and talking about dependencies as well. And what's nice about this, is that everybody then commits to the work that's gonna be performed. Also at the program level, at the end of each time box, we are still getting these potentially shippable increments. But now, at the program level, it's our job to increment across project teams, to have an overall product sweep, to have an overall deliverable from that actual release.

0:47:07 DQ: This is also at the program level, where we do the Scrum of Scrums, which has been the traditional solution to having to deal with multiple project teams doing Agile, you tend to have your Scrum of Scrums, but you need to come up with who's going to lead the Scrum of Scrums, and all that sort of information. Well, that's what Scaled Agile Framework defines for us. It tell us how the Scrum of Scrums is operated, it tells us that our trained engineer is in charge of the Scrum of Scrums, to make sure that all the things stay in sync with each other. And so we're helping to deal with those interactions, those dependencies across project teams. We also have the teams coming to do their sprint retrospectives, where they're looking at their personal performance, and trying to improve the team's performance on a regular basis. One of the differences though with the Scaled Agile Framework is, we take those lessons learned, and bring them back to the overall Agile release training. And so part of the power of the Scaled Agile Framework, is it builds in that lessons learned sharing, so that other project teams can learn from each other, and that we're improving overall as an organization, not just on a per project team basis.


0:48:24 KL: So, what was your take away from today, it's supposed to be about actionable intelligence? 

0:48:28 S?: Well just that times are changing with technology and software, and I think our techniques have to change as well.

0:48:37 S?: I was actually thinking about how there's some general principles of Agile that could really be applicable to the work that our member associations do, which is actually more in the engineering field.

0:48:50 KL: With all the disruptions in the marketplace, organizations today need to be agile in order to maintain their competitive advantage. Encouraging us to be "agile-icious", David Mantica, President of the American Society of Professional Education, has some great ideas about how organizations as a whole can be more effective.


0:49:12 David Mantica: There's a fundamental business issue or an economic issue going on that makes Agile so exciting for companies today. That fundamental business issue isn't going away, it's actually gonna continue to get bigger and bigger. We're disrupting products faster and faster than ever before. We gotta get comfortable with it, we have to get used to it, and we have to learn to build management structures around the disruptions that are occurring in our marketplace. When we think about disruptions, we gotta be thinking about speed. The speed that the market changes is astronomical right now. You gotta maintain your productivity in order to meet the adaptations that you have to deal with in order to gain that competitive advantage. And guess what? Competitive advantage is economics turn. It means you do something better than somebody else does, which makes you more efficient and more effective, and you can make money that way. But it doesn't last very long any more, because it's constantly disrupting, it's constantly moving and changing. But we have to be organized and structured in a way that we can jump at those opportunities when they become available to us. Change is paramount to competing in today's marketplace. In order to compete in today's marketplace, even government folks, government has to compete.

0:50:33 DM: Compete for services, compete to make sure that you're client constituency are providing the things they need, or you're gonna lose credibility. So, you have to compete, which means you need a management in an organizational style that allows you to adapt to change. The ability to predict the future is impossible in today's marketplace. So you don't know what's gonna hit, you don't know when it's gonna hit, and how it's going to hit. So what that means, is you have to be able to organize and structure yourselves in a way that allows you to handle the unknown better. Fundamentally speaking, Agile is about adoption to change. So if you're looking for a way to handle change, Agile gives you the opportunity to do that, but it also comes with a crazy management construct. But that crazy management construct is important because of what I'm gonna show you. CLO Magazine, Chief Learning Officer Magazine, 2014. Look at those numbers, 50% up to 70% of managers fail, 30% of workers are engaged, only 30% of workers are engaged. One in five are actively disengaged. What does actively disengaged mean? 

[overlapping conversation]

0:51:55 DM: And they're subverting the situation for their own intent and purposes They're not following where the company is trying to go, they're trying to go where they wanna go. They're negatively using their influence. Engagement is the single most detrimental situation in business today. Stress illnesses are going up by 23% in the last four years alone. Heart attacks, diabetes, mental health issues are growing significantly in our working environment, because we're not managed appropriately. Our current structure has been to hire the most effective worker to become a manager, yet being a manager takes skill sets outside of what the workers do. And this is part of the thing if you remember anything about Agile for leadership and management, there's a skillset to be a leader and a manager in Agile is significantly different than what we've done in our command and control structures. It's not about measuring and monitoring performance any longer, it's about enabling increased engagement for higher levels of productivity.

0:53:05 DM: We gotta start looking at management leadership as a way to grow people, break down road blocks, set vision and direction, set goals, communicate goals and reset goals. There wasn't a single things about monitoring on that list, there wasn't a single thing about reporting metrics, there wasn't a single thing about talking to someone about doing their job a certain way. A manager and a leader in Agile doesn't care how the sausage is made. The team makes the sausage, the team figures out how the sausage is made. I don't care how the sausage is made, as long as it's ethical and legal. You solve it, you make it happen, I'll set the vision, I'll tell you what goals I wanna hit, I'll communicate those goals on a regular basis. Our requirements have jumped astronomically, because everybody knows what they want now, because everybody is IT enabled, and the solutions that we have available to us have increased exponentially.

0:54:03 DM: Which means we live in this house of anarchy. Look at share point. How many times have share point pop up in your organization all over the place? It's like bamboo, because it's a technology that's easy to get. The other thing is the project law. Market set are great. Scheduled costs, scope, budget, whatever you want it to, the triple constraint. What happens when I meet my triple constraint and my customer's not happy? We gotta start looking at meeting need, more than initially making your triple constraint. Agile fundamentally is a way of working, it's a way of working based on principles and values that've been around for 39 or 40 years. There's nothing really new on the value and principles of Agile. The practices are new. Waler Fall versus Agile. If you come out of this presentation with one, the fact that Agile is a way of working, and number two, understanding that you have a plan driven approach, which you hold the plan as constant. Or you have an adaptive approach which allows your scope to be variable. Agile tries to get as close to the future as possible before you lock in your scope. SO, if you can get as close to the future as possible to predict the future, their is a lot more value in returning something that is needed.

0:55:33 DM: So another way of looking at it, you flip the triangle around. In the predictive model, you fix your scope and you hold your date and cost flexible, meaning that's your change order. The Agile model, you lock in a time box, an iteration, a two to four week iteration, so your date and cost are locked in in that time box, but your scope is ever changing. Walter Fall, you have to throw everything in the kitchen sink into your scope, because you just don't know whats going to happen 12 months from now. So you can't have anymore scope creep, or you're already gonna be way over budget. With Agile, since you're predicting the future in smaller segments closer to the future, you're not gonna have that much wasted effort over time, you don't have to do so much extra work. Remember, as leaders, if your gonna start trying to drive Agile into your organization, it's not a natural way of working folks. So you've gotta have attrition, and you've gotta be able to asses your teams ability to handle that, or you may have to look at rehiring.

0:56:36 DM: Industrial work is all about managing and measuring performance. Knowledge work is all about engagement, and creativity, and problem solving. So an Agile team has a product owner, and an Agile team has a a scrum master. The product owner is on the business unit, and the scrum master is on the development unit. The scrum master is the Agile evangelist. They're the one's making sure the team is agile-icious, for lack of a better term. The scrum masters skill set is different than what a traditional project manager is. Because remember, part of the problem of the scoping phase is you don't know what you don't know. So you allow for show and tell, and whenever you show something, the visual representation of it's amazing. How many words do you think a video is worth? A one minute video is worth 1.2 million words, according to a forester researcher.

0:57:29 DM: I think the most important thing is, one, is visibility? Remember in a Waterfall project, a traditional project, you get no visibility during the production phase. During an Agile project, you get visibility every iteration planning session. Foundationally speaking, Agile is a way of working. It's a way of working that really changes the way we have to manage. It changes the way we have to manage because of self organization. And when I first heard of self organization, that's what I thought. I thought chaos. How can the team come together and self organize and decide what's most important, how are they going to work on something, how are they going to get stuff completed? But the thing is, if you can drive a self organized construct, the first thing you have to treat everybody in your team like an adult. That's a critical piece of self organization, because a lot of times the leader or manager sees their workers as their kids. The reason Agile works and works well, is because of self organization, self organization's ability to provide a team autonomy. That's critically important. If you are ready as a leader to drive an Agile team, you have to be willing to give up and provide that team autonomy. And then what does your power process in return? 


0:58:54 KL: What is your big take away so far from what you've seen today? 

0:58:57 S?: I just attended the most wonderful... So I'm actually going to talk about it. Jason Gallow presented "Left of Charter," a strategic planning overview for project managers, and he was incredible, really really worth my time.

0:59:11 KL: What did you learn? 

0:59:12 S?: I learned a lot. One thing I learned, was that when people go into the store, they not only buy diapers, but beer as well. Fish where the fish are at was his big thing, make sure that for strategic planning you're going to the right place.

0:59:26 KL: So naturally, we just had to include Jason Gallow. Milestone Four, the final milestone. Our point of view shifts again to the organization's external focus. Not just fishing, but finding where the fish are. And they move. What does the project manager need to know to get connected to the right market? Jason Gallow of Cisco Systems tells us how to build a strategy for market share.

0:59:54 Jason Gallow: One of the basic strategy tools that I talk about, is "Fish where the fish are at". I've actually sort of modified, if you will, that old adage of, "Give a man a fish, he eats for a day. Teach a man to fish, he eats for a lifetime." But you can teach a man to fish, if he's fishing in a bucket, he still won't catch any fish. It's going that one step further to discover where are the fish at in the first place, that really starts to define that vision of the goal that you're going after? And there's actually a set of tools and techniques, specific questions, that executive management will typically go through, "Where do we win?" It's not just about winning in the current markets you're in. That maybe changing your vertical, that maybe changing specific product plan, that maybe reinventing your entire company, because the customer's demand, where those fish are at, they shifted. The second thing is how do we win, or how do I actually win in that particular market? And then the last is, the value of winning. And a lot of people focus on profitability, I think it's common to think of profitability. But the one I'll talk about today, or at least highlight, is market-ship. So your strategy is not based on just profit margins, that I make 5% versus someone else who is gonna probably make 6%.

1:01:08 JG: No, it's how many more of those 5% chunks of the pie can I grab? One of the things that Cisco uses to find out where the fish are at, if you will, or to communicate that out to the organization, is something called a VSEM. It's a technique that every director or above has to know if you want an organization system, everyone has a VSEM. One page, very simple. You should be able to communicate out to every project manager, every part of your company your vision, which is the five year focus. Your strategy, which is how will you actually get there and differentiate yourself? A two to four year window. Your execution item. In the next 18 months, I will have these five projects. Now I want the project element right in this execution. And then the metrics, and there's a series of metric that I may follow on a weekly basis, a daily basis, whatever it needs to make sure that all the way back through that chain of events, till five years out, I'm achieving that business outcome of VSEM.

1:02:05 JG: So let's talk about a case study, involved and promoted to C Level Executive at Kodak. You're one of the most successful companies on earth, you're probably sitting proud, and someone tells you, "The market has changed. We're gonna shut down a ton of projects and change things. You've been going strong since 1878, we can see you've changed some logos over time, about $25 billion in market cap. You've got 140,000 employees. You can't shake this foundation, our company will go on forever. Did it, or did the fish move? 

1:02:44 S?: The fish moved.

1:02:45 JG: In 1970, I believe it was '76, this gentleman came up with the first digital camera. He was a Kodak engineer, he brought it to the board and he said, "Guys, the world is going digital." "No, it's not. We define ourselves as a global photo processing chemical business. Steve Sasson, get out." He took his idea somewhere else. Now granted, it's not the greatest thing to look at. [chuckle] You've got this guy who comes into the office, it costs about $10,000, it's almost four pounds worth of metal. "This is the way it's going." You're a chemical company executive. Okay, that may fall on deaf ears at first, but look at what the market is telling. The market is starting to shift overtime from 95 where "Yeah, you're right, it is chemical and photo processing, but the fish are moving." The fish, look at all the categories that are now memory, digital camera, photo print, digital imaging software. Literally, all of the photo finishing category, the market share in each of those elements started to shrink up. So what do you do if you really miss the boat? Well, here's what Kodak did. In 2000's, they're not gonna shift their strategy, "We're just gonna execute better, our projects are gonna deliver faster." They improve efficiency. "I want better scope schedule budget." Okay, it didn't work. "Well, get the marketing team in here. Change the logo."


1:04:21 JG: It didn't work. "Alright, you know what? Film... People just wanna do it more often, that's where it is with digital, they just wanna take pictures more often. Discount the film." Didn't work. Let's start launching new ways that they can consume the film, disposable cameras." How many of you remember those where you had the slider thing? They started selling disposable cameras. We'll even get into ink jet printers, just to stay in the ink and the chemical side of things. So, the pace has changed, disruptively disrupted. About two weeks ago, I was at Cisco's sales meeting, and our CEO, John Chambers stood on stage and said, "Disruptively disruptive. 40% of you in the audience", this is our audience full of 25,000 of our customers. Our customer, he said "You won't be here unless you disrupt or resurface up." Imagine telling your customers that. It made the news, and everyone's was like "Oh my God, John Chambers told his own customers they won't be there." And everybody was saying "No, he's right." Look at what's happening with the pace and change in the business models. Uber, Airbnb. "If I'm helped in a Marriott or Sheraton, I'm never gonna leave, I'm a hundred plus year old company. I have bricks and mortar hotels everywhere on this earth. Airbnb came in, and that's what made them, their margin.

1:05:45 JG: The whole point of this is to make sure at the end of the line, you're not just being productive and getting things done, but that's you're being strategic and you're getting the right things done.

1:05:58 S?: How do we think strategic, how do we do that as project managers, think outside those... 'Cause we think we're doing things right.

1:06:06 JG: I think it is a little bit difficult sometimes if you're a project manager, but you're closer to the customer, and that's invaluable to anybody in a executive position. Because the higher up you get, you don't want to, but you get more and more removed from the day-to-day customer. So, I guess my recommendation would be, learn how to frame the things that you're seeing, so that when you communicate the map up the chain, they understand the gap that you're trying to communicate.


1:06:38 KL: We want to thank Marcus Parker, 2014-15 president of the Silver Spring Chapter for inviting us to record the second annual Silver Spring Chapter Symposium for this podcast. Thanks to the many presenters for letting us record them, and special thanks to the presenters you have heard on this podcast; Lisa Hammer, Laura Bernard, Reed Spearman, David Offenkrantz, Phil Magrogan, Mike Hannan, David Quinn, David Mantica and Jason Gallo. Thanks also to the many men and women on the street interviewees we recorded. And to the ones we heard on this podcast, Christine McKenna, Prasanna Menta, Jeffrey Coleman, Terry Hyman, Ron Ames, Joe Williams, Sara Leinen and Tony DeLunca. To find out more about the presenters and the tools and graphs used in their presentations, visit the Silver Spring Chapter's website at

1:07:29 S?: Our theme music was composed by Molly Flaneur used with permission. Post production performed at M Powered Strategies, and technical and web support provided by Potomac Management Resources.

1:07:42 KL: For PMPs that have listened to this full podcast, you may record 1 PDU, currently category A Directed Learning, by entering C046, the Washington DC chapter, and event code P-M-P-O-V-0-0-2-0, entitled Hot Topics from the PMI Silver Springs Symposium.

1:08:06 KL: I'm your host, Kendall Lot, and until next time, keep it in scope and get it done.

1:08:12 S?: This podcast is a Final Milestone Production, distributed by PMI WDC.

1:08:17 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.