(Danielle): All right. So, welcome everyone to episode two of Project Design, The Good, The Bad, and The Wild. I'm your host, Danielle Wilkins, and we're here having conversations with regular people about project design and what it means for them in their work. So, with me today is Matt Cleary-Kessler. He's a former, well, former colleague because I no longer work there, but he currently works at the World Resources Institute. And so I'll hand it over to Matt to give us a little background about himself.

(Matt): Thank you. And thank you for having me. I feel honored to be a guest and I'm certainly in line with the guest type by being a very regular person. So, I feel like I kind of met my podcast calling here. So about me, I... You mentioned I work at the World Resources Institute, specifically focused on our cities work.

For the past several years, that's been more concentrated on strategy and management. So very much bigger picture thinking, but with an intended focus on how we actually consider implementation.  And with the results kind of orientation, right. Not just going through strategy design cycles for the sake of making ourselves feel like we have a plan and comforting ourselves, but actually trying to sort of bend  that curve of whether it's strategy design, project design towards results, and then actually learning from implementing processes to figure out, you know, did we actually even get proximate to what  we were hoping to. Or did we hit the target? Did we not? And always questions around why.

So yeah, my work has tended to focus on a lot more so, I think, project titles aside, I oftentimes feel like I'm a fixer of broken things. So, I think when we get into the details here, more of my project examples tend to be how I was brought into things that were already not functioning particularly well and trying to bring them back on track. Yeah, thanks again for having me.

(Danielle): Thank you so much for joining! And I apologize in my intro I got your name backwards!

(Matt): It's okay. It's not a problem. It's Kessler-Cleary. But I go by KC, which leads some people to think that I'm from Kansas City, which is not true. I'm very much a son of New Jersey.

(Danielle): Well, thank you for being a good sport about that. I feel so silly, but, on that note, and also just to say, you are not just a regular person. For all of the listeners, I think Matt is one of the most articulate people in the World Resources Institute, which is saying something. So, I'm really excited that he's here to share his experiences with us. And with that, I'm going to jump into the first question, which is: tell us about a project where the design phase fundamentally, in your opinion, shaped either a positive or a negative outcome for the project. And in that initial overview, if you could give us a little context about what the project was trying to do, what problems you were trying to solve, just so we can place the type of work that you were doing.

(Matt): Sure, sure. So contextually, at that point in my WRI tenure, I was working more directly on capacity development type resources. So, trying to develop kind of new content types to go from WRI's very research heavy kind of technical focus with very dense content, and distilling that into things like learning guides, which if you had seen, this was probably around 2018. So Vox.com at that point had started to do these like hard stack formats where it was a very simplified learning structure, sequential, you know, and very, the tone was very oriented towards people who didn't have a background in whatever the subject was, right.

So, we were trying to use it [that format] as a bit of an entry point to draw people, you know, if you  get through this type of learning resource, maybe you might want to read the research product, right. So, that was sort of the substantive focus of what I was working on at that point.

And the project in particular was a pilot. So we had a specific amount of funding to set up an online platform where we would host these e -learning resources and a particular type of content structure with these learning guides. And the idea, again, was to have something that was very easily accessible to a wide range of users, different geographies, different kinds of backgrounds.

But it was a very new product type for WRI. And I love WRI but, new product types at any research organization are sort of met with heartburn and anxiety, I think. Um, so I was brought into the project after the design phase and after things had already started to be, you know, been worked on. And that was where some of those like fixing somewhat broken things came up. Right. We were trying to, again, trying to pilot something new in an institute that doesn't always like to move that quickly, um, for a variety of good reasons. Um, and the project seemed to have been designed.

There weren't a lot of resources that were designed to be resources. We had a grant document and that probably was the closest to an outline of what we were doing that we had, that I could look at. But there wasn't really a plan or any sense of how we were going to engage with internal stakeholders.

There was this assumption of, well, people will be fine with creating this type of product. So, like, we're just going to hit the ground running and we're going to move forward. We're going to develop it. And my entree into the project was, uh -oh, right? People are not responding.

The assumption that people will be amenable to that and okay with it without pushback or concerns about, you know, propriety in terms of who owns this,  who has oversight over it, quality assurance issues, all those things that come up when you're trying to put out something new at a big organization came to bear.

So, the initial problem I was trying to solve wasn't even the problem the project was trying to solve in a different letter, right. The project is trying to solve this ‘there's a knowledge gap. Not everybody's going to go get a multi-year degree or a higher ed degree in urban planning. So how do we fill that gap?’ That's the project's objective, right.

My problem was ‘how are we going to get people on board with actually letting us do this content type, which we've committed to a donor who's not the most flexible donor.’ So that is kind of the lay of the land of a stressful period of time of this project.

