image of office building behind podcast titleAdvances in PM Part 3: The Organization Leans In

August 22, 2016  |  Time: 1:00:19  |  Subscribe in iTunes

Projects exist within the context and value requirements of their organizations. This episode looks at three angles the organization can (should!) take to get the right projects designed for the strategy set by executives and the organization as a whole.

From design, to portfolio management, to identifying where the projects may fail the strategy as they generate and collide with organizational constraints, these guests Charles Black, Steve Butler and Dr. Alan Barnard speak to us from the international community of PMs.

What we learn? We need more than a focus on how to manage a project, we need to think how our organizations can lean in to get the right projects doing the right things.

Listen online or read the full podcast transcript below.

About the Speakers

portrait of Alan BarnardDr. Alan Barnard

Goldratt Research Labs

Dr. Alan Barnard is one of the leading experts in Theory of Constraints (TOC) in the World and worked directly with Dr. Eli Goldratt, creator of Theory of Constraints, for almost 20 years helping organizations from both the private and public sector implement Theory of Constraints to achieve more with less in less time.

Today, Alan is the CEO of Goldratt Research Labs (USA) whose primary focus is to develop and test new knowledge and new applications of Theory of Constraints. Alan also serves as the Chairman of African Phosphates (RSA) and the Odyssey Institute (USA). Alan is also the past-President of TOCICO (2003 to 2005) and serves on the judging panels of the Southern African Logistics Achiever Awards and Technology Top 100 Awards.

In 2009, Alan was awarded a PhD in 2009 in the field of Management of Technology & Innovation by the Da Vinci Institute with a thesis titled “How to identify and unlock inherent potential within organizations and individuals”. He is a frequent presenter on Theory of Constraints at international conferences, has published a number of articles on this topic and is also the author of 2 chapters in the 2010, McGraw Hill published, Theory of Constraints Handbook.

