3 of 84

Why I built the APM

Job interview materials focused on reframing resumes and other job applications… but in order to do that, you have to understand on a fundamental level what the receiving party is looking for
PMP prep materials provided a super in-depth review of ALL THINGS project management, which was WAY MORE than I needed.
This program focuses on giving you a thorough understanding of the PM landscape, and maximizing your ability to:

Map your existing Higher Ed/Student Affairs experience to it
Showcase outstanding work examples
Strategize places you could strengthen your PM experience in your current role

Fundamentally, I built the Aspiring Project Manager because I pivoted out of Student Affairs and into Project Management, and while I was first learning about PM, it seemed like we missed a few steps along the way that would have made that transition easier. I felt like there was a gap in the industry between simply telling HESA pros that they had transferable skills, and then turning around and honing materials to either apply for jobs within project management or prepare for a credential.

And then, once I had made that pivot, I started thinking… you know, regardless of what you want to do with these new skills, whether you want to pivot into a new profession completely or whether you want to use project management skills to enhance your student affairs career… we’re doing student affairs pros a disservice by not helping them understand project management as a discipline, way before we talk about what we’re going to do with these new skills.

And I think there’s a really critical step we miss when we forget to focus on the broader landscape of a discipline we might pivot into. You can’t tailor your materials well without a really strong understanding of what your application reviewers are hoping to read and hear, which pre-supposes a strong understanding of the industry. There’s also, of course, the all-important question of would I even like this job? My guess is that most of you here in the program are not here because you weren’t good at your roles in higher ed. My guess is that you’re here because, in some way, the role no longer matches what you need your career to give you – whether that’s rooted in money, time, use of your skills, etc.

And then when I began studying for the PMP exam, it was almost the opposite: way too much detail that never felt like it met me where I was, which was a higher ed pivoter that had at one point imagined myself saving the world using my people skills and then had sort of shifted to hoping to save my organization using my administrative skills…. And now was hoping to find education about how to become and be a project manager. This program exists because when I began my transition from higher ed student affairs to project management, I didn’t find that.

I found a lot of information out there about how to become a PMP, which is often based in jargon and doesn't feel experiential at all, and about how to apply for project management jobs. But I didn't find a lot of information about how to actually make the switch, behaviorally and experientially. I found a lot of people saying, you've got transferable skills. And it's like, okay, well that's great. Can you share some of them with me? I would really love to know what it looks like to use higher ed student affairs skills to become a project manager, right? I didn't see that that existed anywhere. I couldn't even really find it for nonprofits, which is usually my go-to when I'm kind of trying to zoom out, not having found anything for higher ed. So… I built it. I built a program to map your experience to the PM landscape, help you identify and develop the language to showcase the outstanding work examples you already have, and then strategize places you could strengthen your PM experience in your current role.

And now you’re in it, and one thing I’d really love for you to know is that I see this program as a living, breathing, dynamic thing. If you have feedback, please share it with me! I’d love to hear from you.

4 of 84

What this program IS meant to do/be

Provide education about how to become a project manager.
Provide education about how to be a project manager.
Provide a road map for what embracing project management can look like – whether or not you leave Higher Ed/Student Affairs right away (or ever!)
Provide a community of support as you begin to use project management skills to take the next step in your career.

So what is this program meant to do and be?

As I said in the last lesson, this is meant to complement education about becoming a PMP and about your job search. We'll talk in a moment about what this is NOT meant to be, but what it IS meant to be is education about how to become and be a project manager, and making that transition super, super confidently, so that you're feeling super capable and super confident in your new role. We're gonna do that by looking at item three and four on this slide. Item three is about provide a roadmap for what embracing project management can look like, whether or not you leave higher ed student affairs right away. I really genuinely do believe that one of the most awesome things about pivoting out of higher ed into project management is that everything that you do is gonna make you better at your higher ed job in the interim.

To make this story a bit more personal, I'll underline that part of why I built this program is to be a little bit more transparent about what the process of becoming a project manager looks like. I began learning about project management formally midway through my MBA program. So I first heard the term project management in the summer of 2018. It took me about a year to kind of really commit to it as a career path and learning more about what it looked like, which culminated in September of 2019 with me getting certified as a PMP. There’s information in Module 8 about how to decide whether becoming a PMP is the right choice for you, but I do wanna tell you upfront that lots of people make this transition really successfully without getting a PMP.

In September of 2020, I started my role formally as a project manager. I hung out my own shingle. I left my higher ed job, and I began full-time project management work. So again, that's about two, a little over two years, between summer of 2018, learning about project management and fall of 2020, hanging out my own shingle and becoming a professional freelance project manager. The point that I'm trying to make to you here is that within those two years where I was still working in higher ed and learning about project management, I was able to apply everything I learned and become a better higher ed professional because I was learning about project management. I believe that's possible for anybody who wants to learn more about project management. So a lot of what I'm hoping to do in this program is to pull back the curtain on how that looked. We're really thinking through ways that you can be understanding and practicing project management skills without having to leave your role, so that by the time you are ready to interview, you're a rockstar with the way that you think about project management, the way you talk about project management and the way you use examples from your current role to talk about your eventual role as a full-time project manager.

So that’s items 1 and 2 on this slide: making the transition, or becoming a project manager, and then I also believe this curriculum will serve you really well early on in your career, so some information on how to confidently be a project manager.

And then finally, we're gonna be providing a community of support as you begin to use project management skills to take the next steps in your career. So I think items three and four on this slide kind of hold hands. We're talking about a roadmap. We're talking about a community of support so that you have not only me, but also ideally as this program grows a whole network of folks who've made that same transition, right? So I know a lot about project management. I've been a freelance project manager for two years, and then I just ended that season of my life to become a director of operations and strategy. So I now oversee project managers. While I was working in project management, I worked across different industries, I worked across project sizes, project team sizes, and wildly different team dynamics. So I know a lot about project management, but I'm not gonna know everything that you might potentially be interested in. And so having that network, that community is really important. So that's a little bit about what this program is meant to do and be.

5 of 84

What this program is NOT meant to do/be

NOT a credentialing course (if you're here for PMP or CAPM contact hours: STOP, TURN AROUND, this will not get you there!)
NOT meant to train you for a particular industry
NOT assuming that you'll ultimately pursue a credential

So, of course, having talked about what this program is meant to do, I also wanna be really, really clear about what it's not meant to do. So first and foremost, the number one thing that you have to know is that this is not a credentialing course. If you are here for contact hours for the PMP or for the CAPM, stop and turn around, because this program will not get you there. Again, this program is meant to provide a lot of education and a roadmap about how to become and how to be a project manager. And so of course we're gonna talk a ton about project management principles. You'll learn a lot, and if you put the effort in, you'll be in a really good position to then turn around and apply it. This program holds hands really well with credentialing courses, but if you are applying, for example, to become a PMP, you're gonna need to show 35 contact hours or educational activities that you've spent in the pursuit of project management knowledge... and this program is not that.

This program is not that. This is not approved for that, and it's frankly not gonna get you there because we're not gonna go through the official project management standards with a fine-toothed comb, which is what a credentialing course would do. We're gonna talk a lot about it. And again, I'm gonna get you to a place where, if you've got interest and aptitude for project management roles, we're gonna get you to a place where you're gonna be confidently applying and moving into your first PM role. But we’re not going to drill formulas (I am already a PMP, so I’d be happy to never spend a day doing that again) or memorize definitions.

Which is all to say: it's not meant to be a credentialing course. I know I've repeated that a number of times. I just wanna make it really, really clear. So if you purchased this program thinking that that's what you were gonna wind up getting, go ahead and shoot me an email, and we can get you out of the program. If you finish this module and it turns out that this isn't what you were hoping for, I can probably also make some recommendations of what you might want instead.

This program is also built to be industry agnostic. So what that means is I don't have any assumptions that you're gonna wind up working in, for example, tech or healthcare administration or construction or any of the other sort of like large, what I'm gonna call feeder careers for project management, right? The content in this program is either tailored to be very general and to be applicable wherever you're going or, where we use individual industries as case studies, I'm gonna make it really clear that that's what we're doing. So this is not meant to train you for any particular industry. And then really importantly, this program also doesn't assume that you'll ultimately pursue a credential like a pmp, right?

Again, in transparency, I pursued a PMP as part of my transition, and I did that for a number of reasons, mostly around where I was at in my own professional development journey. I will share in great detail all of that, and do my very best to help you weigh the options about whether a PMP is right for you in Module 8. But I wanna be really, really clear that a lot of people successfully transition into project management as an industry without gaining a PMP. A lot of people never gain a PMP. Some people get a PMP after, you know, maybe a year or so of working with their current employers, and then their employers pay for their professional development contact hours and their exam fees, right? So there are lots of different paths. This program does not assume that you'll ultimately pursue a PMP. It does give you some resources, if you decide that you wanna pursue a PMP, I think this program is really, really helpful in figuring out how to prep for that as a student affairs pivoter; but just know that you can get a lot of value out of this if you decide not to do that.

6 of 84

How To Use The APM

Content

The content is self-paced. You have lifetime access, and you can return to any of it at any time.

Community

Join the private LinkedIn community to network with a group of other aspiring project managers, ask questions, and workshop challenges. (I’m in it every day!)

Finally, a little bit about the logistics: the nitty gritty of how to use the APM as a program. Broadly, you can think of this program as containing two halves. The first half is the content, which is completely self-paced. It's what you are accessing right now through the learning platform. So, just a little bit of vocabulary for you: said content is divided into modules. So right now you are working through module one, which is sort of some level setting and foundational work. And then each of those modules are divided into lessons, which are the individual pieces that you work through as you complete modules. Again, this content is self-paced. You have access forever and you can return to any of it at any time. We'll talk a little bit about, about the end of this module, about recommendations I have for you in terms of pace and how much you work through at one time, and whether you work through it linearly or whether you kind of scan through, we'll talk about all of that. For now, all I want you to know is that whatever the pace that works for you is the right pace to move through the program.

I also am all about giving you resources and actionable next steps. So I try to end every module with downloadable worksheets and links to learn more: things that I think might be helpful to you. Some of it will be my content, and some of it will be external content. If there's ever anything that you feel like is missing, absolutely reach out. I really view this program as a living, breathing document that's dynamic and it changes all the time. I don’t have any interest in you paying me to get this static thing that never changes. So if you ever feel like a resource would be particularly helpful, always feel free to reach out and I will do whatever I can to make that happen for you. The chances are really good that if you've got a question or if you are looking for a particular resource, somebody else has that same question or is looking for that same resource too, and I take a lot of pride in being really responsive to what you're looking for.

Kind of on a similar note, if something exists as a download, I want you to download it. I want you to keep it, I want you to reference it often. A quick note on like intellectual property in general, I feel, and you know this, hopefully, from following me on Instagram: I give away a lot of content, right? So in general, if you download a PDF or if you have a link and you're like, wow, this would be really helpful for so and so, feel more than free to share it, right? I really don't feel like a really tight sense of possessiveness or gate-keeping around the content I put into the world. I do ask that you don't sort of like wholesale share all of this with somebody. Like, don't share your login information with someone else and then tell them like, boom, this is everything you need to know. On some level, this program is part of my livelihood, right? So really I would just ask that you sort of extend the same grace and concern in that sense that I extend when I say, you know, feel free to get in touch with me and ask for whatever you want added and I will add it. So I hope that distinction is clear: please do take care not to like wholesale share all of this information at once with a bunch of people, but of course if an individual resource is, is helpful to you or to somebody else... well, if it's helpful to you, you own a license to it, as a subscriber to the program. And then one resource is helpful to somebody else, feel more than free to share it with them, right? I really do believe that this world, our communities, our workplaces are, are better when more people have access to more high quality resources, and I take a lot of pride in the work that I do, so I know that this is high quality. If you're ever on the fence about like, can I share this with somebody? Always just feel free to get in touch. Again, nine times outta 10, I'm probably gonna say yes, and here's something else you can share with them too. So that's a bit about content.

In terms of community, recall that kind of our two main goals as we teach you how to become and then be a confident, capable project manager, is providing that roadmap, which we're gonna do primarily through the content and then also providing support, which we're gonna do primarily through that community. So in the following lesson, you'll see instructions on how to join our private LinkedIn community. That's gonna allow you the opportunity to network with a group of other aspiring project managers. So my hope here is that we can use that as a space to ask questions, maybe workshop challenges that you're currently working through. I'm in that community every day. As the community grows, it will also be helpful to you to see other folks who are walking that same journey. Because again, remember I have a lot of varied project management experience, but you know, there's no way I'm gonna be able to have direct experience with every question, every person might ask. I also do have a pretty broad project management network. So if I don't know the answer to something, there's usually somebody I can give a call to and figure it out. But as this program grows, that network will come to include all of you all too. So that's a little bit about how we can use the community to provide each other support. And again, I'm in there every day.

For the LinkedIn community, you have what I call "life of the program" access to that, which means that as long as this program exists, you have access. That’s really the spirit of what I'm trying to do, right? What I'm trying to do is really build a community of people who again, feel confident and capable and understand that they have the tools and that we can help other people have the tools as well to make a successful pivot from higher ed to project management, right? When you leave somewhere and you climb somewhere else, you turn your hand back around to help the people behind you, right? And ideally I’d love to see some of you, as you make your career transition confidently and capably into project management, maybe even answering some newer folks’ questions from your own experience!

7 of 84

About Caroline

Former SA pro with experience in first-year orientation, transfer student orientation, family programs, and student activities

Came to HESA by way of an MA in Counseling

Earned an MBA and a PMP during my last 3 years in SA
Freelance project manager and strategist, formerly a director of operations & strategy at a start-up, and now co-founder of Boundless Impact, LLC
Board member: B Local Michigan and Project Management Institute Huron Valley

So I am a former student affairs pro, just like you; I worked in the field for about a decade. I have experience in first year orientation, transfer student orientation, family programs and student activities. I came to HESA by way of an MA in Counseling so I do really keep human development and social context at top of mind as I approach these topics. I earned an MBA and a PMP during my last three years in student affairs – I worked in the field for about a decade and I always really enjoyed the field, but I think I also always knew on some level that it wasn’t really going to serve me for my entire career. And so while I really do believe in, you know, “Bloom where you’re planted,” I also, if I’m being candid, sort of spent the last few years in my role exploring what it would look like to take a leadership role in other organizations. I knew was ready for leadership, but I also knew that it probably wasn’t gonna serve me to be in higher ed the whole time.

Midway through my MBA, I discovered project management, and I earned my PMP, and then a few months after that I left higher ed. For two years, I worked as a freelance project manager, so I worked across all different industries. I got my start in the digital marketing space… and honestly, I felt confident applying for that role because I supervised the marketing design student team in my HESA department. That experience alone gave me what I needed to pivot into project management roles in the digital marketing space. So while that’s a small example of taking what you have and using it to wedge open what you could have, it’s so important to think about building that as a fundamental approach to job seeking. Really asking yourself: is there anything that you’re doing right now that could be connected to this landscape more broadly? So hopefully this program will help you think about that; remember that the program is the LinkedIn community and this content, so that community really exists to help you process this stuff, and part of what we can do in that community is we can help you answer that question. If there is one tiny little spark on your résumé that we can fan into a larger flame, let’s do that. So again, if I had been following a traditional career path and applying to a Director role based on my coordinator job, I would not have written, like, “supervised our marketing and design student team” as a top bullet point on my resume. But because I was applying to digital marketing roles, the experience was relevant, and it was enough to help me succeed in those initial roles.

So that is how I pivoted into freelance project management. I did that for about 2 1/2 years and then, eventually, the time was right for me to go into full-time work, and move back away from freelancing, and then the time was also right for them to bring on kind of an elevated operations role with one of my long-term freelance clients that hadn’t existed within that organization before. So I jumped ship from freelance work and became their Director of Operations and Strategy, which basically means that I led our strategic planning process, kind of the as the CEO’s right hand, and then I was the person responsible for implementing that strategy. I did that through conceptualizing and authorizing projects. Sometimes I managed those myself, sometimes I brought on project managers (who I also supervised) and then I also directed sort of all the day-to-day operations of the business, so I had a great deal of responsibility. And what that taught me was that I really love using projects to fulfill strategy, and what that means, though is that I think I have kind of a unique view of project management in that I tend to think of it less as a path and more as a tool.

Last year, the siren call of entrepreneurship pulled me back in, and I left that role. I’m now a co-founder of Boundless Impact, where we spend our time trying to help people broaden and deepen the impact they can make on the world through their work. About 50% of my time is spent in client work, and about 50% of it is spent developing courses and projects and programs like this to help people like you.

So one thing that I think becomes really apparent from hearing my path is that I have always worn MANY hats. One of the reasons I want to bring that up for you, another thing from my story that I want to highlight for you, is that I actually am somebody that really enjoyed the opportunity to wear a lot of hats. I was in a small student activities department and I think anybody would attest to the idea that I kind of did all of the things and wore all of the hats and I really liked that. I didn’t want to give that up, and so I have found start ups, including my own, to be a really good sort of a approximation of that. There are other people that really hate that and really want the opportunity to specialize in, kind of dig into, one thing. And that’s wonderful! We all bring our different dispositions and desires as well as our different skillsets to this broad field of project management, which is big enough for all of us. We can talk in the LinkedIn group about that, the idea that you can kind of be strategic about where you land.

Finally, I’m a member of two boards that I think are really important for you to understand my background. First, I’m a member of the B Local Michigan Board of Directors, where I serve as the Director of B Academics, which is a body liaising between academia and the ethical business world to hopefully train up the next generation of business leaders. I’m also a member of my local Project Management Institute chapter’s board of directors – I am, of course, the Vice President of Training. What else would I be? :)

8 of 84

About Boundless Impact

Co-founded by three former student affairs pros
Focuses on broadening and deepening impact through marketing and management training, consultation, and contracting
Founded with social impact as a core value – all three co-founders are board members of social impact orgs across MI and IN

9 of 84

The Aspiring Project Manager

Module 1: What is Project Management?

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

10 of 84

Getting Started: About the APM & PM

What we’re covering:

What is project management?
About PMI and the PMBOK
Defining value and the business environment
Defining strategy
Defining the project life cycle
Fit check!
Closing out
Resources & next steps

11 of 84

What is a project?

Projects ARE:

Defined into a beginning, middle, and end
Bound by clear, agreed-upon objectives
Collaborative

Projects ARE NOT:

Ongoing operations
Single-person endeavors (this is a Caroline distinction, not a PMBOK distinction)

“A temporary endeavor undertaken to create a unique product, service, or result.”

Let's take a couple moments to really clearly define what is a project, what is management, and then let's put it together and talk: What is project management? Certainly this is a lesson that is gonna really serve as the foundation for everything we cover through the rest of this program. You may even wind up memorizing these definitions, and at least certainly coming back to them often.

Let's begin by defining what is a project. A project is a temporary endeavor undertaken to create a unique product, service or result. I didn't come up with this definition: This is project management internationals definition. We'll talk a little bit about PMI later on in this module, but, for now, what you need to know is that Project Management Institute sort of sets the global standards for what is project management. And so in that sense, what they say goes.

So we can take a couple things from this definition on the column. Over here on the left, you see that I've kind of pulled out some pieces about what projects are. So projects are defined into a very clear, beginning, middle, and end. They're not ongoing into perpetuity. Projects are also bound by clear and agreed upon objectives. That's a central part of a project manager's role: the idea that once we've aligned as a team on these objectives, a project manager's job is to keep everybody on track. And it's not a project if there's not things to keep on track too. So projects are defined, clear, beginning, middle, and end. Projects are bound by agreed upon objectives and projects are collaborative.

And then projects are NOT, and we see this over here on the column on the right, ongoing operations, right? So, if there is something that you do every single day or maybe every week, you do it on a cadence, an ongoing operational effort toward your department. So an example might be that you process payroll. If you process payroll for student employees, that is certainly an indication that your department trusts you a great deal with financial resources. It's certainly also an indication that you are in charge of something that people get quite mad about if it's messed up. So while it's a really good example of responsibility that you bear, it is not an example of you managing a project because it is an ongoing operational effort, not a temporary endeavor undertaken to create a unique product service or result.

Another example, and let's tie this directly to higher education: So, like probably many of you watching this, I served on a number of committees during my time in higher education. One of the committees that I served on that I really, really enjoyed was our general education advisory committee. This was a committee that came together on a monthly basis to make recommendations around the universitywide general education curriculum. That was not by itself a project. We might have taken some projects from it. So for example, if we initiated as part of that advisory committee a project to engage in a learning beyond the classroom component, where we brought together stakeholders from experiential learning and academic affairs, maybe the volunteer center, and then in a clear beginning, middle and end, we began a project to create that service learning portion of the general education curriculum. That could be a project, but my role generally serving on the advisory committee would not be a project that would be an ongoing operational initiative.

Another thing that I would say a project is not -- and what I wanna make it clear here, this is a Caroline manages distinction, not a PMI distinction -- I would say that in general, if you can avoid it, you should avoid talking about projects as single person endeavors. So again, that's not a PMI distinction. Technically, it's technically correct to say that a project could be a single person endeavor. There's nothing in the PMBOK or in the Project Management Institute's guidelines or standards, anything like that... there's nothing that says that technically, a project can't be a single person endeavor. But this is where we get into the fact that the purpose of this program is to prepare you to make a transition and a pivot into a career in project management.

And I would argue that in general, when you are talking to an interviewer, any examples that you use to illustrate your project management skills are always going to be stronger if you can come up with an example of a project that has been collaborative and interdisciplinary, right? So even if it's not you doing your most technically challenging work, it's going to be a more relevant, and therefore better and stronger example, if you can come up with a time that you worked with other people. Because working effectively with others and leading others effectively is SUCH a big part of project management, then an example like that is always going to be more tightly aligned to project management than an example where you did your best, most amazing work as a single person endeavor.

So I'll give an example. Some of my best and favorite work, and some of the work that really springboarded me into being interested in project management, came from work that I did overhauling our graduate assistant training within student affairs. I had a really good friend and colleague working in housing, that historically had done an amazing job training their grads. And we over in the student activities side of student affairs really wanted to sort of mirror that. And so I did a lot of work by myself to begin to create that. There was a lot of process improvement, there was a lot of documentation and standards, but because I did it by myself, I would hesitate to use it on its own as an example of time that I did really great project management work, right? Versus, I also oversaw our homecoming committee for the six years that I worked in higher education. And while I wouldn't say that this was the most technically challenging work I did, or the work that caused me to grow the most, it was SO deeply connected to stakeholder analysis and to risk management and to moving initiatives forward around ambiguity that even though it might not have been what I call "practicing at the top of my license", I would still say it's a better example of project management work because it was collaborative, right? When you share examples with an interviewer, it's so important that they can see your understanding of what project management is as a field based on the examples you give -- NOT just your raw talent.

So because this is really meant to put you in a place where you are ready to confidently transition into a PM career, I would say that it's probably best to lock into your brain that projects are not single person endeavors for the purposes of talking about and thinking about and putting your best foot forward with respect to project management.

12 of 84

What is management?

Management is a set of principles related to the functions of planning, organizing, directing, and controlling, and the application of these principles in a work setting.

Oversight & stewardship on behalf of another (usually an organization)

Oversight: we understand the progress of an initiative, and we take responsibility for continuing to move it forward
Stewardship: we act in a way that advances the interests of the organization retaining us.

So then what is management? We talked just now about what is a project. So let's segue now into talking about what is management. You're probably pretty familiar with this concept, given that as a student affairs practitioner, you are almost certainly responsible for managing within your functional area, if not managing a team. For the sake of kind of setting a common foundation, I'm gonna talk a little bit about management. A textbook definition management is a set of principles relating to the functions of planning, organizing, directing, and controlling, and then applying those principles in a work setting, right? So kind of textbook-speak for making sure that everything that is supposed to happen is happening. I do wanna call out two specific pieces of management because I think this is really helpful: When I am talking to stakeholders or to potential clients bidding for a job, or on job interviews, I like to talk about management in two different ways:

I like to think about management with respect to oversight and stewardship, and we're doing both of those things on behalf of another, usually on behalf of an organization.

So with respect to oversight, really what that looks like as a manager is understanding the progress of an initiative and then taking responsibility for continuing to move that forward, right? So that's sort of that piece about planning, organizing, directing.

And then with respect to stewardship, I think it's really important to bring that piece in when we're talking about management, and really driving home that as managers, our job is to act in a way that advances the interests of the organization retaining us.

I think it's really helpful to split those things into pieces for two reasons. The first is that, frankly, it makes a good impression, right? Talking to upward stakeholders about management in a way that recognizes both oversight and stewardship is usually a good sign that the person they're talking to (aka YOU!) really has their best interests at heart.

The other reason that I really like talking about oversight and stewardship as a piece of management is because it helps you understand where your blind spots might be around what you are prepared to answer and not. So stewardship is acting in a way that advances the interests of the organization. You can't do that if you don't know what the interests of the organization are, right? So whenever you're talking with somebody, particularly in a job interview, but also in any kind of networking or connecting context, it really behooves you to do as much, much research as you can to really think about what are the interests that this person is bringing to the table. So certainly you should be able to understand, you know, from a mission and vision perspective, what does the organization do? But also the person directly across from you, what are THEY responsible for? What are THEY evaluated on? What are the pieces that THEY'RE trying to move forward? The needles that they're trying to move, the balls that they're trying to keep in the air, right? So once you can answer that question, once you can answer the question of interests on an organizational or a personal level, then that stewardship piece becomes a lot clearer, and then we're able to put together oversight and stewardship. So hopefully that's a helpful way to think about management, even though certainly I know that as a student affairs professional, you're not new to the concept of management.

