...
I go into some detail, below, so I'll put my summary here instead of at the end. For the project requests that come in from employees of the company I work for, we have the following things in place to manage them:
- An intake form that everyone is expected to use. This helps to control the flow of project requests, and automatically creates a record of the request, who placed it, and basic information about the potential project.
- Project thresholds that help us to determine if the request should go through the project intake process, or could be handled as a "service request."
- A ranking process based on alignment with company goals. The idea being that projects which have a stronger alignment to our company's goals would be considered ahead of those that are only somewhat aligned. Project requests with no alignment are parked (i.e. the request is a good idea, but it's just not the right time for it) or rejected.
I can only speak to the practices I have worked to put in place at the company where I work. The first step we take in evaluating a request is to determine if it meets certain thresholds to be considered a project. There are four major thresholds that are time, cost, required resources, and impact on the organization. If a request meets or exceeds the threshold on any of these, it is considered a project. For example, if a request can be completed by one person, in eight hours, affects only a handful of users, and does not carry an external cost, we consider that a service request, not a project. Those requests go through a different process.
If all requests that meet the threshold to be considered a project start out on a level playing field, then one way to evaluate them would be to rank them according to how well they align with company objectives. I'm working on something like this for the company I work for, which has historically struggled with prioritizing projects. The idea is a project is weighed against each of the company's objectives for the year. Each objective has a score based on whether the project is not aligned, somewhat aligned, or strongly aligned. This produces an alignment score that can be represented as a raw number or a percentage. In either case, the bigger the number, the stronger the alignment, the more likely the project is to bring value to the organization. Value may be dollars, but might also be intangibles like risk avoidance or process improvement.
In all cases projects must have a sponsor, and they must have completed a business case and requirements document. Both of which are components of the project charter, and become inputs to the overall project plan. These are ultimately presented to a project steering committee that reviews the project documents, relative alignment to the company's objectives, and weighs the project against a number of other factors before determining if the project is approved.
