In this episode of the Project Management Paradise Podcast, we speak to Jeff Kissinger, a Senior Project Manager at Grand Rapids Community College in Michigan.
Jeff has over 25 years experience in Project Management and today we are going to discuss Project Prioritization.
Subscribe to Project Management Paradise via one of the links above and you’ll automatically receive new episodes directly to your device.
Can you give our listeners a brief background?
I’m a senior project manager in the information technology department at Grand Rapids Community College, Grand Rapids, Michigan. I have over 17 years of experience in managing information technology projects at academic and commercial organizations. Also, I have over 25 years of experience as a volunteer, managing projects at non-profit organizations. I am PMP certified, I am certified as a flow trainer and professional and I have a bachelor’s and communication studies from University of Nevada, Las Vegas, master certificate in SAT project management from Villanova University. Most recently I graduated from project management to leadership master class 2017. I live in Jenison, Michigan with my wife and two daughters.
In your own terms or in your own language, if you will, how do you define project prioritization?
There are basically two parts to it, there is defining which projects to work on and then once you determine which projects you’ll work on, what order you are going to work on to complete those projects. And it gets back to what’s the vision of the organization, why do we what we do and since projects are about change, what changes do we need to make to the organization and whatever aspect that may be to accomplish that vision.
Are there other reasons why it is important?
Take a look at the project that is prioritized low, if somebody requests something and it doesn’t get it automatically. You go and take the time to work on that project, you spend the resources, both financial and human, and you take away from more important things. As a result, if it’s a low priority, and we take the time and the effort. Then, once the project is done, the operational costs and support for it, which take away from more future projects. It’s a waste of time, it’s a waste of effort, it’s a waste of money and it’s a drain on your organization. So, we prioritize, we first look to the vision of the organization, so what do we do, why do we do it, and which projects are going to best allow us to accomplish the vision of our organization, what’s going to help us meet our objectives or goals to do our mission which helps us achieve that vision.
If a decision-maker, the most senior person in an organization comes in and says “Drop everything, this is the project.” how do we deal with that and kind of feedback to them or almost push back to them and say “Look we’ve got a process here where we prioritize” or do we have to drop everything and go?
That’s a good question. And how we do things at Grand Rapids Community College is that the projects, in the end, are which ones we choose to do, are prioritized at the highest levels of the organization. Four vice presidents or the president of the college make the final decision about what projects we will do each year. If they come in with one that just comes out today and decides to take it, when it happens it’s typically something that was regulatory. For example, the Federal Government of the United States said “Hey everybody’s got to do this now.” and they say “Ok, we got to do this.” and then we’ll take a look at “Ok, we have these projects that we are already doing. Which one can come out and what we’re going to replace it with this one that has to be?” But it rarely happens. Since we’ve been doing project prioritization the way we do it, I think we may have had one or two of those instances where something came alarmed, where we had to re-adjust because we just had to. But it wasn’t because somebody wanted to.
In Grand Rapids Community College, how did you develop your project prioritization system?
There is a bit of history behind it. Back, before August 2011, project request in prioritization was just, it was all over the place. People would request things from the IT department; napkins, in person, over lunch, they would send emails, they would write things down, put it in the office mail, they would just walk into somebody’s office and ask for it and they were just all over the place. So, really, there was no idea of what was being worked on nor there was a system. There was a system in place to record some of this but not all those projects that were being worked on or in the system.
A project management office was established in August 2011 and the director of the project management office at the time, she went about trying to figure out where all these pieces of projects. We had 148 projects, either in progress or that were requested for Community College, the IT projects. That’s an astronomical amount, most of which had nothing to do with the overall vision at the college. They’re more pet projects or something to make one person’s life better or making three other people have to support it. It was chaotic, so, the first thing we did was that we eliminated as many of those product requests as we could, completed the ones that were in progress if we already committed to it. And then, we just tried to do a request process. Now in the early attempts of prioritization, several things went wrong. The process that was created was complicated and had a long-form, it had lots of different workflow passes that have to happen, this person and that person had to be reviewed, there was not a lot of the connectivity, the feasibility process was even disconnected. The information of the project would go to an IT director and then they would pass it to another IT director and they would pass it off and it would take forever to get information back. By the time we got the information back, it was already stale. There were too many people, too many of the wrong people actually, and at the product prioritization community, there were probably 15 or 16 people. Most of them were middle managers, maybe a dean at the most, but nobody from the executive level. There were too many executive overrides as a result because people making the decisions weren’t the executive so if an executive wanted to do something different, they just said: “Ok, I’m overruling you, we’re going to do it this way.”. So, there was no attention paid to the actual capacity, so every time somebody made a project request, then they go through a review everything and reprioritized everything again. There was just these constant requests cycle, with constant review cycle and people on the prioritization community became very displeased with that. Therefore, there were too many projects. I was working on these projects, I could complete a lot of projects but I was always under the water because there’s always more request coming. And again many of those requests were being used by one person or another that didn’t necessarily have the whole college in mind, at least the vision of the school in mind. In 2014 there was a reorganization, the PMO director was put into another position and the chief information officer came to us and just said: “How would you re-do this?”. So, this is what we did, we made up a process, there were eight sub-processes, there was a project request process and it’s aligned with our budget request. So, the budgets for everybody at the school fall between November and February where they have to determine what their budget is going to be and how they are going to rationalize it. It has to be approved in February before the fiscal year starts on July 1st. So, our request process aligns with this budgeting cycle, so if you want a project and you get the money, you’ve already planned for it by putting it in your budget. And this aligns with the community schedules and the IT directors, the deans and executive team meeting, so it’s all aligned. Again, that ties back to the importance of vision and all this because if what we are going to do is going to involve money, it’s going to involve resources and all these people then they’re going to tie it to the budget for the project and the changes that come with it, or going to be tied to it, as well. That was received pretty well. The next thing was the request. Instead of having this long workflow form that went from place to place, we had a simple web form. It asked a few questions and as soon as we receive that form, I think of five questions, PMO project managers respond to the request within one business day, set up an appointment to do project research. And the research is the face-to-face interview with the project requester. We bring subject matter experts to the interview, the project managers encouraged to talk to their project requestor. My role is that if I can talk you out of it, it is not important. If it’s not that important, we shouldn’t be doing it.
In the project request piece do you have to, the person who is doing the request, do you have to say where this fits in with the college vision?
Oh yeah, the first question we ask is how it aligns with our vision and how we do our actual selection. Everything gets back to the vision, not only of the college but of the department, of the team that’s going to work on it and the individuals. They all have to align as much as possible in order to reduce the amount of friction or anti-flow that goes throughout the organization. So, the next thing is we compile the research and we send it back to the requester for the approval. The requestor signs off on it then it goes onto the next stage which is the feasibility stage. The feasibility meaning the project request research information sent all to our IT directors. They get it all at once and they have to review it responsibly a week ahead of time. Then we have time during a weekly directors meeting. In the first half hour, we take out the request, we’ll do three a week typically and sometimes we will schedule an extra meeting if we are getting a lot of requests. The IT directors will go through and look at what they need to do in order to accomplish this project because they have already taken this information of their teams to get the feedback they need, so they can address it amongst all the other IT directors at one meeting. And the IT directors can kill a project request during these meetings. In fact, every step along the way anybody can kill a project request, kill them while they’re young. There’s a guy who wrote a really good seminar on this, his name is Dr. James Brown. He talks about killing products while they are young because if you get a bad project and you start working on a bad project, it’s a waste and has effects that to be long reaching. After we have the feasibility meetings, then we write an executive summary for it. We take all the research and feasibility information, we summarize it into a one-page document and now requests can get prioritized. We use Microsoft Project online. I’m not a big fan of Project but one thing they have that is really good, is their portfolio analysis. We attach all the requests information, the project record and then once we have all these requests, we inform the CIO that there are some requests for them to prioritize. Then we have a scoring rubric, you asked earlier about vision and how everything relates, the rubric was developed and tested and signed off at the highest level. The executives, the four vice presidents, and the president all signed off on this rubric. They all agree to it, so we defined what a priority is and we all agree and what makes it a priority. Here are the 8 scoring categories.
The first one and weighted the heaviest, is a line of GRCC’s vision, mission, values. The second category, and as I go through these the higher up it is the highest weighted, so the next one is regulatory compliance. The next one is the ability to support the project deliverables, do we have it within the IT department to support it, it could be a great idea, could be something that’s considered free but end up being free like a puppy because the support for it is just crazy, it spends a lot of time, it spends money, after the fact to figure out how to keep something going. So we look if the ability to support the project deliverables is it something that is going to be a burden. The next one is the barrier removal, what kind of barrier does it remove, accessibility barriers, barriers that help take down other barriers to help students get into a school because we are the educational institution, we want to teach people, we want to give them an education. Will this project help remove barriers? Next thing that we look is that is all the effect of enrolment and revenue. Is this going to bring revenue up, is it going to bring enrolment up or is it going to bring it down? We scored accordingly and if there’s really nothing it’s going to do, it just doesn’t get a lot of weight. But if it does affect enrolment and revenue in a positive way, it gets more weight. Then the effect on the cost reduction, is it going to bring the cost down, are we going to save money by implementing this project, is it going to cost us money, positive net value, what’s the value after it’s implemented over time, what do we expect it to be with value analysis. Then finally the impact on the project and support resources, how is this project going to affect other projects, currently and in the future, is it something that’s gonna be in the way. If it becomes a support burden, it takes away from our project resources so much that we have to borrow throughout the organization. Then the CIO gets it, he scores all this, and what he does is he reviews requests and scores using this rubric. It’s all built in the Microsoft Project so he just goes through and scores them and it accumulates all this information and we run a report and we consider just top 20 requests. So, out of 20, it’s the top 15 actually that when they are all scored he’ll take those and then he will put 5 in reserve and anything below that is we’re not gonna do it. He takes that information, he brings it to the executives, to the other three vice presidents because he’s the vice-president. Three other VPs and then the president. Usually about 90% of the information he brings for, they all agree to, and there’s a basically a cage match over the last ten percent or someone will say “Well, you know, this one is down below 20 and all, this is really important to me.” but the others have to agree to it. They all get one executive override at that point. When one says “I want to use my override on his project to take the low priority but I want to make it a higher priority.” then sings got to come out of the mix because we are not going to do 21 or we are going to do 20 at the most, 15 for sure, 5 in the reserve, anything below we are not going to do. That’s the negotiation.
Essentially, the container that we provide to fit all these projects and the time to do it, the effort and the money are only so much and we cannot do more unless you are going to pay for more resources.
In terms of how the college is running now, based on this comprehensive process, can you give our listeners, maybe one or two things that are tangible, that you can actually see now as a result of the process?
First of all, the projects are easier to track, easier to know what’s being done, easier when we report on our projects from week to week to the CIO, they are easier to understand. There are fewer of them. We complete the projects within the timeframe so they are more likely to be completed on time, on the budget, on the scope. Sometimes they’re not because some things may occur because not everything is going to be perfect. But it’s a manageable amount of projects and the people that are assigned to them and it’s also the right projects. I can’t tell you how often we had the wrong projects based on the way we did things before, but now we are doing the right project. And everybody agrees that they are the correct projects, especially at the executive level. Not everybody is happy with the projects that are approved in the lower levels because some people wanted something that they wanted, but it may not have been good for somebody else that’s why we discussed it at the highest levels. If there are any comments, people have they run it up through the various bosses and so it gets to that level and they can make their voices heard. We have even added a new step in, to take it to our Dean’s Council. This is one step below the executive level and we show it all of them and they go through and discuss it. It’s not a requirement that they approved but it’s politically a smart move to do. We had, maybe, like I have said, two executive overrides since we started doing this in 2014 and they were smart moves because we didn’t see them coming because they were issues. I think one of them was the Federal matter and the other one was just something that the timing for was really good and we took out one of the projects maybe even two projects we had approved in order to make room for this one. It’s made for a much more efficient process, better work, better use of resources, better use of time, risk have gone down and opportunities have gone up, the quality of the projects are better, the time we can spend working on them is better. Then we also created another category for smaller things, like monitor projects and ticket level things because a project is a unique product service or result. The ones that we are talking about the ones that involve project management or project managers, multiple groups, lots of money involved typically or something when it’s all completed is going to have a very distinctive effect on the college and what we do in terms of IT.
Can you share with our listeners a little bit about the book?
Sure, it’s not my book but the book is called “Flow: Get Everyone Moving in the Right Direction…And Loving It” by Ted Kallman and Andrew Kallman. It’s a book that’s available on Amazon. It just came out and the model that they use is called a unified vision framework or the flow model is how we designed the project prioritization process around vision in the middle.
It has people, tools, and techniques and it has the importance of getting an agreement. Then driving things on them, delivering on the project and driving things forward and keeping in mind the vision of what we’re trying to accomplish, not just at the project level but at the team level, at the individual, all the way up to the department and to the top of the organization. Working way down so we can make it easier to understand why we’re doing this and be able to find out when there are issues with the projects, we can be able to quickly identify and diagnose what the issues are, so we can get rid of the things that get in the way of delivering the project.
The book has a lot of good tips and how to do that.
Show Notes
Connect with Jeff on LinkedIn here.
