The People, Process, & Progress Podcast - How to Build an Effective Project Intake Process | PPP #93

Episode Date: November 1, 2021

In this episode I expand on the three key elements of defining the need, initiating the request and approving the project I believe are essential for setting up projects, organizations and people for success.

No matter how good the team or how efficient the methodology, if we're not solving the right problem, the project fails. Woody Williams. Woody Williams is a Congressional Medal of Honor winner. He's also established the Woody Williams Foundation that honors and provides services to the loved ones of Gold Star families. That's military members that died in the line of duty. And to date, per their website, the foundation has established 89 Gold Star Family Memorial monuments across the US, 78 additional monuments underway in 50 states and one US territory. And the foundation continues to grow. And I would ask all of you to check out the Woody Williams Foundation.

So what does that have to do with this episode 93? It all starts with the intake process. Well, as Woody Williams states, it doesn't matter how good the team is or how efficient the methodology is. If we're not solving the right problem, the project fails. So if we don't start with the right intake, if we don't ask the right questions early, if we don't make sure that it's something we need to do, then maybe we're setting ourselves up for failure. So in this episode 93, it all starts with the intake process. I'll share some key areas that I think every organization, particularly every project management office, should include in their intake process.

But before we get started, please silence your cell phones, hold all sidebar conversations to a minimum, and we will get started with People Process Progress in three, two, one. Welcome back to People Process Progress episode 93. It all starts with the intake process. I am your host, Kevin Pinnell. Thank you for sticking with me for these 93 episodes and 46 episodes of Between the Slides podcast that this was called before that. Remember, you can check out those old archived podcasts on the same feed. You can go to peopleprocessprogress.com for this show, some resources, particularly tracking your experience if you're going to apply for the Project Management Professional Certification. There are also some templates, particularly the Planning P that's the P shaped planning process we follow in all hazard incident management. This one is set up for public health.

So timely, hopefully other organizations out there are putting those lessons learned together thinking how we could maybe plan a little better. There is a large planning P eliminated, you can print out with times and who's who. Also some great situational awareness things from my friend, Rob Raleigh, who we had a couple discussions on previous episodes as well, but situational unit. So checking out how we can track what's going on when the next meetings are, contingency plans, those kinds of things, project management for studying for the exam, like I mentioned there. And you can always email me at peopleprocessprogress at gmail.com, connect on Facebook and Instagram

at people process progress. But let's get into this episode 93. It all starts with the intake process. And it truly does, right? If we want to have an efficient project management system, office organization, and there's probably many variations of that for all of you listening. Maybe you don't even have a project management office, or you're the project manager for the organization. Or you can be a huge company that's chock full of project managers and has a whole stable of folks that get sent off to different projects. But either way, hopefully the effort, which means the approved project, that kind of single thing, and of course, a project is a reminder per the Project Management Institute standard is a temporary endeavor undertaken to

create a unique product service or result, right? So before we're going to essentially put money, people, time, facilities, equipment towards that unique endeavor to get whatever result we're looking for, we should review it and make sure we want to do it, that we have the money for it, that we're thinking of all these different areas. And I'll bring these up here throughout this episode. But that intake process that is viewed by some mix of people from your organization is the gateway to resources money and whether you should or shouldn't put forth effort. My thought is there are three big areas. We can define the need, we initiate the request, then we approve it. And in

each of those is where I'll break down and provide some key things. So let's jump into defining the need, right? As we said, a project, if this is an official thing, is temporary. It's a unique product, service, or result. Another factor typically in some places is it costs a certain amount. It's going to take a certain number of hours. We might need this number of resources. And then those are triggers. Hopefully, again, if you've got an intake or a view board or something like that, that say, yep, this is a project verse. It's just something I'm going to do. Like I'm going to get three new pieces of furniture for the office verse. I'm going to put 300 pieces of equipment in the entire organization. You can tell there's