Alan is also the chief architect of HARMONY ( - a Desktop, Web and Mobile app used by hundreds of organizations around the world to design and validate their organizational strategy and tactics, to plan and monitor their implementations as well as to resolve strategic and tactical conflicts. In 2013, Harmony was nominated for the prestigious Silicon Valley Business App awards.

Additional Bio information available from:

portrait of Charlie BlackCharlie Black

Xundis Global, LLC
Co-Founder and a Managing Partner

Charlie is the Co-Founder and a Managing Partner at Xundis Global, LLC, which specializes in navigating complexity through creative & reflective application of design, strategy and planning to realize favourable futures.

Charlie is retired Marine Corps Officer with over 26 years of diverse leadership, planning and operational experiences on three continents with conventional, special operations and coalition forces. His formative design experience emerged while leading a high priority national security initiative within the Department of Defense from 2008-2011.

Charlie is currently focused on an initiative to inculcate design thinking across the Special Operations Enterprise. He has collaborated on the development and teaching of novel design thinking practices, as well as enabling practical design inquiries for several clients.

Additionally, he serves as Senior Advisor to Leadership Under Fire Inc. of Brooklyn, NY. He also teaches as an Adjunct to both the National Intelligence University and the Joint Special Operations University.

portrait of Steve Butler, MBA, PMP, PfMPSteve Butler, MBA, PMP, PfMP

Avner International

Steve Butler, MBA, PMP, PfMP, is founder of Avner International, a portfolio management consulting firm based in Hampshire UK and has over 20 years of experience in portfolio, programme and project management.

He has most recently worked with companies such as HSBC, Holley Holland, Zurich Insurance and Vodafone, and is current working with Old Mutual Wealth in Southampton England.

He is the current Chair of the UK Portfolio Management Forum, is on the core committee responsible for writing the PMI Standard for Portfolio Management 4th Ed (due for release mid 2017), is one of the creators of the PMI Portfolio Management Professional qualification (and now sits on the panel of reviewers for applicants for the PfMP), and regularly addresses conferences on the subject of the Agile Portfolio.

Full Podcast Transcript


0:00:03 Kendall Lott: There are plenty of examples where projects or programs have been instituted, executed well, but in the end the world changed so the end goal was no longer relevant or maybe needed to be different.

0:00:17 Steve Butler: The modern world is doing more for less and getting to market quickly. If you're tied up with lots of processes and stuff you've gotta go through in order to start doing a project, that ain't gonna work.

0:00:29 Alan Barnard: You could actually analyze the whole system by analyzing the performance of the constraint.

0:00:37 Kendall Lott: This is the third episode in our series on Advances in Project Management. Every time I interview an innovator or a thought leader in the PM field, I'm told I should contact yet another thinker or innovator with a parallel theory, a different angle or an interesting approach. I just follow the threads and see where they lead. In this episode our focus is on portfolio management and the organization's approach to project management. I was able to speak with experts on three continents, all speaking the same language, project management. And they all share the same goal, trying to envision the most efficient, effective and durable organization. One point that resonated among all three was that project managers should be looped in and included in discussions of the greater organizational strategy and that they should have a clear understanding of how their projects fit into the bigger picture.

0:01:23 Voice Over: From the Washington DC Chapter of the Project Management Institute, this is PM Point of View, the podcast that looks at project management from all the angles. Here's your host, Kendall Lott.

0:01:35 KL: After serving many years in the military, Charlie Black teamed up with fellow veteran, David Sears, who you'll be hearing in an upcoming episode about security, to create Xundis Global. They use design thinking to help organizations transform and align with an emergent future.

0:01:52 KL: My business partner and I both are military and we worked on some really complicated and complex issues, and traditional planning and ways of thinking that were overly structured, which has a purpose, were not sufficient. And so I began to explore what are other ways, I'm missing some tools, started self-educating myself on design, futurist thinking and other areas like that. I've done a lot of design inquiries, which is the process where you help an organization learn about themselves and the environment and which direction they want to go. I call that CRISP thinking.

0:02:30 KL: Is that an acronym? 

0:02:31 KL: The C stands for Critical and Creative. The R stands for Reflective Reframing. The I is Iterative Ideation. S is Systemic Synthesis. And then the P is Possible and Paradoxical Futures.


0:02:49 KL: The charter for a project is one of the most important documents. What is the input to that charter? Clearly, the project management professional can help shape that with the boss who's considering whatever it is he or she is trying to achieve, design thinking can be applied to help you better frame that charter; more importantly, to inform the judgements of the decision makers as to what project should or should not be undertaken.

0:03:17 KL: So it's more of a portfolio look. Now, does it help shape what that project should look like? Or rather the output of the project? 

0:03:22 KL: I think it can be both. So dependent upon if you're doing a very small project, it can be very specific. Clearly, you wanna give as much leeway as possible to the program manager, you wanna give them, essentially, the left and right limits, but they need to know what success looks like, what is that.

0:03:42 KL: Design thinking takes me to what success looks like? Or it helps me...

0:03:44 KL: Design thinking will give you the left and right limits of what that is. So depending on... If you're talking about an IT system project, that's very definitive, very complicated, but you can quantify that. There are some projects transforming an organization where humans are involved and it's more than hardwire, that's a little more difficult. And so because we live in a complex world, if you define it too precisely, then you set yourself up for failure before you even undertake the project. So design thinking will help you determine what is a reasonable bounds, how to delimit, essentially, the future that you are trying to achieve.

0:04:22 KL: I'm hearing scoping. Scoping at the portfolio level and ultimately down to the projects that are in that portfolio.

0:04:27 KL: Yes.


0:04:32 KL: So at the highest level, what is design thinking? Is it steps? Is it a process? Is it a way of thinking? 

0:04:36 KL: It is a way of thinking. There are many designs and there's many ways in which you can apply design thinking, so it's a very large field. It's best described as a transdisciplinary field. PMP is very underpinned by the scientific tradition, meaning repeatable, there's a hypothesis, there's evidence. Design thinking is a little less structured than that. And so for many individuals in the program management field, design thinking's gonna seem a little uncomfortable.

0:05:14 KL: Tell me something about the process then, let's go ahead and dig into that a little bit.

0:05:17 KL: So design thinking, my interpretation, there are many, is the first is to appreciate the current context. If I'm in a corporation and I'm in the PMO office, I need to understand the environment that I'm in. I need to understand the problem that the executives perceive for which they're considering some sort of project. The first is to appreciate the context. That's where you're going to gather as much information as possible about as many things as you can. My experience has been more in the government sector dealing with human beings, and so in that case I'm looking at the constituencies that are involved. What are the different constituencies? What are their interests? How are they all connected? What are their goals? What activities are they undertaking to achieve their goals? And how are all these things connected? 


0:06:11 KL: The second aspect of appreciation is, this is where it gets little more cognitively difficult, because now you're jumping into a future which does not yet exist, and you're trying to imagine that which does not exist. And then in the end, you're gonna describe it in a way, so that it can be brought into the real world with a purpose.

0:06:31 KL: And this is for current state appreciation.

0:06:33 KL: This is for appreciation. So there is the current context. This one is sort of, you could call it step A. The second is, what is my desired future? 

0:06:42 KL: Gotcha.

0:06:43 KL: If you're undertaking a short-term project, that's not so difficult. You can plan this thing out. You can use program management principles, put some good people in charge, and with the right resources, you can make it happen. But what if you're doing a multi-year project, and the stakeholder analysis, based off as you describe, is your stakeholder register is huge. But those actors are changing over time. Their interests are changing over time. To know what exactly your desired future is, they don't know what they want in the future. Their interests are gonna change. And so, what design thinking helps you do is help you consider a range of futures that might emerge. You might have one that's most optimal. If I were to be able to draw on the board here, I would draw you like a range fan, and there would be a range of futures that you would shoot for. Now, as you progress towards that desired future, you have to continue to do appreciation. So you don't do it once.

0:07:47 KL: 'Cause you're refining.

0:07:48 KL: Right. So you don't do it once, and then write the charter and then begin executing the project. Someone, somewhere, it could be the project leader, it could be the sponsor of the project, someone has to continue to do the appreciation to continually evaluate the efficacy of that project. Because maybe the situation has changed, and it's no longer relevant.


0:08:16 KL: Around those futures, do you say, "I can show you this range based on six factors." Like, cost could be a factor on one. So we have some very high cost stuff to very low stuff, and there's a whole range in here. So we can look at cost, we can look at whatever. Or even the characteristics about these futures, are there some tent poles there, or some outlines of the characteristics you look at? Or is that also part of the kind of completely informed...

0:08:40 KL: I think that that is all situation dependent, but I think a good starting point are the major variables that you already consider in program management. You could use cost, schedule, you could use some of those. However, I would not be too tied to those. It's a good starting point to begin your intellectual inquiry. For example, your company has asked you to undertake a program to upgrade the IT system, let's just say. The larger question is, where's the company gonna be three years from now? Meaning, is the corporate vision that the company's gonna remain the same in terms of revenue generation, size, numbers of offices? Or do they envision all the sudden now, they plan on being in emerging markets and having future offices? That's gonna shape, even though that's not been formalized, their thinking about this. That's gonna shape the direction of that project, right? And so, if you were to implement the project today, "Well, I only have three field offices, so my IT plan, I'm considering three." Well, now, three years from now, the project was successful, because it did what the charter said. But the reality is, you could've had implemented a better project if you had considered these range of futures that might emerge.


0:09:58 KL: So when you do the futures planning like this, or futures thinking, as...

[overlapping conversation]

0:10:01 KL: Planning yet, are the futures comparable, or literally comparable? Are you be able to say, "Well, now that we've thought out a bunch of ideas, I can look at future C versus F and kinda see how they're different." Is there a way to look at that now? And that would only work if you're asking some of the same questions.

0:10:18 KL: Right. If you ask some of the same questions, you could do that.

0:10:22 KL: Or do you find that you often can't actually compare these questions because they're so radically different? 

0:10:26 KL: Usually, there'll be sort of categories will emerge, from... So you could predetermine what those categories are, but I think that limits your thinking. It's better to take this intellectual journey and consider. And then afterwards, then you determine what the categories may or may not be.

0:10:46 KL: So you're right about these cognitive piece, we're not even planning how we're structuring thinking about the futures in a certain sense. We're capitalizing post facto, after the fact.

0:10:55 KL: If you do it ahead of time, then you're predetermining the solution and you may be limiting. Does that make sense? 

0:11:01 KL: Sure. Sure.


0:11:05 KL: So that was the appreciation phase.

0:11:07 KL: So the appreciation of current context and the desired futures is about 60% to 70% of your intellectual capital.

0:11:16 KL: So what are we heading to next? 

0:11:17 KL: Defining the problem, and then developing an approach.

0:11:20 KL: So walk us through defining the problem.

0:11:21 KL: Okay. Defining the problem is really when one juxtaposes the current context and you juxtapose that against this range of desirable futures. There are things that would prevent the transformation from one to the other. Some of these are physical things, bureaucracy, etcetera, process. Some of these are cognitive, culture, mental models, bias.


0:11:48 KL: What does the definition of a problem look like? What's the nature of a problem? 

0:11:51 KL: It's a declarative statement. So corporation X's executive culture undermines their ability to see the future world, which therefore, they make poor judgments about what programs should or should not be in place. So, as we go to the next phase here, the development and approach is a little bit of the easiest part. That's focused on from a strategic perspective, what are the things that need to be undertaken to address that problem? Usually, the problem isn't one specific thing. If you're talking about organizational culture, that's pretty significant. You would have to break that down into smaller pieces. You're not gonna do one thing to resolve that. So, as you develop an approach or develop an approaches, some are gonna be some near terms, some are gonna be the long-term. So, think of develop and approach more as strategy.


0:12:49 KL: When I was looking at this a few years ago, design thinking to me struck me as an example of a very strong visual component. This audio podcast, we had some issues with...

0:12:57 KL: Yes, so they're...

0:12:58 KL: Is that where that comes in to help drive this part? 

0:13:00 KL: Yeah, so design thinking, so if we go back to the appreciation part, humans are visual learners. So, a big dry erase board where you can creatively just make connections and you can see it in totality. This is not about reductionist thinking, this is about synthetic thinking. This is up and out...

0:13:18 KL: In connections? 

0:13:19 KL: In connections. So, the dots that you draw on the board are not the most important. The lines between the dots are more important. The value that you place, the interpretation you give those relationships is more important than the dots themselves.


0:13:38 KL: So, at the project level, then, what's an output from the design thinking level that drives the charter? What does a project manager end up getting to see that helps inform that charter? 

0:13:48 KL: Okay, so one, I'm confident that you identify stakeholders that you wouldn't otherwise.

0:13:53 KL: So, they see a broader list of stakeholders? 

0:13:55 KL: A broader list of stakeholders. I think the priorities of those stakeholders in terms of their importance I think would be changed. So, therefore, the project leader is gonna interact with individuals that they one, that they probably wouldn't have considered at all. And two, they would interact with some individuals more often than others, based off of this appreciation. Two, I think it helps you set the problem in context. What is it specifically that the project is focused on achieving? So, the initial intuitive answer, I think what you're gonna end up in the charter, is gonna be... They're gonna be different.

0:14:33 KL: Does this help set measures for success, then? Not so much for the performance of the project, but the output of the project? They know what the product really has to be able to do to drive...

[overlapping conversation]

0:14:41 KL: Yes. I think this helps those that are participating in the projects have... They all have a deeper context for how their contributions fit. Therefore, the project manager can... And all the others that are on the team can make better evaluated judgements during execution, because they have a better understanding of why they're doing it, where they're going, they'll understand the timescale better. So, this...

0:15:07 KL: It's context.

0:15:08 KL: This is all about context.


0:15:14 KL: Project managers tend to receive the charter, and they decompose from there. They start from, "Okay, this is the thing and it has some implication of an outcome. And I have to get us from A to Z, and I get to do B to Y." And I have to figure that out, and we use some structures for doing that. We decompose the work, we decompose the benefits, possibly. We decompose the budget. We align budget to work and timing on the schedule. We call that earned value. We do all sorts of tools and techniques that we can do to help people understand better, and to understand the work, and perform the work, and monitor their work.

0:15:47 KL: How do you determine how much reserve you should have? 

0:15:50 KL: From the beginning, right? 

0:15:51 KL: But how do we make that judgment today? 

0:15:53 KL: That's the intuitive part, isn't it? 

0:15:55 KL: It's not really intuitive. You can do design thinking and you look at the range of the futures, you know the range of things that might emerge, what the potential risk associated with that is, and then the rate of change. If I'm undertaking a near-term project where the rate of change isn't great, I might have less risk from my perspective. If it's a four-year project and the world is volatile, and I'm an international corporation, then the rate of change is very high. Therefore, my ability to predict two, three, four years from now is much lower. Therefore, I need to have a much greater reserve, because too many variables can change that could affect my project, so I have to account for that.


0:16:42 KL: Now, let's say I'm a project manager and I've received a charter, what can I be doing to think about this? It may be in a more traditional organization that didn't have the foresight to bring in a design thinking organization.

0:16:53 KL: Well, the boss is gonna say, "X, Y, and Z is the problem. Go write a charter and fix that." Some organizations, you would get the group together and you would write the charter, and you would then immediately begin executing. I would argue, "Woah, woah. The boss thought about this for five minutes," so your first and foremost goal is to question is that really a problem? You're gonna come back with a charter, but you're gonna do some thinking before you write the charter. Because the charter might come up with solving a completely different problem than the boss thought was the problem.

0:17:21 KL: It's an output of this whole process. It's not an input.

0:17:23 KL: Correct.

0:17:24 KL: It's almost like the last thing we even think about here at this point in the game.

0:17:27 KL: Yes, but what do we do? We tend to focus on, "The boss said this is the problem. Let me go fix that problem. Well, let's evaluate whether that's the right problem. Let's place that problem in context. Let's set that problem in context. He may have gotten it right, but maybe he scaled it improperly. Maybe it's too narrow or maybe it's too big."

0:17:48 KL: So, what do we do? We go through your three-stage process, is that the idea? 

0:17:50 KL: Yes. And then maybe the answer, you come back to your boss and say, "Boss, you thought there was a single project. In fact, we actually see three separate distinct programs."


0:18:03 KL: So they've heard this. So am I inviting project managers to do this or am I suggesting that they really need to make sure they get a chance to do this? What's our obligation here? 

0:18:11 KL: I would say that they have an obligation to help the decision makers before they invest resources, clearly understand what it is they're being asked to do and why, and evaluate the efficacy of that undertaking beforehand. Otherwise, you could begin to execute a project or a program, execute it perfectly, but the corporation, the entity in the end doesn't benefit, because it was achieving the wrong thing.


0:18:48 KL: For more information and resources, just Google 'design thinking'. You will find a number of articles, schools and experts, or you can email Charlie at That's X-U-N-D-I-S. Xundis with an X.


0:19:13 KL: It was Joe Sopko from our Advances in Project Management Part II episode who urged me to contact Steve Butler. Steve is a globally acknowledged expert in project portfolio management, and has handled portfolios in a wide range of industries, automotive, software, insurance, finance, research and more. He is a co-author of version three of the PMI Portfolio Standard, and is currently working on version four. He's also writing a book on agile portfolio management. Oh, and he has a day job. Steve heads up the portfolio management office for Old Mutual Wealth in Southampton, England.

0:19:48 SB: Traditional portfolio management is very process orientated. The modern world is doing more for less, and getting to market quickly. If you're tied up with lots of processes and stuff you've got to go through in order to start doing a project, that ain't gonna work. So it's taking the concepts of an agile mindset from the project space into the portfolio space. It's being more nimble, been more reactive, being able to react to what's happened in the market place quicker. You got to be flexible in your approach, that's what agile portfolio management is.


0:20:29 KL: What are the key reasons for portfolio management from what you've actually experienced? And as I guess you're writing your standard, right? 

0:20:35 SB: You can think of projects as delivering stuff. You can think of program management as delivering stuff in the right way. Portfolio management is delivering the right stuff. As soon as you start being engaged in discussions on what's the right stuff, that can change very, very quickly. That's why the agile mindset at the portfolio level can be a real money spinner. If you've got that flexible mindset, so that you're doing the right thing more often, you're gonna be closer tied to your strategy.

0:21:06 KL: So if I'm looking at a portfolio, I normally think of it as, "I'm looking at all the assets that are declared as part of this portfolio, and what their overall return is and the trade off among them." It's a return on investment question, correct? 

0:21:16 SB: Exactly. It's a great comparison. You can compare a project portfolio or a product portfolio to a financial portfolio. And if you look at your financial portfolio once a month or once every six months or once a year, you're not gonna get the return that you could get. If things change quickly in the financial world, you have to react. Similarly, if things change in whatever market you're in that the portfolio you're managing in also changes quickly, you have to be able to react. If you're surrounded by processes, and you're not in control of your portfolio, you can't do that. And that's agile portfolio management.

0:21:49 KL: Is the calculation of what's considered valuable different when you have agile projects, in the sense that you have a series of shorter projects that are trying to create a return faster? Is the calculation then of that portfolio more difficult, understanding what's more valuable or less valuable in the portfolio? 

0:22:04 SB: No. What becomes more difficult is you have to have an understanding of how closely aligned to your strategy, your projects are. So if you're managing, say, 10 projects, and an 11th comes along, traditionally what happens is that management will say, "We're gonna do that one as well." And you just max your people out. If you do things in a more agile way, you should be able to look at that 11th project that's come along, and figure out how closely that's aligned to strategy, whether it's gonna generate more income, more return on investment, if that's what the strategy is, and have an educated discussion and decision around whether you do that 11th project, and terminate project number six or delay the 11th project until you've finished the 10th. Where agile portfolio management differs from the more traditional portfolio management is being able to react quickly to something that comes along, like a new project.


0:23:01 KL: So what is it you're gonna need to be able to let that happen? It strikes me that there's some sort of a method of understanding data before you even have projects.

0:23:09 SB: It's actually deeper than that. We all know that when you implement agile, I will scrum at a project level, the challenge is that you're changing the culture. That's an even bigger challenge at the portfolio level, 'cause you're changing the culture of the company at a more fundamental level.

0:23:23 KL: Really? Because most of the time, we talk about projects in alignment to strategy. To me, it's the issue of knowing the data that would show that one is more aligned or not, or one has a better return.

0:23:32 S32: What you're up against when you're talking at portfolio level is the age-old, the 12-month financial budget cycle. So you're up against that. If something comes along where all of a sudden, you need to invest X amount of dollars, if you're tied into a 12-month budget cycle, that's a very, very difficult conversation to have. Changing the culture of a company to be more agile at portfolio level is a far, far bigger challenge than trying to do it at project level.

0:24:00 KL: What have you observed that is needed in terms of information that would drive that compelling decision to interrupt the 12-month budget cycle? 

0:24:06 SB: You know it's happening anyway, because companies are being driven to do more for less, and to being more reactive to the marketplace. You cannot do that if you're gonna be tied into a 12-month budget cycle, etcetera, etcetera. So the markets and modern corporate life is changing the attitude.


0:24:29 KL: I have a portfolio of projects, and I realize that I need to be able to respond more quickly, but my culture hasn't changed yet. I've got the budget, I'm told this is the IT budget or this is the product budget, or whatever. How do we begin to take those steps? 

0:24:43 SB: That's a very good question. Where I've commonly seen it happen is where something comes along that needs to be done and the culture of the company blocks that happening. Where there's been a change in the market or your competitor or something's changed with a competitive product, and a company has to react quickly. You can pinpoint several companies that haven't reacted quick enough. A classic example is Nokia. Nokia used to virtually rule the mobile phone market place and then along came Apple, and people's attitudes changed completely what they wanted to have telephone calls on, and Nokia didn't react. It's that sort of thing that makes people realize they have to change the culture.

0:25:30 KL: It seems to me there's still some sort of information feed that has to happen where someone says, "Look, this isn't in alignment, actually this is not giving us a return that we need."

0:25:40 SB: Exactly. This is where the link with the stuff that Joe is into with the organizational project management, that's where it comes together very well.

0:25:46 KL: That's Joe Sopko. His point of view is that responsible project managers and responsible executives should keep the communications channels open for just these kinds of conversations.

0:25:56 SB: Because it's the people of that level that typically will identify, "We have to do this differently." And that's how you get the message across to the executives.

0:26:06 KL: Actually, that's an interesting point, as well. I think a portfolio management has to somehow measure return on the assets in the portfolio, right? 

0:26:11 SB: Correct.

0:26:12 KL: So you can measure the value of what is actually the return to a project, or what is the expected return to a project based on somewhat normative and somewhat objective data, both, I think. But what you're making an argument for is that it's about alignment to these external things, the adaptation to something very rapid. It's no longer about the supposed return at the project level, but what you said, is it the right mix of projects to begin with? How can you possibly measure that? What do you have in place or what do you ask to be able to determine that? 

0:26:41 SB: Where it starts is the corporate strategy. You have to assume that the corporate strategy is correct. Now that's a very, very big assumption to make. If you assume the corporate strategy is correct, then you can rate the activity that you're doing within a portfolio, and by that I include operational activity as well, which is something that's very often missed. But you can rate the activity that you're doing within a portfolio against those strategic drivers. And that's how you score. Now, it can be a financial thing, but it can also be, for example, if you're talking about a charity, you can be talking about a different sort of value you're adding. But the crucial thing is that the underlying corporate strategy has to be correct.

0:27:23 KL: Yeah, that's what I'm thinking. It's not a failure project portfolio management in Nokia's case, but rather at the strategy level, right? They didn't feed down to it. They had the wrong strategy.

0:27:32 SB: Indeed. One of the things that I brought up in the very early days of doing the third edition of the PMI, Portfolio Management Standard, in those days it was very much seen that there was a one-way journey from the strategy, to the portfolio, to the road map, to programs, to project, etcetera. If anything's happening during the execution of projects that makes the people on the coalface think, "Hang on, we're doing the wrong thing," there needs to be a mechanism where that can be fed back to the guys making the strategic calls. Now that didn't happen with Nokia. The guys that were doing the telephones knew damn well they were doing the wrong thing, but the message never got through. That's not a criticism on Nokia, that's a very, very common thing. It's a cultural thing, and it's a big change to have to make. But if you're scoring your activity, rating your activity against your underlying strategic drivers, that's the way to success.


0:28:30 KL: So that's an alignment question, or a total value question? How are you seeing those two things? 

0:28:34 SB: Both.

0:28:34 KL: Okay. Can you give an example of how you'd set up a scoring mechanism in that way, that's the kind of thing people probably wanna be able to hear.

0:28:40 SB: You need to identify all your strategic drivers. For example, I wanna be the, I don't know, the biggest water bottle manufacturer in Texas, for example. Well, why do you wanna do that for? Do you wanna make money? Do you wanna get people drinking water? Do you want people to be living healthily? You've got to identify what your strategic drivers are, what it is that's driving you to do the stuff that you wanna do. Then once you've identified that, you need to identify what the capabilities you wanna have within the company in order to accomplish those strategic drivers. Once you're talking about capabilities, then you're talking about the projects you need to do. Once you've identified the projects, then it becomes relatively straightforward to score those against the capabilities and against the strategic drivers, so that if something else comes along, or if something changes, you can very easily see how those projects rate on that scale that you've devised. But it very much depends on whether it's a financial thing you're trying to do, whether it's another value add you're trying to make.

0:29:41 KL: This logic seems pretty compelling and kind of even in a certain sense traditional. But what's different is, one, you need a feedback loop to find out that the projects you are doing are no longer scoring against those drivers properly. Our customers have shifted or something like that, the Nokia example, for example.

0:29:57 SB: Correct. Yeah.

0:29:57 KL: The other one is, is I think you said something about breaking or having a culture where that feedback loop matters into the decision making, and by decision making, investment and budget. So I can't be...

0:30:07 SB: Yeah, absolutely.

0:30:08 KL: "We've discovered this problem, but we'll wait until 17 months when we're done with the next budget routine."

0:30:13 SB: Yeah, absolutely. And it's more fundamental than that. How many people out there are working for companies, and they haven't got a clue what their strategy is? How many companies out there will spend millions of dollars identifying what their strategy is, and go nowhere with it? They'll develop a portfolio, they'll develop a road map and it goes nowhere. How many CEOs are being fired because effectively their portfolio management's been very poor? It's taking the concept a really fundamental level. It's taking the concept of a daily stand-up where, you're doing a software project and your guys will stand around in a group for 10-15 minutes saying what they've done yesterday, what they're gonna do, and what the blockages are. You take that to a portfolio level, it's immensely powerful. Trust your people. You employ people to do a job, trust them, listen to them.


0:31:04 KL: But what is the thing they report against? What is it that they talk about that becomes the standard? And I think setting that standard seems hard to me, or it seems like there's a data flow question to me still, that informs a feedback loop, or am I missing something? 

0:31:17 SB: No, you're not. It's related to that logical chain that I'm talking about. It's having a core strategy that everybody identifies with. It's identifying what the strategic drivers are related to that strategy. It's identifying what the capabilities are which enable those strategic drivers to happen. Once people have bought into that, and that's the crucial thing, is having everybody understanding and buying into it, because the thing that traditionally is missing, is understanding. Now, if people can understand what you're trying to do, they'll buy into it. The metrics around how you score this stuff is... To my mind, it's less relevant. Once you have everybody bought into it, then the rest should become easy. There's so many ways to score projects in a portfolio against your strategic drivers. Having the accuracy of that scoring, that's the fundamental thing, and in order to get the accuracy of that scoring, you have to have understanding and buying into your corporate strategy.

0:32:19 KL: If the team is informed and can feel trusted, they'll actually tell you what's working and not working, and then the executive in charge of that has to be ready to act on their behalf having heard that information.

0:32:30 SB: Correct, and that's the agile there. And that's what I'm talking about with the culture change, and that's difficult.


0:32:42 KL: So where does this go from here? What are you seeing as a future for this? 

0:32:45 SB: I think agile portfolio management's gonna be huge. It's still a very... It's a very immature profession, it's still being learned.

0:32:55 KL: People listening and getting excited, what should they be reading? What should they go and pay attention to to get a sense of what's happening here? 

0:33:00 SB: Do you know the best book I've ever read on this subject is the chap who turned around IBM, Lou Gerstner, wrote a book, 'Taming The Elephant', I think it's called.

0:33:09 KL: That's 'Who Says Elephants Can't Dance? Leading a Great Enterprise Through Dramatic Change', by Louis Gerstner, former chairman and CEO of IBM.

0:33:20 SB: You read that book and it's all about portfolio management. It's all about the way portfolio management should be done. I recommend it to everybody, it's a fantastic book. But I think the underlying message I would put across is trust your people. The number of companies that have succeeded in an agile way just through trusting their people is phenomenal, it works.


0:33:52 KL: From South Africa, Alan Barnard is an industrial engineer by training, and later went on to complete a Master's and PhD in Management of Innovation and Technology. He worked very closely with the late Dr. Eli Goldratt, writer, thinker, scientist, creator of 'Theory of Constraints', and is currently CEO of Goldratt Research Labs, which works with complex, private and public sector organizations to find innovative and sustainable ways to achieve more of their goal units in less time, with the same or less resources. I Skyped him to find out what his Theory of Constraints was all about. Through the course of our discussion he shared a new development within the Theory of Constraints, strategy and tactic trees.


0:34:31 KL: Talk to me about The Theory of Constraints, what is it and why does it matter? 

0:34:35 AB: The Theory of Constraints is a body of knowledge that is trying to explain why are constraints important if you're trying to analyze, manage and improve any system. It's important from the perspective that the traditional way of trying to analyze, manage and improve systems is you try to analyze every part of the system, try to improve every part of the system, and manage every part of the system, and you hope that by doing that the whole system will be improved. Of course, the reality is that it often results in local optimization, we're short of optimization. So, the essence of the Theory of Constraints is that you can actually analyze the whole system by analyzing the performance of the constraint.


0:35:36 AB: Step one of the Theory of Constraints, the five focusing steps, says, "Identify the system constraint." Once you've identified the system constraint, the second step is, "Decide how to better exploit this constraint and not waste its potential." Once you've identified how you waste this constraint's potential, typically by doing things you shouldn't be doing. In production, for example, it's over producing, right? It's producing a minimum batch of a thousand, even though the customers only want 200. So the third step in the five focusing steps is, once you've decided how to better exploit the constraint, you have to subordinate everything to that decision. That basically means go and look at any policy, or measurement, or behavior that's in conflict with the decision of how to better exploit and not waste the constraint, and change only that part. Don't change all the parts, change only the parts that's in conflict with this decision.

0:36:44 KL: So there's an efficiency of this analysis is what we're really getting at, almost? 

0:36:49 AB: Yes. It's almost like providing you with a mathematical fast track. It says to you, if you're trying to understand the performance of the system, you can understand it with an approximation of understanding the performance of the constraint. So and a very simple example is to say, "If my constraint can only do 10 per day, guess how much the system can do?" Well, the system can't do more than ten a day on average, but it will always do less. Where do we lose potential is whenever we starve the constraint, or we block it, or it's over-producing things that are not required, or it's down for planned or unplanned maintenance, for example, or there's a quality problem, then we will get less than the 10. But by studying the constraint and seeing, "Ah, its potential is 10, it's actually doing only five at the moment, and that five that's being lost, some of it is being lost because of down time, some of it being lost because of blockage or starvation." Subordination, step three, is all about change the policies or processes or measurements that are in conflict with that decision. So go and put buffers in place. Make sure that the constraint is never starved or blocked.

0:38:14 AB: The fourth step is to say only once you've exploited the constraint that you've got, so you're getting close to the 10 and you're leaving some predictive capacity to deal with fluctuations, only then do you elevate the constraint, do you go and get more of that scarce resource. The last step, of course, is if you want to continuously improve, be careful if you've removed or overcome a constraint in one of the previous steps. Don't let inertia become the constraint.

0:38:44 KL: Meaning what? 

0:38:45 AB: Meaning don't get stagnated at that level. Go back to step one and see has the constraint moved, and if so, go through the process again.

0:38:54 KL: Yeah, in theory, I we see this on critical path analysis, for example, in project management. If you remove that constraint you must find another place that becomes the new constraint.

0:39:05 AB: Right.

0:39:06 KL: And the way you ultimately get to that is by having step four, pump more resources in to increase the machinery to get you past the 10? 

0:39:15 AB: Right, but what tends to happen is you tend to have a process within a department or agency, or even the whole agency that's not meeting the demand. How do we know that? Because we're starting to see queues building up, backlogs, right? And their first reaction is we need more people, we need more budget, we need more resources. People tend to automatically jump to elevate, whereas what they should have done is to say, if I'm an IT division within a government department, it's my main developers that are supposed to fix bugs and develop new functionality. How much of their available time am I actually exploiting versus how much time are they sitting in meetings doing things that they shouldn't be doing, etcetera? So let's first figure out how to ensure they only work on the highest priority items, because that might release enough capacity to meet the demand already. Rather than trying to improve the whole department, it's to say find the bottleneck, the one resource that do not have enough capacity to meet all the demand. Before you go and add resources, before you go to step four, which is elevate, first see if you're fully exploiting that resource. Exploiting here is not in a negative sense. Exploiting is fully utilizing the potential of that resource, and not wasting it by doing things that it shouldn't be doing.

0:40:47 AB: So one of the areas that I've personally been working on in terms of developing a body of knowledge is to look at the concept of a constraint or a bottleneck. And when you ask somebody, "Where is the bottleneck, or what is the bottleneck, or what is the constraint", what I've realized is that the answer exists at three levels. The first level, the highest level, is the physical resource that do not currently have enough capacity to meet the demand. If you think about a road that has bumper-to-bumper traffic, it's very clear that during certain parts of the day or the week there's simply not enough capacity to cope with the demand, the number of cars on the road. The same is true in a factory where there's a machine that during certain parts of the year, or month, or week, or day, or even continuously, simply doesn't have enough capacity to meet the demand.

0:41:55 AB: But that's a physical constraint, it's the highest level of a constraint. But you can also apply that to people, so when you think about, "Where is our bottleneck?" and that is it in fact a title of the book that I'm writing at the moment called, 'Our Bottleneck,' is that our bottleneck, the thing that really limits us to do more of the things that will bring us closer to the goals that we've set for ourselves, is a cognitive bottleneck. We have limited attention. The easy way to check that is I could ask you the number of things that demand your attention or could benefit from your attention, will it always exceed your available attention, and I'm sure you will probably say 'Yes'.

0:42:46 AB: So, that makes it a bottleneck. That's the first step is to say, "What is the physical resource that cannot meet the demand?" The next level below that, the second level, is that resources don't wake up in the morning and say, "I wanna be a bottleneck." There was a decision that caused them to become a bottleneck. Either somebody has committed, too much demand, you've agreed to do too many things at a personal level, or you've accepted too many orders, or too many projects, or, you have made a decision to not give enough capacity, not to put enough capacity.

0:43:31 AB: The second level of a bottleneck is the bad decision that caused the bottleneck to exist. Then the third level below the bad decision is that there's a bad assumption that causing that bad decision. Actually, when we see a resource as a constraint or bottleneck, what we should be doing, is we should be looking at what's the decision that caused that, and what's the assumption that's driving that decision? 'Cause that's the leverage point in the system, is challenging that assumption so we can make better, faster decisions, that will prevent bottlenecks in the future.


0:44:17 KL: This issue of the cognitive bottleneck, the visioning process itself seems to be a cognitive barrier for some people. Can you reflect on that some, about how that works from an executive down? 

0:44:29 AB: Sure, so what we've realized, and this started, I would say, probably around 2009. We were doing very large fear of constraints projects with very large companies and we started asking ourselves the question, "At a company level, what is really the constraint to growth, to profitable growth for that company?" The obvious candidate is it's the size of the market. But then you take one of the biggest companies like a Walmart and you find out they have 2% of the world market, so clearly it's not the size of the market that's limiting their growth. Could it be capacity, or land? No, clearly not. Unless they cover everything with Walmart stores, that can't be the constraint. Could it be supply? No, the same thing, unless they're buying everything that's available on the planet, the supply is not constraining the growth, nor is cash, because if you have a good case you can get... There's always liquidity.

0:45:31 AB: So, what we realized was that the only resource that satisfied the definition of a true constraint, which is that the demand will always exceed the supply, was top management attention. That had a very interesting impact in term of designing strategy, because now it says that if top management is the constraint, step two says, "How do I exploit this constraint and not waste it?" That mean that of all the things I can improve on within a company, I have to decide which ones to focus on and which ones to ignore. So where the strategy and tactic tree comes in, you've got level one that represents the goal that you're trying to achieve. In the case of a strategy and tactic tree as a turnaround for a whole company, level one is basically representing the goal that you're trying to achieve, like profitable growth for my company.

0:46:31 AB: Level two are the changes that we need to make, the necessary and sufficient conditions that will allow me to achieve that objective. But it's sequenced from left to right. So 2.1, if I'm looking at a work breakdown structure, is the first change I want top management to focus on that will help to achieve the goal of profitable growth. What we would normally do if we were drawing up a strategy and tactic tree for a organization, 2.1 would be representing those things that I can do relatively quickly, without significant investment of money or time, and 2.2 will be those competitive edges, for example, I can develop but will take some time and will require some investment. What Goldratt's insight was when he created this type of thinking process was to say that, "The objective that we're trying to achieve is to ensure that everybody's focused their limited attention on the highest leverage objectives.


0:47:42 KL: And I'm noticing something here when you say strategy and tactic. We think of strategy as having multiple tactics and to me there was the insight.

0:47:49 AB: Strategy is the answer to the question, "What for?" What's the objective that you're trying to achieve? And tactic is the answer to the question, "How to?" What is the best way of achieving this objective? Then you realize that, actually, there is a one-to-one relationship between strategy and tactic at every level. At the highest level that you're box one, right at the top. The strategy there would be to achieve profitable growth. The tactic would be of all the ways to achieve this profitable growth, what are we focusing on? Am I focusing on revenue growth? Am I focusing on cost reduction? Am I focusing on revenue growth via organic growth or via acquisition? At that level, they have to make that decision. You can imagine what happens if the CEO only communicates the objective of, "We wanna increase profitability by 20% this year."

0:48:52 AB: Now the next level can say, "Okay, I can increase profits by increasing sales and by reducing cost. I can increase sales by increasing prices or reducing discounts and increasing volume. I can reduce cost by reducing variable cost and fixed cost." By the time that you get to the level four, five in an organization, there are literally hundreds of ways that you could help to improve profitability. The question is which ones of that hundred should they be focusing on? Unless the CEO is providing that clarity at his level, you've got an organization that is multi-tasking like crazy at the bottom levels. There's an idea of forcing the focus at every level by saying, "What's your objective, the strategy at your level that you're trying to achieve? What's the tactic, the best way of getting there?"


0:49:55 AB: Whenever you decide to make a change at any level again, whether that's at the CEO level or right down at the shop floor level, there are at least three assumptions that is important to verbalize very clearly so that you could check it in reality. I call them the three whys. Essentially what you have is a node on that strategy and tactic tree that could be at level one or five, but if I go into that node, there's five parts of that that clearly defines that change for me. I've got the what for, the strategy and the how to the tactic, but then there's the three whys. The first why is why do you claim that this change is necessary? The second why is why do I claim this strategy is possible but difficult? And that will help me answer the question of what the best tactic would be.

0:50:58 AB: The third why is why is the tactic that I've given you not yet actionable information? It's a kind of the third why is typically a kind of a warning that I wanna give you to say be careful about the following things. It's almost like another level of detail is required for you to really understand what to go and do, that it's not yet actionable information. But by listing these assumptions explicitly, it also means that when we go into execution, and I'm either not achieving the strategy, or I'm struggling to implement a tactic, I can then go and check which of the assumptions that I started off with ended up being wrong. So what this idea is of actually explicitly verbalizing the assumptions, it makes it very clear to people what is the logic that has gone into this, why are we doing this, why do we claim this is even possible.


0:51:57 KL: So you do this at every node? From the very first one we need to be profitable, you ended up with these five nodes. The what, for, the how, and the three whys.

0:52:05 AB: Exactly. And you can imagine the level at which I stop is the level at which the tactic is so clear that people know exactly what to go and do.

0:52:14 KL: The question I had then in an organization is who owns this tree-driven approach? Is this specifically the executive walking through this? Is this the idea of the operations manager? It's whoever needs to hone it? 

0:52:28 AB: Every level is owned by that level. What I mean is the level one is essentially owned by the CEO. He then communicates that tactic very clearly to the next level, which is probably his senior vice president. The lowest level is essentially the main projects of change initiatives. That could be policies, processes, measurements that need to be changed, or projects that need to be implemented to achieve the higher levels.

0:53:00 KL: It certainly helps you pick the projects and define the projects at some level. So we get down eventually in the case of new things, projects. And so the project manager is now actually figuring this out, it's probably sitting at the end of this node. It sounds like the same process could be done by a project manager within a team.

0:53:16 AB: I think that taking this back into the project management environment is that most of the methodologies are essentially providing solutions for better planning and execution management or monitoring of projects, but very few of them provide you with any kind of guidance in terms of the first two components, which is, "How do I select the projects?" And secondly, "How do I know the scope of the project?"

0:53:46 KL: I think it does one more thing, at least as we've observed, in some of the organizational effectiveness discussion, which is people working on it know where they fit in.

0:53:56 AB: Absolutely. There are five engines of disharmony within organizations. The first two is what you're talking about. The first one is, "I know exactly what my contribution is". That provides harmony. The second one is, "If I don't know how my peers or other people should be contributing", and again the strategy and tactic tree provides you with clarity on that.

0:54:20 KL: What are the other three? 

0:54:22 AB: The third one relates to, essentially, conflicts. The conflicts are, for example, that my contribution is required on two things, and I haven't been told which ones to focus on. As long as there's conflicts related to that part, I'm gonna be stuck. The fourth one relates to the continuous pressure that people have between whether to change or not to change. The pressure for inertia, and you see that especially in the larger, successful organizations like IBM. I don't wanna be the one that stuffs up IBM, so, actually my bias is towards not changing anything. As long as that's the case, you have some people that absolutely believe we have to change now to achieve this objective or to capitalize on an opportunity, and you have another group that says, "No, we shouldn't change now, it's not the right time." Again, you have a conflict and that will cause disharmony. And then the fifth one relates to misalignments between authority and responsibility. That can cause disharmony between levels.

0:55:41 KL: Are you the person who's supposed to execute at the level you've been assigned? 

0:55:46 AB: Exactly. Have you given me the authority to achieve this objective? 


0:55:56 AB: So what we encourage organizations to do is that every strategy should be assigned to a strategy owner. That's the person that's accountable for achieving that objective. Every tactic should be assigned to a tactic manager, and their job is purely to implement that tactic. They should only be held accountable for, "Did you implement the tactic as we specified it?" If it was the wrong tactic, then the strategy owner would be the one that's accountable for that, because he was the one that decided on that or had to make the final call on the tactic. Of course, the tactic manager can contribute that, but the actual decision that provided the focus was the strategy owner. The tactic manager's main responsibility is purely to implement that tactic and to work with a team that can help them do that.


0:56:51 KL: Why do we do all this? What's the point? What's the value we get out of this? 

0:56:56 AB: As long as the management's attention is being distracted, doing things that they shouldn't be doing, or it's being distracted by their multitasking, trying to do too many things at the same time, or lastly, it's being distracted because of the disharmony and firefighting an organization. Then, by having this type of tree, they will get huge value. Logically, which one is gonna achieve the objective the fastest? An organization that's all working in different directions, or an organization that's completely fully aligned, and that's what the strategy of tactic tree allows you to do.


0:57:36 KL: To learn more about strategy and tactic trees, go to Alan's website at or visit, where you will find a wealth of publications and links to related websites, videos, and other resources. Remember, PMs, a project is worth nothing if it doesn't serve the greater good of the organization. CEOs and other executives are best served by their PMs if they keep informed about their overall organizational strategy. Conversely, PMs can better serve their organizations by voicing concerns or suggestions regarding project design and scope. An effective project manager must always keep one eye on the project and the other on the organization as a whole.

0:58:18 KL: And everyone should look towards the future. Alert to new trends and potential markets. Design thinking helps CEOs gauge and plan for their desired future state. Agile portfolio management allows organizations to take on and eliminate projects as they come into and out of relevance. By using strategy and tactic trees, organizations can keep the lines of communications open and clear, allowing for effective, strategy-driven adjustments as needed. We've come a long way from the original PMBOK, that's for sure, but the beauty is all these cool new methods and theories are out there for everybody to share and work with. The possibilities are infinite. So keep tuning in to PM Point of View for more angles and updates. Special thanks to today's guests, Charlie Black, Steve Butler and Alan Barnard.

0:59:02 VO: Our theme music was composed by Molly Flannery, used with permission. Additional original music by Gary Fieldman, Rich Greenblatt and Lionel Lyles. Post production performed at M Powered Strategies, and technical and web support provided by Potomac Management Resources.

0:59:16 KL: PMPs who have listened through this complete podcast may submit a PDU claim, one PDU, 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 PMPOV0031, Advances in Project Management, Part 3, The Organization Leans In. Make sure to select one PDU under the technical category at the bottom.

0:59:51 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. Or you may contact me directly at You can also find me on LinkedIn. I'm your host Kendall Lott and until next time, keep it in scope and get it done.

1:00:15 VO: This podcast is a Final Milestone Production. Distributed by PMIWDC.

1:00:20 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.