One of the actions you can take to professionalize the way your organization handles projects, is to organize its start. Project request identification and ranking is one of the key activities you’ll need to set up. TenForce Project Portfolio Request management automates and supports this process in a pragmatic way.

A request does not exist until it is identified

Like ticket numbers on a support desk or bug entries in your bug database, projects requests need to be identified. As with so many of the moving parts of an organization, it is crucial to identify each request and the status it is in. Once you’ve accomplished that, set up a workflow and a process to move requests through the organization.

During the identification of the project, a number of attributes need to be captured to characterize the request. One such attribute is the project type – we’ll come back to the relevance of attributes in a later post. In the image below, you can see an example of how different types of project requests are distributed.

More than just projects

It may be quite easy to convince your organization you need a workflow to identify, review and approve/reject new projects. However, changes to existing applications, software, processes or anything else also needs to go through this cycle.

Make sure a new project is not split up in several change requests and in this way bypasses the project approval cycle. Therefore set the minimum effort required to enter the approval cycle sufficiently low. We have seen big organizations set it as low as 10 mandays.

Identify portfolio’s

New projects and change requests need to be part of a portfolio. A portfolio is more than just a consolidation level, budgets and review cycles for related projects. Each portfolio should have a clear goal. Typically, portfolios contribute in some way to the high level company objectives.

Within TenForce Portfolio Request Management, you can optionally specify the contribution each portfolio request makes to company objectives. Reports show how objectives are realized - or not realized. Vice versa, for each portfolio request, you can report in how much it contributes to the objectives so its total budget can be put into perspective.

Request lifecycle
These are the states a request for change or a new project goes through:

• Identified
  The request is merely created, has a number, a name and an owner. It’s only merit is its existence. No data is available yet to make decisions.

• Submitted
  The request has been completed. All required fields have been provided. It is now ready to be picked up by the review board to be “planned for review”.

• In review
  The request is under review. No decision is made yet.

• On hold
  It was decided by the review board not to handle the project request now. An ‘On Hold’ reason should be provided. The project or change request is not dead yet, it may be revived at a later stage.

• Approved Project
  The project is approved and needs to be started. A project workspace, team, charter,.. needs to be set up.

• Approved CR
  Same as above, but in this case it is merely a Change Request and does not need a separate workspace.

• Rejected
  The board decided not to do the project or implement the CR. This decision is final.

The interdependencies of these states are shown in the image below.

In a follow-on post, we’ll detail how project ranking is achieved and how you can customize it to suit your organization’s need.