13 of 84

What is project management?

About the field

Project management is the use of specific knowledge, skills, tools, and techniques to deliver something of value to people.
Both a field (Project Management) and a practice (project management)
In layman’s terms: a PM makes sure that projects are delivered on time, on budget, and within scope.

Project Management Institute (PMI) is the largest professional association for PM worldwide.
Industry-agnostic (PMs are everywhere!) and working at all levels

Finally, let's put it together. What is project management? So again, this is a textbook definition, by the Project Management Institute: Project management is the use of specific knowledge, skills, tools, and techniques to deliver something of value to people. That leads really nicely into the idea that project management is both a field -- so I'm gonna refer to that as capital P, capital M, project management -- so you might work in the FIELD or discipline of project management as a project manager. And then it's also a practice, which we can call little p little m project management. So you just engage in project management, and that's the piece when people say that you are probably doing project management as a student affairs professional, that little p little m project management is the piece that you're doing right now.

Here's an example of what I mean when I talk about project management as a practice: it's exactly the same way that you would do arithmetic to balance a checkbook, right? That doesn't make you a professional arithmetic-er or someone working in arithmetic, but it does mean that as a practice, you're using arithmetic to get where you need to be, right? And so if we can think about project management as a practice with a little p and a little m, that's the piece that you're probably already doing. And so if we can get you really comfortable and really capable talking about how that looks, maybe taking the next three to six to 12 months to really work on bringing examples of that right into your student affairs practice. If we can do that, then we can get you to the point where you are not only engaging in that little p little m project management as a practice, but now you feel really confident about entering the big P big M project management field.

So, a little bit about the field. I've mentioned them a few times, but PMI, so Project Management Institute, is the largest professional association for PM worldwide. So if you are a member of NASPA or ACPA,, PMI is the equivalent organization for project management. They issue all of the standards. They also own the credentials. So if you know anybody or if you yourself are interested in a PMP or a CAPM credential, PMI is the credentialing body for those credentials. PMI is also industry agnostic. So project managers are everywhere. A couple times in this program already I've talked about examples like construction or tech, software development. Project managers truly are everywhere in every industry, and they're working at all levels. You will meet project managers fresh out of college or maybe, hasn't even gone to college. You will meet folks working with a high school diploma who are amazing project managers. And you'll also meet folks who have reached VP or C-suite positions after decades in the field. You will meet folks who practiced as individual contributors, and then after a decade or two hopped over into pm. I work a lot with folks like that in software: folks who were engineers for 10 years and then became project managers and no longer, sort of what they would say work on the ground. So what I want you to take away from this is that PMs are absolutely everywhere. They're industry agnostic and they're working at all levels.

I really wanna drive that home to you because I think so often for student affairs folks, our world is so insular that we convince ourselves, you know, no one will ever understand the world that I'm coming from. I have this insurmountable challenge of being able to explain everything I do to somebody else when the truth is that project management in particular is so full of people who are ALSO coming from these extremely insular worlds as an individual contributor or maybe even as a director or an AVP. It is so, so common for the folks you're talking to, to actually have no idea what you've been doing for a living all this time. But they're interested in the extent to which you can do these things on the slide. They're interested in the extent to which you can use specific knowledge, skills, tools, and techniques to deliver something of value, because that's really what's at the heart of project management. So you now have a pretty clear understanding of projects and management and how they work together to contribute to project management. As always, if anything's unclear, get in touch. Otherwise, we are gonna move toward talking about the business environment.

14 of 84

About the PMBOK

PMBOK = Project Management Body Of Knowledge

Available through Amazon, Bookshop.org, or through PMI
Walks you through PM domains, then behaviors (like tailoring)
Please buy the 7th edition, not the 6th

If you have followed me for any length of time, you've likely heard me talk about the PMBOK, which is an acronym that stands for the project management body of knowledge. If this is your first time hearing me talk about the PMBOK, just know that it's not gonna be the last. We love the PMBOK around here. I've included a photo here, just to illustrate that the PMBOK is actually a book. It’s a reasonably small book, I suppose I would call it a particularly skimmable textbook. It's not a beach read, right? But it's also not designed to be dense and difficult to read. One of my favorite things about project management is that the governing bodies and groups work really hard to uplift the profession. So in this case we're talking about the Project Management Institute or PMI. PMI really wants you to know how project management works, right? It is to their benefit and to their advantage if people understand project management. So I really like the PMBOK. It's designed to be sort of a one stop shop for your beginning journey into project management if you are considering certifications. So if you are considering a PMP or a CAPM – or any other certification, but those are kind of the two most broadly utilized certifications in project management – I actually would say that buying the PMBOK is a non-negotiable. It is the very first thing you should do if you're considering certification. And everything that you do from here on out, including all of the content that you take in, in this course, you should do it in conjunction with the PMBOK because the exam for the PMP and the CAPM is written using the PMBOK as a foundation.

The PMBOK is pretty affordable. You can buy it directly through PMI or you can buy it on Amazon. I will drop a link to buy the PMBOK in the Resources section of this module, and full disclosure, that will be an affiliate link, so if you follow it, I will get a little bit of kickback there. So if you choose to use my affiliate to purchase the PMBOK, I really appreciate it. But if you don't, that's great too. Either way, I really do recommend buying the PMBOK if you are committed to project management as a career path. It will behoove you, particularly when you're interviewing with folks who are established project managers and who might be somewhat formal, traditional, and committed to the field. Like I said, if you are considering certification, I would say that goes beyond a recommendation into a have to, you really do need to buy the PMBOK if you are planning to use your project management knowledge to get certified.

IN any event, the PMBOK, like I said, is designed to work basically like a very accessible textbook. It's gonna walk you through PM domains, and then it's also gonna walk you through behaviors like tailoring. The last thing I'll say is please buy the seventh edition, not the sixth. So the seventh edition is what you see pictured here. The seventh edition is designed to be much shorter. It's about half the length of the sixth edition. It's also designed to be not only more skimmable, um, but also it's written with a much more modern point of view toward practicing project management. The seventh Edition takes into account technology and globally distributed teams and remote ways of working. It takes into account more complicated stakeholder relationships than the sixth edition. It takes into account non-traditional career backgrounds (like ours!) which PMI gets better and better at as time goes on. And most importantly, again, if you're considering certification, it's what the exams are based on. So please do buy the seventh edition, not the sixth, and consider it a non-negotiable if you are considering certification.

15 of 84

Defining the Business Environment

What we’re covering:

How (many) businesses work
Defining a value-add
Where to default when you don’t know what’s going on

The next thing I'm gonna talk to you a little bit about is defining the business environment for many organizations you'll encounter as you move into project management. My rationale here is that, you know, to spoil it a little bit upfront: if you've been following me at all for any length of time, you know that I feel very strongly about the fact that adding value is one of the most important things that we can articulate or demonstrate in our role as project managers. In order to really do that strongly and concretely, I believe that we need to understand the environments that we're working in really well. And so in order to do THAT, I think we need to talk through the business environment. We're also gonna talk a little bit about what is a value add. And again, if we're gonna talk about value, then we need to be able to kind of really articulate and quantify what we mean when we say that.

And then I'm also gonna close by sharing some ways you can anchor yourself in this framework when you're asking questions or when you don't know what's going on. For many of us, again, shifting into this culture where we're constantly talking about the business environment is a big shift. So if we can start practicing scripts now to basically in a professional way, say, I don't know what we're doing, then that will be very helpful for everybody.

I wanna share a little bit with you about my background before we go into this, because I think it's kind of helpful and, you know, any speech 101 or presentation course is gonna talk to you about establishing credibility. And so at this point, I think it's important that I share with you that, again, I got into project management by way of my MBA. So I earned an MBA back in 2020, and I've used it ever since to mostly live in kind of the small business and startup world, which means I am very familiar with all of the functional areas I'm gonna talk you through. So that's kind of how I wind up usually having BOTH a somewhat textbook answer to things, because I have a lot of formal education in this area. But I also have lived experience with these areas, because I work primarily with small businesses and startups, so I really get the opportunity to work with a lot of different cross-functional areas and teams across the business environment. Which is all to say: I feel pretty comfortable, qualified, and capable walking you through, at least at a very high level, how many businesses work. So let's dig in.

16 of 84

Defining the Business Environment

At a super high level, businesses are made up of the following functional areas:

Product development/manufacturing: how the thing a business is selling gets designed and made
Marketing: how the thing gets presented to the public
Sales: how the thing financially makes its way into people’s hands
Supply chain management: how the thing physically makes its way into people's' hands
Finance: how the business understands how much money it needs to make
Accounting: how the business understands how much money it DID make
Human resources: how the business takes care of the folks working for it

At a super high level, you can think about your average business being made up of the following functional areas. This is not a comprehensive list. This is also very clearly me trying to come up with a one sentence summary of what these functional areas do, right? Um, so, you know, don't, don't, you know, go applying to an MBA program and then get mad when you write an essay containing only this sentence and somebody tells you that this, this isn't exactly it, right? This is correct, but it's not a very nuanced view. That said, I think it's really important to think through, at least on this non-nuanced introductory level, what makes a business run. Because again, recall that projects are collaborative, they're interdisciplinary and, most importantly, they're really deeply people-driven work, which means it's important to be able to understand where those folks are coming from.

So, functional areas. First things first, we've got product development or manufacturing. So how the thing a business is selling gets designed and made. So maybe it's pencils, maybe it is a CRM system, maybe it is a digital product that doesn't have any physical space in the world. Like this program that you purchased from me, that's a product, right? Whatever that thing is that a business sells, whether it's a product or a service, how that thing gets designed and made is what you'll hear people talk about products.

Once that thing is designed and made, we go into marketing and sales. Let's say the "thing" is pencils, like we said. So marketing is how that those pencils get presented to the public. How do people learn that pencils exist, and how pencils might solve their problems? What do they learn about pencils? What sorts of impressions do they have about pencils, and what does that mean for how they think about the product?

And then marketing's close cousin, sales, how are people convinced to financially invest into owning pencils? How do people actually buy the thing?

Supply chain management is sales' other close cousin. So how that thing -- for example, a pencil -- physically makes its way into people's hands. In our pencil example, supply chain management is the practice of making sure that that pencil is created, making sure that somebody quality controls the pencils and make sure that the lead's not all busted up in the middle there. And then somebody making sure that those pencils get shoved into tiny little boxes, that those boxes get loaded onto trucks that are both fast and efficient, but also gentle enough to make sure that the pencils don't all break on the way, and then from those trucks get into stores. So sales is how the thing financially makes its way into people's hands, and supply chain management is how the thing physically makes its way into people's hands.

Finance is how the business understands how much money it needs to make. Accounting is how the business understands how much money it did make, right? So our finance people are going to set strategy. Our chief financial officer is usually a finance person. Finance people are gonna advise about how much debt is good to take on versus how much is like, uh, that's a little bit dangerous. And then the accountants are basically gonna say, this is how good a job we did. Um, so you'll hear people say that we are in the red -- bad -- or in the black -- good -- those are accountants.

And then human resources, how the business takes care of the folks working for it.

So again, this is a super high overview, but I do want to make sure we cover off on it. By the way, I use the term functional area specifically, because it's a term that a lot of us are, are familiar with. If this is all looking like gobbledy-gook to you, right? I want you to think back to when you were a bright eyed and bushy-tailed college student yourself. You probably didn't understand all of the different higher education functional areas. You probably didn't know what enrollment management meant, although it might have been intuitive if somebody explained it to you, you probably didn't know what facilities did. But you know it now, right? Even without knowing exactly what those people do?

So if this is starting to feel overwhelming to you, or if you are one of those people whose spidey senses are like, uh, I was really hoping I'd be able to get through this without learning anything you'd also learn in an MBA, let me put you at ease: we're not gonna live here, we're not gonna dwell here. But I really do want us to ground ourselves here at the beginning: remember that you are a person with learning agility. You can learn this stuff. Part of your pivot is going to be learning to think about things that you've always done and practices that you've always been good at, and talk about and think about those things in a slightly different way. So that's all this is. This is learning the following functional areas for a business because now these are the sorts of things we're gonna think of rather than thinking about the functional areas that we talk about in higher ed, like financial aid and residence life and admissions and student activities.

17 of 84

Defining the Business Environment

This is all relevant for a few reasons:

Recall that projects are collaborative
Recall that as a project manager, your job is to keep all the plates in the air

This brings us to the main idea of this module:

A project manager’s number one job is to create value.

So this is all relevant for a few reasons. First, recall that projects are collaborative and it's always going to be easier and more well received to collaborate with people whose functions you understand, at least on some level, right? Think about how it feels when someone comes into your office and doesn't understand anything about student development or the job that you do, and then tells you how to do it right. It doesn't feel great. And I can tell you that many, many project managers lead projects that ultimately fail because of a mindset where they don't truly understand the folks they're collaborating with.

So again, you don't need to know what a finance degree looks like to earn and what it looks like to, you know, work in finance for 10 years in progressive experience before coming to the table with a senior finance officer, but you do on some level need to understand if you're sitting across the table from a finance person, what's driving them, what got them there, what's incentivizing them, how they're making decisions. And then all of this ladders up to the idea that as a project manager, your job is to keep all the plates in the air. And again, it's easier to do that if you know the people that you're working with. All of which leads to the main idea of this entire module, which is that a project manager's number one job is to create value.

18 of 84

Creating Value (aka providing a “value-add”)

We can create value in two ways:

Bring a product or service that’s worth money into being
Create or optimize a process that makes said products or services easier or cheaper to create or maintain.

Whenever we’re doing either of these things, we’re adding value.

So when we think about how we can create value, aka how we can provide a value add, we can really do that in two different ways. We can either take a product or a service that doesn't yet exist, but it's worth money and we can take that product or service and bring it into being, or we can create or we can optimize a process that makes those products or services easier or cheaper to create or maintain. So we can either make the thing or we can make it easier, better, cheaper to make the thing. Whenever we are doing either one of those things, we are adding value, and project managers do both. So project managers lead and coordinate efforts around number one. Whenever you are interacting with a product or a service that you paid money for, whether that's a piece of software, whether that's a pair of shoes, whether that's a hair product, whatever it is... whenever you are interacting with something like that as a consumer, a project manager almost certainly brought that into being.

We can take a look at a few HESA examples. If you, for example, create a new program at your university, that is a really clear example of number one, right? So let's take a ticketed event as an example, right? So let's say that you create family weekend at your university where there used to be no family weekend. And so now all of a sudden there is an opportunity for your department to sell parents and family members tickets to an experience where there didn't used to be anything like that. That's very clearly an example of adding value. It's a very straightforward example. If you are lucky enough to oversee like a homecoming or a family weekend, or maybe if your university's theater department is housed within your functional area, that's a very clear example of a ticketed event.

But most of us are not that lucky. I would say I would say it's probably not the norm to have that straightforward an example of creating value within your organization. So we have to think about number two. We have to think about ways that we create or optimize processes. So for example, during my last two years in higher education, I created a committee that created and streamlined processes across student affairs departments. We were able to save tens of thousands of dollars by the end of that committee's work, just by identifying redundancies, identifying opportunities for collaboration, and all of that money went straight back reinvested into budgets, and was made available to stakeholders like students in ways that it wouldn't have been before that committee. So that's an example of creating or optimizing a process that makes products and services easier and cheaper to create and maintain.

Another example would be if you are in academic advising and you are in an office that has never used a CRM and you lead efforts to move toward maybe adopting a CRM for the first time or maybe moving toward a CRM that is more efficient, more effective, saves staff time that then can be reinvested into student success. That's an excellent example of creating value.

Just as a side note, you'll hear people talk about a value add. This was a phrase that originated in the software world: so when that phrase was first introduced, an example of a value add would be an additional feature for a software package, right? It's since gone pretty mainstream and you'll hear people all across industries talk about value-adds. All they mean typically is an example of a time that you've created or added value, right? I guess you can kind of think of it like Kleenex, right? The word "Kleenex" began as a very specific reference to a specific company and now it's just sort of a synonym for "a tissue". The word sort of lost its very specific meaning. So 99 times out of a hundred when people talk about value add, that's all they mean.

19 of 84

Creating Value as a Project Manager

What is the fundamental problem we’re solving?

Management requires 1) effort and 2) a skill-set. If we ask subject-matter experts to lead this effort, we’re taking away from time spent in their skillset – and we have no guarantee that they’ll do it well.

PM’s value comes from stewarding all these resources effectively.

So, let’s put everything that we’ve talked about in this module together and answer the question that’s most pressing: why do project managers exist? Are they just paper pushers? (You’ll hear this pushback a lot, and even I have days where I’m like, man, literally all I did today was send like 800 emails.)

The answer to why do project managers exist lies in the fundamental problem that project management was created to solve, which is that management is a skill set, and it requires effort, and it requires someone proactive and action-oriented overseeing the way that work happens, from start to finish.

Close your eyes – no, really, I really do want you to close your eyes here – and imagine a time that you’ve been led by someone who very clearly didn’t know what they were doing. No malice, no shade… there are lots of reasons that might have been the case. Maybe they were new. Maybe their own plates were too full. Maybe they were disengaged, but it didn’t have anything to do with how they felt about their jobs; maybe they were just really going through something. There are truly so many reasons this person may not have shown up the way you wanted (or even needed) them to… but the fact is that for whatever reason, you did not feel like your work and the work that your team was doing was in safe hands.

This lack of security probably showed up in lots of subtle ways and lots of large ways, right? For example, you might have had to constantly fact-check the things they were telling you. If they shared that an initiative or a program was on track, you may not have felt like you could believe them without checking for yourself. If they took minutes for a meeting, you might have taken it upon yourself to review them just to make sure they were accurate, especially if part of your work depended on said accuracy. All in all, not a super pleasant experience.

Now imagine a time that you’ve been led by someone who really created a feeling of confidence in you. They showed up prepared every time you were scheduled to meet or speak, and even when you ran into them off-the-cuff, it was clear that they really had their finger on the pulse of the work you were doing together. If they said they’d get something to you by a certain time, you believed them. If they gave a status report on how something was going, you believed the report, no questions asked. And if they announced that something you’d been working on together had run into delays, you were quite confident that they’d done what they could, and now it was time to work together with them to figure out how best to solve the issue.

You want to work with that second person, right? Well, guess what: so does everyone on earth.

Funders want to write grants to that second person. Collaborators want to ink six and seven figure deals for long-term collaborations overseen by that person. Experts in their field want to come work for that person, because they know they’re going to be able to just be engineers, or legal experts. And CEOs and chief operating officers and chief technical officers and all the other people in charge of writing and approving org charts know all of that, too. And that’s why project managers exist: because literally everyone’s life is easier with great project managers.

And therein lies both the problem we’re solving – that without PMs, work is inefficient and mismanaged and no one gets to be their best – and the clearest way to articulate the value we create: every person involved in a project, no matter where they work or what they do, is engaged more effectively under a great project manager.

We always want to be doing our work in a way that makes the people we work with, and the people we serve, feel like you felt when you were imagining that second person, the leader who made you feel like they had everything on lock and like if they weren’t raising a flag, there was no flag to be raised. That’s the memory we want people to have of working with us. So throughout this program we’ll talk about how to steward all the resources we have available to us effectively and how to practice this along every step of a project, from start to finish.

20 of 84

Tools to ground yourself in creating value

Remember: as the PM, your job is not to know how to do any of these things. You do need to understand 100% of them.

A script for when you need to pause:

“Can you share more about that? I want to make sure I’m understanding correctly as I get myself up to speed.”

Perspective-taking as a tool:

What would an engineer say here? What would an attorney say here?

So now feels like a good time to share a couple tips with you about what to do when you don't know what to do, because I wanna normalize that that is super, super common. I would actually argue that if you are a project manager that has never felt like you don't know what to do, honestly, that you probably don't exist. So because of that, I do think there are ways we can be strategic about grounding ourselves in value even when we're not sure what to do, and I think it's one of the most important skills we can practice.

So first things first. I am always gonna recommend being honest and straightforward with your team about your experience. So I will give you an example. About a year and a half ago now, I bid on and won a job managing a consumer packaged goods project. So consumer packaged goods, or CPG, has to do with cartons, wrappers, bags, et cetera. for food -- Um, sort of the packaging for the food that you eat as a consumer. So if you open up a wrapper or if you open up a box or a bag, LOTS of stuff went into that. A designer designed that. And then a print shop printed that, a legal department took a VERY fine tooth comb and went over all of the claims on the packaging, all that good stuff. So it was about a six month long project. And there were SO many times during that project that I felt very over my head. What I could always come back to and hang my hat on was the fact that I had shared with them that I didn't have any CPG experience. Thank God.

So I wouldn't be surprised if that thought kind of turns your stomach a little bit. Being new is hard. I wanna invite you to think again, just as we are so often throughout this program, um, about how many times you had to learn something new in your time as a higher ed professional, right? And if you watched somebody around you do that, I want you to think about how you felt watching that, right? So let's say you are an admissions professional, and let's say that you are sitting in a meeting with somebody who is either a brand new admissions professional or who didn't come up in the same kind of school and circles that you did. Or maybe you're on an interdisciplinary committee with somebody who has never done admissions work. And let's say that somebody throws the term FTIAC around, which stands for first time in any college.

And if somebody at that table says like, ah, hold up, what is a FTIAC? If you are that admissions professional, probably you don't think anything of it. You just sort of say, oh, it's a first time at any college student, right? You might even apologize for using jargon without making sure that everybody was on the same page. You certainly wouldn't look at that person and think like, oh, what an idiot, right? Even if they were an admissions professional, um, you might think like, huh, well that person really came up with a different set of jargon than I did, right? But you wouldn't think, wow, that person must have never encountered a first year student, right? What you would think is, oh, that person didn't know the term FTIAC. And then you would immediately move on if that person demonstrated competence and commitment in other ways. You wouldn't immediately make a global snap judgment based on that single interaction.

So I think that's a helpful example to kind of ground us in this idea that, as a project manager, our job is not to know how to do this stuff, right? Our job is to know how to do zero of these things, but we do have to understand a hundred percent of them. And so if you are the person at the table watching admissions reps sitting around and talking about, you know, FTIACs, it's very, very normal, in order to come to an understanding of what that means, to have to ask questions. Questions are one of the biggest tools in your tool belt as a project manager. So one of the things you see here is a script for when you need to pause, right? If you need to take this script word for word verbatim: can you share more about that? I wanna make sure I'm understanding correctly as I get myself up to speed. There's a couple things I really like about this script. I like that it's collaborative. I also like that it takes responsibility for the fact that it's the project manager's job if they're managing an admissions related project, for example, to know what the term FTIAC means, right? But so often all that means that you have to do is ask. Asking questions and getting them answered is such a valuable trick, but we sometimes underplay it, whether that's because we're embarrassed to ask questions, whether that's because we don't know who to ask.

And then the second tool that I share here is this idea of perspective taking as a tool. This is a technique that I developed as a new project manager, because again, project managers so often oversee interdisciplinary teams. And so whenever you are trying to figure out what to do next, whenever you're stuck, whenever you're not totally sure what the next right move is, I find that it's really, really helpful to envision all of your stakeholders and just start thinking, okay, let's say there's an engineer on your team and you need to figure out what the next step is. After this project charter, what would an engineer say is needed? Let's say there's an attorney on your team. What would an attorney say? What would a marketer say? What would a nurse practitioner say, right? And you know, if you're in healthcare, that actually genuinely may be a project team, right? An engineer, an attorney, a marketer, and a nurse practitioner. And who has all those backgrounds? I'd venture to say no one. Certainly no one I know.

The point is, you have a very varied set of stakeholders, and if you can take five minutes to do a perspective taking exercise where you're really letting yourself imagine, what would all of these different people say if I put this problem in front of them? And you may not know the recommendation they make. In fact, you probably don't, right? If you didn't go to law school, you probably don't know what an attorney, what specific recommendation they would make, but you probably know what they would zoom in on, right? You probably know what you would sort of instinctively point to when you were showing an attorney the problem.

So certainly again, you DON'T know what they would say. So we use all these tools together: we use perspective-taking, to shape how we lead, but then we also back it up by asking questions, and the entire time we're transparent and up-front about our experiences. And remember: you do NOT have to know going in how to do all this stuff to be a successful proejct manager. Your job is to understand how these processes work and how they contribute to the overall project success.

21 of 84

Project Life Cycle

Recall that management is a set of principles related to planning, organizing, directing, and controlling in a work setting.

PMI calls this a project life cycle, and it divides this into 5 stages:

Initiation
Planning
Execution
Monitoring & Controlling
Closing

All right. So recall that management generally is just a set of principles related to planning, organizing, directing, and controlling in a work setting. And so project management is taking those principles and applying them to a project, which again, is something that has a defined beginning and middle and end. And it also has a defined set of objectives. So when we take these things together, project management calls this a project life cycle. When we think about the set of principles related to planning and organizing and directing and controlling, project management calls that a project life cycle. And it divides this into five stages.

So we initiate a project that comes first. Once we have finished initiating, we move into planning. Once we finished planning, we move into execution and monitoring. Um, so that's kind of the odd thing that I really wanna flag for you about the project life cycle.

