Project Management

Please login or join to subscribe to this thread

Project approval processes

linkedin twitter facebook  
avatar
A B Campbell, Ca, United States
Does anyone have anything they can share on processes for getting projects approved? We need to modify an online system to create a workflow for project approvals.
avatar
Steven Beebe Colorado Springs, Co, United States
To answer your question well, there is a lot of "it depends". But in any environment there are some important principles for project approval. I will cover some key ones.

(Note: This process should be documented in the same as any other process in your organization).

1. Have a mechanism for identifying project opportunities. This is often best done through a combination of people with business process expertise and technical expertise. The closer the business people are to the "real work" the better. The best ideas come from teams of business and technical people who meet regularly to oversee the improvement of a business process.

2. Once an opportunity has been identified, create a project proposal or business case. Refer to the JPace material on Gantthead for an overview. Also, there is a template (Business_Case_Report.doc to give you a feeling for the content - the format and degree of formality should map to what is typical in your organization). When thinking through ROI, remember there are many types of
returns - not just financial. Customer satisfaction / loyalty returns can be very valuable. While in some situations they may be quanitifiable, it isn't always necessary.

3. The actual review and approval process is both simple and complex. The business case should be reviewed by the "appropriate" decision makers and balanced against all other project pportunities. The difficulty here is "appropriate". At a minimum, you need both budget authority (some one who can
spend the money) and business responsibility (some one who can authorization the change in business process). In some cases, you may need technical representation - if there are infrastructure or architectural issues, these may require approval from technical management with in the organization.


That's the process in a nutshell. As I mentioned, I'd recommend documenting in the standard format for your organization. If you don't have one, this would be an easy and appropriate place to start. A simple format of:

1. Brief process overview - a few sentences.

2. Process Objective - what is this process intended to accomplish.

3. Process Steps - a high level flow chart (keep it to seven or less steps - if you need more steps, do one with less than 7, then explode one of the steps in to a process description of its own).

4. Process Inputs - what things are needed to start, carry out and complete this process.

5. Process Outputs - things that are produced by this process. Include a description and eventually a good definition with samples of outputs done well.

6. Exit criteria - how do you know you can exit this process? Just producing the outputs is often not enough.
------
Those would be a good start. If you're up to it, identify:

7. Process metrics - how will the process be measured to insure it is performing appropriately.

8. Process owner - who is accountable for the processes performance.

Best of luck,

Steve Beebe
-----------
Xapware Technologies, Inc.
Driving Development Success
www.xapware.com

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The illegal we do immediately. The unconstitutional takes a little longer."

- Henry Kissinger

ADVERTISEMENT

Sponsors