(Danielle): Yeah. I love the, well, I don't love that you went through that because it sounds horribly stressful, but I really think the point that you're bringing up about the importance of not just the design process for getting people on board and understanding what you're doing, but having the documentation so that if you have new people joining the project, they understand what happened in the past and what the plan is for moving forward.

I think that's a really important point that we forget sometimes about why we do this. It's rare that the whole initial team works from beginning to end.

(Matt): For sure. And when you work in any organization that's also very fundraising dependent versus you have your own products that kind of fund your work or your own income stream, you also have the handoff between grant design, right? So, there's always something like that where a lot of the people who are more in on developing a grant, or a proposal aren't necessarily ones who are carrying through implementation. So having that documentation now adds sort of that general knowledge base, you know, to give to people.

And it also creates more efficiencies because you don't, you know, there's one person, say the project manager, who was involved in grant design phase as well. It's not relying upon that one person to bring everybody up to speed each time somebody joins, right.

Because usually those people don't have the bandwidth and the time to do that. [And it] detracts from actually managing a project.

(Danielle): Yeah, that's such an amazing point because to your point, no one ever has the bandwidth to do all the things that they're intended to do, at least working in the NGO space. That's been what I've seen and I think what you've probably seen and experienced personally as well.

(Matt): For sure. Yeah. And I think there's a distinction between people who are optimistic and think everything will be fine. And for better or worse, I am very skeptical. So, it's like, I don't think things are going to work. So, I'm putting, my brain is trying to formulate a plan for what if it doesn't work so that when that moment arrives, we're not scrambling to figure out what to do.

(Danielle): Yeah. So, what did you do in this case? Maybe you can tell us a little bit more about it. Because you've already mentioned the effects of not having a good project plan in the beginning is that, you know, you came in, you were really hard pressed to get all your internal stakeholders on board to move forward with this project.

How much time then did you have to spend kind of redesigning or bringing people on board? Bringing the people on board to the work as opposed to actually doing the work like how did how did that manifest in the project implementation?

(Matt): Yeah, it took months and a lot of interpersonal engagement. You know what I tend to see when people get into sort of project management conversations at times within project design is that it's a very systemic view, right. We'll have tools, we'll have templates and things will just kind of march themselves forwards through the inevitability of a plan, or a document.

But it's so much of a human thing, right. And human engagement and understanding how people react to things. So a lot of my initial work on the project was in meeting with the Project Manager and meeting with other people involved to get a sense from them. “What are your concerns?”, or sort of where, ‘what lines have you drawn in the sand’, so to speak?  ‘Where do you stand on this?’

And then building my own first mental map but then trying to actually put together a bit of a visual stakeholder map of who feels what way, right. What are the issues at play? Actually documenting what those issues are, and then working with my manager, the project manager on that to triage and say, well, what are the things we really need to solve for first?

Because there was an absence of a project design or a project plan for me to refer to and say, I get everything. And there weren't a lot of notes that people had taken from meetings to document what the different perspectives were, I took it on myself to spend time figuring that out. You know, so I didn't really know how else we go forward without me having a sense of what the issues are and who has those issues. And then how do we try to build a plan to resolve them?

And that took like seven months because you're meeting with different people and then trying to synthesize things from those individual conversations and having more collective discussions and lots of different organizations. Collective conversations are democratic input processes with variable decision-making. I don't want to call them democratic decision-making processes because you leave a meeting and it's like, well, everybody still disagrees. But they voiced it now.

So, it's democratic input in that sense. It's representative. But then you have these iterative moments of, okay, I know what, how did we leave this discussion? Did somebody come a little closer to a certain position that might be, you know, compromise or what do we need to do to build that, their comfort, right? With compromising on something or coming to some sort of middle, you know, shared position.

So just a lot of that type of engagement and then coming up with and not something super formal in terms of a template and document necessarily, but just a sense of here are the key decision points that need to be made and who needs to be involved in them right, and by when, you know, are there things that we need to do before that to make so that we show up to. If somebody says well I want to see you outline all the assurance process which is the big part of this and we can't sort of wait until another group conversation happens to do that because they're just kicking the can way too far down the road. And we need to actually come with a proposal of what that's going to be, socialize it ahead of time so that you use those bigger conversation spaces to actually come to some sort of agreement on next steps, as opposed to using it as a way to share the information.

 And then people have to go off and think about, well, how do I feel about this? Let me get back to you. Yeah. Lots of handholding, lots of feelings, negotiation of feelings.

(Danielle): Yeah. The point about feelings is an important one. I think it's, you're right. When people talk about, you mentioned when people are talking about project design, there's often this idea of like, there's a template and you're just going to march through it. And that's going to be that. And in this case, it sounds like you didn't even have that. But, the danger is that you forget that these are people. And at the end of the day, even though they might check a box, if they're not emotionally invested in what's happening, you're still going to have problems.