Um, initiation and planning happen in sequence. So you initiate a project, you finish initiating, you plan a project, you finish planning, you move from planning into executing. And as you are executing, you are also monitoring and controlling that project. It will become clear as we move through the program and we move through the modules and talk through what those things look like, why those two stages three and four, execution and monitoring, happen in parallel to each other. But of course, if you have any questions, you know, get in touch, ask in the community, all that good stuff.

So while execution and monitoring are happening in parallel, we wrap those two stages up and then we come to closing. We're gonna close out that project, which is then gonna free us up to initiate other projects, or to maybe return to this project if it's iterative. (We’ll talk about that when we get to closing.) In any event, we're going to close a project before we begin moving on from it, right? So we're not just going to assume that the work is done and not inspect it. We're gonna formally close it. And only then are we gonna consider this project concluded or finished. So again, PMI calls this project life cycle. It divides the project life cycle into five stages, which are initiation and planning, which happen in sequence. And then once we finish planning, we move into execution and monitoring, which happen in parallel. Once we wrap up execution and monitoring and parallel, we move into closing. And once we close the project, we consider it finished.

22 of 84

Concept: Phase Gates & Milestones

Milestones conceptualize progress throughout a project.

Phase gates are big-picture milestones that mark moving from one stage of the project life cycle to another.

Typically, once we pass a phase gate, we don’t go back.

Really quickly, I want to touch on a vocabulary-based concept that will be helpful to you during your time as a PM. Recall that basically, what a project manager does for a living is track the progress of many processes across an entire project. So what you see here on the screen is the concept of phase gates and milestones. Milestones you’re probably actually already pretty familiar with, because outside the discipline of project management, you’ve probably used the term or heard someone else use it. Very simply, a milestone just conceptualizes progress. That’s all it is. If you decide that you want to complete a marathon, one of your first milestones might be completing your first mile. And then your first 5-mile run, your first 10-mile run… all the way up to your 26-mile run. So you have mileSTONES along the way, leading up to this larger project.

Phase gates are bigger picture. It’s kind of up to the project manager’s discretion: what makes the most sense to carve out, as a given milestone, that makes progress toward a larger collection of tasks? You might actually have a somewhat small task represent a milestone, because it’s the cherry on top of a larger phase. Example: Let’s say that you need to close up the phase of active negotiation with a vendor, and so ultimately the task of archiving the finalized statement of work to Google Drive is a milestone. It’s a very small thing, it’s non-ceremonious, BUT it’s the last thing that needs to be done before you move out of negotiation. So, again, it’s up to the project manager what is a MILESTONE.

Phase gates are milestones that are bigger picture. They mark moving from one phase of the project life cycle to another. So it’s kind of in the name… it’s THE thing that you do to say, okay, we’re no longer in this PHASE of the project, we’re now in this PHASE of the project. So for example, as we move through this course, I will share all of the individual phase gates for the project life cycle. You don’t need to know this right now, but as part of the project initiation phase, we are going to complete a project charter. It’s the very last thing we’re going to do in the project initiation phase. Once we complete it, and have it approved, that’s actually how we know that we’re moving out of initiation, because once we move out of this phase gate, once we move THROUGH that gate, we’re moving out of initiation and into planning.

What you see here on the screen is that TYPICALLY once we move through a phase gate, we don’t go back. That’s not ENTIRELY why we designate phase gates, but it’s a big PART of why we designate phase gates, is so that we can say: if everybody agrees that this project – again, we’ll use the example of initiation – if everybody agrees that this project charter is complete, then we can move forward, and we’re no longer in the initiation phase. Part of the purpose of a phase gate is so that everyone can sign onto the idea that: hey, it’s a speak now or forever hold your peace. Speak now… otherwise, we’re moving forward out of initiation and we’re not going back.

So typically, again, once we pass through that phase gate, we’re not going back. Every phase gate is a milestone, but not every milestone is a phase gate. So just a quick little bit of vocabulary for you, because you will hear both of those terms used very often as a project manager.

23 of 84

Fit Check!

What have we learned in this module about great project managers?

All right, so really quickly, let's do what I'm gonna call a fit check. We're gonna do a couple of these throughout the program, and that is because the very most common question that I get about project management doesn't actually have anything to do with what is project management, or what it's like to be a project manager. The question that I get the most often is: would I like being a project manager? Is this a good fit for me? And so again, throughout this program, at a couple different points, we're gonna stop and kind of tackle that question. We're gonna talk through: okay, so based on everything we've talked about so far, what are some of the questions you should be asking yourself in order to evaluate whether you would be a good fit for this role? And really at this point, I think the question that you need to be grappling with is: how comfortable are you with ownership?

�Which again, is not the same thing as a boss relationship. It's not the same thing as having power over somebody. A project manager is really the “buck stops here” person, right? A project manager is really the person whose role is not only to know all of the details (although that certainly is a piece of it), but also to be the one who is responsible if something is confusing or if something is left undone. And if we're not sure who's going to take the lead… thinking back to the “who will do what by when” framework, the project manager is the default person to be able to take action. So they have to be action oriented to resolve ambiguity during a project, which again, is not the same thing as doing all the work. In fact, many project managers manage their entire PM careers without really ever living in execution land and contributing their own work to a project.

�So it's, it's really an entirely different skillset so we can practice beginning to think about work that way as well, right? And so, again, the question that I would really encourage you to ask yourself at this point, am I comfortable with ownership again, particularly when I might not be the one doing the work? Am I comfortable owning the results of other people's work, organizing it, reporting it upward, tying it to strategy? That's really what a project manager does. And so if any part of that kind of makes you feel uneasy or queasy, honestly, I think now is a really good time to get in touch with me, or with another mentor you might have… it's a really great, great question to bring to our next community session. (So those are monthly and you can sign up for those in the learning platform.) But again, if you're not comfortable with that ownership mentality, that would be the first red flag that PM is not for you. Certainly a lot of the things that you hear, you know, so you'll hear that PM is for detail-oriented people. That is certainly true. And if you are not somebody that loves details, that might be something else to flag for your fit check. But frankly, you can also get tech systems in place to do that for you on some level, right? On some level, you can get the computer to do the thinking, for you to remember dates and details and all that good stuff. You cannot get a computer to do the work for you of taking initiative and ownership and leadership and stepping up, especially when you might not know the answers to some of these questions.

So if you think back to when we covered the business environment, you are gonna have to liaise with all those people, and you might not know what they do. You might have to ask a lot of questions, and you might kind of have to be Googling before and maybe even during you talked to them, um, to figure out what it is that they do. And if that freaks you out a little bit, that's okay. It's very normal. It honestly freaks me out a little bit too. Sometimes even, you know, a couple years into this gig, it, it, it can freak me out a little bit. So, very normal to be a little freaked out. But if it really sends you spiraling, right? If it just makes you doubled over to think about moving forward without knowing what to do, talking to people who know more than you do about what you're doing… if that really freaks you out, I would say that it's not so much that PM might not be for you, but I think you gotta stop and pause and figure out what it is about that. And part of what I'm here to do is help you with that. So this is our first fit check. How comfortable are you taking ownership?

24 of 84

Vocabulary for this module

Projects & project management
PMBOK
Project Life Cycle – initiation, planning, executing, monitoring & controlling, closing
Milestones
Phase Gates
Business environment

25 of 84

A few thoughts on human nature

So to close out, one of the things I wanna leave you with for each of these modules is a few thoughts on human nature. So you can learn everything in the world about project management from a book perspective, and you should! Most of the best project managers I know spend a lot of time learning about their field. Whether that's the discipline of project management, like I said, that big p big m project management field that we talked about earlier, or whether that's the discipline that they're working in, for example, marketing, technology or education. But the very best project managers also have a really, really keen understanding of human behavior. And so we're gonna spend a little bit of the last of these modules talking about how human nature sometimes throws us curve balls, and what we can do to resolve that. In this very specific case, the human whose nature is being examined is actually you.

I wanna spend a little bit of time talking about how you can pace yourself through this course. I think it's very natural to want to speed through this content just to make sure that you understand it right? Like you buy the subscription and then you're like, okay, I just wanna take all of it in at once and then I'll know whether it's a good fit for me and then I'll know whether to keep going. I think that is natural and it's human nature, and that frankly is how I approach e-learning a lot of the time. Which is why I can tell you that I actually think it's probably not the most effective way to sit through content. I would encourage you to sit with the idea that it's actually better to take your time with each module and to make sure that you really, truly understand how it connects to you in your career. I would argue that that is better than it is to get through as quickly as possible and then try to go back and connect the dots later.

So certainly move as quickly as is comfortable, right? Like, you don't need to hold yourself back because I'm telling you that you can't rush through, move at the pace that works for you. But I'm gonna encourage you to make sure that the pace that works for you includes connecting the dots to your current higher education career as you go. And as you go, to be thinking about, hmm, what are some times that I've done something like that? Or what are some ways that I could get some experience doing that if I haven't already? And if I have some questions, let me pop over to the LinkedIn community and see what people are thinking over there. Let me ask Caroline what she thinks about blah, blah, blah. Not that you know, I'm your end all, be all. I don't need to be. But the more people you ask about an idea you're chewing on for the first time, the more likely you are to land on an answer that actually genuinely works for you. So again, what I'm not saying, you know, is, you know, take your sweet time with this and then 10 years later finish the program. What I am saying is, take your time, connect the dots as you go. Sit with ideas. Make sure that you can really, truly see yourself in the content. Because otherwise, what was all this for? And the other thing I'll say is if you are somebody that's just rushing through and you wanna race to the end, because it's really important to know like, oh gosh, is this really a good fit for me? That is coming from a place of scarcity, that is coming from a place of fear and you not being sure that you're good enough. And so you wanna race to the end to make sure that this actually does fit you. And I would really love to encourage you to sit with the idea that you are good enough that you're already doing parts of this work, and that the work ahead of you is achievable and doable as you finish this pivot. So again, not trying to slow you down, just also trying to make sure that there's a counterbalance in case there's a voice inside of you that's rushing.

26 of 84

“Operations keeps the lights on, strategy provides a light at the end of the tunnel, but project management is the train engine that moves the organization forward.”

Joy Gumz

So if you weren't convinced before of my background in student affairs, uh, perhaps it will convince you when I say that we are gonna end each module with a quote. I think that this is a really helpful way of kind of viewing the difference between what I would call the trifecta of operations strategy and project management. So, operations keeps the lights on. Strategy provides the light at the end of the tunnel, but project management is the train engine that moves the organization forward, right? So operations are all of those things that we have to do in order to make sure that the organization continues to exist into perpetuity. So I gave the example earlier in this module of processing payroll. You have to process payroll. People aren't gonna come to work tomorrow if you don't process payroll, right? We're also really, literally keeping the lights on.

You have to pay the electric bill. People also aren't gonna come to work tomorrow if you don't pay the electric bill.

Strategy, you know, anytime you've been familiar with a strategic planning process, know that this process is actually very similar in lots of corporate settings, right? So strategy provides a light at the end of the tunnel. Where are we going? What are we doing? How are we gonna get there?

But project management and project managers are really the people that are pushing that work forward and making sure that those initiatives happen in the order and in the manner that they're supposed to. So beyond keeping the lights on, beyond providing that light at the end of the tunnel, really driving the organization forward, hopefully this module has given you a good sense of how that looks, um, and how that may look for you in the future. As always, if you have any questions, let me know. Otherwise, I'm excited to see you for the next module.

27 of 84

Thank you!

Next up: Module 2, where we’ll discuss Project Initiation

createboundlessimpact.com | @carolinemanages + @boundless_impact

28 of 84

The Aspiring Project Manager

Module 2: Project Initiation

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

29 of 84

What We’re Covering

Welcome
Stakeholders
Initiation definition
Scope
Scope & Stakeholders example: vFairs
Constraints & the “Triple Constraint”
How to start working on more “initiation” based projects if you aren’t already
Fit Checkkkkk
Closing Out
Resources & Next Steps

30 of 84

Concept: Stakeholders

