 Welcome to small programs, big projects, practical tips and tools for managing your projects. My name is Kiskea Addison. I work with Just Tech and I have been an accidental project manager and accidental techie at times. And I'm really excited that we're able to bring this webinar to the legal aid community. We hope to give practical tips that you can take have takeaways that you can use in your everyday practice. We know that many times legal aid organizations are continually taking on projects to improve legal services delivery. So we want to try to make sure that you have some of the project management principles in place and understand also ideas of how project management can be informed by security issues and also DEI. So what we want to help you at so you can have successful projects. Today we have two speakers Tony Lou and Amy Newman. I'm going to let them introduce themselves. We'll start with Tony Lou. Hi everyone. I'm Tony Lou. I'm a senior consultant at Just Tech, and I've also previously worked in various legal aid organizations as well as at Pro Bono Net. So have a foot in both worlds. Thank you Tony. Amy Newman. Yes. Hi, I'm Amy Newman. So I have a couple of different roles. I founded a nonprofit a few years back that gives free or low cost technology and resources to other 503 nonprofits. And I also currently do a lot of consulting with an organization called Ramp Rate and Sysogy Impact. So we work on global scale blockchain projects primarily that are related to social impact. And I'm a big fan of making sure that projects are not just well run but also diverse, equitable and inclusive from the from beginning to end so that we're getting the best results possible so I'm excited to be. Thank you so much. So we will get started. We have a giant back session but we do have a small group so we will open up for questions. Please put your questions in the chat. And then at the end of our session we'll have about 15 minutes for additional questions. And you can ask any questions. Honestly, we are a very humble group I think we're very open to giving feedback and also just talking through ideas. So we'll get started. Great. So, we're going to, I'm going to set us up to just talking about some project management fundamentals and kind of setting up some definitions of what it means to be a project manager and, you know, even just like what a project is. And we'll talk a little bit about the tools as well. And so, you know, what I guess without further ado we can just jump right into it and next slide please. Next slide please. So, it's helpful before kind of going into project management, a conversation about project management to think about the different types of the characteristics of projects that you might be assigned to manage. And so, Eddie Obing, who's this, who's an author and business school professor has very famously kind of characterized four types of projects. He calls them walking in the fog. If we could all just make sure that everyone's muted. Somebody's microphone is open. Right. So, he characterizes them as walking in the fog, making a movie, going on a quest and painting by numbers and the, you know, the main two factors are, do you know what you're doing and you know how you're going to do it. And so walking on the fog as if you don't know what you want, or how to achieve it. This is very common when organizations are trying to do something new, something that hasn't ever been, has never been attempted before. So, typically that's because of some change in circumstances. And I can give an example that probably applies to almost every legal aid organization in the country, which is March 2020, everybody suddenly had to go completely remote with all of their staff. And so everybody was probably walking in the fog, trying to figure out how do we manage delivering legal services with when our staff can't meet with clients in the office. And how do we make sure that people have access to all of their files, how do we make sure that the mail is getting read and payroll is happening and all of that stuff. So it was sort of having to kind of build the ship while it started to set sail. The next type of making a movie is typically when you know what you need to, you know how to do something but you don't know what you need to do, what you're trying to do and this is probably less frequent in the legal services context but you know one example might be like, you know, let's say an organization receives funding to create a new pro se clinic with volunteers. And the funding doesn't say specifically what kind of what area of law, but this organization has a lot of experience running these types of clinics. So then it would be about figuring out well what is it that we're trying to do because we already know how to set up these types of clinics. And this is where you're pretty sure what you want to do. You're just not sure how and this is probably where most tech project falls projects fall. You've kind of talked about like what you want and what you sort of want, what the outcome should look like, but because you're implementing a new tech system or new software or a new process business processes you're not exactly sure how to go about doing it. And then there are projects which, you know, typically, again encompass a lot of tech projects. This, this type of mismatch between the what and the how generally puts a lot of pressure on the project team to deliver on time and within budget. But if the organization doesn't know how they're going to do that it's, it can create a lot of that pressure. The numbers is the kind of project where everyone knows what to do and they know how to do it and the clear the goals are clear and the activities to get to those goals are very clear. And so one thing I always think about is like the best outcome is if you have any of the other three types of projects trying to do as much as you can to get it to being more like a paint by the numbers project is great, like that would be a good use of your time. Sometimes it's not possible. And then also, you know, painting by the numbers project might also be something where like you've done this project over and over again before you know exactly how to do it. So talk a little bit about project managers. Very broadly speaking project managers somebody who's just responsible for the day to day management of the project and there's sort of six aspects that a project manager needs to keep track of, and that's the scope of schedule, the budget or financing quality of the project and then the resources being used to actually achieve that project and we'll get into more detail about what that looks like on the day to day. Next slide. So, okay, so the accidental or unwitting project manager in the legal services tech space we've talked about accidental techies a lot but we I don't know that there's been a lot of discussion about accidental project managers. So, this has been my experience that that everybody has to manage projects and their day to day lives, you know, organizing a birthday party or if you're renovating your house where you're moving to a new home. There's always some level of project management that we ability that we have to have in order to just to just function and modern society. There's a big difference then when you're assigning a project to manage and the legal services space and it's a tech implementation project. And you give that to somebody who may not have specific project management experience or training to manage these types of efforts. We don't really put any project at risk. If we don't really real recognize that projects of a certain scope or complexity kind of require a set of skills and competencies that go beyond what many of us have kind of developed intuitively in our own lives. It's just to kind of set the stage I mean it's important to like if you are an accidental project manager know that you're not alone, that there are a lot of people out there who've been asked to manage a project and you think oh well I, you know, I managed a big house home renovation so I should be able to do this. But it's not necessarily true and there are resources out there for you to look, look to to kind of guide you through how to how to get from point A to point Z with as little pain as possible. With that said, so we're going to dive into the project lifecycle. Next slide. So, this is a way of kind of visualizing the lifecycle from beginning to end of the project. And this is a framework that has been developed by the project management Institute. The official name for each of these phases is as above initiate initiating planning execution monitoring controlling and closing. I've also seen other formulations of it that are really sort of more human friendly characterizations, and that's what you see in the boxes below. It's useful to think about these as sequential phases, but that's not necessarily the always the case. They don't always have to happen in a linear sequence. I mean, yes, you typically are initiating the project before you can actually start working. So there's a lot of times when you start, you think that you've done enough planning and you start working, and then you realize, oh wait a minute, we didn't plan enough, and then you have to go back to planning to kind of figure out this, this new information that you have or new requirements may be defined or added. Or if you're just if you're handling the project in a more kind of iterative approach, where there's smaller sub cycles, you may be constantly kind of doing the print plan work track cycle. In iterations to get you to that final endpoint for the project. So, sometimes you'll hear those usually you'll hear you'll hear them called phases but oftentimes are called. They're technically referred to as process groups by the project management Institute. I'm calling phases because process groups is a mouthful. So the initiation phase, and the key activities here are really about just understanding the project goals and and making sure that you've communicated to everybody, the stakeholders, the team members. And the person who has a has some stake in the project, what the, what the expectations are right like why are we doing this project and who, who is the project manager and the project team accountable to. And there are some key documents that I've highlighted there. The important thing to note the scope of work piece typically that's more if you're working with external contractors. This is just a fully internal project that you're managing. What would normally be captured in your scope of work might, you might still call it a scope of work but it's sort of typically what you know what the deliverables are and would be sort of incorporated into your project charter. Next slide. So the key documents for the initiation phase is as a project charter and this concept hopefully isn't completely new to you. But if it is, it's essentially just a, you know, something that documents all of the major requirements for this project, what the business need is a high level schedule of the project. And then really importantly is identifying assumptions and constraints. And this, this will help kind of manage expectations about what is possible what's not, and then also will surface certain assumptions so that, so that they don't come up later in the project and surprise people that oh I didn't know that we were assuming that this was the case and it's important to kind of have that upfront in a charter. You'll also see that it doesn't necessarily have to be a document called the project charter some organizations or companies kind of refer to a set of documents as their charter, or maybe it's not like a word document but information that's captured in a project management or in a field in your, you know, case management system or you know the charter doesn't have to be like an actual document that where everything is contained within the four corners of that file or that that web page. And then, and then the other important thing to notice that it's not really the same as a project plan. You create this really at the start the very very beginning of the project and it's a way of really kind of defining what the project is not necessarily how you're going to accomplish it. So another key document is called the work breakdown structure, this is something that I think a lot of accidental project managers aren't very familiar with because it's not a common thing for people to think intuitively I need to do this. But professional project managers who've gone through training or gone through certification like this is one of the bread and butter documents that they typically will create, particularly if it's a project that they've never done before. So as an example of how it works. Imagine you're trying to plan a holiday party. What you would do is you'd break it down by deliverables. So, you know, you have to have guests so you kind of have to manage guests and you have to, you know, there's going to be decorations there's going to be food drinks, entertainment, and then you kind of you break it down a little bit more. The focus is on the deliverables, not on tasks. It's really a work breakdown structure like this is really a way for everyone to really understand everything that's going to kind of go into calling this project complete. And you can do it in an org chart format as we saw, or you can do it as an outline view. So this is the same work breakdown structure kind of constructed as an outline. I am a very visual person and I prefer the org chart. Also, because an outline kind of suggests sequencing. And this is not meant to in any way represent sequencing. It's really just a way to identify the deliverables for a project. So some of the key concepts in a work breakdown structure is again it's deliverable oriented and then you want to apply what's called the decomposition method. So you've got a project holiday party right the project is I want to have executed a holiday party by the state and everybody's going to have fun and walk away with, you know, leftover food, etc. But you have to decompose that into its component parts right and you saw that in the diagram earlier, and then you can keep decomposing those parts right so then under food, you might break it down into main dish side dishes. You know, finger foods, but you keep decomposing to get it into a state where you've broken it down enough for everyone to understand what the project looks like, but not so much that it becomes like a granular activity list. And then another key rule is that it had the 100% rule that all of the work needs to kind of be identified in that work breakdown structure, there shouldn't be anything that you don't include and sort of lives outside of it. Because then you run the risk of losing sight of that or assumptions about that not actually that work not needing to be done kind of make reaping. And ideally, and this is where it can be a little bit hard conceptually for people who haven't created one before. You don't want to create those component parts where there's any overlap in the deliverables. And so that's, there's sort of an art to that. If you look online, for example, the work breakdown breakdown structures you'll see that it's, it's a very sort of cerebral conceptual exercise. But ideally you want to try to try to make sure that like as you're breaking it down you don't have any overlap, because that can kind of distort the understanding of the scope. Next slide please. So in the next phase, the planning phase. This is where you're really whittling down the sort of the big picture kind of deliverable components into actual activities. And this is where you also set the, you know, a budget baseline if you're working with a specific budget and creating a project plan and timeline and defining the roles and responsibilities of the project team. It's really important in this phase to really identify what does 100% done mean, what does that look like. And then defining how as a team you're going to work and communicate with one another, and then also clearly identifying all of the people that are going to be involved in making the project happen. And then I've identified some other key documents there and we'll talk specifically about those. Next. Oh, I forgot there was an animation attached to this. So if you just keep advancing to scan to the whole slide appears my apologies everyone. So this is what's called the network diagram. This is kind of a logical next step after you've done the work breakdown structure is to create a way of visualizing the activities that need to be completed in order to get from beginning to end. This isn't again it's not a Gantt chart or like a timeline necessarily and it's not a task list necessarily. It's meant to show the sequencing and the dependencies for various activities. I found increasingly this exercise to be really really helpful because it helps me understand that there's a lot of stuff that can be happening at the same time but also helps me identify the dependencies. Before I actually start trying to write out like a task list, because typically when you are doing a task list you just sit down and you start writing them down from top to bottom on a document. And then it can be really easy to get lost and like oh wait a minute I have to do this before that and like and sort of trying to manage all of those dependencies. This is a way of doing it that's not sort of as linear, you can kind of represent it in a in a more organic way. After that another key document is communications plan and and this is something that I think gets overlooked a lot but it really a communications plan is a way to identify all of the stakeholders and team members who need to receive communications. And then also kind of clearly laying out how those communications will happen. So and then figuring out what you need to communicate to each of those groupings or individuals. So for smaller projects you may not necessarily need to have a very complicated communications plan but something that might go into communications plan is for example weekly, or, or, you know by monthly updates to the executive director about the status of the project, just writing that down in a plan kind of makes it more real in terms of this is I need to do this, and will sort of push you to tracking that, you know effectively so that it's not something that sort of creeps up on you. In addition to that laying out how the project team will communicate with one another right are you going to have weekly project meetings or you're going to do all your communications through Microsoft teams or manage communications about the project through a project management system like a sauna. That's the communications plans will then give everyone sort of the blueprint to understand if I need information this is how it's going to happen. And also is important if for whatever reason as a project manager you're not able to do your job somebody can kind of step in look at this and say oh, the executive director is expecting an update. We need to let them know that, you know, Tony's unavailable and but but here's a summary of what's going on. Sorry, next page, the. It's also really important during project roles to clearly define project planning is to define the project roles and this is an example to frameworks for characterizing a team members role in the project. They're both in common usage, either the racy approach or the mocha approach. They have different preferences for which they, which they like. I would encourage everyone to do more reading on it in terms of understanding specifically what each of these mean, but really the key exercise here is really figuring out. Like if you have a project team not everyone's going to be responsible for communicating to stakeholders and not everyone's going to be responsible for setting up the database right and not everyone's responsible for providing specific requirements about when to open or close a case in the case management system and so really kind of putting people in the right place and then also identifying who's going to approve. Decisions and and really and who's ultimately responsible for making sure that the project's moving forward. It's also helpful as a way to identify who's going to be responsible for making sure that the project gets the resources it needs so it's a very important thing to do with the outside of a project and something that I encourage all of you to think about no matter how large or small the project is. And then the project schedule. I don't, I'm not showing an example because I don't want everyone to get caught up in thinking like there needs to be a particular way a project schedule should be handled. It can be done very simply through just like a table with, you know, activities milestones and dates attached or it could be a very complex thing like a Gantt chart. The important thing is that it's after you've sort of broken out the activities involved in a project. So that's when you can kind of apply dates to things. And then the accuracy of the schedule depends heavily on how familiar you are with these types of projects and how well defined the project is. So, if you feel like I don't have a lot of confidence in the schedule that may be a function of you either need to do more defining and more work kind of understanding the project and the requirements or it's just like you have to be comfortable with the uncertainty you know this is something new that we we've never done before and so it's hard to give accurate estimates. And then project planning project plans. So not every project will require a formal project plan, but you know it depends on the size and complexity and the sort of structuring of the project like is this part of a grants, then you probably do need a project plan. It's an internal project that you know, maybe the project plan is really more captured within, you know, wiki page or, you know, an email that that you send out. And, ideally, it's something that will help to summarize or a link to other documents that are important like a work breakdown structure or timeline. Usually you'll want at least some kind of executive summary whether it's just one sentence or one paragraph or a couple paragraphs kind of summarizing the project, like an elevator pitch version of it. And then identifying milestones, any, any risks that you're aware of already and then any sort of countermeasures to those risks. So if you really want to kind of lay out the methodology, are you going to be doing this iteratively or in sort of one soup to nuts approach like waterfall. Everything needs to be defined up front and then we'll build it and then we're done approach. I apologize this is a little bit out of sequence but I want to talk a little bit about defining the actual activities, you know, like almost like a task list or a breakdown of the activities. The guidelines typically for the project management Institute is that, you know, it's it just break it down to the point where you feel like you can reliably estimate that work. Right. So if you've never poured concrete before I have no idea I'm going to keep breaking that down until it makes sense to me. I had to you know if you asked me to like pour concrete I wouldn't necessarily know how long that takes. So then if I start breaking it down and doing research and understanding then I could do a little bit more estimation there. So, you can see that example. And then the responsibility should always be clear for those activities and then, you know, really just make sure that the completion criteria started and dates and then the completion criteria what does it mean for this activity to be done is clear. And then just the additional information about what an activities list might look like you really want to, it's really just kind of a further breakdown of the work breakdown structure diagram or that outline that I was showing. And again, just make sure that it's measurable. Typically, it's better to use like a verb and noun construction so that anyone in the team or anyone looking at these documents kind of understands what that activity is just by looking at the title. Okay. Execution so here's really just the key activities are managing resources managing people and managing the processes. And so it's, you know what you're really doing here is kind of understanding who's doing what on the project and what is the status of the various tasks. As I mentioned, you know, these are really the key objectives for a project manager during this phase and you may also be doing things like actual tasks right not just managing the tasks but actually sort of completing some of the tests identified in the plan. But if that's the case, then you always have to remember that you're wearing multiple hats and you have to step into your project manager role frequently throughout this phase to focus on these three objectives. So, during execution you really want to keep referring back to that activity list that you created during planning. It's really it really should be the hub for working the project. And so, and that's also where you would want to make sure that you're tracking status on activities and you know when activities have been completed. And you also want to start trying to use it to identify blockers like if there's impediment to any of the activities getting done. And then, if you notice that one activity just feels like that's too big. That's, you know, you would want to break that down further and add new activities to it as necessary. So, some of the specific activities that a project manager is doing during this phase, you're, you're overseeing the execution of the scope and you're delegating. You're always trying to make sure that if there's not, there's a need to your recommending changes to process or approach, or maybe reassigning tasks and taking other corrective actions. The execution stakeholders throughout this phase is critical and then team building is a sort of a key aspect of the execution phase. The, the next phase would be what's called monitoring control, and in this phase you're really just trying to track the effort and monitoring the project progress. So oftentimes monitoring control and execute basically they kind of are happening at the same time. And so throughout the, the effort of working the project you're always trying to figure out are you on track. Is there anything that's going to throw this thing off course, and then what's left to be done. And then one key thing that to sort of note during this phase or this, this, this part of the project is that you want to try to keep track of scope creep and he anything that comes in that wasn't part of their original scope. It doesn't mean it's not important doesn't mean that it shouldn't be done, it just means that it should be identified and not sort of just assumed, oh, we'll just build that in. And so if it's not sort of within what was in the project charter than probably that's a change request and then you would just make sure that you have a process for for identifying that and getting approval. And then another key document is just making sure that you have someplace to track risks and issues that come up. So if you think that's something maybe a problem down the line for this for the success of this project document somewhere. So then make sure that allows you to communicate with your stakeholders about these risks so that you can try to address it proactively rather than reacting to a risk once it's become an issue. And an issue is just basically a realized risk. This is only project closing. So, sometimes we're done, we think we're done with the project and everyone just sort of, you know, brushes their hands off and sort of walks away on to the next thing, or they look at back to my real job because I wasn't really meant to be a project manager. This is an important thing that all organizations should engage in is a project closing phase where there's sort of a retrospective, sometimes also called a post mortem as morbid as that might be. And then where you are not just handing over the deliverables to whoever it is the stakeholders involved, but also making sure that you document anything that you've learned from this effort. And very quickly I just want to talk very briefly about tools I think Amy will talk about project management tools in more detail but I just, you know, I want to emphasize that you can really manage any project with any with a lot of the things that you already have. Spreadsheets are probably one of the most common tools that people use to manage projects and they're fine. They're just fine. The most important thing is that the team understands the project plan and the activities list and they can like understand whatever tool it is that you're using to communicate with them. And then that you as a project manager can actually use it effectively to monitor and track the project you don't have to like sign up for an Asana or a Monday calm subscription just because you got assigned a project to manage. And finally, keeping things simple can be really effective still. And, and I have actually used this approach to help manage various aspects of building out an online system to help people fill out the citizenship application. And so, I took over a room at pro bono net and had the walls covered with sticky notes divided into columns and, and team members would come in grab a sticky note move it into the doing column from the to do. And then I knew that they were what they were working on. It's easy for people to understand intuitively and it's also really easy to know when there's any log jams, it might be because john has five sticky notes in doing and nobody can do five things at once. It's just not possible so it helps you to kind of see those things a little bit more in a way that's not about rows and columns on the spreadsheet if if you're a visual person like me. That's my final thoughts remember that being a project manager managing a project team is kind of like being a band leader, you're trying to get everyone to learn a new piece of music and play it together. So imagine that that's what you're doing. But you're also trying to build new instruments that no one's ever played before, and then on top of and teaching your team how to play that instrument and then on top of that. So imagine that your, your band members and maybe never studied music before or played any instrument before. So, before you think like oh we need a project management tool like, you know, like Microsoft project or JIRA or whatever to to be able to effectively do this project like, that's really what being an accidental project manager can feel like is like you're trying to teach people these tools as you're trying to get them to learn the music and so maybe instead of like handing them. You know, complicated instruments to learn and trying to get them to perform a symphony like maybe just give everybody kazoos, whatever is as easy as possible for people to just like oh I get this, I can play this. That's kind of the approach. I feel like is the best starting point to figuring out how you want to manage a project. Thank you Tony. Now we're going to have Amy, who will talk about project management diversity inclusion at every step. Yes, thank you Tony. That was great and I've been in some short duration sessions where small groups worked with post it notes and it was extremely effective so I think that you're right. And what I also want to point out is, even when you're thinking about tools for project management or anything else, you also do want to consider like you were saying if you're trying to teach people how to play instruments, you know, do they have background and playing instruments already. This is the first time they've heard about instruments. Are they already former symphony players you know you kind of want to feel out the user capabilities and levels as well so that's a very valid point. And I've often been an accidental project manager much more than I've been a professional project manager, but is truly a very useful skill set for almost anything to be able to think through in a methodical manner. How to do these things so you can go to the next slide that'd be great. So, the reason that I wanted to sort of focus in on this so much is I think that a lot of projects get built a little bit in the vacuum right so I don't necessarily work as much in the law space but I do work a lot in the technology space. And I think that it's very important to me to always take a step back and say, Okay, we're having a conversation about how to help a group of people are people from that group of people here to be part of this discussion. What can we invite them to the table to be part of this discussion. You know who needs to be in the room. Who, who are we, you know what are we trying to do. Do we have the right background information and different skill sets lived experiences to try to really make this whole thing makes sense, or are we sometimes what happens with the best of intentions is people take something from another time and place that worked well. And they just sort of grab it and try to overlap it into a different time and place, which almost never works the same way twice. I always like to, you know, really pause before anything starts happening with any of the pieces of the phases that Tony just very well did a very good job running through. And just at the very beginning and again at every transition of every phase, just again think you know what conversations are we having right now. It is included at the table in these conversations who isn't but should be included at the table in these conversations so that we're making sure that whatever. However well we go through the process that ultimately gets us where we want to go and not that we did a really good job of doing a process that got us to the wrong place. If you can go to the next slide. Okay, so I'm going to run through why diversity equity inclusion is so important. This is something that I think as a project managers can be excellent to point out to people who want to keep things moving so fast that maybe they don't think some of these steps are as important as they are. Thinking about goals and how technology might help with your project management. And again to Tony's point technologist just means a way to help you keep track of all the pieces of a process. And it could be something like in a son or Monday or many other tools that are available, or could be as simple as post it notes. Really the point is whatever is working well for the group is probably a good technology to use. And then how we tie it all together. Okay, and I also like to point out since every person who is a project manager also has a lot of role other roles in this world. I think about if you're part of a nonprofit, you're, you're on a board of directors or an advisory council grassroots organization, another project team. You're in a division of an organization, maybe you're a project manager, but you're also part of another division, maybe you're part of some committees in different ways. And they're all things that oftentimes get missed in my experience. So people don't necessarily think about the implications of people being included or not included. And it's usually with the best of intentions, but not everybody has a lot of awareness of these things moment to moment. So, you know, the Boston consulting group says that diverse organizations have 19% higher revenue. They have a lot of people in, even in the nonprofit state, you're always wanting to get more revenue into an organization typically revenue in resources equal the ability to complete that. And those can be nonprofit related things or they can be business related things. There's typically not a lot of downside to getting higher revenue, generally speaking. Diverse organizations are also 1.7 times more likely to be innovation leaders in their market. Now this applies also again to the nonprofit space and the business space. And again, it's usually you don't get a lot of pushback to people who are like no no no. We definitely don't want to be more innovative. We just really want to be, you know, kind of status quo in our space forever and let everyone else do the innovation. I never heard that that statement right so I think this is really important to you and the reason is because the more variety of viewpoints perspective lived experiences backgrounds that you have. You just have a lot more dots in the room to connect. And they get connected in different ways. So, that's really important to you. And diverse organizations are also 70% more likely to capture a new market. So I'm Harvard Harvard business review. So again, I don't know a ton about law my daughter wants to be an environmental lawyer, but I do know from taking a few legal classes working on a graduate degree right now that a new market is really important there's a lot of things changing in the world right now. And there's a lot of categories of that. And technology itself is changing the legal field, how people have access to law and legal advice. If there's a lot of interesting questions about globalization and citizenship and human rights and there's all sorts of areas where being able to capture a new market for to be more helpful with human rights issues let's say or if you want to reframe it a little bit is really important. So these are all positive things. And so let's talk about just a little bit more specifically some of the concrete diversity. The reason that you would want diversity. So the variety of different perspectives is one of my favorites. This just means that if you go into a room and you sit down at a table. If the if the group of people in the room is very homogenous in a number of ways. The ideas generated tend to be very homogenous. And they seem like they're all good ideas to the homogenous group. Whereas if you had a wide variety of people in a room with different backgrounds. Somebody might be able to see a big blind spot that a homogenous group wouldn't be able to see. I use, I use emerging technology a lot of times as an example, there are a lot of unintended biases that come up because the developers are very homogenous with similar backgrounds and experience. And if people who didn't have that level of similarness were to walk into the room they could easily say oh whoa whoa whoa just to point this out I don't know if anyone noticed this but this seems to be problematic for a number of reasons. From my perspective so the having that variety of different perspectives is important. And this can just be important on a project. Because again if you have blind spots. I think Tony referred to it as the, you know, mitigating risk or seeing risks and how to, how to counter, take countermeasures against that. What you want to do is to not have pitfalls if you can avoid that right you just want things to go smooth, especially if you're the project manager. So this can be really important. Increased creativity. Of course this is another one. There are often many different ways to accomplish a task. If you have a lot of people in a room. Somebody may have done it before in a different way, and it can offer that creativity. Same thing for higher innovation, faster problem solving. I think you're starting to see a theme here. What you're trying to do is get a lot of variety of lived experience. So if you have that, or can tap into that, you're much more likely to see things before they become problematic, or start delaying your project. This also results in better decision making increased profits. It's more of a concern for certain organizations, but you can also think of it as increased impact. There's a lot of employee engagement or constituent engagements. So, again, there's just a lot of positive reasons to have diversity and inclusion reduced turnover. This can also apply to a project and if you think about it differently is reduced need to find additional vendors or partners or other people like that but you want to do is create an environment that is welcoming, thoughtful, diverse, where they can come with their whole selves, and they're not going to feel like no one's listening to them, or for whatever other reason that they don't feel like they're really part of the group so they leave the group. It does help with company reputation. And it does help with hiring results, especially with younger groups of people. There are studies that say how important it is to have not just diverse and an inclusive workplace but also a workplace focused on things like social impact. So, this is something that some people will say is or isn't more or less important to them, but just generally speaking it becomes more and more important day after day, and day over day over time. If it's on your radar now, it probably needs to be on your radar and it increasingly will be forced on your radar if it isn't already on your radar. Next slide. And here's just a, this is a wheel from John Hopkins. And the reason I put this on here is because you hear a lot about, you know, women and people of color for example, maybe LGBTQIA plus in different areas but there are so many ways to think about diversity. I always bring it back to lived experience. In other words, I have some different degrees and certifications and a lot of experience and things like diversity, equity inclusion and STEM inclusion in particular science, technology, engineering, mathematics, just from my background. However, I only have my own personal lived experience. So no matter how much information or knowledge or conferences, number of conferences I've gone to, how much philosophical debate I have about these things, it doesn't change the fact that I have just my own personal set of experiences. And so what you want to think about is stuff like socioeconomic backgrounds, educational backgrounds, if you have a whole group of just PhDs, way too homogenous no matter what else is different about them. It's, you don't want homogenous thought as much as you don't want homogenous anything else. So you have age, gender expression, and identity, gender, national origin, sexual orientation. Mental and physical ability very often gets missed by people. I would put some thoughtful consideration into this, especially if you have some sort of product you want people to use. Invite whoever is going to be in a group of people using it to tell you what is good bad or other about that. I think sometimes we forget to say, hey, have you tried anything like this before. Did you love it? Did you hate it? What else have you tried? What works? What doesn't? What do you like about it? What do you hate about it? What are any blind spots that we don't see? So think about that. Race and ethnicity I think people tend to think of pretty readily. But then you have again education, political beliefs, family systems, organizational rules, language and communication skills, income slash socioeconomic, religion, appearance, body type, things like that. So in work experience. Just keep all these in mind because we tend to, at least I know from my personal experience, your lived experience is what you think of as normal, right? Typically. And if you're in a group of people very similar to you, everything that looks like you, that group of people feels like that experience for that group of people is going to seem normal. And you're going to forget that there's a lot of other lived experiences out there that are totally different in a number of different ways. So this is important for projects because again, especially if you're doing something that is going to impact another group of people. Like if you're trying to come up with a new way to provide legal services, for example, to a group of people that you maybe haven't been working with before. It's super important to ask that group of people what they think about it at the beginning in the middle when you're testing it, etc. Because if you have a group of people that does not include that lived experience, trying to create a project, however good the intention, a lot of things will probably get missed. And this is this happens again with good intentions a lot of times in the nonprofit space that I see with people that I've done consulting with and things like that is somebody may have done a great project and another time in place, maybe with a different group of people. And another part of the country or something like that they just really excited about it as they should be, but they want to take that and just set it on top of a different community at a different time and place. And then that community, if no one asked them they could have done that already and it didn't work and they could have told them that and save them two years and hundreds of thousands of dollars if someone just would have asked right. So that's what I'm saying lived experience is really important because you can't have someone else's lived experience, you can only invite that to the table. All right, so is technology and answer. These are questions that I like to ask people so my nonprofit, which is called resourceful nonprofit. I decided to create that because I'm just very curious about technology in general and I started doing stuff in the technology space in the mid 90s. So I like to sort of just find out, you know, how does this work. How can this help social impact. What does this do for the nonprofit space how could this help with human rights. And so just through being curious about this I accumulated a lot of information about cool tools and things that were available, oftentimes free for anyone or just were super helpful. And so I created it support sort of come up with a place to put all those ideas, but ultimately I like to tell people the same thing Tony said. It's really never about the technology it's about what you're trying to accomplish. So you have to start thinking first, like why are we doing any of this, the first place, you know set aside the whole technology thing. So my point of this project is it to get 10,000 more people to sign up for help with their legal questions. Well that's the goal. The project is to facilitate that goal. And the technology is to facilitate the execution of the project. So you don't really focus you don't want to focus on the technology first. You don't want to be, you know, mindful of what technology might be a good thing to choose. So, if you have a project is a little different because it doesn't already exist. But let's say that the last project you worked on was super tricky because some of the things that Tony mentioned, like communication created the bottlenecks or maybe it was hard to see what things were dependent on other things, or timelines issue. Just think about okay. Is it a newer ongoing challenge. Have these challenges already existed or is it something new that we need to find something new to address because it doesn't exist before. Who does it impact well if you're the project manager. It all impacts you right. So that's definitely one group, but it also impacts those 10,000 people that you want to have sign up for legal help, or all the executives making decisions whether to fund certain things at certain times, or the grassroots organization that you're partnered with. So, think about who are all the different people that it impacts, and then also think, you know, will whatever technology that we want to have benefit the process of interacting with all those groups together. And then think about what will happen if a good solution is found. Well, hopefully things go flawlessly you get gold medals accolades high five project is spectacular. If you like project management you get to do all the project management you want. And if you don't your project manage your project went well and you get to go back to whatever you're doing before. But either way you want to make sure that you're thinking about. I guess you could also think of downside but I like to think about like imagine everything went flawlessly. What would that look like why would it be important because this will be helpful in getting whatever technology you think you need if you have to request from someone else. So then similar question if you could wave a magic wand and the challenge challenge or challenges were solved. How does that impact your organization. Well we had some hangups last time with the milestones or the partners or the timeline. If we could speed everything up then we could get that many more people's legal questions answered that much faster. So, you know if you start thinking through, how does this help us accomplish those goals we were talking about beginning, then it's a lot easier to get people to sort of back you on certain things. And then have you tried a non technical solution to no avail. So this goes back to Tony's point. Is it really that you need some sort of technology tool or is that that you didn't necessarily have all the right people in place the first time you didn't have the right support. You didn't have follow up from certain teams or our partners. Was it really that you didn't have the technology or is it something else. And then if it was technology, then we can go on to the next set of questions. We can have a couple more slides and we can have a Q&A. Are we doing pretty good on time. Okay. So, also one of the things I like to tell people, because I do a lot of stuff with like artificial intelligence and blockchain and emerging technology that people are shining new things that people are like artificial intelligence I got to get some of that you know definitely need that because it's never about the technology itself. It's about what, what does it do for you. Again, so in project management, it makes your life easier, it makes projects run more streamlined but just generally speaking, a good way to think about these types of things is what makes any technology useful. So it's things like, sure, save money is an obvious one, but maybe it also helps people understand your work better, or minimizes wear and tear on humans. It's a very popular one in the nonprofit space, right. Maybe it frees up time, those two kind of go hand in hand, increases effectiveness, better connects you with your community, or enhances your personal learning. So these are all some sort of productive things that technology can do generally speaking. So then if you're you think about all these things and you think do we have the right people at the table. Do we have we thought through in the past what worked well and what didn't support postmortem as Tony was saying. Are we comfortable thinking that maybe technology could help solve some of these issues. Have we talked to people who are involved in this process. At the beginning of the process and during these different phases, and when we're picking a tool for going to use one. And if those things are all a thumbs up. Here's what I do when I'm trying to find technology to use. So, I love technology. I'm a big fan of freeing a human time using technology so if there's a shorter, there's a more effective faster way to do something. I will typically. I'll do something manually once if it seems a little out of control. My next step will be to take some time and go through this process and see how I cannot have to do that the next time. You're doing a lot of projects, and you get frustrated by certain pieces of it over and over this might be a good way to start streamlining that. So again, it always starts with what you're trying to accomplish. So what challenge or pain point are you trying to solve. Maybe you want projects to move quit more quickly. So I always ask our good friend Google or Siri Alexa Yahoo whatever your favorite tool is a question. So I would say, what is a good project management tool to, if you have a lot of milestones, whatever your question is, I might say something like, how can I better keep track of all my contacts. Exactly. Whatever your question is, ask it like you would ask a technology advisor and just put that in Google because what will happen is probably a lot of people have had this same question before. So Google will ever so politely just return a bunch of blog posts and other articles that give you a list of like the top 10 things to do that. So it might say the top 10 tools for project management, or whatever the question is. And then what I do is I just, I look at a few trusted credible resources, and it could be articles from business journals or news sites, and a combination of maybe bloggers in the space. I look at a lot of nonprofit technology so I know if Alice and fine or best canter are talking about it's probably very legit. Right. And so I see if there's a pattern of two or three come up in every single article in the top five. That's my short list to start with. So rather than me looking on my own manually researching all of this, all unnecessary in my opinion. I just want a good starting point where a lot of other people smart people in the space have already curated this information for me. So then I take these couple of say top two or three. And then I go to sites that also are really skilled at selecting something like a capterra, a G2, or a tech impact, for example. And you can just put, you know, you can take those three names of tools, or even pull up the whole category of the tools, but just put the top three in some of them and you can even compare a couple, you know, sets of what they do their benefits their prices, set up demos. But I think I find that this cuts down a lot of time. I think a lot of people feel like they got to do all this intense research on their own, but really their organizations that exist solely for this purpose. And those are capterra, G2, tech impact, etc. So they have already done all this research for you, got all the compared comparison checklist, you just have to figure out on your own, the part that they don't know is what is your goal. Do these things address that goal? Is this within the budget that you have? Is it user friendly enough for the team that you have those types of things? So then you take those features, pricing, maybe do a couple quick demos, and then you can pretty quickly land on one or two that you think are the best. And then maybe you invite the rest of the team in to also see a demo or give feedback and suggestions without having to take too many people's time going through each of these steps individually. Pretty much the long and the short of it from this side. And then I'd be happy to take any questions. I mean, we can talk a little bit more about any of these particular pieces or particular tools people have questions on. Thank you, Amy. And thank you, Tony, for this presentation. We would love to just open it up. I know that people are in different stages of project management or maybe they have upcoming projects or they're involved in TIG projects. We'd love to hear from you. Any questions and observations? This is, I think, an open, comfortable group where you can talk. Because I thought it was really helpful, Amy, just your example about putting a solution for a community from one community to another. Because I have seen that many times where there have been recommendations. Why don't you do what this state did in your state? And then you see that actually the community is quite different. They have different needs. And the solutions don't actually don't respond to the needs of those communities. And also then there's not the bite, right? We actually want communities to feel engaged, involved, and also feel as if this is something that is their own, not something we're putting upon them. So I really appreciate it of those comments. Yeah, I think that's a common, I mean, people are trying to be helpful in all these different circumstances, but a lot of people don't necessarily have a specific background and stuff like diversity, equity, inclusion, and how do you make a group more diverse and equitable? And so I think that if nobody in a group has any of that, then it's just going to sort of continue on as it always has. So it's good to sort of proactively think about all these different things. And just from knowing Tony from his work with pro bonnet and actually watching the sticky notes on the board where I was really jealous. It was so colorful. Like I felt like I'm so not creative. I wonder how you were able to integrate diverse voices into the design, because I think that that was something that was thought about in design and build out of that tool. So how were you able to integrate those diverse voices across the country, right? Because it was a citizenship app. Yeah, so we worked with a consultancy to conduct focus groups with various potential users of the system. And really kind of got a lot of feedback about, and this was actually the related platform for not citizenship, but just general immigration knowledge. I got a lot of really helpful information about what kinds of sources of information people trust, which kind of really helped us figure out. Well, if we're going to design this a certain way, maybe we need to kind of put kind of user personas front and center instead of it just being like here's information we sort of developed these fictional personas of users that are represented like, you know, one of the focus group participants said well I just get information from my family member or I get information from my teacher, you know, and I feel like I can trust that information and so that's kind of how we were trying to incorporate the perspectives of a diverse group of people who we were expecting to use the system from different communities and different across different age groups, different levels of comfort with technology tried to kind of make sure that we were getting feedback as broadly as possible. So we'll say sort of applying that layer to your project management sort of setup. You might run one project and it goes really well, and then you think oh great. And then you get a new project with a different, different team members and you think oh yeah the last approach I used which was using Trello works amazingly and it may not, that may not be the case you may find that like you have team members that just don't get Trello it just doesn't work for them and so, you know, these systems have to be fluid and as project managers you have to be adaptable because you're really trying to make sure that ultimately the team feels like they have access to the information they need and then they know how to communicate information in the way that that works for you as the manager. So final one or two minutes, I don't know if anyone has any questions or observations I've seen some head shaking and head nodding and so I don't want to call people out but they're only 14 people on this for right now. So, if there any questions and you can definitely, I'll say this, you can definitely reach out I think to Tony and to Amy for follow up, and I think a lot of what was in the slides it's probably a lot to take in right now in this moment and these 60, 70 minutes. But they will be available and will adapt them to make them readily available for people who attended.