So, is it fair to characterize what you had to do as almost a second design? Or I'm going to use the term design and planning a little interchangeably here. I don't know if you have a feeling about if they should be kept separate, but almost a second design or planning process you had to go through in order to actually get to implementation?

(Matt): Very much so. And on the interchangeability, I think to me, design and planning are, there's not an easy delineation, right? And you're sort of, it's a cyclical type of thing. Now, eventually to that, I would say my view as a plan is some sort of you know, set of actions. You know, it may not be every activity you're going to do, but it's a plan for like, how are we implementing this? And a design might be a little bit of a precursor to that of, you know, what are the kind of big things we're trying to accomplish?

And in general, what are the building blocks? Are we looking at something that's stakeholder engagement oriented? Are we looking at something that's knowledge generation, policy development, implementation of infrastructure, you know, different things like that. And then you can get into a plan of how you're going to do this work. So, tangent there to answer that one part of the question, but yes, it was very much a sort of second round of project design.

Right. And then coming up with a plan for how we were going to move that forward. And it went from a nebulous project concept of sorts of what were the end results we wanted to achieve in terms of developing these pilot products, standing up a new website, into the second kind of more detailed or ground level, I guess, of this projects design, of how are we going to kind of build the collective will internally to enable us to actually get to that end goal?

And so, in a way, I've seen projects that are much more focused on sort of outside of an organization's very external engagement and will be very stakeholder focused engagement, like building collective will. It was turning that lens on ourselves.

Because there wasn't a real external environmental constraint to negotiate. Nobody from outside of the organization was going to say, hey, you can't put together a site with learning resources. That's insane. That violates our principles or something, right? But go ahead and say it. Still going to put it together, right?

So, our only external constraint was the commitment to the donors. So, we had, you know, we had more freedom there in a sense of, you know, what types of content we wanted to focus on and such. So, it was sort of this, it’s within the house type of like intrafamilial project design process of how do we actually get this moving forward to get to the goals that have already been set out.

(Danielle): Yeah. And so you touched on a little bit about the next question I wanted to ask or segue to, which is the, I think a challenging part of project management and the whole project life cycle is understanding where one step ends and the other step begins. It's often a very fluid process, particularly when you're talking about the design, planning, implementation parts of this, of this process. So, from your experience, how did you negotiate the differences between those different steps, between thinking about this high level, getting people on board, and then actually moving towards implementation?

Did you see a clear differentiation between them or was it, if it was fluid, how did you help people understand where they were in the process?

(Matt): A very good question. It was not super delineated in a sequential way. We didn't say, all right, we need to, at least in my mind, we need to wrap up this redesign of the project and then move into implementation. A lot of stuff was happening in parallel because of the time constraint. I think we had a year or 18 months to deliver. So we didn't really have the opportunity to say, “all right, let's revisit the design in a methodical way. And then we'll get into putting together the plan and  then we'll implement the plan.” It was, some of these things have already been started being developed. Like the content is learning guides that we're putting together. At the same time, like there was a huge step of this kind of building internal will, like building an internal process of quality assurance that would satisfy everybody's concerns and actually let us publish those resources that needed to be resolved.

But we couldn't stop developing the content right, so that had to kind of go on.  Which meant there were times where we said actually now we need to move away from “no we can't be prescriptive” was one decision right. We can't say unless it's based on a knowledge resource that has gone through its own quality assurance process we can't actually tell people what to do. We can say this is something you can do - we can describe things, but we can't prescribe action.

In some cases this meant going back to the content people were developing and saying, actually, you need to change the tone a bit of it, right. You can't say implement bike lanes in this way and everything would be perfect. We can say ‘in this place, we have done this and it has done this’. Like we've observed this, right? So much more of an observational consideration.

So, I know that's kind of in the weeds on what the actual project was, but it's how my mind worked around it was we needed to be able to sort of do the redesign on the move. In a sense, and kind of a reconceptualization of what needed to happen to have everybody on board with actually publishing these resources.

And it was messy in a lot of ways. Yeah, there wasn't necessarily like a clear kind of point of delineation, you know, in those different steps, which not ideal. I wouldn't recommend that, but at the same time, I think lots of projects hit a point, especially with how tumultuous I think the context is that we're all operating in nowadays.

And then the expectations you have oftentimes butt up against reality once you start trying to implement. So you're really like, you're always going to have these opportunities where you need to go back to sort of not the full design phase, maybe, but at least the concept, right? And say, ‘you know, we started to implement based on the initial framing and the initial plan we had, but now are we at a moment now where we're observing enough pushback or, you know, new kind of contextual information suggests we actually need to not just adjust some of the actions that we plan, but  actually think about the bigger picture’.

