|
The Cover Page The cover page is an important piece of the document. It will include the basic information of the project charter. This will include the project name, the sponsor, project manager and version and revision date information. The prepared by field should include the name of the person who is completing the first draft of the document. In the field of project management, the charter should be completed by the Sponsor and given to the project manager or project management office as an official kick off to the project. In reality it is most often up to the project manager to take the information from the project sponsor and create the project charter. This makes the signature page all that more important. The version and date fields work hand in hand. Every time that a change is made to the charter, either with updated information or via a change request, the version and date should be updated on the cover page. This will help to make sure that stakeholders are reading the correct version. |
||||||||||||||||||||||||||||||
|
The Signature Page The signatures page, as stated above, is your approval to move forward with the project. By obtaining a signature, this should indicate that the sponsor and key stakeholders are aware of the project and are giving authorization to move forward. So who should sign the signature page? This often depends on the project and your company's project management structure. In some organizations, the sponsor and project manager may be the only signatures required. For companies with a Project Management Office, the head of the PMO may be required to sign to make sure that they understand the projects ongoing in the organization. One rule of thumb that might make life easier as a project manager is to include the executives or managers that will be directly impacted by the project. This will include if they are a project sponsor or not. If their department is going to be impacted, then the project charter would be a key to make sure that they understand the project and the impact that it will have. At the bottom of the page is the final signatures section. Once the project is complete, the charter should be updated with the ending information. This will make sure that future project managers will be able to look back and see what was accomplished. Once the charter is finalized, then it should have signatures from the project sponsor and the project manager. In regards to signatures, today many documents are signed digitally. Some project managers will e-mail a copy of the charter to the sponsor and request an e-mail once it has been read. This document can then be filed in the project documentation. Other project managers like to keep an official signed copy in their project notebook and may scan in the signed page to be included in the e-file of the project documentation. What ever the method, the key is make sure that the document is signed by the sponsor and key stakeholders. |
||||||||||||||||||||||||||||||
|
The Revisions Page The revision page is important to make sure that the reader knows what changes have been made to the document. Many managers will go straight to this page to understand what has been changed. The date should be the date that the revision is complete. The document version number should indicate the version of the document. For small updates the version number should be incremented by 0.1. For large updates, ones requiring a change request, the version should be incremented by 1.0. This will help readers understand the magnitude of the latest change to the document. The Approved by field should be used to make sure that a change process is in place. For minor changes, a project manager may get approval through their status meetings. For a larger change, the approval process will be the change request approval. The team or change request number should be entered in the approved by field for reference. The pages affected column should identify the pages that have been changed. This will allow the reader the ability to go directly to the changes in the document. The comments section should further identify where the changes are located in the document and the circumstances leading to the changes. Example
Project Managers should try and keep all previous versions of the project charter in their electronic form. This will help to understand he changes in the project. This will also help the team to understand where the project has evolved from, especially in projects that change greatly over time. This will also help in the project management archives for future project managers to understand what they may expect in completing a similar project or working with the same department. |
||||||||||||||||||||||||||||||
Project Information The Project Information is included as it mirrors the information that will be needed when completing the Project Initiative in vPMO for IS&T Management approval. This information will help management make decisions when there is a need for trade off of resources. The Project ID is an optional field and can be completed by the Project Manager. You may want to include a Project ID to mirror the an account number or name that will be used during the course of the project. You may also want a name so that the department or area can track the number of projects going on and how they are connected. The sub-status section is used at the very beginning of the project initiation to let Management know what, if any, pre-work has been done on the project. If the only pre-work completed has been with the customer, then the Under Consideration box should be used. If the project has been taken to the IS&T Steering Committee, then this box should be checked. Many of the largest projects should be taken to the Steering Committee for review and it is best to let them know of the project as soon as possible due to their limited meeting schedule. Projects such as the Banner 7.x upgrade that will affect many departments are the types of projects that should be given to the Steering Committee for review. The Investment type will outline the nature of the IT project. There are some circumstances where more than one box can be checked, but this will be rare. The Solution type identifies the nature of the solution to be implemented at the completion of the project. If a decision is made to move in one direction, such as purchasing a packaged software, and then is later decided to move to a custom software build, a change request should be completed as this could be a major shift in the project scope. The Classification for the project will determine the area that will be impacted by the project. This will also be used to determine the systems and users that may be impacted by the project. The Project Start and Finish dates may be vague estimates at the beginning of the project. These dates, however, should be firmer as the project progresses. This information will be used to Layout a master timeline of projects that is ongoing in IS&T. The Fiscal Year information will help management determine when money and resources will be used. In the vPMO application, this will be a series of checkboxes. If the project is planning on spanning more than one fiscal year, then multiple checkboxes should be checked. |
||||||||||||||||||||||||||||||
Key Stakeholders The key stakeholder section of this document is the section of the document that gives all of the basic information about the project. This includes much of the same information as included on the cover page of the document. The project sponsor and project manager information is expanded to include the division, department and phone number. The Colleges Affected information was included so that a statement could be added about the users that will have a stake in the outcome of the project. This is important as many times the project charter will be the only document shared with other areas of the company. This information can help put perspective to the area that will use the end product as well as give readers a contact to find out more information about the project. |
||||||||||||||||||||||||||||||
Summary The Summary should be a short concise statement explaining the outcome of the project to anyone reading the charter. The statement should also answer two important questions. If the vision statement, or project, can not answer these two questions, then the project should not move forward in its current state. The first question to answer is: How does this project to the overall vision? In answering this question it is important to first make sure that you understand your company's or department's vision. For instance, one of your company's visions could be to increase customer satisfaction. If a project that you are working on is to deploy a new form that would ask twice as many questions as the previous question, you would need to ask yourself if this will increase customer satisfaction. There may be several reasons to complete this project, but making sure that it support the company vision will be key since it will increase customer time to complete, a seemingly contradiction to the company's vision. The second question to answer is: Which company strategy does this project align? Every company has a strategy. In identifying where the company is headed, the projects undertaken should help move the company in that direction. In some companies, their strategy is written out in sentences and put on a company web site so that the employees could see and understand. The project managers could then incorporate the strategy statement into the vision and how the project aligns. In reviewing Georgia State University's vision, check out the University's Strategic Plan. |
||||||||||||||||||||||||||||||
Priority / Priority Elaboration In dealing with projects, you must first realize that every project will take up resources. Since there are a limited number of resources available, then some priority should be given to projects. This priority will help to determine what resources will be given to which project, The Priority should be expressed as a number between 1 and 100. A guideline on the number range should be as follows:
The Priority Elaboration is the opportunity for the Project Manager / Project Sponsor to make their case as to why resources should be applied to their project. This will help the IS&T Management Team know who the projects should be ranked and which resources committed. |
||||||||||||||||||||||||||||||
Problem / Opportunity This statement is a little more detailed than the Vision statement. This statement should detail the current situation and what the project will do to help the situation. Some projects will be undertaken to capitalize on a company's advantage or to be the leader in a changing market. This should also be identified in this section. This section should answer this question: What is the Problem or Opportunity that this project poses to correct or take advantage? There is a reason to every project. Sometimes the reason is obvious, but sometimes the reason must be explained in detail so that the reader can understand. Often this information may contain confidential or restricted information. This should be carefully weighed on how much should be included in the charter. While the charter itself should be considered a part of the project documentation, some information should be kept in supplemental documents and marked confidential. |
||||||||||||||||||||||||||||||
Benefits The Benefits section of the Project Charter should list the key benefits that will be gained by completing this project. These benefits can be expressed as wither tangible or non-tangible benefits. The Tangible Benefits to the project will include any measurable benefits that will improve the efficiency of the organization or any cost savings. The tangible benefits of a project may be the reduced maintenance cost by implementing new hardware. Another tangible benefit may include the reduced time to complete a task or objective for which the project is implemented. These benefits should be measurable and the measurements outlined at the end of the project. The Intangible benefits to a project include those items that can not be easily measured, but is a desired outcome of successful completion of the project. This could include items such as uniformity among colleagues or easier access to the data being viewed. This could be a major reason for completing the project, but can not be easily quantified at the projects successful completion. |
||||||||||||||||||||||||||||||
Critical Success Factors The Critical Success factors are those items, that upon being completed, mark a successfully completed project. This includes the desired outcomes for which the project was undertaken. Each factor should be measurable at the end of the project to determine success. A project may have many success factors, however there should be no more than 4 high level critical success factors. This helps limit the scope of the project and the amount of work to be accomplished by the project team. Smaller success factors can roll up to complete one of the critical Success Factors. Example: Increase Technician response rate by 25%, measured monthly. |
||||||||||||||||||||||||||||||
In / Out of scope The scope document is a document that many project managers use in determining the scope of a project. This document also provides the bases for the change management plan for the project. In the project charter, it is important to list the major items in and out of scope for the reader. The in scope section should include all of those tasks that the project is to complete. This may include the writing of a contract, the building of new software or the construction of a facility. What ever the scope of the project, make sure that it is listed. Also, remember that anything not listed as being in scope is necessary understood as being in or out of scope. This is the boundary for the project and should be defined in the earliest documents so to reduce the work to a sizeable level and to make sure that the correct resources are identified. The out of scope statement is like the in scope statement in that it defines the boundaries. The difference is that this section defines what the project team is not going to do in the execution of the project. Many times the project will have dependencies on other projects. While dependencies are defines a little later in the charter, this is a good chance to let others know that this project will not be completing that task or project. This part also helps to control the budget in that items added means added cost to the project. Realize that items in and out of scope at the beginning of the project may switch during the course of the project. There is a formal way to accomplish this through the change management process. Items deemed out of scope can be added through the normal channels. There may also be additions to these sections as the project progresses. Many times new ideas and uses can come up during any of the project phases, knowing what to do with these ideas and documenting them can save the project manager and the project team from unnecessary work or added project benefit. |
||||||||||||||||||||||||||||||
Risks / Opportunities Every project has some measure of risk that could hinder it from being completed. Almost every project has some opportunity, that could capture a larger benefit than the original goal of the project. In project Management terms, Risk is "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives." In setting up a project you should try and identify any major risks or opportunities that could have an effect on the project. This will help management in determining the likelihood of completion and also alert them so that they can see if any of the risk can be removed at their level. In vPMO, in order to include a risk with a initiative, you must first save a copy of the initiative. Once it has been saved and is in a draft mode, then risks can be attached to the initiative document. When a project is approved, then the risks will carry over to the project delivery center. |
||||||||||||||||||||||||||||||
Costs At Georgia State University, Costs are related to the amount of expenditure, other than GSU personnel time. This would include any cost such as software, hardware, or contractor time. Any cost known in a project should be included in the project charter. If there will be a cost associated with the project, but the detail cost is unknown at the beginning due to the discovery phase needed to build a cost model, then a best guess should be entered. Cost are usually estimated at the beginning of a project and are negotiated and solidified as the project progresses. When the numbers for the cost section are better known, then the charter should be modified and the cost figures updated. If the cost is a drastic change from the original estimate, then a change order may be needed so that the Project Sponsor can approve the change in the cost of successful completion. In vPMO, the system will help determine a ROI for the project based on a three year payback. This ROI can be used to help justify the project. In order to get an ROI, then the initial cost will need to be known along with a estimated cost of ownership and estimated monthly benefit from completing the project. The better the ROI, then the more likely that a project will be approved. |
||||||||||||||||||||||||||||||
Funding Source The Funding Source for the project should be identified in this part of the charter. The source for the project may be IS&T, another part of the University, or even special funds such as the Student Technology Fees. This funding source should be identified to help management know where the cost of the project will be adsorbed. |
||||||||||||||||||||||||||||||
Interdependencies Most projects in any given organization are connected with other projects or system maintenance. Projects may require the server upgrade to be complete in order for new software to be loaded, or a new policy must be implemented before the project will be successful in the organization. These dependencies may be performed by the project team outside the project, or they may be completed by a totally different project team or department. Whatever the case, these dependencies need to be documented in the project charter. One of the main reasons for the documentation is for risk management. The charter, a document for management, identifies these risks as possible problems for the project. It will be up to the project team to determine risk mitigation plans for these dependencies. This will be done outside of the charter. The main purpose for this section is for identification. |
||||||||||||||||||||||||||||||
Milestones This section of the Project Charter should include the top four milestones for the project and their purposed completion date. For large projects, this may include the date that the project will finish each of the project phases. Each of these milestones should be carried over and be included on the Project Plan. Each of the major milestones should be monitored and the charter updated if any of the dates change. At the beginning of the project, or during the initial draft of the charter, the dates may be very generic (i.e. 3Q 05). As the project progresses, then the charter should be updated to include the actual date. This will help in the future and serve as a historical reference as to when items were complete in the project. |
||||||||||||||||||||||||||||||
Technology The technology section of the project charter has been introduced with the introduction of the vPMO application. This section should be used to identify the technology that will be used in completing the project. At the outset of a project, this information may not be known. It is OK to leave this section blank. If, on the other hand, a technology is known and at the beginning of a project, but changed during during the course of the project, then a change request should be completed. A change in the technology of a project could have big effects on a project's outcome. If there is a technology that is not listed on the technology page, please send an email to ralberts@gsu.edu, so that the technology can be added. |
||||||||||||||||||||||||||||||
Team Composition The team composition section of the document will help management know what the core team make up will consist. There are six choices available:
|
||||||||||||||||||||||||||||||
Stakeholders The stakeholder section of the charter is often used as a list to make sure that all parties affected by the project are successfully identified. This list may include names, titles or groups of people. Make sure that you also think about those people impacted outside of the use's department or the company. Many projects have an impact on the customer in some way; make sure that the identification is made for the project team. A main reason to identify the project stakeholders is for the communication plans. Each stakeholder group will have different communication needs. Some stakeholders may want to see weekly updates of the project plan and status reports. Other stakeholders may not realize the full impact of the project, but may find that their task is easier to perform in the future. Whatever the case, the stakeholders need to be identified in the charter. |
||||||||||||||||||||||||||||||
Resources The resources section should include those resources needed to complete the project. Be sure to remember that resources are people, materials and capital. Resources can be money, or special skills required. Try not to list specific names, but titles are appropriate in determining identifying the resources needed. The key to remember in listing resources is to include those resources that are not usually given. For instance, if every member of the company has a computer, then it is not necessary to list a computer as a resource when you list the skill. If every role listed does not have access to a common drive, then it will be a needed resource listed in the charter. The listing of the resources in the project charter is so that you can identify the needs with the sponsor and have the proper resources assigned to the project. Will this always happen? No, but by identifying them in the project charter will allow you to negotiate for the needed resources. That is why the writer of the charter may also include percentages of the resources needed or the timeframe that the resource is needed. Making sure that you have just enough resources to complete a successful project will help save time and cost while also allowing other projects to progress. |
||||||||||||||||||||||||||||||
Assumptions You know the old saying about assume and what it does to you and me. Here is to make sure that you have it identified for your sponsor. Documentation is a key to project management and here is where you need to make sure that your assumptions in planning are documented. What assumptions should be documented? Any one that is important for the project. Some of the suggestions include: funding will be supplied as necessary; resources will be available; decisions will be made in a timely manner. Make sure that if there is any concerns with what you are supposed to get from your sponsor that you include it in this section. Also make sure that your sponsor knows about your projects assumptions. Talk about them with your sponsor and if they need to be challenged, do it early to protect your project. |
||||||||||||||||||||||||||||||
Constraints What will be the biggest limiter to your project? That will be a question that only your project team can answer. This should be included in this section of the project charter. If you are working with a new technology and you do not have the expertise on your team, make sure that you document it in your constraint section. Anything you document here should be written to identify the issue with sponsors and stakeholders. Also, any constraints that happen over the life of the project, such as a key resource removed from the project, should be updated to reflect the current situation. If there is a problem with the project, a project manager should update the stakeholders as early as possible and document. As with interdependencies, you will need to make sure that the project team has a way of overcoming the constraints. This can be documented in the project charter, but should be documented in the risk management plan with possible solutions. |
The Project Charter: Contract with the Business
(Updated 1/9/05)
The project charter is probably the most important document in Project Management. It is also, often the most overlooked document when working on a project. Often the document will be written at the beginning of the project, placed in the project notebook and forgotten.
The project charter is a living document. Think of the project charter as a contract between the project team and the project sponsor. All details of the project should be included in the charter and updated as the project progresses. A key to the project charter is making sure that the project sponsor reads and signs the document along with the project manager. This should be an indication that the document is understood. The charter is also provides a key piece of information if the project has to be handed over to another project manager.
In the very beginning of the project, information is small and patchy. The information that is known should be included in the charter. As the project progresses through the phases and more information is gathered then the document should be updated. For any major changes to the project charter, a change request should be submitted and run through the change management process.
There are two project charters available to IS&T employees at Georgia State University. These charters are geared for two different audiences:
- Full Blown Project Charter - This document is to be used when the sponsor or major customer is outside of IS&T. This document will help make sure that all the appropiate information is gathered and documented. The reason to use this document is because the customer will not have access to vPMO to review the full documentation and the project has not been completed before soscope and requirements are unknown.
- Abbreviated Project Charter - This document should be used when the project is for an IS&T department who will have access to view all documentation in vPMO, or when a project involves a single IS&T Department and one customer and for which there is a standard request and the project can be easly repeated with the client (ex. building a training module for a customer).
has developed this template to work with the vPMO Application that is used to manage projects. The fields included in the Project Charter Template are there to assist with the building of a Project Initiative in vPMO for approval by IS&T Management. The instructions below will define the different parts of the document and how to complete the document.