program

[Former Member]

what is program chatter?

[Former Member]

A program charter is essentially a contract between the program manager on the one hand and the program sponsor and stakeholders on the other. While having no legal consequence, an agreed-upon charter nevertheless represents a formal commitment between these parties. Writing, maintaining, and using an effective program charter is one of a program manager's most important jobs.

When properly used, a charter will be the single most important tool the program manager possesses for managing the expectations of the program sponsor and all other stakeholders. When formally agreed upon, the charter establishes the very foundation of the program. When key elements in the program change which compromise the agreement as established in the charter, (e.g., a significant change in scope or the invalidation of one of the primary assumptions about the program), then the program charter must be updated to reflect these changes and these changes approved. This is in essence a renegotiation of the contract.

A good program charter is not necessarily lengthy, although it can be. Most importantly, it answers basic questions about the program as clearly and succinctly as possible. An appropriate length is simply the length required to establish an adequate contract for doing the program.

A good charter is also a tool for fostering the sharing of information between project teams and their supporting organizations. Make sure that your program charter is read! Share it with the units who will be impacted by, or must contribute to, your program.

Quality and integrity in the process required to develop a charter are critical. If the chartering process has been poorly done and if the program sponsor and program manager have not truly agreed on its contents, then the program charter is not worth much.

Vinodh Balakrishnan

[Former Member]

How to Obtain a Charter Template

Use your ftp program to GET programc.doc (Word 6.0) or programc.do5 (Word 5.x) from /afs/ir.stanford.edu/group/AIS-proj/_SDP/NavLite/Published/.

Definitions

A project is a group of related work activities which, when effectively carried out, will achieve certain goals and objectives. A project is managed by a project manager and has an organization, a scope, a duration, a budget, and defined deliverables. A project can exist independently of any program or can be identified as part of a program.

A program is a set of related, perhaps interdependent, projects which, taken together, solve an identifiable business/technical problem or complete an initiative. A program organizes the interrelationships of the individual projects within it and provides an overall means for effectively organizing and coordinating those projects. In order for the program to be considered successful, all individual projects contained within it must be successfully completed.

Guidelines for Creating a Program Charter

*A program charter* is essentially a contract between the program manager on the one hand and the program sponsor and stakeholders on the other. While having no legal consequence, an agreed-upon charter nevertheless represents a formal commitment between these parties. Writing, maintaining, and using an effective program charter is one of a program manager's most important jobs.

When properly used, a charter will be the single most important tool the program manager possesses for managing the expectations of the program sponsor and all other stakeholders. When formally agreed upon, the charter establishes the very foundation of the program. When key elements in the program change which compromise the agreement as established in the charter, (e.g., a significant change in scope or the invalidation of one of the primary assumptions about the program), then the program charter must be updated to reflect these changes and these changes approved. This is in essence a renegotiation of the contract.

A good program charter is not necessarily lengthy, although it can be. Most importantly, it answers basic questions about the program as clearly and succinctly as possible. An appropriate length is simply the length required to establish an adequate contract for doing the program.

A good charter is also a tool for fostering the sharing of information between project teams and their supporting organizations. Make sure that your program charter is read! Share it with the units who will be impacted by, or must contribute to, your program.

Quality and integrity in the process required to develop a charter are critical. If the chartering process has been poorly done and if the program sponsor and program manager have not truly agreed on its contents, then the program charter is not worth much.

For further reading and consultation, or for a quick read/review of your program charter, contact Sarah Rahamim or Tim Flood, ITSS/AAI/Project Support & Improvement (PSI).

Table of Contents

A program charter contains the following:

1.0 Program Name [enter ITSS project number (if available) and program name here]

Provide the name of the program.

2.0 Document Information

Provide the author's name, the date the document was produced, information about how to obtain copies of the document, and document change history (if needed) such as who changed the document, when, and what was changed.

3.0 Introduction

Provide necessary contextual information which a reader needs to know in order to understand the program. This can take the form of background/introductory information or an executive summary.

4.0 Program Scope

This section will give definition to the program. Upon reading this section, the reader should understand specifically what the program should achieve for the clients and the key dimensions, boundaries, and limits of the program.

4.1 Program Goals

A program goal is a clear expression of the program's target or direction. A program goal is achieved when all the program objectives (see below) relating to it have been achieved. Goals tend to be less tangible when compared to objectives. Usually goals do not express tangible achievement measures or time frames associated with them, although it is expected that all the program goals should be satisfied at the conclusion of the program.

4.2 Program Objectives

A program objective is a measurable statement of a particular desired outcome of the program. Objectives are tangible, observable, measurable results to be achieved. Whereas goals express intention (what the program is trying to accomplish for the enterprise), objectives express results (how that accomplishment will be manifest in measurable, tangible deliverables).

4.3 Logical Scope

Logical program scope delineates the boundaries of the subset of the information systems to be included in the program. Logical scope can be in the form of a model, such as a context diagram, and/or a written description/list. It is recommended that a written definition of logical scope be careful to identify both what is within the scope of the program and, where there could be questions/confusion, what is not within the logical scope of the program.

4.4 Deliverable Scope

Deliverable scope refers to the deliverables and deliverable components that the program will produce. The deliverables should be based on the program goals and objectives, and should be the minimum set necessary to achieve those goals and objectives. The deliverables should be defined both qualitatively and quantitatively.

4.5 Organizational Scope

This section specifies which organizational entities will be affected by the program -- i.e., stakeholders. It answers the question, What organizations will be impacted by the program and its deliverables? List key dependencies upon which your program is dependent (e.g., your program will depend upon a deliverable in a related project).

4.6 Temporal Scope

Most programs will be constrained by time in some way or another. The program's start and end dates as well as any other externally imposed milestones should always be a part of the scope statement. Externally-imposed milestones should include relevant temporal factors (due dates, target installation dates, etc) and come in three varieties:

external-to-Stanford constraints, such as a government requirement;

internal-to-Stanford deadlines, such as end of fiscal year;

internal-to-Stanford projects which have an effect on your program, such as a dependency on a deliverable from another project

Break your program into phases if the total elapsed time is approximately more than 6 months. Break each phase into major milestones. Milestones will be part of the program plan (which is not part of the program charter). Include any high-level milestones here or in an appendix as you see fit. A milestone is a significant deliverable, event (such as a review), or decision.

4.7 Financial Scope

Financial scope defines cost constraint on the program and value to the enterprise. Program cost constraints can take the form of an estimate of costs, an estimated range of costs, or a not-to-exceed estimate of costs. Statements of value can take the form of estimated savings and income enhancement opportunities.

5.0 Assumptions

Assumptions are key aspects of the program which the program manager believes to be true but which should be expressly stated to ensure validity and concurrence, including items you think are already in place, including funding, resource availability, participants' roles. You should make a reasonable assumption about how any issue will be resolved and express that in this section. Unless you state your assumptions and confirm their validity, you can expose your program to increased risk.

6.0 Program Risks & Critical Success Factors

Risks are factors which jeopardize a successful program outcome. They include any/all of the following factors pertinent to the program: Overall program risks, very specific risks, and risks of not successfully completing the program. You can also state program critical success factors in this section.

7.0 Program Organization

This section identifies the executive sponsor, program sponsor, and program manager. It also identifies the involved participants in the projects and the roles they will fulfill on the projects. It can also specify the duration of their participation in the program and the percentage of their time to be devoted to participating on the program. You can also specify particular expertise which a participant will contribute to the program.

www.stanford.edu/group/AIS-proj/programcharter.html

www.cvr-it.com/PM_Templates/Program_Charter_Template