And one of the things you mentioned, I think was really important. The question is really important to me is that you need to constantly help people understand where we are. Sort of what their role is. And sometimes people don't feel happy with what their role is. And there's a conversation about that, right?

It's, you know, we're consulting you and they want to have decision-making power. It's like, well, let's talk about what that means, right? Decision -making power over what? So, you end up in the, I think, a position of having to constantly remind people that we're part of the shared situation, right? You know, it's an extreme example, like people didn't get on the Titanic expecting to actually have to problem solve together. And they're like, you know, we're going on a cruise, right? And then all of a sudden you're in these situations of we need to get on lifeboats, who gets on lifeboats, who does this, right?

And again, it's a very extreme kind of example to bring into this context, but by reminding people of the collective, right, and making people feel not just they're being placated by, oh, you're part of this team, but actually instrumentally involved, right? They give feedback. Even if their feedback doesn't end up being part of the final decision, you help them understand how their feedback was incorporated into, you know, redesigns or, you know, considerations and updates. And then along the way saying, what decisions, again, revisiting this, we have to decide on these things. Where are we with that and who needs to be involved.

And not just having that for myself as a plan of action, but having that as a reminder for the people involved, this is what is expected of you. Maybe you don't want to be in the decision-making and then we can remove you from that. It's fine. We can adapt. But that again, interpersonal and a part of it of making sure people understand where we are, where we're going and what needs to be decided, I think really helped to smooth out those discussions.

I think it brought things to a point where it's a little less contentious of, you know, finger pointing and playing game kind of conversations.

(Danielle): So, I think what you're talking about here is really the importance of what a lot of people would call closing the loop. An idea of really being effective in how you're communicating with stakeholders or just other people who have contributed something to a project about how their contribution is being used. And that's so important. It's also a really perfect segue into our next topic.

But before we get into that, I want to pause for a second and just summarize. So, so far, we've really dug into what happens when a project doesn't have a great design process and it starts to go a little sideways. And Matt’s given us a really great example of an e -learning platform project where the lack of early stakeholder engagement created this cascade of problems.

So, you started having resistance from people. There were quality concerns. There were ownership questions. A lot of things that probably could have been addressed in a project design phase were left to become problems because that design phase did not happen initially. And so he had to go back and really... redo some of that initial design while the project was already being implemented, which is kind of similar to trying to fix a plane while you're flying it. It's not the ideal situation you want to be in.

And a lot of what he said was, for me, a really powerful reminder about how assumptions can be really dangerous. And the design phase is usually where you would interrogate those assumptions. But if you don't have that, it can lead to these issues that we just talked about.

So like I said, we're going to pause here because to be frank, I'm really trying to keep these episodes under the 30 minute mark and we're running close now, but definitely stay tuned. Be sure to subscribe because the conversation is really going to take a different turn over the next 30 minutes.

We're going to get into what has worked for Matt in terms of project design. And he's going to share some of his experiences on things like how to functionally engage with stakeholders. I think that's something that people talk about a lot, but they usually just leave it there. They say engage with your stakeholders. Matt's going to walk us through how he's done that in real life.

We're going to talk about how to build flexibility into your project so you're not stuck with something that isn't relevant anymore when you're going through the design phase.

And then one of my favorites, we're going to get into why you should cook your projects instead of baking that. So sorry all you pastry lovers, but definitely tune into the next episode to find out why you should cook instead of bake. And also how to do all of this with people in mind, not just plans, not just documents, but how do you go through the design phase when you're centering people? and not just outputs.

So, stay tuned and looking forward to seeing you in the next episode!Description text goes here

(Danielle): Welcome to Project Design, the good, the bad, and the wild. I'm your host, Danielle Wilkins, and we're here with part two of episode two with my guest, Matt Kessler -Cleary.

I got his name right this time. Yay.

And we're continuing a conversation that we started last week around how project design can... If you don't have it, it can lead your project to go a little bit sideways.

Matt shared a story with us about an e -learning platform where that project did not have a design process. And when he came on board, he ended up having to redo a lot of those design efforts in order to deal with some of the problems that had arisen, namely resistance from people, some of the quality issues they were encountering, and then some really real questions around who owned what within the project.

He was able to resolve some of those but it took more work and he had to essentially redo the design process that had not happened in the beginning.

So today we're going to switch gears a little bit and instead of talking about how not having design can hurt your project we're going to talk about what are some of the things that help, that are helpful when doing a design process.

And so Matt's going to share his experiences with us and I'm just going to get right into it. We'll kick it off with the first question. So here we go.