a big difference there, right? So within defining the need, we or someone in your organization says, I need a new something, right? With that, why does it need to be new? Does it need to be totally unique? Does it need to be the new version of this thing? And if so, what versions? And are we going to talk to, right? The other thing with all this is putting together proposals, all that kind of stuff. But this is before that, right? This is do we even want to do the project now. So there will be some groundwork. But at some point, someone says I need to do something, whether it's a replacement, or a new way to do something. Or I need to improve the process of how we track widgets, how we ship left-handed screwdrivers, how we track patient movement, whatever it is, maybe it's a process thing, right? So it's not new stuff. It's not

new equipment. It's how we're using that stuff and equipment or even the staffing, right? It could be, I need to improve the process of how I staff up for whatever work I'm doing. It kind of goes with that I need to new that I mentioned, but I need to replace an existing something, right? Let's say we have equipment that's end of life. It's not supported anymore. We have to get something new. We need to replace it. Or maybe it's just not cutting it. Maybe it's breaking all the time. Maybe it can't keep up with new technology. It's not compatible with the new technology on the other project that we're bringing in. Or maybe we need to replace the existing equipment we use to train new people that come on board.

Whatever it is, you can think about that, right? So do we need a new something? Do we need to improve a process of something? Do we need to replace an existing something? Or did we discover a need for, and this is where our lessons learn from previous projects, whether they went well, whether they were challenging, whether it was a mix of both, which is usually how it is, can help us in the future, right? During the previous project x, we discovered that if we did these things, we would have been more on track, we would have been

more efficient, and it will help in the future. Well, now we have project Y. And previously, we discovered a need for this one thing, maybe this new process in a different organization that we discovered when we were workflow mapping to replace the system, right? Projects have depending on the size or even a program can have all these different tentacles into different business processes into different technical applications into the infrastructure that are going to help us discover things. Some into different business processes, into different technical applications, into the infrastructure

that are going to help us discover things. Some maybe, frankly, we or the organization don't want to know about, but we as project managers, program managers, leaders that are asked to help facilitate processes and get things done, need to pull the rug up and say, as professionally and objectively as we can, well, we did find this out and these are the things that are going on and you all should know about it. Now, what do we wanna do? So maybe we discovered a need to change a process because it was taking way too much time, right?

Which costs money, which pushes other things back, which takes up resources, et cetera, et cetera. So when you define the need as part of an intake process, because to me, an intake process overall should be like an application. I want to move this project forward. But to do that before your organization, or you if you're on the board of an organization approves money approves people to work on it approves facilities to be used equipment to be bought. You have to sell this to us. And you have to tell us if it's something new, if it's going to improve the process of which could equal money savings or time savings or life savings? Or are you replacing something that's existing because we have to or there's just

something better that's going to help with new processes, etc. Or did we discover the need for something on accident, or through another another project or through research, right? Because some projects that happen are research focused. And through that research, maybe we found, oh, we do have a need for this next thing. So define that need as the first big step in making an intake process. And it should be an application to a group of people that can approve or discuss that. And I'll talk about who that group of people should be here at the end when we've pulled our process together. Well, now that you've defined the need, we have to initiate the request. And with any request for anything, there has to be an owner.

So the first question when we initiate the request or in this group is who owns it? Who owns this request? Who's going to sponsor it, if you will, right? Projects have sponsors, which is usually a high level type person. But when you're requesting a new something, you don't have to be the highest level person. That depends again, on your organization. In some places, the highest level person wants to always own it. And other places that say, no, I'll back you, but why don't you own it and take it to this board or this approval process or whatever it is. And so first, you need to say when you initiate the request, and there's probably so many templates, right, you could

probably look up project request form, project intake, intake process form, etc. There's templates, but it should be who owns it almost one of the first things who's putting this request in. And next, it should be what is needed. So that goes back to defining the need, which we should already know, right? Because we define a need be there because it's new, improve a process, replace an existing, discover a need for, there's probably more, let me know, right? Check, email me at peopleprocessprogress at gmail.com. It says other stuff, there's plenty of other items we could use to define the need. But so we have an owner, we're saying what is needed. And to the best of our ability, if we really want to put a good request in to help it move forward, just like applying for a grant or a job or whatever, we need to put the work in when we apply.