Anyone who affects, is affected by, or perceives themselves to be affected by a project. (Anyone who has a "stake" in the project's success.)
Stakeholders do NOT have to be internal to the project team or even the organization.
Stakeholders can influence the project positively OR negatively.

Before we really get into thinking about projects and how we run them, I want to take a few minutes to talk about the word “stakeholders”.

The first thing to know about this word is that it’s broad. The reason it's called a stakeholder is anybody who holds a stake in the project's success, right? So anybody with skin in the game, whether that's internal to the project or even the organization. Maybe a stakeholder is external! For example, if you think about a project to build a parking garage in an urban environment, you can imagine that some of the stakeholders might be the internal project team folks – so your engineers, your urban planners, your construction management folks. Some of the stakeholders internal to the organization but external to the project team would be the customer service folks for the construction company: they’re not moving the project forward, but they sure do care whether you use that project to meet the organization’s revenue goals. And then we can also think about stakeholders who are external to the organization entirely. Folks who live on the same block that the parking garage is being built definitely care, both about the parking garage that they’ll ultimately be sharing a street with and about the extent to which you impact their lives during the project’s completion. Folks who will use that parking garage to park one block closer to their jobs during their daily commute are impacted by the project. And, depending on the extent to which you’ve properly conducted your stakeholder analysis, a project manager may find that the residents on the street and the commuters using the garage to park have very different feelings about the parking garage project. So stakeholders can have positive or negative orientations toward the project.

You'll hear the word stakeholders used a lot during your segue into project management. Whenever you hear someone make the claim that “ultimately, project management is about people,” they’re referring to stakeholders (because recall that internal project teams count as stakeholders, too). I have a lot of very strong feelings about the fact that the word stakeholder is not just jargon. It’s such a broad term because it’s truly foundational to the profession. Any stakeholder can make or break a project; we see that all the time.

In our parking garage example, obviously the project is a no-go with respect to adding value if your engineers and your urban planners and your construction management folks are a no-go. But moreover, if your sales folks aren’t impressed by your ability to execute the project, that’s going to bleed into your ability to win these projects in the first place. If the residents aren’t happy with you, you could wind up facing a real public backlash or even a lawsuit. If your commuters aren’t happy, you won’t wind up with folks paying to use your product which means you just lost money. So, truly (and especially in this age of social media and community organizing), any stakeholder, internal or external, has the ability to make or break a project.

This is good news for you, though, because the fact is that stakeholder relations are probably one of the strongest pieces that you have transferable skills for as a higher education professional. Think about everything we just said: we’re talking about project teams (which you almost certainly have experience influencing if not supervising). We’re talking about organizational partners (what you might call “campus colleagues”). Certainly we’re talking about external partners: so for my government relations folks, for my alumni relations folks, anyone who liaises often with parents or community partners, for my articulation agreement folks in records and reg who are working with partners at other schools: these are all truly excellent examples of stakeholder work.

31 of 84

Project Life Cycle: Initiation

Aligning on the WHY of the work:

Business case: need + justification + strategy
Overall objectives
Stakeholder analysis
Risk analysis

Aligning on the VERY high-level HOW of the work:

Resources (budget)
Scope & Deliverables

You can really think of project lifecycle initiation as aligning on the why of the work. So we're thinking about the business case, which is a phrase you should get comfortable hearing and using that basically means that we’re “making a case” for the project to move forward, which is important because projects cost time and money. If you haven't heard this phrase in the higher ed world, you may hear it in where you're going next, particularly if you're going somewhere a little more corporate.

You'll hear business case used to describe any document that really outlines these three things: need for the project, justification for why now is the time to spend those resources on making that project happen, and then strategy for how the project manager really is going to be the one to make that project manifest into reality. So a business case combines overall need, regardless of time or context, justification for why the time is now to devote resources, usually time and money into making a project happen, and strategy for how that's going to happen.

In addition to the business case, we're also looking at overall objectives. So what does the project need to accomplish? And then we're also looking at a thorough stakeholder analysis: who’s in the mix and what do they need the project to accomplish? Who is involved in getting that project off the ground? Who benefits from finishing that project? Anybody that's affected by the project. And, critically: what happens if any of those stakeholders don’t get their needs met… which sort of bleeds into risk analysis.

What are all the potential things that could go wrong here – including the risks of not taking the project on? Ideally we can use the work we did in the business case to support this – so you can see how the initiation phase is all connected.

And then finally we’re also aligning on the very, very high level how of the work. So we're not getting into the planning weeds; remember that planning is the next phase of the project life cycle. But we are starting to think about the very high level how, as it relates to the why of the work, right? So we're starting to think about resources. We talked about justification in the business case, right? Why is the time now to apply those resources? Well, the natural next step from that is thinking about, okay, from a resource perspective, how are we gonna allocate the budget with respect to finance and human capital? How are we gonna allocate the resources to get that done?

Finally, during the initiation phase, we’re gonna land on scope and deliverables. I'll talk a lot more about scope in a subsequent lesson.

32 of 84

Concept: Scope & Scope Creep

Scope is the total amount of work that needs to be done to complete a project.

“Scope creep” is when a project keeps going further and further outside the bounds of what was defined in the “initiation” stage.
As a project manager, your job is to fiercely defend scope.
Ultimately, scope results in deliverables: tangible or intangible.

I would say that, next to stakeholders, scope is one of the most foundational concepts to being a project manager. So scope is everything that a project encompasses, and really importantly, everything that it doesn't encompass. Scope delineates those things. It says everything in this bucket is part of the project and we have to accomplish it. Otherwise, when we get to closing, we're gonna realize that we didn't do the project properly, right? And carving out that bucket also allows us to carve out a second bucket saying everything over here in this second bucket is not part of the project. Everything over here in this second bucket is outside the scope.

As a project manager, let me tell you right now that you will spend a lot of your time after you pivot into a PM career describing something as in scope or out of scope. We will talk throughout every single module in this program about scope, and you will probably use the term every single day of your PM career.

A closely related concept to scope is the idea of deliverables. So deliverables is basically a fancy word for the result of the project. Sometimes deliverables are physical deliverables, like a car. Other times a deliverable might be something that you can't hold, but that still exists as a product, like a website that a company pays a web developer to create for them. Or it could even be like a knowledge piece, right, like if you’re a think tank and your job is to undertake a project and compile a whitepaper. Whatever the result of the project is, whatever you are supposed to create as a result of finishing the project, that is called a deliverable.These are things that by the time we successfully complete the project at the end, that's what we should be able to successfully inspect and say, yes, we did that. We live up to what we said we were gonna do.

33 of 84

Concept: Constraints & the “Triple Constraint”

Constraints are the limitations that we’re working within as project managers.

Everything is limited: time, human capital, financial capital. Most of the time, one or two constraints run the show. (Your job as a PM is to know that.)
The “triple constraint” refers to the triangle of time, budget, and quality.

Time

Budget

Scope

“You can have it good, fast, or cheap. Pick two.”

Quality

“Constraints” refer to the idea that everything in our lives is limited, right? Our time is limited, the human resources that we work with are limited – we don’t have teams with infinitely many people on them, all of which are top experts in their fields – and financial capital is limited – we’re not working with billion-dollar budgets to plan a single event. If that were the case – if we had unlimited time, unlimited human capital, and unlimited financial capital – you can imagine that project management probably wouldn’t be a job, right? Because it it wouldn’t matter how long something took, or how efficient a process was, but the fact is that because our resources are limited, it does matter how efficient we are. So by the way, that’s another way to think about that value framework: why it’s so important that everything we do creates value. So a constraint is anything that’s subject to limitation – anything that we don’t have control over how much we have access to.

Most of the time, one or two of those constraints are running the show when it comes to our projects. To kind of illustrate how that plays out, we can look at something called “the triple constraint”. Project managers will talk about the triple constraint being made up of a triangle of time, budget, and scope, and the expression that they use (and which you may have heard somewhere else in your life up to now) is that “you can have it good, fast, or cheap, but you have to pick two.” So in that first bullet point I talked about how most the time one or two constraints run the show; if you think about time, budget, and the ultimate quality of your scoped deliverables as really sort of the variables that you’re working with, and you know that you have to create something that doesn’t compromise even a tiny bit on scope and you have to do it really quick, you can probably imagine that you’re probably not gonna be able to do that really cheaply. You’re probably gonna have to pay… whether that looks like paying the team that you have overtime, whether that looks like paying additional team members to come in… if you want something really good, but you also want it really fast, it’s not gonna come cheap. Similarly, if you have a real shoestring budget – if you don’t have almost any money at all – and you have to turn something around really quickly – maybe you’re being given a week to do something that should normally take a month – you can probably extrapolate that if you get it done, it’s not gonna be very good, right? So again, that idea that you could have it good or you can have it fast or you can have it cheap, but you can only pick two, is is a really really good example of how constraints work. Again, what the world would look like if there weren’t any constraints is: you could have it really good and really fast and really cheap: maybe for two dollars you could turn around and have this amazing software package written and built out overnight and it would be the greatest software package in the world and you could sell it for $10,000 a pop to every single person in the United States. If we didn’t have constraints, that’s how it would look and I can promise you that if that were the case, project management would not be a job. Thankfully for us, that’s not the case, so project management is a job.

Your takeaway here is that one of the things you’re always trying to understand with your boss is exactly what the constraints in which you’re operating look like. We’ll talk more about this in module 4 when we talk about executing, but part of your job as a project manager is proactively problem-solving whatever comes up along the way, and in order to function that way you’re going to need to have a really good understanding of where you can and can’t flex along this triple constraint triangle.

I’m going to link a really good animation about how constraints work following list so if this was really clear great, if you’re still a little bit fuzzy on the idea of how constraints work, and in particular how the triple constraint is an illustration of constraints, go ahead and watch that animation in the resources section and see if that helps!

34 of 84

OK, so let's put our concepts of scope and stakeholders together. Let's say you're working on building out a virtual event space, and you're sent the following by your tech partner as an example of a "virtual environment you need to build out." After some consultation with the vendor and based on documentation from a previous project manager, plus your experience attending and maybe even putting together virtual events, you understand that this means your job is to put together what will be the lobby of this virtual event space.

Who are the stakeholders you're working with here?

Graphic designers - who may have a pretty good idea of how they want this to look
External sponsors - who may have no IDEA how they want this to look but who DEFINITELY know how they DON'T want it to look, and who may or may not remember that they have entire brand guides that are DEFINITELY relevant here (whether or not they remember to share that with you)
Subject matter experts – e.g. learning & development experts
Legal approvers
Your boss, who may have come to zero meetings or every meeting or somewhere in between
The vendor themselves

Someone might want to come in and say "oh my gosh, I didn't know we could do XYZ. We should do not only THAT but we should do SIX of that. I don't even care that it pushes the go-live date back... how cool would it be to have six!!!"

So now you know some of the language you can use to push back on that. It's out of scope; the stakeholders are going to be affected by pushing back the go-live date.

That said, there can be a real tendency to be like RED ALERT OUT OF SCOPE ABSOLUTELY NOT. Great project managers balance that RED ALERT with human communication skills. We’ll talk more about change control in modules 4 and 5, too, but do know that of course there’s always room for grey area. Think back to our triple constraint: if the project team is in alignment about wanting to modify the scope to expand it, and you have the time or the money to flex being able to do so, the project team you’re leading might decide to do so. Again, we’ll talk about the mechanics of that later in the program, but I do want to underline for you that our role as project managers isn’t to be totally inflexible even when it makes sense to shift. Our goal is to keep shifts organized and documented, and to keep teams in alignment.

So now, let’s zoom it out. Let's say you're building a software package over an entire fiscal year. Same deal, right? You have all the same stakeholders, but now you're building a whole thing. Same general rules apply:

Follow the rules of the triple constraint to honor the context of your project
Use your communication skills to keep everyone informed and satisfied with the progress
ADD!!! VALUE!!!!

35 of 84

Connections to Higher Ed

Anytime you’ve had to get the greenlight to work on a project
Anytime you’ve been filtering collaboration requests
Anytime you’ve had to build a case for funding
Anytime you’ve done any kind of benchmarking
Anytime you’ve carved out what is and isn’t involved in the work at hand

So that's a little bit about initiation from a textbook perspective. Now let's go into kind of connecting that to higher ed. So again, you can think of this as the why of the work. So if you have ever had to get the green light to even start working on a project, that has been initiation. For example, in residence life, if you have had to sell the value of moving to a curriculum based model, right? That probably involved a lot of benchmarking, which ultimately you did in service of thinking through business case. How has this worked elsewhere? How has this added value elsewhere? So need and justification and strategy. It definitely involved thinking through overall objectives. So what did you want to accomplish by moving to that curriculum?

And you probably also had to think through stakeholders, right? So for example, certainly your students are always a stakeholder, but also, if you had to work with faculty or other staff on campus, that was a stakeholder. If you had to work with an external partner that was a stakeholder. And then also we can start thinking through the very high level “how” of the work, right? So again, if you are a res lifer and you're moving through the idea of selling the curriculum based model upward, you probably had to think through how am I gonna make that happen? Is that something that I can do on my own? Is that something that I need to loop my team into? If I do loop my team in, do they have the capacity to make that lift on top of what they're already doing?

And then scope, right? What is the scope of integrating a curriculum like that? If a faculty member came to me and said, Hey, I really wanna loop you into the common read, right? I think that would be a really great way for that residential curriculum to kind of hold hands with academic affairs, would be to connect it with the common read. Would that be within your scope or would you sort of say like, ah, that's not really part of this project, but I would love to keep the door open for future collaboration, which is stakeholder relation management, right? So that's a little bit of a gray area, and as a project manager, you’d use your knowledge of the project’s context and your environment during the project’s initiation phase to make a decision on whether to expand the project’s scope.

We can also kind of illustrate with, with a more extreme example, which is, you know, let's say you're working on selling a curriculum upward as a residence lifer, and a faculty member says to you like, hey, I think it'd be really great to loop in my intro to chemistry lab with that. That's a very clear example of like, that's actually probably not really within the scope of this project, right? Um, similarly, if somebody from grounds reached out to you and said, Hey, I really wanna loop in, you know, like this garden-planting cycle to this project, it would be very clear to you – even if you weren't using the word scope – that like, wow, this person has absolutely no idea what this project is about. Like, that doesn't even make any sense as a potential collaboration.

So what I wanna flag for you there is that if you are somebody who is really used to receiving collaboration requests, and even informally in your head, you're doing that evaluation sometimes even on the fly about whether that's a good fit, probably some of the things that you're considering are scope and stakeholder analysis, right? So that's an example of how this plays out. You can also think about in addition to that residence life based example, we can think about academic advising folks. So if you have been responsible for upgrading or moving or migrating a CRM system, because the current CRM in your office didn't provide you the suite of resources you needed, maybe you had to integrate with records and registration on your campus perhaps to do some kind of early alert system. If you were part of the initial work to think through the scope of that project, to think through the business case for that project, that's a really great example of project initiation, right?

So again, at that point, you're not planning in the residence life curriculum example or the academic advising CRM example. You're not getting to the point yet where you're planning who's gonna do the what of the work, right? You're not planning out timelines yet. You're not planning any of that. All you're doing is establishing a business case and making sure that you understand what the project is meant to accomplish and who it needs to include or not include. So stakeholder analysis, scope analysis and business case analysis. Um, that's what's involved in the project cycle initiation.

Just for your own knowledge and in the spirit of full transparency, people who are not professional project managers skip this step all the time, okay? And then they call somebody like me and they tell me that they need a project manager for an eight week engagement, which then turns into a 12 week engagement or a 14 week engagement because nobody carefully defined objectives and if you talk to three different people about what the project is supposed to accomplish you’ll get three very different answers. Folks in the corporate world are very, very familiar with that train wreck. Everybody I've ever talked to, particularly when they find out that I am a freelance project manager that I work on a contract basis will immediately begin sharing with me stories of times that projects have gone off the rails.

And so often it comes down to the fact that the projects weren't carefully and thoughtfully initiated. So if you do this work thoughtfully already, this is a great opportunity to highlight that work with hiring managers, because I can promise you that unless you are working with a really, really junior hiring manager that hasn't overseen project managers before, they are very familiar with projects going off the rails directly because nobody thoughtfully initiated that work.

The exercises at the end of this module will walk you through the process of working through your experience with these domains. I really encourage you, if you are somebody that has had a lot of thoughtful work with that initiation phase, um, play that up, because, you know, I think people think of the planning and the execution phases when they think about why they need a project manager. And that is certainly so true. Project managers, in my opinion, keep the world turning because of the work they do in those phases. But often we forget to talk about initiation precisely because so often we forget to initiate thoughtfully. So again, just a note to flag. If you do that thoughtfully, this is really your opportunity to share that with a hiring manager.

36 of 84

Project Life Cycle: Initiation

How can you start working on more “initiation” projects if you aren’t already?

In general, you can:

Expand your work assignments
Infuse this thinking into work you’re already doing

So probably at this point you’re either thinking to yourself: OK here are some examples of times in my career that I’ve worked with project initiation work, or you might be thinking to yourself: OK this seems like an area I maybe need to grow a little bit in, whether that’s growing my expertise or whether that’s growing my confidence in the sort of work I’ve already done. The worksheets at the end of this module will walk you through doing that, but I also wanna spend a little bit of time here talking about, if this is something that you that is a growth edge for you, how can you do that?

Recall that initiation is really about the big picture it’s aligning on on why we’re doing the work on the very high-level how of the work. So some of the low hanging fruit that you can grab when you’re trying to add this to your experience pile is: any time you hear words like benchmarking or business case or initial interviews. That’s a good sign that you’re about to get into some initiation work. Anytime you hear committee formation, anytime you hear exploratory, that’s work that is probably living within that initiation phase. So if you’re able to get onto projects like that, great!

If not, you can also just begin where you are, right? So think about: if your position was brand new, and if you were in your boss’s shoes, trying to get that position green lit, what are the sorts of things you would argue upward to connect your role to the strategic plan of the University? For example, if you’re a Director of Housing, it might be hard for you to imagine a time that that position wouldn’t have existed on campus, because how could you have housing department without a director? But it’s a good thought experiment to be able to engage in. So if you close your eyes and sort of say: like OK. Imagine that there is no housing department, imagine that there’s never been on campus housing. There’s never been an effort to educate folks within the context of living on the University. How would you sell that upward? How would you sort of place your work within the strategic plan of your university, or of what we know more broadly about human development? How would you do that? And then what are the sorts of things that you would want that work to achieve? What might be a preliminary list of stakeholders who are affected by you doing that work well or not? Certainly whenever you’re doing a project, the recipients of that project are a low-hanging fruit stakeholder, but think about faculty, too. Are faculty impacted by whether or not students live on campus? Are there restaurants in the area that would have opinions?

Plan A is always going to be getting yourself onto work assignments that revolve around that initiation piece, but if you’re not able to do that again, there’s also always room for kind of infusing that into the work that you’re already doing. So for example, you know, let’s say that you are an international students advisor, and that part of what you do is you plan international student orientation. Great! What is your business case and your overall objective, and how do you differentiate your program from new student orientation on the rest of your campus? How does your stakeholder analysis yield a difference between your target audience and the target audience for campus wide orientation? If somebody came to you and said we’re gonna collapse your program into the campus wide orientation program, what would you say? How would you root that in business case overall objectives and stakeholder analysis and maybe even risk analysis? How would you push back against that request?

And if you don’t have that in writing for your office, write it down! Workshop it with your team! And then you get to add to your resume that you developed a business case for your department’s flagship program – and, more importantly, you get to point in subsequent interviews to an example of you tying objectives to strategy and getting alignment with stakeholders. That’s project initiation work!

37 of 84

The Project Manager during Initiation

What are the deliverables of the project initiation stage?

Project charter/business case
Stakeholders analysis
Project budget
Project team roster
Project tools

Okay… so what, exactly, does a project manager do and produce as a result of the project initiation stage?

The project initiation stage (like so much of what we’re going to talk about) consists of a lot of meetings. One important term for you to know about is the project sponsor: that’s the person who’s requested the project – usually a higher-up in the company, and it’s the person who’s going to be the most invested in the success of your project. So let’s say you’re at a pharma company, and your customer success team has identified that 95% of all the complaints your company receives are rooted in customer service; the VP of customer success, at that point, might initiate a project focused on overhauling the training processes for on-the-ground customer service representatives.

(Side note: notice that in this example, while you’re working in healthcare, the skillset you’re employing doesn’t have anything to do with needles, or a bio degree, or needing to know what that Elizabeth Holmes documentary was about, or anything like that. The skillset here is pure project management.)

Anyway, that VP of customer success isn’t going to be managing the day to day of this project. They’re a VP, they’ve got VP stuff to do. They’re going to delegate this work, which they consider really integral to the success of their own team in the coming months or even years, to a project manager. And if that project manager is you, you’re going to be expected to provide updates throughout the process to this project sponsor.

So, as I said, this stage consists of a lot of meetings. At the beginning of the stage, you’re going to be working quite a bit with that sponsor. You’ll be working with them to solidify the business case, which will ultimately make its way into a document called the project charter. Everyone on the project team will refer back to this document throughout the lifetime of the project. (If you’re wondering whether I’ve updated a template of a project charter to the resources section of this module… of course I have, friend.) Typically the stakeholder analysis is conducted alongside this and winds up included in the project charter, though every organization does things a little bit differently.

From there, you’re still really going to be working with the project sponsor (or a representative of theirs; for example, if your company is big enough you might be working with a member of the VP’s team, or their chief of staff) to identify resources, like a budget and a team. That’s because – think about it – this person is really the one advocating for the project. So they’re going to be the ones selling upward this idea that, yes, we should allocate time and money and human resources to this project. As a project manager, you’re typically not expected to be the one going to bat hard for a project at this stage – but depending on the environment, you might be helping that process happen with some of the things we talked about earlier in the module, like benchmarking or feasibility studies.

As we get closer and closer to greenlight, we’re zooming out a bit. As the project team forms, we’re of course starting to talk more broadly across the organization, and maybe even externally. Ultimately, though, you can (and should) think about the project charter as really the deliverable of the initiation stage. And after this deliverable, the project sponsor gives the greenlight to the project manager to begin working with the project team on the planning phase.

Now, if you’re a human being (which I’m assuming you are), you’re probably along the way starting to think about the how of the work, especially since as the project manager, you’ll be the one ultimately managing it. You’re starting to think about tools, the project environment… all that good stuff. I find it completely impossible to sort of mentally divorce the planning stage completely from the initiation stage… but just know that technically those things are part of the planning stage, even though of course we’re thinking about them in the initiation stage. In any event, let’s not get ahead of ourselves, because the planning stage is just around the corner!

38 of 84

Fit Check!

What have we learned in this module about great project managers?

See the big picture & root their work in strategy
Prioritize communication and alignment
Have a good sense of their organizational & project constraints
Balance staying flexible with protecting scope

What have we learned about happy project managers?

Comfortable pushing back
Able to talk to folks of lots of different professional backgrounds

All right, so for our periodic fit check following initiation, we're gonna start talking about a fit for a really great project manager as well as a fit for a happy project manager. Because I do really believe… I have seen over the years so many really great project managers burn out, right? And some of you might be coming from places with really heavy toxic burnout cultures. Unfortunately, I regret to inform you that project management is a field where you're really gonna have to work hard on your sense of boundaries, because burnout can happen here too, right? One of the things we talked about in our last fit check is the idea of taking ownership and the idea that really great project managers take ownership of their projects really from the very get-go. What you see here under these great project manager bullet points, you see four things.

First, seeing the big picture rooting your work and strategy. We talked a lot about strategy in the big picture early on in this module. We talked about prioritizing communication and alignment. We talked about having a really good sense of organizational and project constraints. So we talked about that with the triple constraint and the idea of being really clear about what we can flex and what we can't. And then we talked about staying flexible. So really all of those things come down to ownership. Here, though, is where I wanna introduce the idea that we really need to be checking in when we think about fit, not only with respect to really great project managers, but also happy project managers. So happy project managers are really comfortable pushing back. Part of what a great project manager is gonna do is gonna be to push back when something like scope or quality gets threatened. An unhappy project manager, and I have seen this over and over and over again, is a really talented with organization and details person who then leaves a field without having done the work around being a people pleaser and is required now in their new role as a project manager to push back.

�And I can tell you that pushback plus people pleaser equals a really unhappy project manager. So if we're gonna balance that people pleaser mentality with the pushback on scope infringements and the project ownership mentality that we were talking about earlier, we're gonna have to do some work around boundaries there. And ultimately, again, you know, really, really deep people pleasing work is for therapy. It's beyond the scope of, of what we're trying to do here, but this first bullet point that you see under Happy Project Manager, comfortable pushing back, that's a really good goal to get to with respect to just work, what is an appropriate goal for work. And really what we're trying to do here in order to make sure that not only are you great, but that you're happy is we're trying to get you to a place where you're comfortable pushing back. I don't really have any interest to be honest in, you know, you paying me money to take this program and then I coach you into a situation where you know you're a really great project manager, um, and you hate it, right? I actually would rather you not even try the field at all if we're getting to that place. And I know some of these fit checks are maybe sounding a little bit doom and gloom. I don't mean to do that. Lots of people are really comfortable pushing back. Some of you are like, I don't know what she's talking about. I… this comes very naturally to me. Others of you are like, that sounds overwhelming, but it's something I can do. And yes, that is true. We will talk at the end of this course about kind of that like self-coaching mentality and also getting what you need from a network, getting what you need from mentors, getting what you need from peers.

�And a lot of that can become being very aware of, for example, a tendency to be a people pleaser. And then really going to that place when you feel that tendency coming over, um, where you're self-coaching and you get to a place where you're comfortable pushing back. I am perfectly, uh, happy telling you that I am a recovering people pleaser and that this was absolutely the most challenging part of, uh, the transition into project management for me. Um, I was always comfortable with ownership from a strategic perspective. I always felt like I, like, like I knew what the right things to do. Were. I never, ever, ever had a problem with like imposter syndrome. Am I, am I right about what I think we should be doing? Frankly, candidly, I always think I'm right about what I think we should be doing. Um, but I did really have a problem at first, again, with pushing back.

�I had a problem with feeling like, like I needed everybody to like me and I needed to be able to do that by never telling anybody no. And by sacrificing sometimes the overall needs of the project or the group for in an interpersonal one-on-one moment, that person not looking at me as a blocker, right? So if any of that resonates with you, let's talk. I think that might be something that, you know, you wind up really digging deeply into during your transition as a project manager, again, to make sure that you're happy and that you like pm. Um, and then the second thing that you see here underneath what we've learned about Happy Project Managers is that they're able to talk to folks of lots of different professional backgrounds. So there's some intellectual humility there, right? You're able to look at a room full of subject matter experts and really, really ground yourself in the fact that your subject matter expertise is project management.

�And it's okay if the person in front of you knows more about rocket science or about graphic design or about legal applications of baking brownies. Um, it's okay if the person in front of you knows more about that. All you have to know about is project management. So that's a little bit of our fit check. And again, what we see here in this Great Project manager really revolves around being able to keep strategy at the forefront as we prioritize and balance, right? We're gonna talk so much over this program about how project management is really just a push pull, and we're always sort of balancing all of these different concepts at once in order to negotiate that push pull. So that's kind of what we've learned about great project managers throughout this module. What we've learned about Happy Project Managers is that they're comfortable pushing back, um, so they don't lean too hard into those people. Cleaning ple, people pleasing mentalities. And also that they're able to talk to folks of lots of different backgrounds, so they're able to keep that intellectual humility front and center. All right? I think that means that we are ready to close out. So hopefully you've enjoyed this fit check, and I will see you for our closeout.

39 of 84

Vocabulary for this module

Scope
Stakeholders
Constraints
Deliverables
Project Charters
Project Sponsors

40 of 84

A few thoughts on human nature

All right, so for this, a few thoughts on human nature module. I want to talk about the idea that sometimes we let vocabulary and language trip us up. So in the last couple modules, we have talked a lot about the business environment in module one, which kind of oriented us to project management as a field. We talked about all the different functional areas of business because I really do believe that something that can set you apart as a project manager, as an entry level project manager is your ability to come in hitting the ground running, understanding how we interface with all these different functional areas in this module, uh, because it's initiation. We talked a lot about the business case. We talked a lot about overarching strategy. Um, and so I think because we use that word business so often, sometimes I think if we don't have, you know, an academic or an experiential background in business, we can start to think, you know, oh geez, maybe this isn't for me.

�Sometimes I talk to people who know that I have an MBA and I share that with them as a way to bring myself closer to them. I share it as a way to say like, Hey, just so you know, I do actually know this stuff. Not only do I have an experiential background, but I also have an academic background. I'm very comfortable and confident in my own business knowledge and teaching it to you. So I share that with them again, as a way to bring myself closer. And every once in a while I have found that what happens is that actually I wind up farther away from the other person, right? Um, because what they're hearing is, you know, oh, she has an mba so she knows this stuff. That's why I don't know this stuff is because I don't have an mba. And what I really wanna explore with this, you know, thoughts on human nature module for the next couple minutes, is the idea that actually all of this stuff is stuff that has direct parallels to student affairs world.

�So when we talk about a business case, for example, your university has a strategic plan, um, ideally, and sometimes we don't see this because student affairs is not a perfect field, but ideally that strategic plan has been shared with you. And part of the work that your own boss does is contextualizing your work in the context of your university's greater strategic plan. If your boss isn't doing that, that's one of the places we're gonna start throughout your time in this program is we're gonna start kind of proactively, you're gonna go in and take your university's strategic plan and start pulling out pieces of the work that you do and mapping it into that strategic plan, because that's really where we're living when we're living in project initiation. So again, ideally that's something that you're already doing. Um, certainly it's something that you're gonna be doing by the end of this course together, but if you are doing that, you are doing business case work. Even if you're not calling it that, which you're probably not. Um, you don't have to get intimidated by somebody talking about the business case. If you have any experience at all connecting your work upward to University strategy. And if you don't have any experience, it's not that hard, we'll walk you through it. I promise you don't have to be a strategy setter in order to be somebody that maps the work that you're already doing every day. Cuz you have to, cuz you have to pay your rent and no one's gonna pay it for you. So you gotta go get your paycheck, right? You're doing that work no matter what. Um, and it's not that intimidating to then turn around and find where that org fits in a university strategic plan. And that's all it is. Project managers are not strategy setters. Project managers take strategy and they make sure that the strategy that they take shows up in their projects. You don't have to know how to write a strategic plan to be a project manager. You really don't. Um, so again, a few thoughts on human nature.

�I think it's really, really natural and understandable and valid to hear words like business case and freeze up and think like, oh shoot, I don't do that. You know what you probably do and if you don't it's okay. We'll get you there. So more on that in the resources section in the worksheets. Um, but just, you know, no, going into the rest of these modules, there's gonna be a lot of times where you're like, God, do I do that? I feel like I do that, but that language is so lofty. That language is so like boardroom so corporate that maybe I don't do that. Don't get thrown off by that. I promise that if you think you're doing something, there's a spark there that we can fan into a flame.

41 of 84

You don’t have to see the whole staircase. You just have to see the first step.

Rev. Dr. Martin Luther King, Jr.

So to close out this module, which again, is really starting to go into the nuts and bolts of how project management works, I wanna leave you with this thought from the Reverend Dr. Martin Luther King, who says that you don't have to see the whole staircase, you just have to take the first step. And actually, with this quote, Martin Luther King here is actually talking about faith. So the first sentence that I didn't include on this slide is, Martin Luther King Jr's advice to take the first step in faith. You don't have to see the first, the whole staircase. All you have to do is take the first step. The reason I'm including this is that I think it's really possible, you know, there is over an hour of just audio content in this module, and that is in addition to all of the modules and all of the resources and all of the worksheets and everything else that we provide through this program.

�And so if you're finishing this module and you're thinking like, okay, wow, this is a lot of information, and maybe it all made sense that the time as I was listening to it, but I have no idea how I'm gonna keep all this in my head. I have no idea how I'm gonna learn and memorize all this concepts. Uh, that is okay. Every single person who starts learning about project management starts from a place of, this is a lot of information and I don't know how I'm going to keep all of it in my head. And frankly, the answer is that you're not gonna keep all of it top of mind all the time. I have been working as a project manager for years. I've worked across industry. I've worked with lots of different clients. I've worked with different sized project teams, and I still keep the PMBOK on my desk, right?

�Like not next to my desk or in a bookcase in my office. I keep the PMBOK on my desk because it is impossible to keep all of this stuff top of mind all the time. You can come up with little cheats when they're very relevant, very often to your role. You can say, you know, okay, yeah, I know that I need to keep in mind, uh, strategy, stakeholders and the project environment. Okay, great. But you know, we could have an entire hours long course on each of those three topics. And so all I'm trying to drive home here is that if you right now are thinking, you know, this is great, but it's also a lot of information, maybe this isn't for me. Um, MLK would say, take the first step in faith. Keep going, keep learning these concepts. Um, I've worked really hard to build worksheets that will actually truly help you practice applying these concepts to your student affairs background.

�And to then think through what that means for how you're gonna present yourself and the types of roles you're gonna be looking for as you pivot outta student affairs. And I'm really proud of the fact too, that this is a program that is designed to be responsive. It's designed to have lots and lots of touch points between you and I as you move through your pivot. And if you find that there's a piece of your pivot that you're still really unclear about, um, you can use our community. You can use our LinkedIn community, you can use our coaching sessions. Um, use these resources to ask the questions that you have and to workshop the things that still feel unclear. But take the first step in faith, give it your all. Keep going. Go through the rest of the modules, go through the worksheets, print them out if you need to.

But whatever that looks like, you do not have to see the whole staircase. Just take the first step and trust that as you do this stuff, as you learn this stuff, as you work through this stuff, as you start to, I know it sounds and feels scary, but as you start to practice using these words in real life to describe your work to people, you know, um, as you work through this stuff, I promise that it will become clearer and clearer and clearer. And a year from now, we have no idea where you're gonna be, but you are gonna be amazed at all the things that you do and all the ways that you learned how to talk about things that you're already doing, and all of the ways that you make tiny tweaks to the ways that you're working, that then have all these massive returns on investment and help you become even more efficient and effective at the job that you're working now, and help you present yourself in a way that puts your best project management foot forward. So take that first step in faith.

42 of 84

Thank you!

Next up: Module 3, where we’ll discuss Project Planning

createboundlessimpact.com | @carolinemanages + @boundless_impact

43 of 84

The Aspiring Project Manager

Module 3: Project Planning

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

44 of 84

What we’re covering

Project scheduling & the Critical Path Method
Project methodologies
Internal project environments
External project environments
Organizational culture
Fit check
Closing Out
Resources & Next Steps

45 of 84

Project Life Cycle: Planning

Aligning on the “HOW” of the work:

Timelines
Budgets
Team Members
Communication Planning

Any given internal environment will almost certainly have processes in place for this, but when in doubt, fall back on the following formula:

Who will do what, by when?

So the planning phase, as you can probably anticipate, picks up pretty much as soon as the initiation phase wraps up. Um, so I'm gonna introduce you to another concept here, which is the idea of a phase gate. So a phase gate happens when we're wrapping up one process and we can sort of officially say, okay, once we do X, y, or Z, this piece is wrapped up. So the phase gate for the initiation phase is typically something like a project charter. Um, you don't have to know that for this module. What you need to know is that the moment you receive the official green light, right? Um, so whether that looks like approval from your vice president, which is what it might look like in the higher ed setting, and a note that, hey, you now officially have access to a budget that will allow you to complete this project.

That's the end of the initiation stage. And then you move into planning, which is formally aligning on the how of the work. So this is when we really dig deeply into things like timelines and budgets. We think through team members who is going to be assigned to lifting this work. We start thinking through maybe not, um, communicating in that moment because the project hasn't started, but we plan how we're going to communicate. Are we going to issue weekly status reports? Are there members of the project who are going to maybe talk every day about this or maybe multiple times per day, right? So, um, in some organizations, a daily standup is a thing. So you might not have a weekly status meeting, um, where you take an hour to bring everybody around the board. Um, but you do have a 10 minute daily standup where you check in every single day about that project.

Uh, but it's very directed and very focused on moving work forward, right? Um, in some organizations, you would never dream of taking on a project without those daily standups in other organizations, you would get laughed out of the room for suggesting something like that, right? So while it might be our instinct to laugh at the idea of communication planning, right? Planning how we're going to communicate outward, um, it's actually a sign of a really seasoned project manager to think that through and to tailor that to their environment. So any given internal environment will almost certainly have processes in place for how those things look, right? So one of the very most, uh, frequently asked questions I receive from people pivoting into project management is like, how am I gonna know how to do all this, right? How am I gonna know how to wrangle everything into a timeline? How am I gonna know how they want me to present a budget? And the answer is that most environments are going to have processes in place. Most project managers are not stepping into, you know, this sort of free for all environment where no one has ever managed anything before you.

And now your job is to wrangle everything in the first three months that you're there and make sure that there are these like locked down processes and systems for all of this stuff. Most places are going to have, um, what we call organizational process assets to help you through how to structure this stuff. Sometimes that's not the case. Sometimes you are being brought in because no one has ever turned a careful eye to this planning work before. If that's the case, when you're in doubt, you can always fall back on this formula that I've put really big at the bottom of the slide, who will do what by when? If your project plan answers that question for each piece of the deliverables that you're ultimately responsible for, your plan is going to be a solid place to start. Who is going to do what work and when are they accountable for having it finished?

Right? Certainly there's a lot of nuance here, right? So for example, checking in on the work packages is a piece of the work, right? So, um, who will do what by when? And then who will make sure that, uh, that that was finished? Typically that's the project manager. Um, so there's some nuance to how we apply that formula. Um, we'll talk more about that. And I'm sorry, I'm starting like a broken record here. We'll talk more about that as the program goes on. Um, but who will do what by one is a really good fallback if you truly don't know where to start and if you truly don't have any, um, organizational process assets being given to you. But I do want to introduce and normalize very early on this idea that again, most project managers are not being hired to start from scratch. Most project managers are coming in the door to take really well developed process and keep the ball rolling, right?

So if you are somebody that thinks I would be a really good project manager, but I don't know how to get all this stuff started, right? Um, frankly, that's because that's not usually the job of a project manager, right? That's usually the job of a project manager's boss, is to manage how those things are rolled out in the organization. So I wanna dispel the myth that just because you don't know how to create an entire division's worth of a decade of planning from scratch, you're not caught out to be a pro a project manager, right? Um, I do one last note that I wanna make about the planning piece is that people skip this step too, right? This piece is more about budget and timeline and the nitty gritty details of how this work gets done. Um, I think it's more common to skip the initiation phase, but people all the time, and, and I'm sure that you've seen this in higher ed, um, fall into the trap of, you know, building the plane, whether where they'll building the plane while they're still trying to fly it, right? Sometimes that's because we can't avoid doing that, but

Other, other times it's because there's nobody on the team whose skill set or disposition predisposes them to do this really thoughtfully. And so, if this is you, if you are somebody who has a lot of experience planning thoughtfully, um, this is your opportunity to share that with hiring managers. So, uh, you know, this is probably the phase of the project life cycle that you are the most familiar with. I am gonna give an example from higher ed just because that's what we do here in this program, is we connect these concepts directly to higher ed. Um, so let's take the example of a student organization fair, right? Most campuses, uh, at the beginning of the year, um, or maybe even at the beginning of the January semester or your trimester quarter system will have like a large campus-wide student organization fair, and there are a million little details to align on, right?

In addition to of course, how that, uh, event is set up and presented to the public, there's also a whole timeline and a communication system for reaching out to student organization members in advance. Um, who, because they are college students, juggling many roles, may or may not respond to your request in a timely fashion. Um, and so all of the work that goes into making sure that we reach out to the right people on the right timeline to get the right setup on the day of for an event like that, all of that work is gonna fit into the planning stage of the project lifestyle. I keep saying project lifestyle. I'm sorry, I've never made that mistake before recording this. Um, I guess that's just a testament to the fact that we are all, you know, human people. Um, so what I need to say there is that all of the work that goes into, um, that goes into making sure that those, uh, that those tables are set, that the student organizations know where to be and when to be there, know what will happen if they're not there at the right time. All of that work is gonna fit into the planning stage of the project life cycle. Um, so again, um, we're spending a little bit less time on this phase than on the rest of the phases, just because this is probably a phase that you are extremely familiar with as a, um, current higher ed practitioner. Um, but as always, if you have any questions about how this phase rolls out or how to apply it in your own work, how to talk about it in interviews, um, let us know in the community.

46 of 84

Project Methodologies

Waterfall/Traditional

Has roots in manufacturing going back to the 1950s
Plans the entire project out at once because change is expensive

Agile/Iterative

Has roots in tech going back to the 1990s
Plans in waves and embraces change
Includes Scrum and Kanban

Okay, so let's talk a little bit about project methodology. So a project methodology in the big picture has to do with how we structure the planning of an individual project. You can really think of project methodologies as being one of two types. The first type is what you'll hear called waterfall, and that's called waterfall because the entire project sort of falls over the cliff <laugh> of, uh, of the project implementation all in one go. This is also really traditional project management. So, uh, if somebody, I would say that if somebody doesn't specify which project methodology they're talking about, they're talking about waterfall or traditional project methodology. Traditional project, uh, methodology or waterfall is in contrast to agile or iterative project methodologies.

�Before I go into describing either waterfall or agile, I wanna make it really clear that one project methodology is not better than the other. I think that there's a real tendency to sort of say like, agile is the newer project management. Agile is for young people. Waterfall or traditional project management is for like old folks, dinosaurs, people who are stuck in their ways. That is not the case. I'm gonna talk you through each methodology and I'm going to explain why we would use one over the other. So, waterfall or traditional project methodology is what you see over here on the left. Waterfall has its roots in manufacturing going back to the 1950s. So the 1950s is really when we start to see project management as a field come into the literature. And again, it does it through this waterfall methodology. Wa the hallmark of waterfall project methodology.

�The way you know that you're looking at a waterfall project is that it plans the entire project out at once. And that is because change is expensive. So I'm gonna give you the example again, think about how we're saying this waterfall methodology came about. We're we're thinking about manufacturing, we're thinking about the 1950s. You can think about a model year of a car. So think about a 1950 Chrysler, right? I'm clearly not a car person. I feel like that should have a model or a make. Um, I it am not a car person. <laugh>, my automotive project management, uh, father is somewhere like his ears are burning and he is really ashamed of me right now and doesn't know why <laugh>. Um, so think about our 1950s Chrysler model year, right? You are going to plan an entire car out at once because imagine how expensive it would be to make a change nine months into a model year, to a car that you're releasing in the upcoming year. You would have to have such an urgent need for an overhaul. It would have to threaten the entire car, right? Imagine the level of risk that something would need to rise to for you to say like, yep, let's just redo the whole thing. Rather than saying, you know what, we're gonna come back to that next year. It's incredibly expensive and time consuming and maybe even damaging to the way that the consumers see and trust your brand to make a change like that nine months into a model year, right? So that's why we see that resistance to change in traditional or waterfall methodologies. Um, it's because it's wise, it's because it's good stewardship to sort of say like, no, we really need this to rise to a very high level of urgency and necessity before we're gonna make a change.

�Now, this stands in contrast to more agile or iterative approaches, um, which really have the roots in tech going back to the 1990s. So think about how different project management looks. If you are a software company in the 1990s and you're trying to use this methodology that was developed in the 1950s for, you know, these really large scale manufacturing projects, right? You're gonna become, it's gonna become very clear very quickly that you are operating in a whole different ballgame. You're operating in smaller teams, you're building software packages where you can make changes in the same day, right? Because you're building one thing rather than manufacturing hundreds of thousands of individual things based on planning, right? You're probably a much smaller team. You might be a team of 50 people. You're all in the 1990s. Remote work wasn't a thing the way that it is now, right?

�So you're all probably in a room together building one software package. It's very easy to make change. And so what we started to see in the 1990s is we started to see a departure from this traditional waterfall methodology into something we call agile, which in contrast to planning out the entire project at once is gonna plan in waves and it's gonna embrace change. So that's really the core difference between our waterfall methodologies and our agile methodologies in waterfall methodologies change is very expensive. We wanna avoid it at all costs. And so we're planning the entire project out at once. In agile methodologies, change is very easy. Um, and it's not competitive to avoid making change, right? Scope changes are, I don't wanna say they're encouraged, um, but they're accepted. Part of what a tech project manager is gonna do in an agile methodology is they're going to make a lot of allowances for change

And they're gonna track those changes very carefully because if you are managing a tech project and the change comes up to scope and you sort of say like, no, we wanna avoid change, we don't wanna add things, um, that's a very good way to make your software a package very non-competitive very quickly. Um, so like I said, I I, I don't think it's gonna be worth your while as a project manager to really like pick one, right? And there's a lot of discourse in the project management world about, you know, people really wanna position these methodologies as kind of op opposite each other. People who are really waterfall people wanna position agile people as people who don't know how to plan a project. And people who really have their roots in agile wanna position waterfall methodology folks as like stodgy or stuck in their ways.

�Um, and I really want to discourage you as somebody really beginning to learn about project management. I wanna discourage you from thinking about methodologies that way. It really is not possible to pick the best methodology for your project until you understand your project really well and you understand what the constraints are. You understand what causes the most risk, whether that's, you know, having to make a change that's very expensive, or whether that's getting left behind in the dust by a competitor that's gonna change the way that you think you need to manage that project, right? So I also wanna take the stress off you upfront. You do not need to pick a methodology and you know, understand everything there is to know about it before you land a job. So for example, there are people who will get really, really stressed about, stressed about like, okay, I really need to get this agile certification before I start applying for jobs.

�And I would say that's not true. So one of the things I have up on this slide here is that Agile has its roots in tech. That is true. And there are also many, many tech companies that don't embrace a true agile framework, right? And so you're gonna be putting the cart before the horse and maybe even doing yourself a disservice by learning a ton about Agile if you then go to work for a tech company that doesn't really embrace Agile. So what I would say, um, I think you should know the difference between waterfall and agile approaches. I think you should understand that there is no right or wrong approach and that part of your job as a project manager during the planning phase is gonna be to understand which methodology you wanna choose. Um, but I don't think you need to go deeper than that until you know exactly what you wanna do and where you wanna work.

47 of 84

Choosing a project methodology

There is no "right" or "wrong" project methodology. Every project, team, and organization is different, so a project manager's first job is to get a handle on these differences and then choose (or recommend) the project methodology that makes the most sense based on their understanding of the project.

48 of 84

Concept: Critical Path

Critical path = the time needed to complete a project, from start to finish, when following the longest stretch of dependent activities

Set schedule

(1 month)

Select staff

(2 months)

Book spaces

(1 month)

Train staff

(3 months)

Order food

(1 month)

Prep days

(1 week)

Speaker 1 (00:00):

So once you have identified the project methodology that makes the most sense based on your project's objectives based on your organizational environment, one of the first things that you are gonna need to do as you plan your project is understand what's called the critical path. So the critical path is the time needed to complete a project from start to finish when we're following the longest stretch of dependent activities. So I used this language earlier in the course, this idea of doing something in sequence versus doing something in parallel, right? So if we look at this slide here, we can think about we can do some of these things in sequence and we can do some of these things in parallel. If we think about setting our schedule, we have to do that first. We can't book our spaces, for example, or order our food for a new student orientation program before we've set the schedule.

(01:07)�Otherwise. How would you know what to book or how would you know what food to order? Right? So we can think about things that we have to do, what we call in sequence. We have to do them one after the other. And we can't, if, if we had eight different people, we still couldn't like divide and conquer because we would have to do them in the same order. In contrast, if you look at this image, right, once you've set the schedule, if you had eight different people and you wanted to divide and conquer, you could set one person over here to book these spaces and to then order the food and you could set another person to select the staff and train the staff. Booking spaces and ordering food don't have anything to do with selecting and training staff once we've already set the schedule.

(02:02)�So that's the difference between something happening in sequence and something happening in parallel. So the concept of the critical path again, is this idea that like, okay, when we talk, when we talk about the longest stretch of dependent activities, we're thinking about what are those things that have to happen in sequence? What are those things that I cannot make this project shorter than this path. No matter how many people I had, I would still have to do A and then B, and then C, and then D, that A, then B, then C, then D. Path is our longest stretch of dependent activities, and that is our critical path, which then also gives us the time that we need to complete a project from start to finish. So if this is not clear, um, I want you to move to the next lesson and we can kind of, I can, I can show you a little bit more about how this plays out in practice.

49 of 84

Concept: Critical Path

Let’s say the below map is how long it takes you to plan a New Student Orientation Program.

Critical path (staff training) = 6 months & 1 week

Set schedule

(1 month)

Select staff

(2 months)

Book spaces

(1 month)

Train staff

(3 months)

Order food

(1 month)

Prep days

(1 week)

Speaker 1 (00:01):

All right, so again, let's say that this below map is how long it takes us to plan a new student orientation program. If we set the schedule that takes us one month and then no matter what, it takes us two months to select our staff and three months to train our staff. But we have to do that selecting staff and training staff in sequence. We can't sort of say like, okay, well you work on selecting staff for two months and then so Caroline, you work on selecting staff and training staff. I'll give you two months to do that. And then, you know, your friend Jane, she is gonna be working on training staff for three months. You can't do that, right? You have to spend those two months selecting the staff, and only then can you move on to training the staff, which takes another three months.

(00:54)�And you can't do those things until you've set the schedule and you know that that's gonna take you one month. What this means is that our critical path, which is the path for staff training, so that's what I have here in red, takes six months and one week, the way that I got there is it takes us one month to set the schedule, two months to select our staff, three months to train our staff, and one week for our prep days, we can't shrink it any further than that. Even again, if we had 1 million different people to divide and conquer, um, if you see those, uh, those squares below for books, bases and order food, if we had a million people, we could delegate those things and then we wouldn't have to worry about them after we were done with selecting staff and training staff. But what we couldn't do is say like, okay, I've got four people, so I'm gonna assign one of them to set the schedule. One of them selects the staff, one of them to train the staff, and one of them to do prep days. So in theory, I should be able to get this down to three months. We couldn't do that. That's because our critical path is six months and one week, no matter what, it's gonna take us at least six months and one week to plan our new student orientation program.

50 of 84

Concept: Critical Path

Let’s say the below map is how long it takes you to plan a New Student Orientation Program.

Parallel path (space & food) = 3 months & 1 week

Set schedule

(1 month)

Select staff

(2 months)

Book spaces

(1 month)

Train staff

(3 months)

Order food

(1 month)

Prep days

(1 week)

Now, what we can say in the spirit of dividing and conquering is, okay, let's say I've got Caroline on selecting staff and training staff and doing those prep days. So that six months and one week critical path we talked about in the previous slide, what we can say is, okay, so there's a parallel path that space and food path that I can delegate to somebody else. So that could happen in parallel to selecting staff and training staff. In our example, I've said that this takes three months and one week because I've given one month, set the schedule one month, the booker spaces one month to order food, and one week for our prep days, right? So again, if we think about series versus parallel, we could say, okay, once we're done with those six months and one week, uh, parallel, or I'm sorry, that six month and one week critical path from the previous slide, we could say we're gonna do the parallel path after that. That would be, you know, the case.

If you only were working with a team of you and that critical path was taking everything you had, you didn't have any extra resources to work on booking spaces or ordering food, you could do that in sequence after you finished the critical path or if you had the resources or if you had a team to delegate that to, you could have that parallel path taking place in parallel. So this is a very simplistic example, but this is a sort of thing we need to be thinking through as project managers, right? We need to really understand what our critical path is for a given project. So what are those things that we can't shrink no matter what it has to take that long? And then what are the things that can happen in parallel to that critical path that you can maybe be delegating to a different team member or you can maybe be doubling up, um, you know, maybe it's not gonna take a team member's full-time focus. It's not gonna take them all 40 billable hours per week. And so you can put them on another parallel path as well. That's a sort of thing that we need to be thinking about. You'll hear this called Project Architecting, right? What Project Architecting means is you're getting a really clear sense for what those critical paths within a project look like. What those parallel paths alongside look like, and then what you need from a human resources perspective in order to be able to staff all of those paths.

51 of 84

The Project Manager during Planning

What are the deliverables of the project planning stage?

Project plan
Communications plan
Risk mitigation plan
Finalized schedule & budget

Milestone: kick-off meeting!

Okay… so what, exactly, does a project manager do and produce as a result of the project planning stage?

During the project planning stage, the project manager shifts from working closely with their leadership and with the project sponsor (who, remember, greenlight the project, oversee the business case and advocate for the project if needed… all that big picture stuff) and into working closely with their project team, and maybe with their own colleagues if they’re leading a project that they themselves as project managers might feel a little bit of uncertainty about.

One of the first things they’re thinking through is the project methodology – so, like we talked about, what’s going to be the best way to literally, physically, actually get this stuff done? Are you going to assign this work out to your team in one big go, which would be more of a waterfall approach? Are you going to complete waves of work that happen in sprints and then iterate based on lessons learned within those tiny work packages, which would be more of an agile, iterative, or wave-planning approach?

Remember, these things aren’t “right” or “good” vs “wrong” or “bad” methodologies. You’re taking into account things like how predictable is your project? How expensive is change up-front vs later? And then, you’re also working with your team. So project managers are working closely, like we said, with the project sponsor and with their leadership for the initiation phase, but by the time you get into planning, you’re really doing this alongside your team. And it may be that your team has strong feelings about the project methodology.

During this phase you’re working with your team, consulting notes from other similar projects your company might have run in the past, maybe consulting your own network (which now includes this group!), who might give you such helpful hints as “Engineering thinks they can do this in 6 weeks but they will definitely need 10.”

By the end of this stage, all of these meetings with the project team and research on your end will result in something called a project plan, which basically says, okay, how are we actually going to achieve the project charter? We’re ironing out scope, we’re ironing out the schedule of the work and the human resources the project will require, all that good stuff.

Our communications plan is really about level-setting: who can expect communication when? How? From who? You can think here about your time in higher ed and about whether you’ve ever seen someone who “should have known” they were supposed to copy their VP on an email, but who didn’t know that and then got taken to task for it. A communications plan prevents that. Similarly, it (ideally) cuts out an instance of a high-level stakeholder saying “why didn’t I know about that?!” (though one watch-out here is that part of your role as a project manager is writing a plan that people will follow… which means not writing a plan that says “we’ll keep this person in the loop via email!” if they are notoriously not an email checker).

We’re also ironing out risk planning: if something hits the fan, what happens?

Just as a side note, the resources that I’m including for you in this module include a project plan that folds in a communications plan and a risk mitigation plan. For some really large projects (think a multi-year, multi-million dollar construction project), these might actually be separate documents. That said, there’s absolutely no world in which you’re getting hired to oversee a multi-million dollar construction project and your boss says “we have no internal template for this! Make it up!” with respect to a risk mitigation plan. So, as always, I’m providing these resources so that you have them in your back pocket, and you’re able to put them to use in what we call small-to-medium organizations, or projects being worked for the first time that might not have these templates available. And also just to make you feel more confident about how this works! But do know that in a larger org managing a huge and expensive project, those would be separate documents, not folded into the larger project plan.

And then, you’re officially done with the project stage when the project team agrees that the project plan is feasible, the sponsor signs off on the work beginning (aka on moving into execution), and you host what’s called a Kick-Off Meeting to align everyone on the same page and make sure everyone is crystal-clear on how they’re going to move forward. At which point… you do move forward into the execution stage!

52 of 84

Fit Check!

What did we learn in this module about great project managers?

Ask for 360 degree feedback
Good at zooming into minute detail (in contrast with the initiation phase)
Encourage and cultivate a shared vision

What did we learn in this module about happy project managers?

Humble at accepting feedback

Speaker 1 (00:00):

So quick fit check here as we wrap up our planning phase. So again, what did we learn about great project managers versus happy project managers? Um, great project managers. As we move out of the really broad strategic driven initiation phase and into the sort of narrow planning phase, um, we're thinking about asking for feedback from all of the different people that are gonna be contributing to this project, not just the sponsor who is thinking about why it's gonna exist. We're zooming into really minute detail. So again, in contrast with the initiation phase, which is all about really broad strategy work, um, we're really, really zooming into that. Who is gonna do what by when? How is this gonna roll out? What are the different types of methodologies we're gonna pull in? What resources are we gonna need? How is this going to get done? And then once we answer that question, we're working with our project team to really encourage and cultivate that shared vision.

(01:02)�So again, great project managers are gonna be able to switch gears and really zoom into that planning phase, um, figure out exactly who is gonna do what by when, and then work with the team to encourage and cultivate that vision. Happy project managers along the way are gonna be able to take that feedback without taking it personally when they don't know the answers and without completely losing their minds when three different people give them three very different answers for the question. What's the best way to do this <laugh>? Um, because, you know, again, and we'll save this maybe for thoughts on human nature, um, it is human nature. When you say, what is the best way to do this, people are gonna tend to answer that with the way that they know how to do it, not the best way to do it. Um, so happy project managers are humble at accepting feedback. Uh, they take answers to their questions and they take that feedback with a grain of salt, and then they sort of put it all together into that planning document, which again are closing phase gate for the planning stage is ultimately going to be producing that overall project plan.

53 of 84

A few thoughts on human nature

So today in our thoughts on human nature section, I would love to take a couple minutes to talk about the idea that people love to take shortcuts, and so much of being a project manager is about understanding that very natural human tendency and making sure that people say things out loud. Because when you think about it, it's human nature to want to take shortcuts. So I spoke in both the initiation and the planning section of, of this module about the idea that people skip initiation all the time. People skip planning all the time, and then they wind up with these super messy projects, right? We talked in closing about the idea that, uh, people all the time skip aligning everybody on the project team or every various stakeholder on the fact that the project is in fact finished <laugh>, which seems like such a no brainer when you say it outside the context of, of working in the field, right?

And it's so easy to hear those things and think like, why didn't so and so just do that? How silly do you have to be to think that you can skip coming up with something like an overarching objectives document before you move on to spending a bunch of time and money completing a project? And I really genuinely believe that the best way to be happy as a project manager. Um, so at the very end of this program, we'll set aside a little bit of our theory and we'll talk about kind of managing the self of project management, because so much of project management is about really being effective and clear about our own boundaries and how they relate to other people, right? Um, but I really genuinely believe that the best way to be happy as a project manager is to assume the most charitable interpretation of every stakeholder every time.

Because the fact is that doesn't actually change usually what you're going to do, right? It changes the way that you feel about it, um, and it changes, it changes structurally the way that you approach problem solving, right? Um, and, and so if we can assume that charitable interpretation, if we can assume that when somebody decides to skip an entire, you know, a whole ass stage of project management, um, we assume that nothing nefarious or lazy is happening there, we assume that all that's happening there is that they're not playing forward the tape. Um, and then in fact, it probably, actually the decisions they're making come down to creating value, right? We all create value in our own ways. If I'm a software engineer, the way that I create value is to engineer software and engineering software happens in the executing stage, right? And so if I'm a software engineer and I'm responsible for building a software package, of course I'm going to skip the Initiation phase and the planning phase because those aren't things that I've been trained to do to create value. The way that I've been trained to create value is to move into the execution phase. That's why we have project managers. It's also why we train software engineers before we promote them to project managers, right? And so if we assume that when we see these behaviors that as project managers frustrate us, if we assume that nothing nefarious or lazy is happening there, if we assume, again, the most charitable assumption would be like, wow, that person is really, really trying to create value. That person is really trying to live in a place where they're doing their best work at the organization. And that also means I have to have a level, level setting conversation with them about the, the bigger picture of how I see value happening overall at the organization in a way that is integrated in a way that pulls everybody in.

Um, that a gives you a little bit of an understanding to not make your blood pressure shoot up 8,000 times a day, because I can absolutely promise you that as a project manager, if you don't take that orientation to the people that you work with, your blood pressure will spike. And you know, I'm not trying to be dramatic here When I say that I know so many seasoned project managers who've been working in this field for years or decades who are just grizzled and, and who are, um, cynical and, and who really don't enjoy their job, then it's because when they see people making these mistakes by taking shortcuts, they don't assume, um, like a positive interpretation, right? And so if you can do that, then a, like I said, you are going to have lower blood pressure, but b you know, if you can, if, if you can think about that integrated value chain that gives you the way into having that conversation with the software engineer, right?

Because again, human nature, the software engineer's instinct is gonna be to say like, well, we don't need to do that. And if you sort of push back and get defensive and, you know, think like this person is just downplaying project management's contributions to the project environment and you know, this is why we need project managers and you know, this is also ironic and horrible, blah, blah, blah, that's not gonna be a productive conversation. But if you can go in with an educational mindset, which again, you have as a higher ed student affair, I really do believe that hessa folks are really, really uniquely positioned to be really great project managers. You know, how to have these developmental conversations with folks, right? And so, because you know that, because you've had all of this experience sort of taking these large concepts of social change and explaining them at scale to communities, I wanna give you a flag that part of being a project manager is making sure that people say things out loud, making sure that people are on the same page about things that seem so foundational to the folks that are, um, on the project team. And part of being a project manager is also understanding that human nature to want to take shortcuts. So all to say, our job as a project manager is just to understand that nature and to maybe gently disrupt the times that it, that it makes productivity challenging, right? We don't need to feel any kind of way about those tendencies. Those tendencies just are, it just is our nature, is our nature as project managers. All we have to do is accept, anticipate, and then plan. We're gently disrupting where we can, we're bringing those stakeholders back into alignment in ways that hopefully lead to long, productive, happy conversations and relationships later on. Um, but we don't have to carry the baggage of people not being able to see the big picture of project management.

We don't need to feel any kind of way about this, uh, tendency to take shortcuts and move into execution. It just is. All we have to do is accept it, continue to create value, um, and move on. The exception to all of this, of course is, you know, when leadership or your boss sort of like doesn't understand this stuff. Um, and we can workshop that, but honestly, I think you'll find that if you apply some of these things that we talked about a moment ago, if you apply, um, developmental conversations, if you have a very strong understanding of that value creation framework, and then you go in really, really aiming to understand and to help the other person understand, um, even bosses who are resistant to project management, you know, can come around to that. Um, so certainly our community is part of the reason we created this.

Everything I'm saying is easier said than done. I'm saying this like, I'm not somebody that's ever received an email and been like, what are you talking about? Um, but I have worked really, really hard over the last, I'd say year and a half is, is really when I started. I, I would say probably like spring of 21 is when I really, really started to think like, okay, if I don't change the way I approach this work, it's gonna like grind me up and spit me out. So all I wanna say, human nature, people love to take shortcuts. Your nature as a project manager, um, it is going to serve you well to get to the place where you are assuming the most charitable interpretation of every stakeholder, every time.

54 of 84

The single biggest danger with communication is the misperception that it has taken place.

George Bernard Shaw

Finally to close out our planning module, I wanna leave you today with my own spin on a George Bernard Shaw quote, the idea that the single biggest danger with communication is the misperception that it has taken place. So this is gonna come up for you over and over and over again as a project manager, where you are going to communicate something that in your mind was not only communicated a number of times across a number of media, um, maybe you sent an email, maybe you also dropped something in person. You know, maybe you slacked it lots of different ways. So not only was it communicated a number of times across a number of media, but it was communicated very clearly. So, in your mind, there is absolutely no way that this other person doesn't know what it is that you expect them to know. That I genuinely believe is the single biggest danger to project managers experiencing things running smoothly, right?

(01:00)�Um, because again, we just can't assume that we have to. There are so many different pieces and forces pulling at people's time. There are different ways that people understand things. So it may be that they didn't even understand you in the first place, even though you communicated it very clearly because they weren't listening clearly in the first place. Maybe they had a really big deadline pop up the meeting before they met with you, for you to explain that deliverable to them, and they just never really got it from you in the first place. Maybe they got it really clearly, and that deadline that I'm talking about popped up immediately after they met with you to have it rolled out. In any event, they don't know what it is that you're expecting them to know. And to circle back to what we just talked about with our thoughts on human nature, about the most charitable assumption, what you are gonna have to do in that moment as a project manager is just to sort of say, you know what?

(01:56)�I don't have to feel any kind of way about this, but I am gonna make sure that everybody's on the same page. So I very often joke that my job is to be the most annoying person in your inbox throughout the life of the project. But then once the project ends, I'm gonna be everybody's hero. And that has proved over and over and over again. You run your projects really efficiently. People get sick of you throughout them. Um, but then by the end of it, you come in on time and on budget and ultimately that's your job. I mean, I say this a little bit facetiously, that your job isn't to not be annoying, but it's true. You don't get paid to not be annoying to these people. You get paid to help them, uh, deliver their deliverables on time and on budget. And the single biggest danger to that initiative, that objective is the idea that people know what you're talking about, when actually they don't. So that's my ending, uh, closing quote for this planning session is, you know, truly, truly your job is to whatever you think it takes to make sure that people understand exactly what you're saying, dial it up that one step further, and then you're probably good.

55 of 84

Thank you!

Next up: Module 4, where we’ll discuss Project Executing

createboundlessimpact.com | @carolinemanages + @boundless_impact

56 of 84

The Aspiring Project Manager

Module 4: Project Executing

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

57 of 84

What we’re covering

Project Execution
Tools & techniques for effective execution
Fit check
Closing Out
Resources & Next Steps

58 of 84

Project Life Cycle: Executing

Managing the work while it’s happening

Status updates (per your stakeholder analysis)
Timelines
Budgets
Team members

This is where we really start to see the "life cycle" piece coming to life, because everything that happens in the "execution" stage happens according to the... well, plans... you made in the planning stage!

So now here in executing, we're really moving out of aligning, which is where we were living when we were talking about initiating and planning, right? We were talking about kind of aligning all of the team and all of the stakeholders to understand what we're doing and why we're doing it and how we're gonna do it. So now we're moving out of that alignment phase, and we're moving into overseeing the actual project team doing the work. So when I say project team, you know, that's a smaller, less broad term than stakeholders. Stakeholders are really anybody involved in the project. The project team are the folks who are really directly responsible for doing the work. Um, so if we look at this bullet points, what we see are, uh, pieces around managing the work while it's actually happening. Um, so we're talking about status updates, um, which we're going to do per our stakeholder analysis.

(00:52)

We're talking about timelines and budgets and team members, which we are going to have defined for us per the work that we did within our initiation, right? So executing says, we've got this plan, let's just make it happen. This is where we really, really start to see this life cycle piece coming to life, because everything that we're doing while we're executing happens according to the plans that we made in the planning phase. Um, this is also where you're gonna start to see as you become more seasoned and more confident as a project manager, this is where you're gonna start to see connections between all these different stages. Um, so for example, let's take status updates, right? We said earlier that we are going to understand how we need to update our stakeholders after we perform a stakeholder analysis, right? So we're gonna understand the fact that, um, some folks, so let's say that your, um, vice president or maybe even your president, your campus president is part of your, um, stakeholders, right?

(01:54)

They have a vested interest in seeing how your project turns out. What we're not gonna do is we're not gonna invite our president or our vice president to a 10 minute daily standup. That's just like not gonna happen. Um, not only is it not gonna happen, it's gonna make you look out of touch, which is gonna undermine your credibility as a project manager and frankly, just as a member of your team, right? Um, and so you're not gonna do that, but you might do it for your close colleagues, right? Particularly the folks on the project team who are, um, on a daily basis involved in making that work move forward, right? Um, excuse me. So really what I'm trying to get at here is this idea that stakeholder analysis, which we perform the initial analysis in our initiation phase, and then we plan how we're going to communicate with those folks in the planning phase. Um, you might learn as you're executing that, like, oh shoot, I really actually need to be like talking to these people more, right? You might learn, um, as you two or

Speaker 2 (02:58):

Three times over the course of a project, realized that somebody who is really supposed to have a really deep level of knowledge, um, always seems a little bit behind the eight ball or a little bit under-prepared, that is gonna be your signal to the next time you're planning loop in that stakeholder earlier or maybe more often. Um, and by the same token, you might also, as you are executing a project, realize that like, okay, wow, I'm calling these weekly meetings. We're talking about the same thing every week. There's never any real updates and I just feel like I'm wasting everybody's time. Um, again, really wanna normalize that that is a tail as old as time. It is a right of passage for most project managers, um, to realize that in planning you got it wrong. Um, maybe you didn't budget enough time for a particular phase.

(03:45)

Maybe you didn't properly analyze your stakeholders, and now you're finding that they don't know enough about your project or that they feel like you're wasting their time by all these laborious status updates. Um, and so when I say this is where we start to see the life cycle, um, you know, piece really come to life, part of that is you as a project manager getting more experience, um, and learning from planning phases that maybe, uh, you didn't have all the information you needed. And then the next time, because remember, this is a life cycle, because once we close a project, we initiate another one, right? And at that point, you are going to be a more nuanced and a more effective initiator and planner. So what I really wanna drive home for you in the executing phase, uh, is that this is not just autopilot.

(04:36)

This is you. When you talk about managing the work while it's happening, remember, uh, you know, we can think about we have the tools, we need to think about what management looks like. It's, it's planning, it's organizing, it's directing, it's controlling, right? And so while you're executing, you are doing all those things and you're paying attention to those flags that tell you that something is off track. Sometimes that's a disengaged stakeholder. Um, sometimes it's really obvious. Sometimes it's like a bright red over budget sell, you know, and, and, and the accounting or finance team on the project calls you and is like, Hey, what is happening here? Um, we'll talk in the next module about monitoring and controlling, uh, what you do at that point. Um, but what I really wanna drive home is that executing doesn't happen on autopilot, right? You're paying really, really close attention and you're understanding where that work is deviating from planning. Um, and then I also wanna drive home again that it is a right of passage for, um, particularly new project managers to have executing feel overwhelming while it's happening, and then to learn a lot that influences later on the way that you initiate and plan. But of course, we're always learning, right? Project managers who have been managing projects for decades learn things while they're executing projects that then

Speaker 3 (05:57):

Change the way they initiate and plan later on, right? So again, part of what this program is meant to do is to build your confidence, not just your competence, um, to make you feel more confident in moving forward as a project manager. So again, if you are somebody that is really struggling with, you know, I don't know how to do this in a new setting, I don't know how to move outside the role and department I've been in this whole time and execute this stuff. Um, just know that if the person who is interviewing you and hiring you and bringing you onto their team has been managing project managers for any length of time, they know that part of the growth curve for a project manager looks like executing your first couple projects and learning a lot about what you'll do differently next time.

59 of 84

The Project Manager during Execution

What are the deliverables of the project execution stage?

Status updates & report-outs conducted in accordance with the project plan
Risk monitoring
Creating, recording, and making recommendations around issues

Milestone: Moving to close

Okay… so what, exactly, does a project manager do and produce as a result of the project execution stage?

During the project execution stage, the project manager is working really closely with the project team (usually on a daily basis) to understand how the work outlined in the scope we agreed on in the planning phase is rolling out. Remember that this phase happens concurrently with the monitoring & controlling phase… so really what we’re doing here is we’re making sure that ideally, Plan A, best case scenario, everything’s going swimmingly and we’re just keeping everyone updated accordingly with whatever the communication plan says those updates need to look like. And then, less ideally, Plan B, we’re being as proactive as we possibly can be about identifying issues, and moving into risk mitigation response mode (which happens over in monitoring and controlling).

For the sake of clarity, and keeping our Execution phase activities separate from our Monitoring & Controlling phase activities, let’s say we’re managing the perfect project. Everything goes precisely according to plan. What are we doing in the execution stage, and what do our deliverables look like?

Some of this is going to be dictated by the project methodology we choose (which in turn is going to be affected by the project environment and our organization context). For example, in a project that’s moving very fast, with a small project team, you might choose to hold daily stand-up meetings, which are short meetings designed to give very targeted report-outs on task statuses. With a project with many different stakeholders that’s moving more slowly, you might choose to do weekly report-outs. In either case, as the project manager, you’re responsible for determining how these meetings need to run. For example, maybe there are stakeholders who don’t need to be in the weekly report-outs, but you do need to touch in with them on a weekly basis to make sure everything is going okay on their end. (In my experience this is common when working with procurement folks, or the teams that work with contracting external vendors.)

Some of this is going to be dictated by the project plan, which should tell you who needs to get notified about what type of status report, and when.

Outside of external reporting, though, during execution your main job as a project manager is usually going to be 1) watching the project like a hawk and 2) making sure that said watching gets logged somewhere. My number one mistake as a new project manager was assuming that because I kept the status of the project on lock in my head, if someone had questions, they would just come ask me. In fact (and this will vary everywhere, so this is another piece you’ll want to be clear on as a new project manager before you move into leading a project), there was one project team in particular where it was expected that if there were changes to project status, I was making them pretty much in realtime – that is, if a project had fallen off-task in the morning, and I hadn’t as my very first initial response indicated in my PM software that the project was off-task, I could be held accountable for leadership seeing at 10am that it was on-task and then asking me why I hadn’t updated it. Again, no right or wrong here… just something to make sure you’re clear about and understand that you know what’s expected of you as you’re leading the project.