So Matt, in part one, where we left it off, I think you brought up something that was really interesting for me. And that's because we were talking about stakeholders and how you're keeping them engaged. Um we started to touch on how we're keeping them engaged and I'll just preface this by saying you know I’ve read a lot of books and guides on project design and almost every one of them will tell you that you need to consult your stakeholders.

Which, on the surface, sounds like a great idea but what's often left out is how to functionally do that when the reality is not everyone can make a final decision.

So usually, you have one person or maybe a small group of people who are ultimately responsible for deciding what's going to happen with this project, how things are going to be allocated.

But the people you're consulting is typically a larger group. Not everyone that you're talking to to get feedback can be part of that decision -making body. And they all have different opinions and different influences on what they're saying, which are valid. And they're giving you, they're investing their time in giving you this feedback.

And as they're investing that time, you know, they're becoming emotionally invested.

Which is good on some level. That's what you want. You want people to be emotionally invested in the project. And you want them to have a say in the work.

So how do you handle the situation, though, when... you have gotten all of these opinions and you've gotten this  feedback from people, but at the end of the day, the people making the decisions have decided to go against that opinion.

They've decided to take another direction.

How do you continue to keep that group of stakeholders involved and invested in your project when their feedback might not be resulting in the outcome that they want, but you still need them to be engaged with a project?

Have you had to deal with this in the e -platform example or any other projects? Because this is something that I've really struggled with is keeping people engaged when you can't incorporate their feedback.

(Matt): Yeah, it is a constant challenge. I mean, in the work that I'm doing more now compared to the project we're going over, which is more focused on sort of monitoring, evaluation, qualitative learning in particular, to then inform strategic decision -making, which makes it sound super simple. It's not.

Yeah, you know. But there's a constant cycle of getting people on board and like helping people to understand their roles. And some of it is trying to extend more agency in the process, but doing so when it's genuine, right?

 I think it's a... We run into problems where we disingenuously offer agency and a process to people who actually aren't going to instrumentally have it. Right.

And I know I'm using sort of bigger jargony -ish words here, but if you're not going to actually listen to what Matt has to say about this, don't ask Matt for his input.

Don't make it, don't set me up to be disappointed that you're not listening to me because I didn't ask necessarily to be listened to. Right?

So, you have to imagine if you're going to open that door, you can't kind of open it a crack and say, well, just whisper in my ear what it is you want and then slam the door on somebody's fingers, right?

Because you're trying to actually get in the room.

So, what I try to do is if there are moments where the reality is a certain group of stakeholders or an individual stakeholder will not have that agency in a process, right? is to be transparent about it and say, here is why. Right.

And even if there are instances where say I thought that somebody would, so I kind of gave them that impression and then other powers that be said, actually, no, we're not going in that direction anymore. Right. Is to go back to the people and acknowledge, I thought this was, you know, path A was what was going to happen. We actually ended up going down path like Z or X.

And. Not blaming other people for it, but helping them understand what the change was.

At the end of the day, we are human beings, right? I mean, it's oversimplification in a sense, but people want to have some validation and visibility. And even if it's giving visibility and space for them to voice their opposition, you know, or their grievances about a process.

That giving them the space to do so and hearing them out and not just saying, thanks for your input. And now moving on, but like, thanks for your input and showing them in some way how you're trying to adapt to incorporate it, even if not in full.

In part, I think helps people feel like they're part of, whether it's a team, an organization, a project, whatever the framing of the grouping is, right.

I think it helps people feel a sense of belonging. collaboration, commitment to something.

Mission-driven organizations have a bit of a blessing and curse with that, right? It’s people really care about the work. So, it's not as difficult to make them feel engaged if you tell them the objectives of a project, right?

But they also have very strong feelings about it. So, when it doesn't go the way they want it to, it's not just, oh, we, you know, office space, like we work on TPS reports or whatever it is.

I don't really care about TPS reports. So, if they get screwed up, like whatever, right. I'm not emotionally affected by this.

So, it is a bit of a push and pull there with opportunity and then how to sort of harness the passion that people have, right. Without creating too much disappointment.

For me, a summary, I think of sorts would be continuing to focus on what drives people, right.

You know and understanding what also demotivates them.

And that isn't a generalization that can really be made. Right, like different individuals have different things that make them feel involved and make them feel disengaged.

And yes in project management it's I think more obvious that you have to attend to that right kind of pulling those different levers.

But it's also important for project design and project planning to understand how the different people who you expect to be involved in the project and also how, say, the constituents or those who stand to be affected by the work, what is the best understanding we have of their motivations, their concerns, and factor that in, right?

So, you know, speaking a bit to a project that we had in a different geography, it's very much on external implementation. You know, it was about infrastructure and bike lane development.

