Depending on the size of your organization, and of course whether you’re dealing with internal or external projects, it may or may not be beneficial to have a formalized project request process.

I ran only internal projects for very large aviation and engineering firm in the late 1990s and early 2000’s and our web development team had created a formal online project request process that captured key information for each project request. What that gave us was a standardized type and amount of key information for each project that came through making it easier to prioritize and assign the projects to the correct areas of our department (based on the business units they supported and the type of project that was being requested).

In Carl Pritchard’s book “The Project Management Communications Toolkit” he outlines what should be contained in a general project request document and what it is used for. Again, this all depends on which organization is originating the project request. If you’re dealing with external customers, your internal formal project request still may serve you well as a means to get consistent types of project information loaded into a common database from which you manage your entire portfolio of projects. No matter how it is performed or where the project request originates, a common process is usually helpful and recommended.

Much of the following text comes from Mr Pritchard’s section providing his take on this process - however, I have taken liberties to add some of my own thoughts and details to his text.  I believe that his process, for the most part, does a pretty good job of laying out the information that is important to capture the project request.

The Project Request

Purpose

Project Request

 

Because different organizations interpret project requests (as a practice) differently, their purposes may vary as well. A project request may be a simple one-paragraph description of a project that has been formally submitted to management (either through a chartering process or proposal process). It may also be a specific form or format for submitting initial information about a project that may be of interest to the organization or that may serve an organizational need. For the sake of this discussion, the latter is assumed.

Application

 

A project request is used as a means to initiate ongoing analysis (feasibility study, impact analysis) of a project concept. Information available for the project request is generally somewhat scant, as the project request is used only to trigger other processes.

 

Content

Approaches

A project request form includes only the most rudimentary information about a project concept:

  • Project name (or a few-word description)
  • Project description (may include a brief description of the goals or objectives of the project, as well as any problems/concerns it is designed to resolve)
  • Timing
  • Special resource needs (may include material or human resources essential to project initiation or implementation)
  • Support organization (the anticipated “home” for the project if it is determined to be viable);
  • Name of person completing the form
  • Budget and Sponsor information
  • High-level business case
  • Criticality of need (aids in project prioritization especially for internal projects)

Although other information may be incorporated, these are the essentials for initiating a project and ensure that a consistent baseline set of information is available for any project that will undergo further study or scrutiny.


Approaches

 

The information embedded here may be redundant with information collected for a project proposal or feasibility analysis. That is why, particularly in smaller organizations, a project request form may be embedded within those other processes. Larger organizations use project request forms as an initial screening mechanism to enter projects into the process and to ensure that those that undergo more formal feasibility assessment are initiated at the appropriate levels within the organization.

 

Considerations

Considerations

Because the project request form data are frequently redundant with information gathered in other processes, it should be applied only when there are copious requests being filed on a regular basis, the organization is large, and tracking mechanisms are limited. In smaller organizations where project owners are easily identified, project requests may be seen as purely administrative overhead.