When working with the various departments and business units, how do you decide which projects take priority for the year for the company overall?
Hello Kelly. I work for a mid size non-profit organization that has limited tech resources. We have 5 business units in multiple states. Our requests for change from across the agency always exceeds our technology resources. It has been that way for the 19 years I have worked here. Over that time I have implemented some best practices from ITIL and Agile that help manage a lot of that.
One of the processes we have in place is an ITIL Change Advisory Board (CAB). It is made of high level members of the organization that take a look at big projects and weigh the feasibility and value to the organization. Here is a link to a starter version of that process. https://itsm.tools/how-to-adopt-a-light-version-of-itils-change-advisory-board/
We make sure these priority decisions are made by a management team, including our IT leaders. This way the business leaders all share in the decision making process.
Within the first six months of coming on board with the AAFP back in early 2016, I definitely saw there was a vacuum in prioritizing work. I helped the organization and leadership team stand up a Technology Steering Committee that represented each segment in the organization. IT resources were also included on the committee, but were not voting members. This would require the organization to take ownership of what initiatives or efforts were more important than others. It has been in place for three years now and the backlog of requests have went from 550+ down to a more manageable 50 or so at any given time. Once the organization had a process for prioritizing and they were accountable to those decisions, clarity and focus was achieved.
We utilize an IT Steering committee which is comprised of executive level (VP and above) and our PMO to review strategic projects as well as tactical projects. This committee determines priority and negotiates whether or not a project in flight might get put on hold to accommodate a new proposed project of greater value.
I've seen various solutions which include pure ROI, simple business cases that align with company/entity strategy, and business cases that have various drivers. Drivers can be alignment to company or department goals/initiatives, ROI, architecture alignment, technical debt reduction, compliance, etc. I'm more in favor of the last one that have drivers that are decided ahead of time on what's most important to valuing your portfolio. Typically we had 4 to 6 of these drivers with a weighting and a simple scoring system like 1 to 5 with descriptions of each.
At the end of the day we still had some type of leadership steering committees that reviewed them and had the ability to adjust the final priorities. The hardest part of that is keeping them engaged as attendance would start to wane over time.
One other thing that might be obvious is we didn't allow for priorities to change for in flight projects. If that was needed, we did a separate impact analysis that was presented to leadership.
At Kansas City Southern, in our project request process, we force a selection as to the business value and alignment to enterprise strategy points. For example, one of the selections is "operating a safe railroad" or support a new regulatory requirement, so projects that support that vision will kind of rise to the top of the list. While a project that only has a "soft dollar" cost reduction may not get done. Those projects over a threshold set by finance will have a formal business case created. Using the strategy alignment does narrow it down. Then come the hard conversations with the business units to show them where their project request falls and why. Eventually the projects that get funded are approved by generally the VP level, so they can also see what will not get done.
Historically we have had our users prioritize their backlogs within their business divisions and bring them forward. We then had a show and share and prioritization across the enterprise. However, we are currently working to better understand the WSJF (Weighted Shortest Job First) through the SAFe framework to see if that can help us with value based prioritization. We are still learning.