And it turned out that the bigger issue wasn't that people hated bikes and bike lanes. It was that they felt they weren't consulted in the development of the plans in their neighborhoods.

So, it went from a project that was focused on kind of high -level summary. How do we do the infrastructure development? How do we plan for that?

To a project that was focused on community communication engagement. So that people would stop tearing up bike lanes with like hammers, right?

Very like guerrilla warfare on the bike lanes, right?

So, another example of like understanding, and sometimes you don't know that ahead of time, and the team  did a great job of adapting and recognizing, you know, we thought our project was about something which they had designed thoroughly.

And it turns out it really wasn't, you know, the how of the project wasn't what they thought it would be based on the environmental response with people being part of that environment.

(Danielle): Yeah, I think that is a really important point when you're talking about design and planning is that this is not a linear process. It's a loopy one that is constantly going. You make it step, you take, you know, maybe one step forward, maybe two steps back.

You're constantly going back and forth.

And, and you mentioned that a little bit earlier when we were talking about, you know, is there a clear delineation? And, you know, of course it would be great if everything just moved in this nice, smooth, linear process.

But the reality is, you know, things change.

People recognize that the assumptions you made maybe weren't correct or that you missed something.

Um so yeah, that's that's a great point about how remembering that we're all people in this and it's not just about the templates and the check boxes.

It's about how do people actually feel about these things and you know do you understand do you really understand how people feel.

Do you care, like do you care to know how they feel? um

(Matt): And some people on a project, you don't have to actually care, right?

Like instrumentally, you don't have to build their perspective into the project because realistically their power to influence it isn't significant enough or perhaps the impact that maybe they may receive from a particular project isn't of greater concern than say your target population.

So, you know, those bike lanes might really annoy the people who want to be able to park right next to the sidewalk. But are we worried about them or not? Right.

(Danielle): Are they the ones taking the hammer to them?

(Matt): Right. Yeah. Business owners it turned out and just people on the street, like, because in that case, right, like people have this concern of if you can't park in the street, they won't get business.

Actually, all the studies show the opposite, right? That if you open it up to walking and remove parking access and lower vehicular traffic, then miraculously business booms, right?

But it's stuff like that, right? Like we don't have to convince the car drivers to stop driving and parking and caring about that.

You have to convince the people who really have more of a say in the structure of that community and that local area that it's in their best interest to allow this type of infrastructure because it will actually have

a beneficial effect on what most concerns them.

And to your point about the non -linear nature of projects, to me, it's shoots and ladders.

(Danielle): That's such a great analogy!

(Matt): And you really hope that you're only getting the ladders, but you know, it's like, okay, if I roll a two or whatever, like I'm going down.

So how, at least compared to the game, you lose some of the chance of like, how do I avoid making that number of moves that this project is going to go down and shoot, right?

(Danielle): Yep. Actually, I love that so much. I don't think I've heard anyone talk about it in those terms, but that is such a great analogy because you're right.

Sometimes you can see ahead and you can try to roll the dice. Sometimes, you know, you're just unlucky and you get a bad roll and you're going down.

To the extent that you can you're like let me not throw this die super hard so I should hopefully I'm gonna hopefully get like the two instead of the six or whatever.

But, um, no that that is such a great point!

Um i know we're running a little low on times, so I just want to ask you one more question and then we'll we'll wrap up with um kind of your vision for where you think design should go.

But the last question I wanted to ask on really the fundamentals of implementing this is around guarding space for the design process.

Because you talked about how you had all these different stakeholders that you had to bring on board, but at the same time you had pressure from your donor to get things done on this timeline and I’m sure that they want to see action right.

And I don't know if they thought having these conversations with your internal team was really action?

So how do you, yeah, how would you recommend folks in this situation guard that time for the design process?

Cause we've already, I think we've established that the design process was important.

It was important enough that it didn't get done the first time. So, you, you just had to do it again in order to move forward.

But how do you make the case for the space to have those conversations especially given what we talked about before about the need to to take into account the people that you're dealing with which takes time right?

It's not a five-minute conversation. Usually that's a trust building exercise that takes time.

So, how do you guard the space to build that trust to really get people engaged in your work

(Matt): Yeah, at a broader socialization level, like trying to build these skills institutionally, having success and sort of failure or struggle examples seems to be pretty compelling to people.

Yeah, I do think if you can demonstrate from the success side that going through a particular process, particularly not just me, say in a sort of broader view, but people who are working on a particular project team.

You know, can say, yes, going through this design phase helped us in these different ways.

Maybe it helped us secure the funding because the donor said, “I really see your vision here”, right?

Maybe it helped us hit the ground running sooner so we weren't waiting for, you know, six months after getting funding to then figure out how are we putting the team together, right?