Even if it's an internal request, can we get an estimated cost? You can look up some products and you'll get either the website cost versus the vendor cost with your organization if you buy this many of things. But either way, you can have an estimate, right? You could say for retail, these new things do this, or we already have a relationship with this vendor that we want to use, or we have other products, and they said they could get it to us for this for this long. And when you estimate the cost, this is key. And we've probably all heard of we think of the one time costs, but we don't consider the ongoing costs or maintenance fees or upgrades. There's hidden costs, right? We't consider the ongoing costs or maintenance fees or upgrades. There's hidden costs, right? We all see the fine print on commercials, it happens for sure, with other

products across the board, particularly in IT. So when you look at the cost, look at the upfront cost to put this thing in, how much does it cost on its own? What are maintenance costs every year? If there are any, what are support costs? What are the ongoing operational costs to the best that you can? And as project managers, we should know some financial stuff. We should know how to make sense of what our capital versus operating is and what categories we should use. But the best resource we can partner with is a finance person. I have been so fortunate to learn so much from our finance people and help kind of provide the environmental factors, the view of the project with them and let them totally help drive how the intricacies of finance work. And it's also

super educational. So try and get the best cost estimate and work with your finance people to help you do it to put together a good package in this part of this intake process. Also, if you're going to talk money, maybe you could find out who could pay for it, right? Because that's going to be a question hopefully from the board that we'll talk about here or the group, whoever's going to help review these is going to ask, okay, it's going to cost that much. What budget is it going to come from? Have you done that research? You can research that again, your finance person knows cost codes know what we charge to who, you know, and I'm thinking of the organization I work for, and I've worked for before, they're pretty mature. So they have a lot of this worked out, not perfect, but a lot of the cost codes are defined, and we know who's who. So

if you're not doing that, if you're a smaller company, or your 1pm shop, you know, think about how you can get references to to know what the different budgets are, what the different cost items are, cost codes, all that kind of stuff, lines of business, whatever you call them. But if you're estimating the cost, figure out who's going to pay for it or who you think should pay for it. Because you could put this proposal in and think, oh, I think it should come out of this bucket. Good proposal gets approved, comes out of another bucket, which whatever, got approved, right? It's going to help. It's going to improve our process. It's going to replace something like we said before.

As part of initiating this request too, so we know who owns it. We're pretty sure we know what's needed. We're estimating this cost. We're going to estimate who or provide who we think could or should pay for it. But what is the desired outcome, right? So that is similar and related to the need. But the need with the costs with who is paying can help say and ultimately, I would like it to change this. Sometimes the write up for these is altruistic, I would like it to change the face of healthcare forever. I would like it to advance technology for the entire world. Like that's pretty grandiose, right? And if it's for your organization, they're not going to see a lot of value in that. I believe the desired outcome

is to improve staff efficiency by 10%, which in turn will save us X number of dollars over this many years, right? That's a desired outcome. It's like a smart objective. Go figure how those are related, right? Foundational five thing. Number two, smart objectives. So what's the desired outcome and spell it out, you know, make it measurable. There's key performance indicators you could put in there early. So again, you're queuing up solutions, not just throw it out there with vague information,

which is less likely to get approved for a project proposal. Just like if you're an emergency management or public safety, if you write up a grant that's super vague, that's not tied to the monies you're asking for, you're not going to get approved for it. So grant writing is a thing. And that's another good, if you know somebody that writes grants, learning how they write can help you build or improve the intake process that you have for your project management stuff. So what's the desired outcome?

What's the priority? And why is it that priority? And this is where we, and then in particular, whatever board or entity is going to review this, needs to be super objective in their writing, in their review, and in their discussion, and not not shy away. And I've seen it and you all have probably seen it. If you've been in a meeting where different people or groups are vying for different pockets of money, it's like watching a debate on TV and politics, right? You'll get some answers. You might get all the answer. You might get some of the totally objective, but it's not 100%. Unless you have folks and leaders that drive folks to say, no, no, no, we don't want a sugarcoated desired outcome or priority of it. We want to know why this is going to improve the life safety of people