Another thing I want to drive home here as we think about “what the PM is doing” during execution is the value of a creative problem-solver. You are usually the only person with a birds-eye view of the team, which means when someone from one area feels like the project is stuck, if you have an idea about how you might be able to use a resource from somewhere else in the project to resolve the blocker, that’s very valuable. You’ll also get very used to saying “are we sure that’s the only way we could get that done?” when project teams push back on a timeline.

Finally, this is where your leadership skills get to take center stage with your project team, and also where you get to act as a liaison! You might celebrate milestones with the team internally, make sure that project team members or the team as a whole receive recognition, or even advocate upward for recognition and reward for the team. You’ll also be working hard to keep the team aligned to strategy – whether that’s the organizational mission, the project’s objectives, or pushing back on their scope creep, you’re managing the team as they get the work done.

One note here: note that while you’re managing the people and the processes that get these projects done, you’re not managing them as employees. You’re not their boss (or at least, you aren’t by simple virtue of being a project manager), and while you might get called in to give them feedback as part of the job they did during the project you led, you’re not taking on the role of giving them a performance evaluation overall. This is one of the tricky grey areas of being a project manager: sometimes, you might be providing coaching, or managing laterally or even managing up to people totally outside of a formal reporting relationship. So, again, you’re leaning heavily here on the coaching and development skills you’ve honed during your time in higher ed to make sure that you’re able to separate the coaching and development process from the employee evaluation process.