You know, where are the band members? What's going on here?

That can help, but... candidly, but the stick also helps is showing people if you don't do this, this is what can happen. Right.

And you know, helping people understand from experiences I've had, you know, if you don't give the design phase enough attention, it can take you three months to get a project up to speed when you don't have it. Right. And then it compresses your delivery schedule for everything else.

Um, in a more kind of one -on -one or small group conversational space, asking people kind of challenging questions, not totally challenging, right? Like how dare you or, you know, anything of that nature, but more if I see gaps to the thinking, asking a question about the gap.

One, because it gets them thinking about, you know, in their response to it, oh, I haven't considered that, right?

Because oftentimes we make, we conceive of projects as a, dream scenario and getting back to the mission -driven part, or even in business, if you are super excited about a product you're going to develop or about an impact you might have on the mission -driven side of things, people want to just run with it and hope that it's going to come together.

And we're not getting them to sort of download in a sense what's in their brains from a vision standpoint and unpacking it. And the prior perspective about giving people success or challenge examples, I think can help to shift or raise awareness at a broader organizational culture level.

But it's not really enough when you get down to a particular project, right? And really developing it in that sense.

And what I find works better there is having some sort of template or resource that disaggregates and unpacks the concept.

So, you can't just say we're going to build beautiful cities. Everybody's going to be happy. You know, we do this one thing and it's all solved. Right.

What do you assume needs to happen to get to that point?

What are those assumptions based off?

And it gets a little into kind of the theory of change development stuff that we share an interest and also an exhaustion, I think, from as well.

(Danielle): Yes. That'll be another conversation.

(Matt): Whole other podcast. But yeah, getting people to really unpack their assumptions about a project and doing it in a facilitated way where it's not just, I sent you a template and you send it back to me and I give you comments on it and say, nope, still not good enough.

But actually, you know, put together a template of some sort that gives people space to kind of do pre -work for a conversation. And then heavily load the discussion with deliberation, right? Like, or just more energy, I should say, right?

Don't inspect people and clarify, I'm going to send you this template, but it's to help us have a more in -depth conversation. It's not for you just to compliance, like fill out a template, right?

And then use that discussion space to ask them questions that sort of draw out what they might not be looking at.

And oftentimes that can be that human element of, you know, you say you're going to work with the government. Does the government want to work with you? What are the government's priorities? What are the risks of, excuse me, working with the government and not with local constituency groups, right? Or communities, right?

So, or what's the risk of the inverse, right? If you work with the communities, maybe the government doesn't like that you went around them.

So, interrogating some of those things.

And, you know, I love the little like, why though? meme. We're just always like, why, why do you think this is going to, why will X yield Y? Right.

And the more people go through that, I think they find value in it, just the thought process of it. And then they start to become kind of champions for it, right? If they perceive the value.

So hopefully if you're working in the same organization, the more you have those discussions with people and put them through that type of process, the less you have to convince people to do it because word of mouth helps, right?

But it's just like project design is important in and of itself for the project. Getting people convinced early on that project design is important, is important, is useful for everything that comes after, right?

If you front load your effort on that and you will see kind of the results of not having to constantly try to demonstrate the value to people.

Folks will say, oh my gosh, that person has such a great experience with, you know, such and such team or process. How come I didn't get that?

And that, you know, fear of missing out is a massive driving force for people to then say, I want that too. So -and -so got it and I didn't.

And all of a sudden people are sort of, you know, kind of beating at the door for your help or for this type of a process of project design inception.

(Danielle): I love that. Make it, use FOMO against people. No, not against people, but what is the, what is the term I'm looking for? It's like a marketing term that is, it's commonly used creating scarcity in a way.

You're almost creating scarcity of, oh, this is a really cool thing and you really want to get in on that.

I'm sure if there's anyone in the comments who knows more about marketing, please tell me how to characterize this appropriately!

(Matt): Yeah, but some sense of exclusivity. Yeah. Right. Like that seems like a cool thing and I want it too. How come I haven't been told about this?

I'm happy to tell you about it.

I'm happy to work with you on it.

(Danielle): You can be part of the cool kid club. If you come join us. Yeah. Um, no, I think that's such a great point. And, um, one that needs to be highlighted more on how we make this something that people really see value in and they want to join.

So, to wrap it up though, for our last question, I want to ask you, what do you think that we should be talking about? We being the industry as a whole.

We've had this, us, the two of us have had this great conversation and we could talk so much. We could talk about so many other things, but as a whole, from a project management industry perspective, what do you think we should be talking about when it comes to project design, that we're not currently talking about much these days?

(Matt): So many answers.

What comes to mind is helping people to see that design is a map. It's not a detailed work plan, right?