that we see if we're in healthcare, or we want to know why this is more important than the other two projects we just heard that are vying for the same technology upgrade, know why this is more important than the other two projects we just heard that are vying for the same technology upgrade and why this should be number one on the list. And this is where you're going to get into the leaders, rightfully so, that have the approval authority for money, for projects, for whatever threshold, really having frank discussions, which is fantastic, right? Here's why this one's more important than that one. And it's not because I'm more popular. And it's not because I have more money, or I'm a VP, and you're a director or whatever. It's because

it's the right thing to do for the organization. And this prioritization, as part of an intake process is probably one of the hardest components, because you should keep it really real, right? It has to be real because you don't want to waste time or money or resources on something that seems really cool, but it's not going to help the organization as much. Now, does that mean there's some stuff that's going to go through that maybe is low hanging fruit as they say, right? It's easy to do and it will raise morale. Yes, absolutely. Versus the thing that's going to take a year and it's going to cost a lot more. Absolutely. But this prioritization, which again, behind this is if you have a governance model or you have an intake process, if you have an approval group, whatever you call it, you should know there's priorities that should be pretty

objective too, right? With some, maybe some of those factors, like I mentioned, is it regulatory? I'm in healthcare. So these are big. Is it regulatory? Is it, is it safety related? Is it a required thing? Is it, you know, whatever. And you can imagine in whatever space you're in that you work in or industry, how you would prioritize projects and programs and efforts against themselves, you know, that could have an impact that are that are real priorities, right? And last, what is really helpful in anything, and whether it's one request to do a change in the system, or it's like this, let's say a multimillion dollar request for a project, what is your estimated level of effort? The good thing is, if we've defined the need pretty well, if we know who owns it, what's needed the estimated cost, who we think should pay for it, what the? And costs. And so the level of effort, you know,

how long will it take? However many resources to get this done for each area of it. Another great resource, like we mentioned before, is do you have a lessons learned repository for a similar project that you did months ago, years ago, right? You, those are really, this is where those, those project artifacts that you should archive after each effort or for a whole program really come into play because you could say, well, we did a similar effort with a different kind of software or a different process improvement, but very similar structure. And it was this many hours, this seems like it's a little bigger, here's a right. And so the other level of effort that you want to do that I like to do is contingency plan. Now, not everybody likes to hear that it's not

going to be a sunny day, and everything's going to be on time and on budget, but that's reality. So a good thing of contingency planning is so if we're at 100% funded, we get all the time we need, we get all the people we need, we get all the people we need, we believe this could take this long. If we don't have all the money, we go 75%, 50, 25, however low you want to go. At some point, you know, if you're between 25 and 50%, right, and it's not really going to provide value, then that that could be a trigger point for well, just do we even need to put the request in, but it'd be good to have a couple options, right? Your primary, this is the best outcome that could happen with full funding, full time.

And then, okay, if we didn't do this kind of premium level or whatever, then this is what we would get from it, but it would still be good. So the second component, we've defined the need, we've initiated the request. And with this initiation, who owns it? What is needed? What's the estimated cost? Who do we think should pay for it? What is our desired outcome for all of this? What is the priority and objective discussion, right? It within this, as we look at the organization, and then what do we think the level of effort is for all of it to help us make this change that we want to make? So what's left to do with this request as part of our intake process that starts all of this project work or whatever effort even if it's not a full project well we have to approve the requests

so this is where we get into the group the team the board council i've heard all these different terms it's but who are the people that are together going to look at all these that are inputted and say this one's number one this's number two, we're not doing that one, we're definitely doing this one, who's going to approve it, right? The first thing that I think should happen every single time is, is the request complete? Right? Just like if you apply for grant money, if you apply for a job, if you put forth any sort of documentation, think of the DMV, right? Great example, if you give them incomplete work of documentation, think of the DMV, right? Great example. If you give them incomplete work, they're going to give it back to you. They're going to

tell you to complete it the right way. You'll get back in line. And I think the same exact thing should happen with a weak project proposal, right? And that's just true because you're wasting time, right? I think we should do this. No, I didn't really look up that money. I have no idea about this. Well, then if you don't know enough to put in what we talked about earlier or similar, right? Not have to be exactly the components I mentioned, but if you put an incomplete request in, why would this group of people who are taking their time to review things approve it? Right? I wouldn't. I wouldn't suggest that you or your organization do either. If you're getting incomplete requests, having said