Now, we know that (unfortunately) projects usually don’t go perfectly… so, of course, we’ll talk about that during our monitoring and controlling module.

60 of 84

Fit Check

What did we learn in this module about great project managers?

Hyper-focused on detail
Action-oriented
Effective communicator

What did we learn in this module about happy project managers?

Doesn’t take it personally when they have to repeat themselves

Speaker 1 (00:01):

Our fit check for the execution module is really living in what most people probably think of when they think of project management. Just from what we absorb culturally, right? Just from those narratives that exist around all of us. When people think of a project manager, what do they think of? They think of somebody with a clipboard. They think of somebody with a spreadsheet for everything they think of. Um, <laugh> the itinerary friend. I am that person in my friend group and in my family. Uh, actually literally this day as I record this, my family is planning a vacation for later this summer. Um, so my parents both sets of my parents, my mother and my stepfather, um, my father, all of my siblings who are flying in from different states, me and my toddler, uh, and I <laugh>, am the one managing all of those details.

(00:53)�Because when we think about, you know, uh, when we think about coming together with a bunch of details and a bunch of people descending on one campground, the person to plan that of course is Caroline. So just so you know, by the way, occupational hazard of becoming a project manager, you all of a sudden have to put some real boundaries in place if you don't want to be the one in your family that plans all the vacations moving forward. Um, so like I said, when we think about a fit check, uh, again, that's that really classical view of a project manager that I think, again, we absorb culturally, spreadsheets, itineraries, everything is buttoned up. Um, and really as with most things, that image exists because there is a kernel of truth to it. There's actually a great deal of truth to it in the execution phase, this is where we start to see the project manager's attention to detail really come through.

(01:45)�So one thing that I think is really interesting here is that we have actually spent a lot of time before this module in the apm. We've spent a lot of time thinking about the project manager's kind of strategic abilities, right? What the, um, laager competencies call strategic acumen. So the project manager's ability to look at the organization overall and see how their projects and their portfolio fits into strategy. So that's really where we're living in initiation. We talked a lot in planning about the project manager's ability to again, see the big picture and start making some choices, right? So taking that proactive initiative and deciding things like what should my project methodology look like? How should I put these big planning pieces together in order to make sure that the project rolls out effectively based on the strategy we've set in initiation? So we've talked a lot about the project manager's ability to again, live in those big pictures.

(02:44)�Um, and that is so important. I would argue that most project managers who kind of decide that the field is not for them after the first couple years do that because they come to the field knowing that this fit check stuff that we're talking about in module is part of project management. They know that project managers have to be organized, they have to be buttoned up. They have to understand all of the details at any given time of any given project. Um, but again, those project managers that may not last more than a couple years in the field get surprised by those strategic pieces that we talked about in the first couple modules. So that's why I harp so hard on those during the apm. But I do think it's also really important to acknowledge that really great project managers, of course, have to be hyper-focused on detail.

(03:33)�So that's what we see here in bullet 0.1. In bullet 0.2, we also see action oriented. Um, so really great project managers. When I say action oriented, what I mean is that your instinct when it seems like something's not right, is not to sort of like chew on it and see if you can figure out internally what's going on here over the next day or so. If you get the sense that something's not right and you can't diagnose why really great project managers are oriented to action. Whether that means bringing in somebody else to say, Hey, can you take a look at this? Or if you know that a flag needs to be raised, raising that flag by maybe moving into the monitoring and controlling phase. Um, so again, recall that those two phases, execution and monitoring and controlling happen side by side in parallel.

(04:20)�And then that third bullet point, effective communicator is really sort of the glue that holds all this together. So if you are hyper-focused on detail, but you're also action oriented, um, but you're not an effective communicator, it doesn't really matter, right? None of these things really matter unless you are somebody who can speak to lots of different people in lots of different ways and deliver lots of different messages really throughout your entire day. Um, so really great project managers. Again, this is that classical PM view that you're probably familiar with. If you came in knowing nothing else about project management, you probably came in knowing these pieces of a fit check for execution, hyper-focused on detail, action-oriented, effective communicator. And then as always, um, when we think about happy project managers, <laugh>, of course we're thinking about people that really thrive under those conditions. So people that are really happy being detail-oriented, action-oriented, people that are really happy being effective communicators.

(05:22)�But what I have here in this Happy Project manager's piece is that they don't take it personally when they have to repeat themselves. What I mean by that is we can think back to that quote that we closed the last module with the idea that the biggest threat to communication, uh, the biggest danger is the illusion that it's already taken place, right? So as a project manager, sometimes you have to say things over and over and over again. Sometimes it's very easy to take that personally, uh, and wanna know like, weren't you listening to me the first time? Was I not being clear? Uh, <laugh>, this is where we see that cultural

Speaker 2 (05:57):

Meme about, you know, per my last email. Uh, and so I can tell you that if you are somebody that gets very annoyed by having to send per my last email, uh, emails, then being a project manager might be very annoying to you. <laugh>, you might be very good at it. Um, but I send a lot of emails that basically boiled on to per my last email. Um, but instead of falling into that per my last email trap, I'm diagnosing and maybe I'm having to change the way I'm doing something and maybe that doesn't feel like fair or right. Maybe that seems like, you know, this person actually really should be able to get what I'm saying the way that I'm saying it, but I'm usually not their boss and it's usually not my job to develop them. My job is to keep the project going.

(06:41)�And so in execution mode, um, I may have to repeat myself and I may have to diagnose and make some behavioral changes. Certainly I'm also coaching along the way, right? So, um, we're always sort of balancing how do we accommodate the people and the processes and the issues that are in front of us. How do we balance accommodating that? With coaching, our role is to kind of do both. Um, and so honestly, a lot of what we might discuss in the community coaching sessions and in the LinkedIn group is finding that balance. Um, if you talk to a very seasoned project manager, they will talk to you about one of the most challenging pieces, and this challenge never goes away, is resolving how we balance accommodating versus coaching. Um, so that is a complexity and a nuance of project management, but in any event, uh, we are gonna have to do both. And so happy project managers, again, don't take it personally when they have to do either when they have to accommodate or they have to coach.

61 of 84

A few thoughts on human nature

For our thoughts on human nature section in executing. I wanna talk a little bit about coaching and I wanna talk a little bit about what coaching subject matter experts as a project manager who is probably not an expert in that same subject. I wanna talk a little bit about what that can look like, because I think it can feel really uncomfortable for new project managers or sometimes seasoned project managers. Um, if not uncomfortable. I think it can feel confusing, right? Like, how, how am I gonna coach somebody on this when I have no idea how to do their job? That's a really fair question. But I also wanna normalize that coaching is really your superpower. If you are listening to this, you are a current or maybe just recent higher education, student affairs professional, um, I promise you that one of your differentiators from some of the people you're gonna be working with is your ability to coach somebody from a really holistic perspective.

(00:57)�Your ability to sit down with somebody, to really take in who they are as a person, what that means for how they're taking in their environment, how they're responding to challenges that are in front of them, um, maybe even how they're perceiving those challenges, um, and then working with them to move forward. Anyway, I cannot tell you how many people have shared with me that one of their favorite things about me being assigned to their projects is my ability to do that. And I'm not even compared to some of the other folks. Uh, like I would not say compared to a real student affairs coaching rockstar. I wouldn't say, you know, that that is my standout strength as a student affairs professional, but it is certainly my standout strength as a project manager. So I wanna talk a little bit about it. I really wanna normalize the idea that a lot of times we are coaching subject matter experts on something that doesn't have anything to do with their expertise.

(01:54)�Think about all the different dimensions of your career. Think about all of the different skills and disciplines that you are bringing together as you apply for project management roles. You have so much experience in your functional area, but you also have experience with administrative pieces. That's probably a lot of what brought you to project management. You might have experience with benchmarking or researching. You also have experience with interpersonal skills, right? What people might call soft skills. You have experience with leadership skills. You also have all these experiences and competencies and skills that may not even have anything to do with your career, right? Maybe you are a musician or an athlete outside of your student affairs role in your project management work. Um, and so you have pieces from that domain to draw on. The point I'm trying to make is there's nobody, there's probably, I suppose I shouldn't speak, you know, from the absolute, there's probably nobody in your life that could coach you on every single thing you're good at.

(03:00)�You are gonna have to have lots of different people in your network, and you probably already know this and have probably already begun to develop this. You are gonna have lots of different people and you're gonna draw on different facets of each of their experience in order to coach yourself into ultimately the best version of yourself as a professional. And that's true of your subject matter experts too. So for example, um, I can tell you that the subject matter expert that I have coached most often in my own career, uh, in the last year or so is a marketing manager. So this person is a director with about two decades of marketing experience. Um, and they are really phenomenal when they get in the zone of like marketing strategy. Like they're truly, sometimes they say things in meetings where I'm just like, how did you pull that out of your brain, right?

(03:48)�Just like you can watch a campaign almost come to life over the course of a meeting and it brings in all sorts of interdisciplinary marketing roles and it's just like, wow, this is happening in real time and this is incredible. And also I give this person so much coaching around how interpersonal skills and strategy are related. When I say strategy, I mean organizational strategy. This person crushes it with marketing strategy. But when it comes to having interpersonal skills and knowing how to be strategic about the organization we're working in, um, and about really being able to think about politics and about how teams play out and about how you might speak to this person differently than that person because that person has a different level of understanding and competence. This marketing director is not good at that and their career shows that, right? There are definitely times that if this person had been better at that, um, their career would've gone differently.

(04:51)�So I do a lot of coaching this person because again, they wind up on my project teams and they do a really great job with respect to their narrow subject matter expertise. But I also have things that I need this person to be able to really do outside of their role as a marketing strategist. Um, and so I need to give them some coaching around exactly what that looks like. I also, for the record, have had this person tell me a number of times that no one has ever invested that time into them before. The way that I have, um, a couple takeaways there, <laugh>. One is that your job is not all of a sudden to like be everybody's boss and sounding board and you know, the savior that comes in to give them something they've never had before. Um, that is more a failure of this person's bosses prior to their current role than it is, you know, like they've just been waiting for the right project manager. Um, so that's takeaway number one. But takeaway number two is sometimes that happens with subject matter experts. Sometimes they're so good at the thing that they're good at that they do kind of, you know, get

Speaker 2 (05:56):

A for the things they're not so great at. And what that means is that you wind up with, you know, the genius software engineer who can't show up to a meeting <laugh>, right? Or the marketing strategist who you really can't put them in front of an external partner without lots of coaching, right? Um, and so that's really the domain that we're coming at when we think about coaching as a project manager. If you are somebody that has seen coaching for project managers and been really freaked out about like, how am I gonna teach a software engineer how to code? The answer is you're not right. Their education is gonna teach them how to code. Their mentors in software engineering are gonna teach them how to code. And also probably by the time they get to you, they know how to code. They're not really working on that part of their career anymore.

(06:42)�What they are working on is some of those pieces that we just talked about. And that's where you're gonna come in as a coach for a project, uh, in a project management role. So when we think about thoughts on human nature, my challenge to you is gonna be to start thinking about how do you already do this in your student affairs role, right? So for example, you are probably a really great coach to students in biochem programs, for example, but you're not a biochemist, right? So the human nature, I think is to really let imposter syndrome take over here and say like, well, how can I coach subject matter experts? And the answer is, how do you coach students who are currently in degree paths that aren't what you got a degree in and know way more about their subjects than you probably ever will, but you still able are able to make really powerful and profound impacts on them, right? So my thoughts on human nature here is do not minimize the ability that you have to make a mark from a coaching perspective on subject matter experts. It's such a powerful piece of project management. It's such a powerful differentiator for you as an aspiring project manager. Um, so I really wanna challenge you to lean into talking about that and lean into coming up with examples of time that's, that you've done that. Um, and be proud of that because it's really transformative work.

62 of 84

The conventional definition of management is getting work done through people, but real management is developing people through work.

Agha Hasan Abedi

63 of 84

Thank you!

Next up: Module 5, where we’ll discuss Project Monitoring & Controlling

createboundlessimpact.com | @carolinemanages + @boundless_impact

64 of 84

The Aspiring Project Manager

Module 5: Project Monitoring & Controlling

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

65 of 84

What we’re covering

Budget Management
Risk Management
Risk Up Front
Fit check
Closing Out
Resources & Next Steps

66 of 84

Project Life Cycle: Monitoring & Controlling

Monitoring = actively understanding the status of your project
Controlling = responding to changes that need to happen for the work to continue to go forward effectively

Risk management
Budget management
Stakeholder management

So monitoring, controlling, like we said, happens really, really tightly connected to executing. So as you are executing, which again, like we talked about in the last lesson, is all about making sure the work happens, making sure it moves forward, you're also monitoring that work. So when we say monitoring, what we mean is that as the project manager, one of your biggest responsibilities is actively understanding the status of your project at all times. So if you are having a meeting with your project sponsor, so the person that you're reporting to, um, job your, I would argue your single biggest responsibility as a project manager is to be able to answer any questions that they have about how the project is unfolding. So if they ask you whether the project is over or under budget in a certain area, your job is to know the answer. If your job, or I'm sorry, if they ask you whether the project is ahead or behind schedule, um, your job is to know the answer.

(01:04)

If they ask you what a certain stakeholder thinks of a presentation that you gave last week or, um, of the changes that they made at the initiation meeting, um, your job is to know the answer, right? So, and that is what we mean by monitoring, actively understanding the status of your project. Um, so across the entire project and across all of the ways that we can understand it. So through the lens of stakeholders or budgets or timelines or project team performance, um, anything like that. Controlling is when we say like, okay, so we're monitoring and, you know, if everything's going smoothly, all the lights are green, great. Um, but if something happens, if a flag goes up, controlling is about responding to any changes that need to happen in order for that project work to keep going forward effectively. Um, so the three that I've thrown up here, because they are the most common things to go off the rails are things like risk management, budget management, and stakeholder management.

(02:07)

Um, so, you know, um, when we think about risk, we can think about any number of things we can think about, somewhat mundane, uh, pieces of risk, right? That are, um, internally contained. So something like, you know, um, your project falls a day or two behind schedule because somebody got sick on the project team. And so your job as the project manager is to say, okay, how am I gonna make up that day or two of shortfall, right? Um, so that's low stakes internal management. Um, that's probably something that you as the project manager can resolve on your own, on the other end of the risk management spectrum, you know, um, and this is like the stuff that PM nightmares are made of. So, you know, I don't mean to, um, to unsettle you, but do know that if something like this were to happen, you would not be resolving it on your own. Um, you know, you are working on a

Speaker 2 (02:58):

