Project Management Central

Please login or join to subscribe to this thread

Topics: Business Case, IT Project Management, PMO
Project Intake
Network:1762



Anyone have insights into the process of Project Intake / Idea Management and any related templates you can share?

Want to give all ideas equal ‘starting’ chance to be heard, but need to incorporate a way to evaluate the ideas and determine which should be considered for potentially becoming projects vs. which should be considered rejected/not at this time. (This could be IT or cross functional ideas.)

And then to complete the process, steps for additional vetting of valid ideas until they are eventually authorized as projects.
Sort By:
Page: 1 2 next>
Network:8



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.
...
2 replies by Krista McCord and Sophia Gagakuma
Aug 22, 2017 1:54 PM
Krista McCord
...
Isaac - what information are you requesting on your intake form?
Aug 14, 2019 3:30 PM
Sophia Gagakuma
...
Great question. What is on your intake form?
Network:4046



This is something I have implemented successfully.

I have set up a Project Request process which all the Heads of Departments (Business Leads / Business Process owner), have to request, based on a PGIO concept - Problem, Gap, Idea, Opportnity. They make the initial business case highlighting the business benefits, and the potential losses if no change is made.

This comes into the PMO under the Initiatives Portfolio, where initial analysis in coordination with the Business Lead are conducted. If it clears the first level of analysis, it goes into the Initiatives Portfolio where the PMO and business analysts conduct a full spectrum analysis, look at internal and external solution, cost impacts, and prepare the initial business case, feasibility analysis. PMO analysis the results with the Business Lead. The GPIO request is compared with the results available. Should the feasibility analysis and business case, show a positive outcome, it is then moved into the Proposal Stage, and put forth to the Executive Board for approval.

Executive Board, assess the proposal and liaise with the PMO through series of Questions or presentation to prove the Criteria to acheive the defined Deliverables, Cost analysis, Portfolio priority, Business Impact analysis (to indicate changes required on other business processes, and any financial impact from these changes are part of the proposed project), Resource Planning etc.

PMO provides the Executive board all the required information and PMO's "opinion" for the Project Intake/Go Ahead. The executive board then makes a decision and depending on the area of business impact, the responsbile Executive board member, takes the lead function of Sponsor and performs a critical top to down analysis, before recommending Go Ahead / Re-Assess / Reject the proposal.

Go Ahead - Project Initiation Stage kicks in. PMO forms Initial PMO Project Management Team, allocated Project Manager and the downstream team.

Re-Assess - PMO assesses the Recommendations made by board for reassessment and restarts from the Analysis phase.

Reject - PMO critically studies the Rejection reasons and in collaboration with Business Lead, analysis the impact of not making the change due to the Rejection. At times, the rejection comes with alternative recommendations, which are analysed as a Idea/Opportunity. SOmetimes, these rejected initiatives are resubmitted after taking into account the recommendations and running the feasibility - business case again.

The Project Intake of approved projects again go into the portfolio pipeline and the priority is set by various indices from the Exec Board, Business Lead, Resource Availability, Project Complexity, Project IMpact etc.

Hope this helps
...
1 reply by Isaac Brown
Jan 10, 2017 7:06 PM
Isaac Brown
...
This is excellent. One question - assuming the project is approved, does it then get sorted into a portfolio, or some broad grouping of projects based on its initial PGIO concept?
Network:8



Dec 31, 2016 5:31 PM
Replying to Chanu Rajagopala
...
This is something I have implemented successfully.

I have set up a Project Request process which all the Heads of Departments (Business Leads / Business Process owner), have to request, based on a PGIO concept - Problem, Gap, Idea, Opportnity. They make the initial business case highlighting the business benefits, and the potential losses if no change is made.

This comes into the PMO under the Initiatives Portfolio, where initial analysis in coordination with the Business Lead are conducted. If it clears the first level of analysis, it goes into the Initiatives Portfolio where the PMO and business analysts conduct a full spectrum analysis, look at internal and external solution, cost impacts, and prepare the initial business case, feasibility analysis. PMO analysis the results with the Business Lead. The GPIO request is compared with the results available. Should the feasibility analysis and business case, show a positive outcome, it is then moved into the Proposal Stage, and put forth to the Executive Board for approval.

Executive Board, assess the proposal and liaise with the PMO through series of Questions or presentation to prove the Criteria to acheive the defined Deliverables, Cost analysis, Portfolio priority, Business Impact analysis (to indicate changes required on other business processes, and any financial impact from these changes are part of the proposed project), Resource Planning etc.

PMO provides the Executive board all the required information and PMO's "opinion" for the Project Intake/Go Ahead. The executive board then makes a decision and depending on the area of business impact, the responsbile Executive board member, takes the lead function of Sponsor and performs a critical top to down analysis, before recommending Go Ahead / Re-Assess / Reject the proposal.

Go Ahead - Project Initiation Stage kicks in. PMO forms Initial PMO Project Management Team, allocated Project Manager and the downstream team.

Re-Assess - PMO assesses the Recommendations made by board for reassessment and restarts from the Analysis phase.

Reject - PMO critically studies the Rejection reasons and in collaboration with Business Lead, analysis the impact of not making the change due to the Rejection. At times, the rejection comes with alternative recommendations, which are analysed as a Idea/Opportunity. SOmetimes, these rejected initiatives are resubmitted after taking into account the recommendations and running the feasibility - business case again.

The Project Intake of approved projects again go into the portfolio pipeline and the priority is set by various indices from the Exec Board, Business Lead, Resource Availability, Project Complexity, Project IMpact etc.

Hope this helps
This is excellent. One question - assuming the project is approved, does it then get sorted into a portfolio, or some broad grouping of projects based on its initial PGIO concept?
Network:102077



I have often seen companies use a ticketing tool, Samuel. It is often sufficient to capture and evaluate ideas. Once they are approved, it is simple for the ticket to become a work request.
Network:303



Dec 28, 2016 5:47 PM
Replying to Isaac Brown
...
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.
Isaac - what information are you requesting on your intake form?
Network:607



1. Intake form is filled out by the requestor. It contains, the objective, problem statement, why we need the change, its benefits and cost/schedule assumptions.
2. First level of lead discussion happens with key stakeholders. Initial Analysis will entail a rough cost, and schedule estimate.
3. For us, there are different levels of approval processes. change less than 250K is internal approvals, 250K goes to Regional approvals, 500K goes to Regional, Central boards plus CAB.
Once it gets approved as a project, it goes through regular PM'ing process.
Network:0
I in the process of implementing the better project intake process. Can anyone help me with a standard templates that i can use.
Network:7609



wow, a lot of the inputs here.
Network:1568



Coming in almost a year late on this discussion, but I am a fan of a progressive funding disbursement approach.

All ideas get one hour's worth of funding. 10% of those get a day's worth of funding. 10% of what remains get a sprint's worth of funding... and so on...

Kiron
Network:36



Interesting idea Kiron, and not one I've seen used..

The biggest issues I've encountered have been corporate budgetary models and capital funding of projects. Intake comes into a big bucket and results in a bun fight over which are most important.

Small projects aren't an issue with opex funding and a capital fund to cover a budget cycle.

But larger projects need an intake process that reaches to the top of the organisation to ensure alignment with corporate drivers, and also make competing requests visible across business areas.

Paul
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Maybe this world is another planet's hell."

- Aldous Huxley

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events