that, help educate the person on why it's incomplete. So you have to have standards on what that means. Is it just filling out every single line and checking the box for the right category on whatever template you use? Yes. But also give the feedback on how they wrote it, right? So what if it's part of the narrative thing on what's the desired outcome or what you know, what is needed and you're really defining the need. There's some, some writing there that's more than just numbers. It's more than just hours. It's more than just how many people do we need? Those kinds of things. So help, help give that constructive feedback on maybe why a request wasn't approved and that will help make it better. And that'll, you know, hopefully proliferate throughout the whole organization. Who then should and can approve requests, right?

So let's say we got the complete requests. Good to go. We got a stack of them. We have them in online forms, whatever intake process you have. Probably hard to manage them via email. I don't suggest that. I've seen some great online forms, so many different things, whether you use Google Docs or you're a SharePoint project online shop or JIRA or whatever, but some kind of intake process.

So who could approve those? So just like I mentioned earlier, and you all that are project managers or even folks, you know, there's going to be a high level sponsor, right? Whether that's you're in public safety, a chief, a major, somebody else similar in the military. If you're in the civilian world, probably at least a director, somebody else similar in the military. If you're in the civilian world, probably at least a director, VP, and on up the C-suite, right, on who can approve. But it should be a group, my thought, in this team, council, board, whatever, intake, group, team, you know,

whatever. It should be high-level person for sure that has, you know, whatever, it should be high level person for sure, that has, you know, influence, maybe a C suite person or VP, because what they can do, if there's maybe a controversial or challenging or really expensive things, they can champion it. And each project should have that they should have it, you know, a champion and sponsor to speak for it. But you do at times need someone that has position, right? They can also give you the strategic perspective of the organization that maybe other folks in the group don't have. We've got an executive, a C-suite person, so they can have that influence. Could be more than one, right? Depending on what's the scope of this board, of this council, of this team, right? Is it for the entire organization? So you need someone that covers business areas,

that covers them in healthcare clinical areas, that covers something else, regulatory things. I think this is where that internal discussion in whatever organization you're in comes into play to decide what's a good balance of high-level leadership, of their time, of their focus, is there concern? And that's all internal discussion. There, a lot of good references out there to if you kind of look at developing an intake process or a governance council or a board or whatever you want to call it. But there needs

to be someone that's high level, then there needs to be someone at the next level, like a director or senior manager, those kind of folks that have a little bit more of a pulse on what's happening with the people, right, and also have so they're kind kind of, let's say if your C-suite looking at these intake projects is 30,000 feet, then your directors and managers are looking at maybe 10 to 15,000 feet, roughly, right? Still pretty good altitude, but they can give a little more perspective on what their teams directly are doing and how this project may actually help them or improve those processes. Then I think you have to find a balance of boots on the ground perspective,

whether you get that through your managers and directors, whether you have a couple folks that are line workers that sit in on these projects, right? Because there is proposals and things where you don't want everybody to know about it. So there's a trust factor there. But how is she going to get that perspective on how it's really going to affect, you know, John Doe's team, versus Jane Doe's team, if we do these

changes, that's from the folks that are out there doing the work. So that's kind of the balance. So you definitely need high level leaders, mid to higher level leaders as well, that have a good pulse and have approval authority, right? So they'll be part of this team, and they have perspective, and they make approvals, and they have a good sense of leading hopefully all the time, not just with this council. And then you need to get that perspective loop from the folks on the ground. That's pretty critical. I would also absolutely include the project management office, someone from there. And just like on episode 92, the successful project manager with Donna Gregorio, maybe as part of the PMO or an augment,

like the PMO director, manager, program manager, a business analyst, right? They can help pull these proposals together, help review them. That's kind of how their mindset, their skillset works, is looking at different requirements and what one company can do versus the other. And they can then be leveraged when we get to the next step for the approved projects to help pull together proposals and bids and RFPs, requests for a proposal, or it could just be an RFI, a request for information, whatever that is. But having those business analysts looped in early, maybe even managing the queue of requests can make a big difference in helping all the other leaders make decisions and weigh the options. So how often will we review these requests, right? Is it