Software, software package and you've been working on it for two years. You've got another year in the budget and you've already earmarked all the money. Um, and then something happens technologically, uh, let's say that software is no longer compatible with, you know, I'm clearly not a tech person, um, with like any computers, <laugh>, or phones anymore, um, or let's say a competitor that was not on your radar, um, during the initiation, uh, phase, they did not come up as a stakeholder or as a potential threat. Um, they, they weren't on your radar at all, and all of a sudden they drop us software a package, um, like six months before you were gonna drop yours that is just like yours, except maybe it's a little bit better. It has a feature that you didn't plan or, um, it's cheaper, but it's just as good as yours, right?

(03:47)

Um, so that's an example of a tremendous risk. Um, again, if that were to happen, uh, you would not be the only one managing that, right? You would escalate that up to your boss who probably would escalate it to the ceo who might even escalate it at that point to the board. Um, but again, your job as the pm uh, would be to obviously as soon as you find out about that risk, you would flag it. Um, and then together with your project team, you would move into controlling, you would move into responding to changes that need to happen for the work to continue to go forward effectively, right? Um, so one thing I wanna flag here before we go on any further, um, is that just like everything else we've talked about, right? With respect to controlling, with respect to risk management and budget management, um, your job is not to know how to be a marketplace analyst, right?

(04:44)

And to know all of the different, um, software firms on the horizon. Your job is not to be a CFO and to understand exactly, um, how a budget is built from, you know, ground zero. That's not your job as a project manager. Your job as a project manager is to work with the folks in your organization who can advise you on things like risk management and budget management. Your job is to work with those folks until you have a very clear understanding of how your project's resources fit into the organization's resources. And then your job is to effectively monitor and then control. Um, and so those are the pieces that I'm kind of wrapping up into the idea of stewardship, right? Your job is to effectively steward your project's resources. We do that, um, through careful planning and then through monitoring and controlling. So hopefully that's clear.

(05:41)

Um, let's talk about an example rooted in higher education. Um, so let's say that you are a service learning coordinator, right? Um, and part of what you do is you plan international service trips, right? You are responsible for sending a number of students maybe on an airplane, um, off to a different country than the one that they live in. Um, and you may or may not be on site because maybe you're running lots of different trips and you obviously can't be in many sites at once. Um, and so while you are the person responsible for those pieces unfolding, you're not there. If you are serving in that role. There is absolutely no world in which your initiation phase of, let's call it an alternative spring break trip, um, there's no world in which the initiat, the initiation phase of your ASB doesn't involve a lot of careful risk management planning, right?

(06:44)

Um, so you are thinking through every potential scenario you can imagine what happens if someone gets sick? What happens if someone needs to go home? What happens if, um, somebody violates the student code of conduct and you need to discipline them in a country that isn't where they are, um, and that isn't where you are, sorry, I said isn't where they are. That doesn't make any sense. Uh, uh, that isn't where the university is and isn't where you are, right? So they're in a totally different country. Um, what happens if, if, if, if, if, if, right? And then your job the entire time, of course, uh, that those students and their chaperones are in that different country, you are monitoring. So you've probably set up check-ins with the folks who are on the ground in that different country with the students. Um, and you are controlling.

(07:35)

As soon as something happens, you are responding to those changes. You're deploying your risk management plan, you've set that plan up in advance. You have a very clear picture of what it means to put that plan into action. That is an example of monitoring and control. That's actually an excellent example of monitoring and control, right? So you don't have any control over whether something happens you don't have control over when it happens. Um, and so I wanna make that really clear when we say control, what we're not talking about is controlling the project because, you know, maybe better than anybody else, as people who are responsible for college students, that, you know, a lot of times we can't actually control the things that we are quote, responsible for. What we can control is the extent to which we plan in advance during the, in the initiation phase, and then put those, uh, plans into place when our monitoring reveals that something needs to happen in order for the work to continue to go forward effectively. Um, so that's a little bit of a nuance, right? Um, but again, a hiring manager is gonna be happy to hear you say that you understand that we can't control everything that happens on a project, but we can control the extent to which we plan in advance. We plan for every contingency. And then when it becomes clear that a contingency needs to be put into effect,

Speaker 3 (08:54):

We act quickly and decisively to put that plan into place. Um, so hopefully that ASB example sort of like illuminated the difference between what it means to try to control a project and what it means to monitor that project and then control how we put, um, risk mitigation, uh, plans into effect.

67 of 84

Project Life Cycle: Monitoring & Controlling

M&C happens in two major ways:

Change control

We’ve decided to make a change and manage it effectively. Could look like:

Changes to scope statement
Changes to project team
Anything else!

Risk management

Something has gone wrong and we need to mitigate it.
Typically looks like enacting a pre-determined risk response (which we listed in the Project Plan).

Speaker 1 (00:00):

I wanna do a little bit of level setting at the very beginning of talking about monitoring and controlling. So again, remember that monitoring and controlling happens in parallel to execution. They're the only two stages that happen in parallel. The easiest and clearest way for you to think about this is going to be that if we take a look at what we planned to do when we were in project planning, things are either gonna go that way or they're not right. And if they do go that way, if everything that we planned happens exactly as we planned, we are in executing. If not, we are in monitoring and controlling. And the two main things that happen in monitoring, controlling are change control and risk management. One way to really clearly conceptualize that is that when things don't go well, when things don't go the way that we had imagined them to when we were planning our project initially, we can respond really in one of two fundamental ways.

(01:01)�We can either say, okay, this change is welcome, we're going to roll with it, right? Maybe it's because we overlooked something in the initiation and the planning phase, in which case, of course we're gonna document these lessons during the monitoring controlling phase. And then as you can imagine, when we get into closing, we're gonna make sure that we document it for the future. So again, it's possible for things to change. We don't like it. It's not how we plan for it to go, because change never comes without cost. Even if a change is, is so welcome and so clear and it's so obvious that like, yes, that is the way we should be doing it, it's still more expensive ultimately to change the way we're doing something. Even if that, you know, the very best case scenario is just, you know, maybe it takes 45 minutes of a subject matter expert's time to say like, oh, you need to change course.

(01:57)�Um, that's still 45 minutes that you wouldn't have had to pay for otherwise. And typically that's not the only expense associated with changing course. So that's route one is the change is welcome. Um, we decide to roll with it. Typically, that's not a decision you're making alone as a project manager, typically that's a decision that you are making in conjunction with your project team and your project sponsor. Um, and so what we're doing there is we're managing the change process. We're documenting the change, we're determining how we're gonna change our project rollout, how the rest of the execution stage is going to roll out as a result of that change. And then of course, again, um, documenting as we go. So that's thing one we can do in response to monitoring and controlling. Thing two is risk management. So again, the two major ways we can sort of respond or we can roll with the change or we can sort of say like, Ugh, no. As a project manager, my job is really to kind of pull this back to reality, right? So we're holding up

Speaker 2 (02:59):

Versus reality. When we're managing change, we're saying, you know what? This diverges, it's okay, we're gonna roll with it. In risk management, we're saying like, this diverges and I really don't want it to, and so I'm going to initiate a control plan, a risk response, a mitigation plan. Those are kind of three different ways of saying the same thing. And all of what we're saying is we're doing our very best to, when expectations and reality diverge pull that reality back to expectation. So I gave an example earlier about, you know, how sometimes people can get sick over the course of project execution? That's a risk. One mitigation plan you might take is let's pull in an extra staff person to be able to come on board for that. We were looking at when somebody got sick, having to extend a project timeline. I really don't want that difference to play out.

(03:54)�I really don't want that to take longer than I imagined it to deliver. And so I'm going to implement that risk response and pull that reality back to what I imagined when I initially built the project plan. I'm going to do that by implementing the risk response of pulling an extra staff member onto the project. So hopefully that sets the stage. Again, we're gonna talk a lot throughout this module about how that looks, but I really wanna make it clear that really the two major concepts we're talking about when we talk about monitoring and controlling are we're talking about change control, which again, is where we decide to roll with a change. Um, and the project manager's job there is really controlling that change, documenting it, re documenting the scope and making sure, you know. So certainly once we have a change, making sure that we don't wind up in a slippery slope type situation, that's change control. And then the other major concept we're talking about in monitoring and controlling is we're talking about risk management. So again, when something goes wrong, what are the plans that we implement in order to mitigate that risk and make sure that it has the lowest impact possible on our project?

68 of 84

The Project Manager during Monitoring & Controlling

What are the deliverables of the project monitoring & controlling stage?

Risk mitigation
Change control

Change request
Change approval
Change implementation

Milestone: Moving to close

Okay… so what, exactly, does a project manager do and produce as a result of the project monitoring & controlling stage?

So remember that the Monitoring & Controlling phase happens in parallel to the execution stage, meaning that as we’re executing the project, we’re engaging the monitoring & controlling process on an as-needed basis in response to any issues that pop up as we roll out the project.

Remember, too, that we’re not sort of randomly choosing our responses to these issues. Allllll the way back in the planning phase, we came up with a project plan that included our risk management plan (or, if the project was big enough, this may even have been a standalone document). Part of creating that document was identifying every single risk we could think of, and then anticipating (as best we can) what the appropriate response to that would be, which we call a risk response.

Now, obviously, we can’t read the future as project managers, right, so certainly there’s some judgment and fine-tuning that goes into implementing the risk response. Typically you’re checking in at a minimum with the project team (because they’re likely to have a lot of thoughts on how best to proceed, as your boots-on-the-ground folks), as well as the project sponsor, who you want to touch in with from a perspective of keeping them in the loop and also because as the sponsor they may have some expertise related to the issue you’re facing. You’re also going to check in with any other stakeholders you named in the risk mitigation plan, back in the planning stage, as well as anyone else your judgment tells you might be relevant.

A couple more notes on risk: again, this is a little confusing because I want to be very clear that we’re creating the risk management plan in the planning stage, but it makes sense to talk about it here (because we cover a LOT in the planning module). If you’ve ever done a SWOT analysis as part of your role in higher ed, you know that SWOT is an acronym that stands for Strengths, Weaknesses, Opportunities, and Threats, and it helps us think through an environmental analysis. Strengths and Weaknesses are internal. So an internal weakness, or risk, would be similar to the example we used earlier about a project team member getting sick, and maybe they’re the only person at the company that can do their role, so now the project is a week behind and you as the project manager need to figure out the best course of action. Does it make sense to ask for more time to get the deliverables? Maybe if this is an internally-facing project, or a project you’re completing that doesn’t have any external sales orders yet, that’s no problem. Or maybe the deadline is a really big deal and there is no flex, so you need to figure out how to work with your leadership to get another person temporarily assigned to your team to help get that workload covered.

And that’s what I really want to drive home, here: as the project manager, people are looking to you to make recommendations. Just like we said in the last module, you’re going to have a birds-eye view of your project – you might be the only one with a birds’ eye view – and you’re going to be one of the best-positioned people to understand where you can flex, and where you can’t.

A closely-related concept here is the idea of change control – again, we can’t predict the future, so sometimes we’re going to write scope statements in the initiation and planning stages, and then something is going to come up (maybe a new idea from a stakeholder, maybe a new market trend) that positively or negatively impacts our project in a way that makes it logical, reasonable, and maybe even necessary to change the scope of the project. The way that we handle this is called the change control process. In its simplest form this looks like creating and overseeing a three-step process of requesting the change, approving the change, and implementing the change. Different organizations again will do this differently, depending on the size of the project or the parent organization.

69 of 84

Risk Up Front

Risk Up Front is a project methodology, but we didn’t talk about it in the Planning module because of how heavily it ties into Monitoring & Controlling principles.

RUF says that Risk Identification and the writing of the Risk Management Plan is the most important thing we can do, and that it should take center stage in the Initiation phase.

This is because change is expensive the further into a project we get.

Risk Up Front is a project methodology. We didn't talk about it in the planning module because of how heavily it ties into the monitoring and a controlling principle of risk management. And I actually also think that the authors of risk upfront, um, Adam Josephs and Brad Rubenstein would probably object <laugh> to me talking about it in monitoring and controlling. Because what you see here in the second paragraph is that risk upfront says that risk identification and the writing of the risk management plan is really the most important thing that we can do as project managers, and it should take center stage in the initiation phase. So I'm talking about it here because a very traditional view of project management is going to think about risk when they think about monitoring and controlling traditional project managers view those things as really inseparable. Risk defines the monitoring and controlling phase, and monitoring, controlling happens as a response to risk.

(00:59)�So that's why I'm placing this here. But I would really recommend that you take a deeper dive into risk upfront, which is, um, a book. So if you're interested in what I'm about to go over, uh, in the next couple minutes in this module, um, I will link the book and I will link my own blog post reviewing the book in the resources section for this module. Um, it's very popular in tech and agile circles, so if you know you're gonna work in, you know, a very traditional project environment, it's probably not something to prioritize. Um, but again, it's becoming really popular in tech and agile. So if you're interested in that, I would definitely give it a, um, give it a quick skim or even a full read. I wanna talk about it here though, because I think one thing that it's easy to miss about risk upfront, you know, if you're just sort of like reading people talk about how, you know, it's this real tech, um, agile game changer.

(01:56)�Actually, one of the things that risk upfront really talks about throughout the entire book is leadership, right? So risk upfront, I'm just gonna take like 30 seconds to give you a real, um, high level overview of the book. Risk upfront basically says that because change is much more expensive the further we get into a project, if we can front load thinking about risk, if we can spend time with the entire project team in the very, very early phases of the project, identifying every single piece of risk that could possibly happen, and then really building that risk management plan and getting our entire project team on board. And they talk a lot about how really what we're using when we do that is leadership skills, right? They make the point that it's not really possible to do that without having a really strong background in leadership and in organizing and in personal development. It's not possible to do that without getting buy-in on a really deep personal

Speaker 2 (02:59):

Level from your project team. And so I think that it's really, really important to recognize then that if we're really going to put risk upfront principles into play, student affairs competencies are key. They're critical. We can't move forward without some of the things that student affairs professionals do better than any other pivot I can think of. We can't move forward without people who are really, really good at understanding what motivates people and what drives people. We can't move forward without people who have really diverse and broad applications to leadership and who know many different leadership theories and can pivot and turn when something isn't working and can modify their approach, right? Um, so that I, to me that is a really good example of how in project management, everything is related to everything else, right? If you hadn't come in with a student affairs mindset, you might look at risk upfront and kind of relegate it to like, oh, that's how tech people talk about risk.

(04:08)�Instead, what we can say is, oh, the way that tech people talk about risk lends itself really well to leadership and requires and presupposes an understanding of how people work. And leadership development is a really good example of that. So the point that I wanna drive home for you, um, again, generally if you are planning on working in tech, I would recommend checking out or purchasing risk upfront, giving it a read. But I would also recommend going in knowing that you are going to be able to apply your, um, higher education student affairs principles to it.

70 of 84

Fit Check

What did we learn in this module about great project managers?

Strike a balance between fiercely protecting scope and being flexible when things have to change

What did we learn in this module about happy project managers?

Don’t internalize making mistakes as they learn how to make judgment calls

Speaker 1 (00:00):

Our fit check for monitoring and controlling really hinges around, honestly, one of the most important project management concepts there is, which is the idea that here we're really, really living in that push pull territory. So we're striking a balance between, on the one hand, we're monitoring and we're really fiercely protecting our scope, and we're making sure that as scope creep wants to come along and as stakeholders say like, Ooh, wouldn't it be really cool if blah, blah, blah, right? We're making sure that we are our, a project scopes only advocate, and we're making sure that we're living up to that. So we're striking a balance between that fierceness and also between being flexible when things have to change. So sometimes things have to change because we learned something new. Uh, we learned that we left something out of a market analysis, or we left a really important stakeholder off the table and we didn't know that we were doing that.

(00:54)�So we have to change. It makes sense to change, it makes sense to be proactive about deviating from the project plan. Sometimes we have to do that. Other times things change because the world makes us change, right? Um, something happens that we had anticipated in our risk management plan. So we put that plan into place and we take mitigation measures. Always. What we're trying to do is we're trying to sort of pull, we're trying to close that gap between expectations and reality. We're trying to pull the train back onto the tracks. And again, sometimes that looks like changing the plan and changing the way that the tracks go. Other times it looks like pulling the train, which in this case is the project that has gone off the rails, <laugh>. Uh, and we're pulling that train back to reality by implementing that risk mitigation plan.

(01:44)�The takeaway here for you is that as a great project manager, you really have to be ready to strike that balance, and you're not always gonna get it right. Sometimes you are going to want to fight too hard. Uh, and, and in retrospect, it's gonna be very clear that you should have made a change earlier. Other times it's gonna be very clear by the end of the project that you know, what you probably could have fought a little bit harder. And ultimately we did give into a little bit of scope creep. That's okay. That's another one of those rights of passage. Um, unless a company is very toxic, they don't hire project managers with the intention of, you know, from the jump, this new project manager is gonna do their job perfectly every single time. And when they don't, we're gonna punish them, right? You're gonna live and you're gonna learn and you're gonna continue to use your judgment to strike that balance. But again, um, one thing we wanna really underscore is that a happy project manager is comfortable with that learning curve. You're comfortable with the idea that project management is a judgment game. And what that means is that you're not always gonna get it right upfront, and you're gonna have to build relationships with your leadership, including your direct boss and your stakeholders that are gonna mean that. Sometimes you're gonna have to go to them and say

Speaker 2 (02:58):

That you made the wrong call while you're balancing. And that doesn't mean that you're a bad project manager or an unwise professional. It doesn't mean anything like that. It means that you're learning and that as you're figuring out how to use your judgment to strike those balance, you're sometimes taking a misstep. So again, great project managers are gonna wind up striking that balance really as a result of their professional judgment and of living and learning. And happy project managers are gonna be able to do that without sort of internalizing what it means when they make mistakes.

71 of 84

A few thoughts on human nature

As always, we're gonna wrap up this module with some thoughts on human nature and the thought on human nature that I want to talk over for our monitoring and controlling section, which again, is all about change management and risk management has to do with a piece of pushback that I often get, um, when I'm coaching or working with new project managers or project managers in training. And that is the idea that some of the concepts that we talk about in this module come dangerously close for some people to the idea of either tattling or throwing people under the bus, right? Isn't this just getting my coworkers in trouble? Um, particularly when I talk about being action oriented and taking action swiftly to resolve issues, um, you know, isn't that just getting people in trouble? And so I really wanna dispel the myth that a, every time we're taking action, what that means is like running to your boss and saying, I need help resolving this.

(00:58)�Right? That's not what we're talking about. Taking action might be reaching out to somebody on the project team and saying, Hey, I need a status report on this ASAP because I'm worried that X is going on. But if y is happening, you know, we're all good. That's taking action. And then another action would be, if you haven't heard from that person and our following, but you, they're showing online on Slack, right? How are we gonna get in touch with them otherwise? So I wanted dispel the myth A, that taking action is always like raising your hand to quote unquote squeal, but there's also something deeper going on here. There's the idea, and I think this does often show up in student affairs professionals, this idea of like, you know, um, we're all in a foxhole together and I have to protect my colleagues at all costs.

(01:46)�That's in some ways an outgrowth of being in toxic management situations. So if you are coming from an environment where people quote, get in trouble, right? There's, there's some unpacking we can do there. I listen to a podcast and I have spent the last year wishing I could remember which one it was, but a podcast about a year ago that posited the idea that adults don't really get in trouble as an adult. Other people aren't getting you in trouble. And if you're working with authority figures who are getting you in trouble, that's a red flag or a sign that something deeper is going on there. Adults just sort of work on things, and if things don't go well, we can give feedback, right? But we don't like punish or get people into trouble. At least we don't in healthy working environments, right? So that's something to keep in mind too, this idea of like as many environments, it doesn't look like, are you in trouble or are you not? And so in an environment where that's not the case,

Speaker 2 (02:58):

Raising an issue or raising a flag and saying, Hey, I'm consistently getting work late from so-and-so, or Hey, um, this person's deliverables are consistently not meeting the standard of quality. So first, you know, project management happens in the exact same world we all live in. And in this world, whenever you have an issue with somebody, the first person to raise that person with is, or the first person to raise that issue with is them, right? So that doesn't change because you're a project manager. So if you're constantly getting, you know, deliverables late or getting deliverables that are unserviceable because they're not high enough quality, uh, project management doesn't change the fact that you're still gonna talk to that person first. But then beyond that, if you are managing projects in a healthy environment, it's not getting your coworker in trouble or squealing on them to share that issue.

(03:50)�Particularly if you're working on projects that you care about when you report issues of quality or timeliness, ultimately that's in service of the greater project. It's in service of the greater organization, and it's also in service of that person. Because how many of us have had feedback shared with us after the fact? How many of us, this has happened to me, right? I have been in a situation where somebody later on said, Hey Caroline, if you had just gotten me those reports a couple days earlier, every time they would've been much more useful to me. And I'm like, well, what the heck? Where, where was that feedback while the reports were being generated? I worked hard on those. If those weren't helpful when I was giving them to you, I would've wanted to know that, right? And so I think it can be really hard to apply the idea that feedback is a gift when we are coming from environments where feedback, frankly isn't a gift in practice because the environments are unhealthy or maybe even toxic. So this may not apply to you. As always, if the thoughts on human nature in these modules don't apply to you, you know, take them for what they are and push them aside. But if you are coming from an environment where that is the case where it's not a healthy environment, maybe it's even a toxic environment, and feedback is absolutely not treated as a gift, um, just know that it's not like that everywhere. And that managing projects does not have to feel like squealing or tattling on people who aren't getting things done.

72 of 84

At NASA, we never punish error. We only punish the concealment of error.

Al Seibert

In NASA says, Al Siebert, we never punish error. We only punish the concealment of error. This quote is not perfect because you and I both know that as human development experts, we know that punishment is actually never effective, right? Particularly at work. I strongly believe that there's no place for punishment at work, and yet I have pulled it here because I think it really draws attention to the idea of the only true error as a project manager is concealing errors. Hopefully, a theme that by now is really coming through strongly in this course is the idea that as a project manager, our ultimate goal is simply making sure that everybody's on the same page and that everything that needs to be communicated has been communicated. We can't do that through concealment, we can only do it through transparency, and that's true throughout the entire project lifecycle.

(00:56)�That's true throughout all of the different supporting professional development activities you'll do in service of making you a more effective and efficient project manager during the project life cycle. Um, but it's perhaps never more true than during monitoring and controlling. This is really the stage where transparency and immediacy and action around communicating, um, particularly when we discover errors, is really, really important. And so if you are somebody whose intent sometimes is to like, I'm just gonna fix this myself, I'm gonna get as far as I can, and then I'm gonna ask for help if I can't resolve it on my own. You know, I'm not telling you that as project managers. You know, our job is to sort of like run to the teacher whenever there's a problem. But I do wanna challenge you that the mindset I just described, right? So wrestling with a problem for a couple days before I tell anybody about it, is that of an individual contributor. But a project manager is gonna have a really finely attuned sense of judgment for when they need to escalate issues. And it's much quicker than an individual contributors, um, sense is going to be.

73 of 84

Thank you!

Next up: Module 6, where we’ll discuss Project Closing

createboundlessimpact.com | @carolinemanages + @boundless_impact

74 of 84

The Aspiring Project Manager

Module 6: Project Closing

Presented by Caroline Horste, PMP, MBA, MA

createboundlessimpact.com | @carolinemanages + @boundless_impact

75 of 84

What we’re covering

Organizational Process Assets
Impact vs value
Fit check
Closing Out
Resources & Next Steps

One of the toughest transitions from HESA is that often, in HESA, we talk about impact as if it's synonymous with value… which is fine, because often we’re talking to people for whom that is true. Your VPSA likely understands you when you talk about impact as if it’s synonymous with value… even if they’re doing the translating from talking about impact to talking about value when they talk with other folks.

A basic example that sometimes makes our skin crawl in the HESA world is student engagement. We know that students who are involved in student organizations as leaders see all sorts of positive psychosocial effects. It helps their development across any number of Chickering vectors, it moves them through the self-authorship framework… all that good stuff. We also know that students who are leaders in student organizations are more likely to persist to graduation.

Now, personally, as a mother, as a cub scout leader, as a human person living in the world, it matters much more to me that our students, after having taken leadership roles in student organizations, are happy and fulfilled and feel confident in their roles. Yet when I come to work, I’m not wearing the hat of mother or cub scout leader. I’m wearing the role of the person managing to revenue metrics. And so in my role, what would matter to me if I needed to make a decision about allocating funding to expand a program, or allowing for some of the increased budget or scope requests we talked about in monitoring and controlling, to keep things on track… what would matter to me in my post-HESA career as a director of operations and strategy is that metric about students being more likely to persist to graduation, because that’s the number that ultimately makes its way into my incentives.

Outside the HESA world, impact =/= value. Sometimes, value may INCLUDE impact... but outside the higher ed and non-profit world, impact is rarely a value unto itself.

The reason it's a ... let's say "pink flag" for me when you talk about impact first is NOT that I don't care about impact... it's that I think it probably affects the way you prioritize and make decisions when things hit the fan. I need to know you have value in your head first.

And again, we can struggle with this. I think that’s fair, and I think it’s fair to mourn leaving a field where we don’t always have to attach value to the impact we’re describing. I’ve talked and blogged about this before, but a helpful reframe for me has been that as long as I’ve been at an organization whose mission really matters to me, thinking in a metrics-driven rather than impact-driven way is what allows the organization ultimately to succeed into perpetuity. Because – and this might be a hot take – some of these organizations who aren’t forcing us to attach value to impact are not surviving into perpetuity. No organization lasts forever, of course, but ultimately prioritizing value allows for increased perpetuity.