To something you mentioned before, what's the distinction between a work plan and project design? It’s that you're not, design needs to be something that is flexible enough that as you adapt, it doesn't require you to restructure the entire design. Right.

So, you need to have enough specificity to know where you're going.

And now if you're planning a vacation, you need a destination. Or you at least need to know, like, am I going to the beach? Am I going to the mountains? What are we doing here?

And then you can figure out like how you're going to get to that destination, right?

You know, a plan can then help you with a little bit more specificity, figure out the how, right, of that journey. But still, you know, staying away from this.

And I see it a lot from certain donors, this desire for rigidity of activity planning.

And then we need to consult because activities always change for a variety of very legitimate reasons that don't have to do with laziness by the project team, right?

So, leaving that flexibility so that we're not making planning processes, making design processes a straitjacket, that then actually is detrimental to the implementation side of things.

Because teams spend more time negotiating with a donor or some other oversight body that they're accountable to about what changes they want to make, such that by the time maybe they have that buy -in, the moment may have passed, right?

The opportunity, or the context has changed further. And now you agree to this other thing that because we were too slow in adapting, now the decision we made is really not best fit for the context.

So, getting away from this sense that we need to have a very detailed recipe of sorts, you know, the cooking versus baking.

I’m full of like weird analogies today, so apologies.

(Danielle): No, I love them. They've been great.

(Matt): When you're baking, it's scientific and I'm not good at it, right? Because it's, you have to go through these detailed steps.

If you forget to add this thing at this moment in time or your temperature is actually off, like it's going to screw up everything.

And with cooking, you can be a little more flexible. You can add some things here and there. It's a little bit more of a fluid process where if you don't follow the recipe, you know, it's not like your steak is going to collapse, right? You know, deflate necessarily. I hope not. I don't know what type of meat you're buying if that ends up being the case.

So having that space to do more of the cooking when it comes to projects, right?

We know in general what our goal is and we have a sense of like, what we need resource-wise to include, you know, what the ideal sequencing of actions might be.

But if it turns out that we need to make a change somewhere, we have that space to do it, right?

 I think the other, and I had one more, is this through -line conversation we've had. For me, it's very much about people.

It's, you know, what are the goals we have? Who and what do we want to affect? Why? How?

What are the assumptions of how people respond to certain stimuli, certain actions?

Can we make a reasonably informed guess or inference about that and then actually build that into how we design a project?

So, if we know that in a particular space like people are not going to take any action or be on board with anything if they feel they haven't been part of the agreement, then you can't just walk in and say here's what we're doing. Speak now or forever hold your peace because they will speak now and then they will find ways to oppose you, right. Even if they may agree with what you're doing, right.

So, if you know those types of things and you stay attentive to this human element of who stands to be affected from not just the end results, but the kind of steps along the way.

And also from your project team side, right? How did different, the people who you know are involved, like what is their position in an organization or a team?

You know, what are they being asked to do or expected to do?

How do you know? How much do you know about how they respond to things?

Like, do members of the project team actually prefer to just be delegated to? Like, just tell me what to do. And understand that, right?

Okay, I don't have to have part of the project implementation plan include, you know, having all these different meetings to bring people up to speed. I just need to tell Matt, like, do this and he's going to go do it, right? Not ask questions or people oftentimes are the opposite.

 So, maintaining... this perspective that at the end of it all, like actually underneath all of the project design, beautiful templates, the PowerPoints, whatever substance, like resources people put together, people are the essential element of any project actually moving forward and being kind of accepted and durable once it's implemented.

And if you don't consider that, it's going to come back to bite you anyway, right?

They're going to be there no matter what.

(Danielle): Yep.

Yeah. No, I completely agree with that point. So much so that I've actually developed an entire tool based on the premise that people are not going anywhere.

I don't care how many different AI tools you have, at the end of the day, AI still exists, at least at this point, for people to do things. And so, if you don't have the buy-in of people, nothing is going to work in the end at least in my opinion.

(Matt): Agree.

(Danielle): Yeah I think that, I think we're definitely in agreement on that.

And I'm just going to sum up what you said before um as don't bake your project cook it.

Or cook your project don't bake them

(Matt): Let's make the t -shirts or the mugs.

(Danielle): Yeah I love that!

All right, Matt, thank you so much for this conversation. It was great. I think we touched on a lot of

really important pieces about why project design is important and what happens when you don't spend the time to do it well in the beginning, which I think is an element of this conversation that people need to be aware of.

So, thank you so much.

(Matt): Thank you as well.

(Danielle): And thank you to everyone who joined us today. Feel free to subscribe if you'd like to hear more conversations uh from regular people about their project design experiences what works for them and what hasn't worked for them.

Hope to see you next episode, until then have a great day!