monthly, bi-weekly? Probably depends on the tempo of things that you're getting. But again, if you have a project, this one-time endeavor, then it's going to improve something, replace something. We know who owns it. We're looking at these. Well, they're going to start as we start to approve them and move them forward, kind of stack up. And then if we don't have a whole bunch of PMs or folks to lead them, then they'll start to get backlogged. So you've got to get that balance of, you know, I think a monthly, at least every couple months to review and prioritize. Because remember, just because we review it and approve it doesn't mean it's going to start tomorrow. Right? So, and it depends on who can put a project request into your organization, which I think should be part of your overall model of intake is can I line worker put one in,

can manager put it in a director? What level is that? Or can anyone put a project request in, but it has to go to their leader before it gets submitted, right? Because maybe the leader knows something or knows, Oh, no, we're already planning to fix this or resolve that. And it just helps filter out. It's not keeping secrets. It just helps not have 1000 requests in for, you know, 200 things that we're actually going to do, because we've, you know, we either don't have budget, or we've already got solutions, maybe in place for those other things. So need to determine and balance that out. And I don't have a magic answer for that. That's really, again, thinking about how many requests do we get, how often, and how many resources can we apply to those for the ones that we think we would approve requests, and

then kind of balance out how often we're going to review them. Or just again, communicating, we're going to review these monthly, we're going to prioritize them, but letting everyone know that puts a request in so that you don't start getting hammered with where's my request, it's approved, we should start, we should start, that we're not going to start them right away, right when it gets approved, because there's 20 projects ahead of it, or 10, or five, or whatever. So that's something very much to consider is, again, how often are we going to review these things? So the last thing I thought of is how are your project managers assigned, right? So we've defined the need, we've initiated the request with a good, you know, complete requests. We know who's going to approve it, we're reviewing it in whatever frequency.

So how are we going to assign project managers to these projects? Do we have project managers that work in whatever area of the business? Do we have some folks that work on finance projects only, technology projects only, clinical projects only? How does that go? Do we have kind of a bullpen of all hazards, if you will, all project type PMs? Again, that's an organizational decision. I've seen it all different ways. What I would submit for my two cents, which is free, just like the cost of this podcast, is that the PM be assigned pretty early so that they can get a better understanding of what's going to happen. And this is something I've seen recently, which

is really cool, is you actually can charter a project pretty early with some of the basic information that's in the request. get that PM working on it. Because for me as a project manager, when I come into a project that's already been handled maybe by the leaders in the PMO or someone else in the organization, it's a little harder to get up to speed than if you're brought in early and you know the background right away. Maybe you help bring it into or work with the request for a proposal or for information with those business analysts. Then you have all the background. You're better leveraged from start to finish.

And you're not coming in and missing a lot of the background of it and a lot of the handoff information. If something happens, you don't get a good handoff. So another thing to consider as part of this kind of routine of reviewing all these intake processes. So to me, the intake process is critical. If we don't capture this information up front to the best that we can, because we're not going to have all the info. And even when we start the project, we're not going to have all the info and we'll have different info three months in that we will six months in that we will when we're done.

But we can set our organization, ourselves, our project team members that we're going to pull together up for success, save time, save money, and help be prosperous if we really get this intake process the best that we can, and then hone it along the way. So just like we're going to learn from our projects themselves, we should learn and apply lessons learned to our intake process. So let's say we churn through 2030, whatever, you know, intakes or reviews of proposals. Let's go back and say, okay, what worked well, what didn't work well, is our objective prioritization working, or is it not right? And just all these different components, however you you put that together. So I thank you so much for checking out this episode 93 of It All Starts with the Intake Process. I really believe that it's a critical component to success and just having a kind of a more stable project kicking it off.

I hope things are stable out there for you all. I appreciate your listenership for you sharing this show. Please give it a rating on Apple, Spotify, wherever you listen to this. Check out PeopleProcessprogress.com, People Process Progress on Facebook and Instagram. Stay safe out there, everyone. Wash your hands and Godspeed.