76 of 84

Project Life Cycle: Closing

Inspecting deliverables and documenting wrap-up processes:

Has all work been completed, and are the deliverables up to par?
Have all agreed-upon project management processes been executed?
Has the completion of the project been formally recognized – i.e., does everyone agree that it is completed?
Have the “lessons learned” been documented?

All right. So now that we have initiated, we have planned, we have executed, and we have monitored and controlled where necessary our project, we are ready to move on to closing out. Project closing has four major components. In general, across all four of these components, we are inspecting deliverables. So again, those things that we had to produce in order to say that our project was successful, according to the scope and the objectives that we set out in the initiation phase… we're inspecting those deliverables and we're documenting our wrap up processes.

There are a million different ways to conceptualize and quantify closing, but when I’m leading projects and the organization I’m working for doesn’t have a map, I divide project closing into four main pieces, and we can think about asking ourselves questions for each. So question one is maybe the most obvious. Has all of our work been completed? And does that work measure up to what we're hoping it does. Some work genuinely needs to be perfect. Other work doesn’t. But all work has what we call a “standard of quality” set out in the project planning documents. So if all the work has been completed, but it's shoddy and we know that it's not going to hold up, we know that it doesn't live up to our own standards for quality, that we can’t put our company’s names on them and our names on them… then we can’t inspect those deliverables and say that they have met our scope.

Now, ideally, this is where the project life cycle comes into play. Ideally, we have noticed that before, right? Remember that as a project manager, our job is to be very in tune with all the components of our project at all times, throughout all the project phases. So – again, ideally – nothing that ever happens in closing should really be a surprise. Ideally, during the monitoring stage, we've seen like, oh wow, the quality of these deliverables is really, really not something I can present to a sponsor and say, this is done. And then at that point, very proactively, we've issued some kind of control plan to make sure that we increase that quality within the bounds of our project, right? (Think back to the Triple Constraint here in Lesson 2… that triangle of time, budget, and scope.) So within budget, within schedule. So ideally this first question is just a formality. Ideally, we already know that all the work has been completed and that the deliverables are up to par.

Every once in a while, though, we get surprised. And so if that happens, just remember exactly what we've been saying before, that this is a life cycle and that every time we're surprised by something in closing, what that means is that there's something we need to keep in mind during the next project's initiation and planning phases. So that’s question one: inspecting deliverables, has all the work been completed and are the deliverables up to par?

Item two is more about process. So for some of my counseling friends in the room, if you found your way into higher ed and student affairs through counseling, one of the things that counselors will talk about is process versus content, right? So the first item on here is really content-oriented. Did we do the work? The second item on here is process: have all of the agreed upon project management processes been executed?

So for example, if we said that as part of this project, we were going to document our stakeholder analysis so that the next time we initiate a similar project, we don't have to duplicate that work… is that stakeholder analysis logged somewhere? Did I as the project manager make sure that everything that we said we were going to accomplish along the way… has that been completed? We talked a few minutes ago about how typically in the planning and executing stages, there are organizational process assets in place for you as a project manager to lean on. It’s worth remembering that those don’t happen magically. Those happen because the project managers that have come before you have done their jobs really thoughtfully and as part of the closing stage have said, okay, so here's the timeline that I used to plan this project. Here's the planning document that I used to make sure I had everything I needed. Here's the tool that I used to conduct a stakeholder analysis, et cetera. So if one is about content and has all the work been completed, then two is about process. And have I done everything as a project manager that I need to do in order to make sure that the next time we initiate a similar project, it goes smoothly for the PM in charge at that point.

Item three, has the completion of a project been formally recognized and does everybody agree that it is completed? So this item is important because of our BFF's scope and stakeholders, right? Sometimes what can happen if we don't formally recognize the completion of a project is three weeks down the line, a stakeholder sends an email and wants to know when we're having a status update to talk about this project. When everybody else on the project team is like, okay, wait, <laugh>, we all thought that this bad lad was done and that we weren't talking about this anymore, because it is done, right?

This can happen because sometimes stakeholders have different levels of engagement, right? And so this brings up an important concept, which is that we sort of have to accept varying levels of stakeholder engagement as just a thing that happens during a project, right? Think back to our conversation about monitoring and controlling. We can't control the project, we can't control our stakeholders, right? All we can control is the extent to which we work really hard to understand what all the potential outcomes of a situation are, work as hard as we possibly can to guide those outcomes in the direction that supports success, and maybe even anticipate when things are maybe gonna go off the rails and then put contingency plans in place.

And one of the quickest ways for things to go off the rails is to have stakeholders who maybe play an important role or who are very connected to the success of a project, but who maybe blow off meetings or maybe don't read emails… I'm not sure if any of you listening to this have ever had an experience with a similar stakeholder. If so… I regret to inform you that this is not a problem specific to higher ed. These stakeholders are everywhere. And so this question of: has the completion of a project been formally recognized is a specific response to the fact that sometimes stakeholders don't pay careful attention, right? And so what a really great project manager is responsible for doing is making sure that all of our stakeholders go through check-in points. We talked earlier about milestones as stage gates: those checkpoints of a project that we can’t really go back on. And certainly, one of the most important stage gates – maybe THE most important stage gate – is the project is done. Does everybody agree that the project is done? Does everybody agree that anything that we've left undone to this point is something that's out of scope? It wasn't our job to do it in the first place. It's not our role. And if somebody were to ask us why this isn't done, would everybody on the project team and would all of the stakeholders be in alignment with the response because it wasn't part of the project? If not, you probably as a project manager have a little bit of work to do ahead of you in terms of closing.

So in theory three should be part of one <laugh>, right? In theory, everybody should be on the same page automatically once we agree that all the work has been completed. But remember that as a project manager, your job is to take into account not just managing and executing the work, but also making sure that you understand that the people that you're managing are just humans. And humans have things that they're really awesome at, and humans have things that they're really terrible at. And sometimes that means that we're not all on the same page. So like I said, while we should be able probably to fold this third item into the first, t is always good as a project manager to err on the side of making sure that you are very clear that everybody is on the same page.

Similarly, item four is a process question, just like item two: have the lessons learned been documented? I you spend a lot of time in the project management community, you will start to hear this phrase, lessons learned, often. All that means is that anything that came up for you during the project, anything that came up for you as a watch out for next time or a flag that, you know what, in retrospect, that was the moment that it all started going down, right? Anything that you can think of. And really, you know, what we're thinking about here is you've heard this idea that, you know, we want to plant seeds for trees whose shade you'll never sit in. That's what we're thinking about here, right? Probably most of us don't work on projects where like no one is ever gonna touch anything related to it ever again. Most of us work on projects that at some point somebody else on our team might pull up and might say like, Hey, how did Caroline do this? Wow, this is a really thorny set of stakeholders. Or maybe, wow, this timeline really doesn't make any sense. I think Caroline worked on a project like this last year. How did she manage this? Right?

If I as a project manager, Caroline, am really carefully documenting everything that I learned from working through a pain in the neck project, then the next project manager who works on a similar pain in the neck project can come over and say oh wow, okay, Caroline did it this way. That's really good to know, I'm gonna save myself a little bit of time and do it that same way. So here we're sort of, again, hearkening back to the idea that as a project manager, you're never really working on this stuff alone or in isolation or in a vacuum. Probably there's somebody else at your organization who has done this before. And probably you can reach out to them, because ideally they've documented this stuff really clearly and maybe you don't even have to connect with them personally.

That said, if they haven't done that because maybe they haven't been in a formal project management role and they haven't been trained to think in this way, you can still at least connect with them. And, because you are part of this program, you have access to a community of people that have definitely done something like this before. You have access to me, you have access to everybody else in the program. You have access to our community where you can throw out questions like, Hey, I for some reason can't find any lessons learned on a similar project. Has anybody ever worked on something like this? So as a project manager, keep in mind that your goal is really to make it so that when you close up a project, you are contributing to your organization's community. In that way, you are making it so that the next time somebody works on a similar project and they say, Hey, has anybody ever worked on anything like this?, your organizational process assets speak for themselves and say, yes, and this is how I did it.

77 of 84

Concept: Organizational Process Assets

Organizational process assets are anything that a company or a team owns that ultimately makes a PM’s job easier. Examples:

Templates
Lists of stakeholders & relationships
Lessons Learned from past projects

78 of 84

The Project Manager during Closing

What are the deliverables of the project closing stage?

Project Report (signed off by project sponsor)
Organizational Process Assets

Milestone: Project Closure meeting!

Okay… so what, exactly, does a project manager do and produce as a result of the project closure stage?

79 of 84

Throughlines: what are we keeping in mind throughout?

Strategy

Why? This is how we know we’re creating value.

Stakeholders

Why? This is how we know we’re meeting the needs of the organization.

Project environment

Why? This is how we contextualize the decisions we make (recall that PM is the ultimate push-pull: you’re using your judgment every second).

So now that you have a pretty good sense of how the project life cycle works, right? How it happens in sequence, and certainly it starts over. Once we close one project, we move on to initiating another, but it doesn't happen all at the same time. We initiate a project, we plan for a project, we execute a project, and then as we're, as the work is unfolding, we're monitoring, controlling, and then once we're finished executing, monitoring and controlling, we close the project. Throughout all of those stages though, there are three things that I want you to be keeping in mind. The first is strategy. We always need to need to be rooting back to how are we creating value? How does the project that we are moving forward and the ways that we've chosen to do that, right? The ways we've built our project team, the ways we've articulated our business case, how do those things root back to the larger strategy that we're working within?

(01:00)

The reason we do that is because this is how we know we're creating value, right? So this is not something that is like formally people's, I I would say most people that I have known that worked as project managers. This is not something that's formally part of your role, but if you are looking to distinguish yourself, which you are as a pivot, right? I'm not saying that we are at a disadvantage. Um, we're not as higher education professionals and folks who've worked in the field, um, we have a strong advantage because we typically have been tasked even at entry level roles with overseeing a lot of these pieces related to the project life cycle. So we're not at as it is at a disadvantage other than the fact that sometimes we convince ourselves that because we didn't have a title like project manager, um, you know, we, we haven't done this.

(01:54)

We're not, we're not qualified for it. We're not experienced enough for it. And so if we want to distinguish ourselves, if we want to differentiate ourselves from folks that, you know, we feel may have had more direct experience, the way that we do that is we root our work to strategy. And we use that strategy to understand how and articulate to other people how we're creating value. So for an example of this, think back to the initiation example that we talked about with the academic advisor who is trying to understand and articulate how, uh, implementing or changing CRMs is going to make the work of the advising office overall more efficient. Nobody would ever <laugh> migrate CRMs if it didn't create value because it's a huge pain in the neck. If you have ever been involved in a CRM project, you know, um, depending on the scale of your organization, I just worked on a project where I was helping a large healthcare system migrate CRMs and it took

Speaker 2 (02:59):

Months, uh, and it was a, a truly staggering amount of of work. No one would ever do that if it didn't create value. And also sometimes the things that we, like, I'm making quotation marks know if, if they go unspoken, what that means is that they go unacknowledged by leadership, right? And so we really, as project managers want to keep that strategy in mind throughout and throughout and articulate it every chance we get to stakeholders into leadership. Which leads us to the second thing that we're keeping in mind throughout all of this life cycle, regardless of the stage that we're in, is stakeholders. The reason being is that stakeholders are how we know we're meeting the needs of the organization, right? Um, and this is where I get a little bit touchy-feely with respect to project management. Projects are always for people and they always happen because of the labor of people.

(04:03)

There is no reason to undertake a project. Even the most cynical eese or SCR project in the world, Eese are screwed, is still a person, right? Eese are scr still might want to, and again, I'm, I'm really delving into like deep, deep, cynical world for the purpose of illustration. You know, if you are working on a project where the only purpose is to take a billionaire and to make them even richer on, on the backs of, you know, other people, that billionaire is still a stakeholder <laugh>, right? Um, and so there is always somebody who has a personal vested interest in the success of your project. And as a project manager, you have to know who those people are, right? Um, to be clear, most projects are not sponsored by an eese or Scrooge. So, you know, to take an example of a, of a much more common and regular project, let's say that you are working for a transportation company, right?

(05:04)

And your job is to expand the transit routes available within your region, um, to neighborhoods that they currently don't surf. So your stakeholders certainly are going to the people that ride the buses, certainly they're also going to be the bus company itself, but they may also be, well, they are also people who don't ride the buses, but who live in neighborhoods that are served by the bus routes, right? Um, so if all of those people are happy, great, but if one group of those people, if the bus company isn't happy, or if the people who are riding the buses aren't happy, or if the people who, uh, live in the neighborhoods that the buses are going through aren't happy, you as a project manager are gonna hear about that. That might look like negative publicity for your organization. If it's the folks who live in the neighborhoods and who are organizing to make their,

Speaker 3 (05:57):

Uh, dislike known, that might look like a direct loss of revenue. If you spend a lot of money in order to put bus routes into a neighborhood that it turns out people actually there don't even wanna ride the bus. That may have been ineffective stakeholder analysis during the initiation phase, right? So if we don't keep a close eye on both strategy and our stakeholders, in addition to know not knowing whether we're creating value, we also might not even know that we're meeting the needs of the organization. And then the third piece is the project environment, right? Um, so the reason we keep the project environment in mind throughout is that this is how we really contextualize the decisions that we make. So project management, you'll hear me say this over and over again in this program, project management is the ultimate push pull. You are always using your judgment.

(06:48)

Um, very rarely that I can think of is your job as the project manager to make the right decision over the wrong decision. Um, it's, it's one of those, uh, situations. I, I don't know if you've ever taken a standardized exam where the, where the instructions were to pick the most right answer, right? So, um, some of the answers are technically correct, but they're not really like a great choice. Um, some of the answers might be a pretty good choice, but there's a really, really great choice in there. And so you're gonna get the question wrong if you pick something that is like correct, but not as correct as a super obviously correct answer. So as a project manager, unfortunately that's a little bit more true to how it actually looks to be a project manager. You are always trying to juggle, um, competing priorities.

(07:38)

You are always trying to juggle competing stakeholders. That's why. Um, and you know, at the closing, uh, at the close of this program, one of the resources involved is like, what are common project management, job interview questions and why? Um, the most common one that I can think of, uh, revolves around what are times that you've juggled competing priorities? Because that's what being a project manager is. Being a project manager is always contextualizing what is the best choice I can make here? Not unfortunately, what is the only right choice I can make here? What is the best choice I can make here based on the project environment, right? And of course, we're pulling in things like strategy and stakeholders, but the project environment on a tactical level is what's gonna help you understand, you know, to go back, for example, to our planning, um, example where we were talking about communication.

(08:32)

The project environment is where you're gonna know like, okay, this is really not an environment where daily standups are gonna fly, right? These people don't like meetings. Um, they prefer, um, they prefer maybe emails or they prefer if they have to meet, they wanna roll everything up into, you know, one sort of digest of a meeting that maybe happens weekly or even biweekly. Um, versus other organizations where, you know, these people are, are gonna roll their eyes if you schedule a biweekly and wonder why you're not updating them more often. Another example of project environment, you know, so you would want to know, I imagine if you started a new role and let's say you started a new role in student affairs, right? Let's say, let's put your pivot aside. If you're working in housing, for example, you're working in housing operations and you are meeting with, let's say, um, the facilities office on campus, right?

(09:29)

And you're trying to figure out camps and conferences, you would want to know if facilities is in a situation where they just had, you know, a wild budget cut, let's say they just had to, you know, cut 15% or something wild like that. Um, versus let's say, uh, enrollment was really great that year and facilities directly benefited from that. And you know that they are looking at a marginal increase. They've got 3% more in their budget for this year, um, than they did the year before. You would want to know that difference and you would probably tailor the way that you approach them as a campus partner based on what you know about their budget. So that's another example of project environment, right? You really wanna understand and contextualize the decisions you're making. Um, because in the long run, I'm not trying to say that like you have to prioritize diplomacy over everything.

(10:29)

Um, but think about what we talked about at the beginning, right? Think about and, and think about what we talked about in closing. Actually, when we talked about closing, we were talking about the idea that, um, in general you're never working in isolation. You're always working a set of projects that are a part of a larger portfolio. And what that means is that ultimately what we're trying to do here with our stakeholders, the reason we wanna keep them happy is because it's not like you get like a reshuffled deck every time, right? By being sensitive to strategy and stakeholders and project environment, that's how you work with the same group of stakeholders over and over again and form these really positive relationships over the course of time. Hopefully you are listening to that and you're thinking like, I do that. I already do that. The reason I created this program is that I know that you do that as a higher education student affairs practitioner.

(11:20)

You do that every single day. You do it every day, you do it every semester, you do it every year. It's why there are people who every single year are excited to work with you again on your Hallmark programs. That's the sort of energy we need to take over to these job interviews. Uh, and this is the language I want you to use, right? You, uh, we talk about, like, I'm trying to think about what my old department used to call it. I feel like it was like, you know, building goodwill with campus colleagues, something like that. Um, that's great and it's great that you do that. I

Speaker 4 (11:52):

Want you to use language like this. I want you to use words like strategy, stakeholders, project environment, contextualizing decisions, leveraging relationships, um, that's jargony. And I'll teach you over the course of this program how to do that. But I hope that all of this is making you think like, okay, this is familiar. Um, there are some places I know where I need to grow, and then there are places I need to contextualize the work that I do, but maybe not change what I'm doing. So, um, hopefully this has been some kind of some helpful things to chew on.

80 of 84

Impact Vs Value

If you can, try to reframe the idea that we measure our value through impact.

In many environments, value is related to the impact we have on a person, but it’s not the same thing.

Outside the HESA & non-profit world, impact is rarely a value unto itself.

All right, so this is a toughie. I talk a lot about value. I talk a lot about understanding how to articulate value. I'll throw some resources into the, uh, I'm sorry, I'll throw some links into the resources section of this module about how that looks. Different ways to quantify value when you're working on different activities. Um, and so because of that, I often wind up in conversations with pivoters who feel really uncomfortable about the idea that you should frame value as the primary thing that you're bringing to the table versus impact. So I wanna clear up a couple things about this. Um, I wanna clear up the fact that value and impact are in opposition. Very often value is related to impact. And very often, um, when we, part of the way that we create value is to deliver impact, right? If you are working at a non-profit or a for-profit, right for profits, uh, deliver impact all the time, if you are serving a constituent group, and that is directly within your job description, part of the way that you create value is your company changes money into impact by giving you a salary in response for the work that you do, right?

(01:21)�Um, so what I'm not saying is that impact and value are in opposition. Um, I am saying that impact and value are not the same thing. And I am saying that in higher ed, and particularly in student affairs, we often get a little bit intellectually lazy about short-cutting and talking about value as a stand-in for impact or vice versa. We talk about them synonymously when really they're not outside of student affairs and higher ed, and sometimes nonprofits, although not always, right? Impact is rarely a value unto itself, which again, does not mean that they're not related. It just means that outside of higher ed and some nonprofits, we have to sort of make it explicit and make it distinct. That impact is how we're talking about value impact is how we are delivering value, right? And there are lots of other ways to deliver value too.

(02:20)�We can make it more efficient, we can make it easier. Um, we can make it more scalable to deliver that impact, right? Um, but the reason that I consider it, I don't wanna call it a red flag. The reason I consider it a pink flag when there are higher ed student affairs, um, expats who can't really distinguish between impact and value, the reason that's a pink flag for me is because for project managers, the place that the rubber really hits the road, again, as we've said over and over and over again in this course, is decision making and professional judgment. And if you are not clear in

Speaker 2 (02:58):

Your head about the difference between impact and value, particularly as a student affairs person who really probably got into the field initially to make impact on somebody, I'm not sure I can trust your decision making to not default to making impact versus creating value. So again, not in conflict, not in opposition, and not even really a, a pink flag that may have been too strong a yellow flag, right? Um, not, not a deal breaker at all for somebody to really come from an impact. First background, I prefer <laugh> working with people who really have a, have an intuitive, heartfelt sense for why we would want to go out into the world and to make impact, right? Um, but if you can, I want you to reframe this idea that the only way to make value is through impact. And also that impact is how we measure value.

(04:01)�They're not the same thing. And in many environments, impact is not by itself, doesn't even have value right by itself. If you make a lot of impact on somebody, that it's totally outside your strategic plan, it's not related to any of the objectives that your company wanted to achieve, that your division wanted to achieve, that your department or your team wanted to achieve. That by itself doesn't actually have value. And so that's one of the hardest jumps to make. I think for many people. Moving from student affairs to a more corporate role, um, that's typically one of the things I spend a lot of time coaching and talking through with people. Um, it can take a long time, I think, for people to feel comfortable with that idea. Um, so if that's you, just know that you're not alone, um, know that I have talked with many people who've really been able to wrap their heads around that idea. Um, and we can get you there, right? But just know if you can, I really want you to try to reframe this idea that impact equals value, and really practice articulating the difference between those two. And also practice how the impact that you're making contributes to value, because it does.

81 of 84

Fit Check

In this, our final fit check, we're coming kind of back up for air. We're kind of zooming back out. Remember that in initiation we were super broad, we were super strategic-minded. We started in the planning phase to narrow down a little bit, we started working with the project team. We started thinking about what the actual rollout would look like. And then in execution and in monitoring and controlling, we really had our noses to the grindstone. We were in the weeds. Everything was about details and about capturing exactly what the minutiae of rolling out a project looks like. Here in closing, again, we're kind of coming back for air. So you can kind of think of it almost like a little triangle.

And now we're coming back to the same sort of mindset we were at with initiation. We're wrapping things up with stakeholders, we're making sure that everything is as we had imagined. And then we're also documenting those lessons learned and those organizational process assets so that future project managers have what they need. And so in our fit check, which again is pretty broad at this point, I really want you to think through, am I comfortable throughout all of those stages of the project lifecycle? Am I comfortable with the different pieces of my brain that's going to require? Am I comfortable working with higher level management like I might need to in initiation? Am I comfortable working with a project team who may have expertise in areas that I don't like? I'm definitely going to need to, in planning, am I comfortable living in being the detail keeper, like I'm gonna need to be in execution. And am I comfortable being the flag raiser and the really action oriented risk mitigator, like I'm going to need to be in monitoring and controlling.

�And then am I comfortable zipping it all back up again like I'm gonna need to be in closing. So project managers wear a lot of different hats. They use a lot of different parts of their brain. And I feel like that's really exciting! I know that I've talked to a lot of different people in student affairs who are like, you know what, I actually kinda like the opportunity to wear lots of different hats, and use different parts of my brain and my skillset at different parts of maybe the academic year or even the semester. And if that's you, project management is probably gonna be a really, really great fit for you. So hopefully, these fit checks throughout the course of the program have kind of helped you illuminate and understand where your different strengths and passions and areas of achievement throughout your career might map to project management.

82 of 84

A few thoughts on human nature

Similarly to our final fit check. My final few thoughts on human nature is going to bookend the first thoughts on human nature, which was about you and your experience in this course.

All of my testers by this point in the course… I asked them to imagine themselves as a new project manager just having finished all of the content you just finished. And I asked them, where do you think your head would be at right now? And every single one of them had one of two responses.

The first type of response was, I'm super excited. This sounds awesome. I'm really ready to, to transition into this. And I feel like I have a really clear sense for how I can see myself in it. The second type of person was really a little bit overwhelmed. The content had made sense to them. They understood everything we had talked about and they maybe even understood how it applied to them. They were able to use the worksheets to come up with really clear examples from their own career of times they had done student affairs work, they had really clear understandings of where in their own experiences they could continue to grow and continue to take on new assignments that would give them experience if they were missing something in a given process group. Um, but it still felt a little bit difficult to really imagine themselves doing the work. The jump felt hard. I understand what it looks like over here on this side, and I also understand what it looks like over here on that side, but I can't just see myself making the jump. That was the second type.

And if I'm being honest, that's how I felt when I was understanding, um, project management when I first, in the summer of 2018, began learning about the field and began setting some professional development goals for myself. And I think it's human nature if something feels overwhelming for long enough to decide that it isn't for you. And so for our final thoughts on human nature, I really wanna remind you that the content of this course is just part of the APM program. You have access to a community, you have access to monthly coaching calls. You probably know by now that I'm pretty responsive, <laugh>. And so if you've got, you know, a burning question or something that doesn't make sense between the coaching calls, reach out. I am so happy to walk you through it. You're not alone. If something feels very overwhelming, just know that that's very normal and a very natural part of learning, a new way of being.

�Cuz that's really what this is. We can think about ways of doing, we can think about ways of being, both are overwhelming and project management is both. It's a way of doing and a way of working, but it's also a way of being, being and a way of thinking. Um, so again, my thoughts on human nature are, I think it's normal to feel overwhelmed. I think it's normal to let that sense of overwhelmed convince you that maybe this isn't for you after, um, that while it feels understandable, it maybe doesn't feel accessible. And I really, really want you to push back on those feelings. I want you to push back and know that that sort of narrative, that if something feels overwhelming, it isn't for you. Um, it isn't real. If a student shared that with you, you would push back on it. If a colleague who was a real rockstar shared that with you, you would push back on it. You would help that colleague make sense of the fact that sometimes the next step feels overwhelming. But that doesn't mean it's not the next step. So that's my thought on human nature. Um, that gets back to the MLK quote we talked about earlier, is take the first step with faith, right? You don't have to see the whole staircase. Take the next step and take that step with faith.