The Project Charter gives a clear picture of the project ...
The Project Charter gives a clear picture of the project and the rationale behind it. It fully explains the intended path of the project from conception to desired outcome. The Charter answers the question: “Is there a compelling business need for the project”? The purpose of the Project Charter is to provide the approval/funding authority enough information to decide if the project should proceed to the next step—Project Feasibility Analysis.
Why? To collect information needed to evaluate whether or not a project should be funded—it is a GO/NO GO/GO BACK test that must take place before a project starts.
Who? Created by the project sponsor’s program staff and the project manager, with assistance from other managers and technical staff—the core team members.
When? Development time depends on the size of the project—a general rule of thumb is that development of the Project Charter should be less than 2 weeks.
What? An initial statement of the project scope and objectives, the problem it addresses, who benefits, successful completion criteria, and a brief alternatives analysis.
Project Charter Review Questions
• Is the Project Background described completely and clearly?
• Do the Business Objectives address the problem described in the Problem/Opportunity Statement?
• Do the Functional Requirements (if the project includes information technology) relate to the Business Objectives?
• Does the project sponsor clearly receive benefit from the completed project?
• Are the Successful Completion Criteria clear and measurable?
• Is the Project Scope stated so that it is clear what the project is to provide and what it will not provide?
• Is the Project Objective Statement clear and concise?
• Are all Assumptions and Constraints identified?
• Are the Alternatives reasonable?
• Do the Project Milestones relate to project deliverables?
1. PROJECT NAME 3
2. OVERVIEW 3
2.1 Project Background 3
2.2 Problem/Opportunity Statement(s) 3
2.3 Project Objective Statement 4
2.4 Project Scope 5
2.5 Project Sponsor 6
2.6 Project Priority and Strategic Fit 6
2.7 Project Organization 7
3. PERFORMANCE OBJECTIVES 10
3.1 Business Objectives 10
3.2 Functional Requirements 11
3.3 Successful Completion Criteria 12
4. PROJECT CHARACTERISTICS 12
4.1 Assumptions 12
4.2 Constraints 12
4.3 Issues/Concerns/Risks 12
4.4 Impact Assessment 12
5. PROJECT RECOMMENDATIONS 13
5.1 Existing System 13
5.2 Alternative Analysis 14
5.3 Recommended Alternative 14
5.4 Project Milestones 14
5.5 Cost Analysis 14
5.6 Source of Funding 15
1. PROJECT NAME
Choose a short, energizing name or acronym that describes your project. Be specific and make sure you're not duplicating another project's name.
2. OVERVIEW
2.1 Project Background
THIS SECTION DESCRIBES THE CONTEXT SURROUNDING THE PROJECT, AND PRESENTS THE PRIMARY MOTIVATION FOR THE PROJECT. IT INCLUDES A HIGH-LEVEL DESCRIPTION OF THE BUSINESS AREA, THE CURRENT SITUATION, THE DESIRED SITUATION, AND THE GAPS THAT EXIST.
The following list identifies potential items that could be included in the project background:
A general description of the business functions, the specific services, and the customers
The sequence of events or conditions that contributed to the current problem or opportunity
Contributing historical data
Relevant features of the program areas involved
The manner and extent to which information technology is currently applied
A definition of the affected units of work and estimates of the quantity of work processed
2.2 Problem/Opportunity Statement(s)
THIS SECTION INCLUDES A CONCISE STATEMENT OF THE PROBLEM(S) THAT NEGATIVELY IMPACTS CURRENT BUSINESS OPERATIONS OR THE SPECIFIC OPPORTUNITY(S) THAT WOULD MAKE THE BUSINESS, OR PROGRAM OPERATIONS MORE EFFECTIVE.
Avoid describing the symptoms of the problem instead of the problem itself. Symptoms, which may seem to be the problem include:
Processes which are old, confusing, convoluted, redundant, labor intensive, undocumented, or nonstandard
Data which is incorrect or incomplete
Data which requires excessive effort expended in collection, multiple collection points, or different versions of the truth
Too many manual processes
The symptoms of a problem are important in that they help lead to a solution. However, symptoms alone are not enough to justify a project. To make sure that you have reached the real problem, ask yourself “So what?” for each item you have included as a problem. If you have identified a business problem or opportunity, your answers should fall into one or more of the following categories:
Problems
EXCESSIVE COSTS INCURRED IN OPERATING AN EXISTING PROGRAM
Generation of additional program costs
Services at an unsatisfactory level according to a specified policy
Workload / staff increases
Quality or timeliness of information
Additional requirements mandated by law or Federal regulations
Limitations on the capability or capacity of current resources
The following are example problem statements
Statistics of UI claims filed on Fridays are not available until the following Friday.
The current process requires 3.6 PYs of overtime to process travel claims.
The current error rate with travel expense claims averages 60%.
Opportunities
AVOIDANCE OF FUTURE OPERATING COSTS
Improving mission critical customer services
Workload / staff reductions
Ability to add capacity to current resources
The following are example opportunity statements:
Provide the capability for state employees to access and calculate retirement payments while reducing the number of phone calls into the customer support unit.
Call center processing allows the department to continue with the current staffing level, and improve service, even as the number of calls increases.
Since revised Federal law allows state access to Social Security Administration information, this information can be used to reduce the workload required to maintain current addresses on all individuals.
2.3 Project Objective Statement
THE PROJECT OBJECTIVE STATEMENT (POS) IS A HIGH-LEVEL, WRITTEN SUMMARY OF THE PROJECT. THE POS STATES WHAT THE PROJECT MUST ACCOMPLISH IN ORDER TO BE SUCCESSFUL. IT REFLECTS THE CURRENT UNDERSTANDING OF THE PROJECT AND IS USED TO FOCUS THE TEAM MEMBERS, THE SPONSOR, AND OTHER KEY STAKEHOLDERS ON THE PRIMARY OBJECTIVE OF THE PROJECT. THE POS SHOULD BE CONCISE, 25 WORDS OR LESS, AND AVOID JARGON AS MUCH AS POSSIBLE.
A word of caution—Make sure that the POS is measurable and achievable. The project’s success will be determined by how well it achieved the POS. The following are example POS’ for different projects:
Apollo 11 Mission: …”I believe this nation should commit itself to achieving the goal before this decade is out, of landing a man on the moon and returning him safely to earth.”
For an advanced military aircraft: Design a plane that can fly over the Soviet Union at more than 70,000 feet, preferably without being detected, and take surveillance photos that are unprecedented in their clarity.
For a Training Information System project: Develop a central database by Q3FY13, which will be the sole source of scheduling and registration activities and information for the department.
For a Procurement Reengineering project: Streamline and automate the procurement process to provide computer hardware and software to all department employees in a timely fashion at best-cost value and in compliance with department and statewide Work Group Computing Policy.
For a software quality initiative: Create and implement a corporate-wide “no rework” program to reduce software development costs by 50% within the next 12 months.
2.4 Project Scope
CLEARLY DEFINING THE PROJECT’S SCOPE GOES HAND-IN-HAND WITH THE POS. THE SCOPE SETS THE BOUNDARIES ON THE PROJECT SO IT CAN BE DONE SUCCESSFULLY. THE PROJECT BOUNDARIES ARE DEFINED BY SPECIFIC CUSTOMER BUSINESS AREAS TO BE SUPPORTED, FUNCTIONALITY TO BE INCLUDED, AND/OR TECHNOLOGIES TO BE ADDRESSED. IF THE PROJECT NEEDS TO BE ACCOMPLISHED IN PHASES, THE SPECIFIC BOUNDARIES FOR EACH PHASE SHOULD BE STATED HERE.
The project scope must be consistent with the Business Objectives and the Functional Requirements stated in Section 3, “Performance Objectives,” of this Project Charter. For example, the scope statement for the implementation of a new automated system could include business process re-design, physical office alteration, new office procedures, legal issues, financial management, and even administrative support such as travel arrangements.
It is often beneficial to clearly state what the project does NOT include to help identify the project boundaries. For example, the following table shows the scope of an Operating System Upgrade project. Listed under the “Provides” column to signify that when the project is completed, this is what the project results will provide. Listed under the “Does Not Provide” column signifies those things that will not be included in the intended project results.
|OS Upgrade Project Scope |
|Provides |Does Not Provide |
|Upgrades all central office workstations to CyberOS |Workstations at sites outside the central office |
|Ensures that current user applications continue to function|Replacement or upgrades to user applications |
|Training to central office users on the new CyberOS |End user training on user applications under the new |
|interface |interface |
2.5 Project Sponsor
IDENTIFY THE PROJECT SPONSOR BY NAME AND ORGANIZATION. THIS INDIVIDUAL IS THE ONE WHOSE DEPARTMENT HAS THE GREATEST STAKE IN THE PROJECT’S SUCCESS AND IS RESPONSIBLE FOR THE PROJECT'S COSTS AND BENEFITS. TYPICALLY, THE SPONSOR COMES FROM THE CLIENT ORGANIZATION. ASK THE FOLLOWING QUESTIONS TO HELP IDENTIFY THE PROJECT SPONSOR:
Who cares so much about the successful completion of the project that they are willing to fund the project and ensure that adequate resources are assigned to it?
Who will make the final decision if the team cannot resolve a problem on its own?
Who will make the final decision to add resources, cut features, and slip the schedule for the project?
The project sponsor has the ultimate responsibility for the project’s costs and benefits and should be of a high enough level to have the necessary leverage, authority and the ultimate responsibility. If it's a small, local project, a division or section manager could be the sponsor. If it's a large, multi-departmental project, a senior executive should be the sponsor.
2.6 Project Priority and Strategic Fit
IDENTIFY HOW THIS PROJECT FITS INTO THE BUSINESS UNIT AND THE ORGANIZATION’S TACTICAL PLAN. DETERMINE THE PRIORITY FOR THIS PROJECT RELATIVE TO OTHER PROJECTS THAT THE PROJECT SPONSOR IS RESPONSIBLE FOR. THEN DETERMINE THE PROJECT PRIORITY ACROSS THE ORGANIZATION AS WELL. REFER TO SPECIFIC GOALS AND/OR OBJECTIVES IN THE STRATEGIC OR TACTICAL PLAN AND IDENTIFY HOW THE PROJECT HELPS MEET THESE GOALS.
The following steps may be helpful in clarifying the strategic fit.
Identify how the project fits with the organization’s strategic/tactical vision(s). Determine which set of visions/plans the project must satisfy or be tested against. Then describe the project’s alignment and/or variance from the existing vision/plan.
Identify the fit with organizational strategies. Sometimes the project may affect one or more local department strategies or business plans. Identify which one(s) and describe the project’s alignment and/or variance.
Identify the fit with legal/regulatory direction, if appropriate for this project. Describe how the project complies with the organization’s legal mandates.
2.7 Project Organization
PROJECT ORG CHART
TO BETTER ASSESS THIS PROJECT’S IMPACT ON THE ORGANIZATION, PROVIDE AN ORGANIZATION CHART THAT INCLUDES THE PROJECT TEAM, INCLUDING NUMBER AND CLASSIFICATION OF TEAM MEMBERS AND THE IMPACTED PROGRAM ORGANIZATION(S).
Project Stakeholder Roles and Responsibilities
A FORMAL PROJECT STRUCTURE PROVIDES PARTICIPANTS WITH A CLEAR UNDERSTANDING OF THE AUTHORITY AND RESPONSIBILITY NECESSARY FOR SUCCESSFUL ACCOMPLISHMENT OF PROJECT ACTIVITIES, AND ENABLES PROJECT TEAM MEMBERS TO BE HELD ACCOUNTABLE FOR EFFECTIVE PERFORMANCE OF THEIR ASSIGNMENTS.
Briefly describe the roles and responsibilities of the major participants in the project. These will probably include, at a minimum, the project manager, executive management, program management and staff, and core team members. In particular, if outside vendor resources will be used to assist with the project, clearly differentiate between the roles and responsibilities of State staff versus those of vendor staff. Include tasks such as data conversion, training, project management and oversight, and ongoing maintenance, as appropriate.
|Project Stakeholder Roles and Responsibilities |
|Role |Responsibilities |
|Project Sponsor |Authorize project |
| |Articulate program requirements |
| |Ensure that requirements are met |
| |Define sponsor needs |
| |Assign sponsorship personnel as project points of contact |
| |Approve funding |
| |Review and approve project plan |
| |Participate in planning session |
| |Make go-no go decisions project if critical issues arise |
| |Mediate approval issues which cannot be resolved between core team members and the |
| |project manager |
| |Attend executive requirements reviews |
| |Help resolve requirements problems |
| |Provide written agreement to requirements and qualifying criteria |
| |Monitor milestones, activities, timelines, resources, budgets and critical path |
| |Monitor contracts |
| |Communicate and coordinate with project stakeholders |
|Project Manager |Implement project policies and procedures |
| |Review and refine project request documents |
| |Define project success criteria |
| |Document project tradeoffs |
| |Conduct cost/benefit analysis |
| |Acquire reserves required to perform work |
| |Maintain staff proficiency and productivity, and provide training where required |
| |Establish and maintain project quality |
| |Identify and procure tools to be used on the project |
| |Develop detailed project plan, tailoring methodology to reflect project needs |
| |Ensure that project plan is approved and baselined |
| |Assign resources to project and assign work packages |
| |Approve project quality and configuration management plans |
| |Ensure that management, users, and contractors agree to project commitments |
| |Regularly review project status, comparing budgeted to actual values |
| |Identify risks and track issues |
| |Manage change request process throughout the life of the project |
| |Ensure that project plan is updated regularly |
| |Review the results of quality assurance reviews |
| |Obtain management and user approval of design, test, and approaches |
| |Review project risks and establish mitigation procedures |
| |Develop an action plan for any product that does not pass acceptance test |
| |Obtain user and management approval of tested solution |
| |Close-out open action items |
| |Assist in contract close-out |
| |Develop post-implementation report |
| |Conduct project retrospective |
|Core Team Members |Represent business needs/requirements for Identify project alternatives |
| |Implement solution within budgeted cost and schedule |
| |Support project planning and tracking |
| |Provide task estimates. |
| |Ensure that requirements are feasible and appropriate for available resources |
| |Analyze requirements for completeness, consistency, and ambiguity |
| |Ensure that all team members understand the project plan |
| |Identify staff training needs and provide qualified staff |
| |Establish the project's facilities and environments |
| |Ensure that the project team staff fully understands requirements. |
| |Review technical approach |
| |Assign tasks |
| |Assist in development of estimates and schedules |
| |Track the work effort and submit status reports |
| |Conduct internal and external work product reviews |
| |Coordinate with quality assurance, review quality assurance results, and correct any |
| |deviations |
| |Establish testing plan and coordinate test activities |
| |Accept problems and schedule fixes |
| |Identify risks as they are found |
| |Participate in change request reviews |
| |Participate in issue management |
| |Participate in risk assessment and mitigation activities |
| |Identify ways to improve project processes |
| |Participate in the project retrospective |
|End User Representatives |Define user needs |
| |Review current business practice and the impact the new system will have on it |
| |Ensure that requirements are met |
| |Ensure that staff are trained and ready to accept the new system |
| |Be proponents of new system to other remote users |
| |Assign user personnel as project points of contact |
| |Review and approve project plan |
| |Review project status reports |
| |Attend requirements reviews |
| |Help resolve requirements problems |
| |Assist in user testing |
| |Approve delivery and installation procedures |
| |Develop procedures, policies, and systems to support the new system |
| |Participate in the project retrospective |
3. PERFORMANCE OBJECTIVES
3.1 Business Objectives
BRIEFLY STATE THE BUSINESS OBJECTIVES THAT EFFECTIVELY RESPOND TO THE PROBLEMS AND/OR OPPORTUNITIES. INCLUDE AT LEAST ONE OBJECTIVE FOR EACH PROBLEM/OPPORTUNITY MENTIONED IN SECTION 2.2, “PROBLEM/OPPORTUNITY STATEMENT.” OBJECTIVES DEFINE THE SIGNIFICANT RESULTS THAT MUST BE ACHIEVED BY THIS PROJECT. WHEN WRITING THE OBJECTIVES REMEMBER TO FOCUS ON “WHAT” THE SYSTEM OR PRODUCT WILL DO, NOT “HOW.” EACH OBJECTIVE SHOULD:
Directly relate to a problem/opportunity item
Be realistically achievable
Be measurable (this means that progress on the objective can be tracked, measured and compared)
Indicate the direction of expected change (more, less, same as etc.)
Indicate the degree of expected change (percentage, prior year level, numbers of)
Business objectives usually fall into one of the following four categories: increasing revenues for the organization, avoiding costs, improving customer service, or complying with federal and state governmental regulations. For example:
Provide statistical data of all UI claims filed on Fridays as required by state mandate.
Eliminate 3.5 PYs for processing travel claims, reducing the cost per travel claim.
Verify current address for 75% of new claims filed, reducing errors and rework per claim.
3.2 Functional Requirements (if information technology is required)
IDENTIFY THE ESSENTIAL CHARACTERISTICS THAT THE PROPOSED AUTOMATED SOLUTION MUST HAVE IF IT IS TO SATISFY THE OBJECTIVES. FUNCTIONAL REQUIREMENTS DESCRIBE “HOW” THE PROJECT RESULT WILL FUNCTION AND PROVIDE A LIST OF THE MINIMUM TECHNICAL FEATURES THAT MUST BE IN PLACE WHEN THE PROJECT IS COMPLETE. EACH FUNCTIONAL REQUIREMENT SHOULD TRACK BACK TO A BUSINESS OBJECTIVE, AND SHOULD BE SPECIFIC ENOUGH TO BE USED TO MEASURE THE SUCCESSFUL COMPLETION OF THE PROJECT. THE PRIMARY FUNCTIONAL REQUIREMENTS APPEAR ON THE PROJECT DATA SHEET AS “ABILITY TO” STATEMENTS OR “PERFORMANCE OBJECTIVES” DEPENDING ON THE NATURE OF THE REQUIREMENT.
Depending on the project, the functional requirements are written in terms of:
Types of data, in terms of groups, size, retention period etc.
Database characteristics
Processing procedures
Processing functions needed to support the program process
Types of output, in terms of groups, volume, timing, location, quality, media etc.
Types of input in terms of groups, volume, timing, location, quality, media etc.
Software constraints
Equipment/hardware constraints
Staffing constraints
Security or confidentiality risks
Hardware/software interfaces
Development scheduling constraints
Data constraints
Organizational constraints
Legislative constraints
Functional requirements usually describe very high-level, but specific features of the resulting system. For example:
The system must have on-line access to SCDB U1 claim records.
The system must print credit card numbers on travel vouchers.
The system must be able to access the SSA UNIX-based database.
3.3 Successful Completion Criteria
DESCRIBE HOW THE SUCCESS OF THE PROJECT WILL BE DETERMINED FROM THE CUSTOMER’S PERSPECTIVE. THE COMPLETION CRITERIA SHOULD BE IN QUANTIFIABLE/MEASURABLE TERMS SO THAT THERE IS NO DOUBT AS TO THE PROJECT’S SUCCESS. IF THE BUSINESS OBJECTIVES HAVE BEEN SUFFICIENTLY QUANTIFIED, MEETING THEM CONSTITUTES THE SUCCESSFUL COMPLETION CRITERIA. QUANTIFIABLE MEASURES OF CUSTOMER USE AND/OR SATISFACTION WITH THE FINAL PRODUCT ALSO MEASURE THE SUCCESSFUL COMPLETION OF THE PROJECT.
4. PROJECT CHARACTERISTICS
4.1 Assumptions
LIST ANY ASSUMPTIONS THAT WERE MADE IN DEFINING THE PROJECT. ASSUMPTIONS CAN AFFECT ANY AREA OF THE PROJECT INCLUDING SCOPE, THE STAKEHOLDERS, THE BUSINESS OBJECTIVES, AND THE FUNCTIONAL REQUIREMENTS. A BASIC ASSUMPTION BEHIND MOST PROJECTS IS THAT THE PROBLEM SHOULD BE SOLVED. IF ANY ASSUMPTIONS HAVE BEEN MADE REGARDING STAFFING, E.G. SPECIFIC TECHNICAL OR BUSINESS SKILL SETS AND/OR INDIVIDUALS NECESSARY TO COMPLETE THE PROJECT, LIST THESE ASSUMPTIONS HERE.
4.2 Constraints
IDENTIFY KNOWN OR SUSPECTED CONSTRAINTS TO THE EXECUTION OF THE PROJECT. THESE CONSTRAINTS DESCRIBE BOUNDARIES WITHIN WHICH THE PROJECT MUST OPERATE AND WHICH ALSO MAY BE OBSTACLES TO THE PROJECT’S SUCCESSFUL COMPLETION. FOR EXAMPLE, CONSTRAINTS COULD INCLUDE ANY OF THE FOLLOWING:
Limited head count
Lack of or limited knowledge
Short window of opportunity
Staffing constraints
Delivering the product within a specific time frame
Delivering the product within a limited cost
Be as specific as possible and describe the constraints in the context of the project.
4.3 Issues/Concerns/Risks
IDENTIFY MAJOR ITEMS THAT COULD CAUSE THE PROJECT TO FAIL. CONCENTRATE ON THOSE ITEMS, WHICH ARE OUTSIDE THE JURISDICTION OF THE PROJECT AND COULD BE “SHOW-STOPPERS” TO THE SUCCESS OF THE PROJECT. INCLUDE WHAT MITIGATING STEPS CAN BE TAKEN TO REDUCE EACH OF THE RISKS.
4.4 Impact Assessment
THE IMPACT ASSESSMENT IDENTIFIES ANY SYSTEMS, PROCESSES, OR PROJECTS THAT WILL IMPACT, OR BE IMPACTED BY, THE PROPOSED PROJECT. THE NATURE OF THE IMPACT, THE OWNER, AND ACTION REQUIRED SHOULD BE ADDRESSED. FOR EXAMPLE:
A new software system may increase the number of calls (transactions) to the call center.
Deployment of a new software package may require all PCs to be upgraded to the latest version of the operating system.
Introduction of a new product into the market may render certain current products obsolete, and they may need to be retired (e.g., existing warehouse stock may need to be liquidated).
The implementation of a project may impact the redesign of the database structure used by another project currently under development.
In the case of related projects, it is helpful to describe the nature of the dependency. The project being planned may be dependent on another project, be interdependent with another project, or have projects that depend on it. The nature of the dependency can include:
Data: The project shares data with another project.
Function: The project shares common functionality with another project.
Staff: The project shares staff with another project.
Technology: One project installs the technology that another requires.
Funding: The projects share funding arrangements.
Include any dependent or interdependent projects on the Project Data Sheet under “Dependencies.”
5. PROJECT RECOMMENDATIONS
5.1 Existing System
BRIEFLY DESCRIBE THE CURRENT METHOD OF OPERATION. IF AN AUTOMATED SOLUTION CURRENTLY EXISTS, INCLUDE A GENERAL DESCRIPTION OF THE SYSTEM PROCEDURES, INPUTS, OUTPUTS, OVERALL COSTS, PY NUMBERS AND PY COSTS. IN ADDITION, INCLUDE PERTINENT INFORMATION FROM THE FOLLOWING TOPICS AS NECESSARY:
Current system objectives
Shortfalls of current operations
Current workload requirements
Backlogs
Data entry methods, both manual and automated
Data characteristics, contents, structure, size, languages, volatility, accuracy
Data integrity, security, privacy, confidentiality; Existing equipment, peripherals, processors
Software, software languages
Documentation, accuracy
User satisfaction, system drawbacks, failures
System successes, things that work well
Support costs, future costs, overruns
5.2 Alternative Analysis
IDENTIFY THE POTENTIAL ALTERNATIVES FOR ACCOMPLISHING THIS PROJECT. FOR EXAMPLE, ONE ALTERNATIVE COULD BE TO BUILD A SOLUTION IN-HOUSE. ANOTHER ALTERNATIVE COULD BE TO BUY THE SOFTWARE FROM A VENDOR, AND TAILOR IT TO SUPPORT THE ORGANIZATIONS BUSINESS. STILL ANOTHER ALTERNATIVE MIGHT BE TO ACCOMPLISH ONLY PART OF THE DESIRED SOLUTION IN A PHASED APPROACH TO THE PROJECT. INCLUDE SPECIFIC TECHNOLOGIES IN THIS SECTION ONLY IF THEY ARE REQUIRED BY ORGANIZATIONAL CONSTRAINTS OR ARCHITECTURAL STANDARDS. INCLUDE ENOUGH DETAIL TO THOROUGHLY DESCRIBE THE POTENTIAL ALTERNATIVES, AND DIFFERENTIATE BETWEEN THEM.
Include the following general information for each alternative:
General description including what the alternative is, how it would be implemented, and how it would work after implementation. Include additional details such as specific interfaces, tools required, architecture requirements, support, etc.
Estimated time frame
Specific assumptions and constraints
Advantages
Disadvantages
5.3 Recommended Alternative
SELECT ONE OF THE ALTERNATIVES TO BE CARRIED FORWARD. PROVIDE JUSTIFICATION FOR WHY YOU CHOSE THIS ALTERNATIVE. PROVIDE PRELIMINARY COSTS TO DEVELOP AND MAINTAIN THE PROPOSED SOLUTION.
5.4 Project Milestones
LIST THE MAJOR EVENTS BY WHICH YOU INTEND TO MEASURE YOUR PROGRESS ON THE PROJECT. THE MAJOR MILESTONES SHOULD COINCIDE WITH THE DELIVERABLES. IT IS NOT NECESSARY TO IDENTIFY A SEPARATE MILESTONE FOR EACH DELIVERABLE. HOWEVER, IT SHOULD BE CLEAR FROM THE MILESTONE DESCRIPTION WHICH DELIVERABLES ARE COMPLETED BY THAT MILESTONE.
Events that must be reported include: project start date, development completion date, operational date and post-implementation evaluation date. Any other important deadlines or key management checkpoints critical to project success, such as procurement dates, budget deadlines, legislation enactment dates, or partial implementation dates, should also be included. Project management milestones should be identified at no less than three-month intervals during the life of the project.
Most milestone completion dates are represented by elapsed days/months from the project approval date. However, if the project includes dates mandated by legislation, show these specific dates as the milestone.
|Project Milestones |Completion Date |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
5.5 Cost Analysis
ESTIMATE THE COSTS AND INCOME OF YOUR SELECTED ALTERNATIVE FOR THREE TO FIVE FISCAL YEARS FROM THE BEGINNING OF THE PROJECT, DEPENDING ON THE PROJECT DURATION AND SIZE.. PRESENT THESE HIGH LEVEL ESTIMATES IN THE FOLLOWING “COST ANALYSIS TABLE.” REMEMBER THAT THIS IS ONLY A PRELIMINARY ESTIMATE. IT WILL BE USED AS A GUIDE TO ALLOCATE RESOURCES, NOT TO MEASURE THE SUCCESS OR FAILURE OF THE PROJECT. A MORE ACCURATE ESTIMATE OF BOTH SCHEDULE AND RESOURCES WILL BE DERIVED DURING THE PLAN PHASE, IF THE PROJECT IS APPROVED.
Cost reductions or personnel-year reductions should be reported as negative numbers, while cost increases or personnel-year increases should be reported as positive numbers. If the proposal modifies or replaces an existing operation, savings and cost avoidance should be based upon comparison with the current method of program operation. If the proposal recommends a new system, provide estimated costs for the proposed information technology capability. If the proposed solution will increase program income (i.e. tax revenues, collectable audit exceptions, accounts receivable, etc.) such increase should be reported as negative numbers under “Program Income.”
| |FY |FY |FY |
| |PYs |Costs |PYs |Costs |PYs |Costs |
|One-time Costs | |$ | |$ | |$ |
|Continuing Costs | |$ | |$ | |$ |
|Impacted Program Costs | |$ | |$ | |$ |
|Program Income | |$ | |$ | |$ |
|Net Program Costs | |$ | |$ | |$ |
|Cost Savings | |$ | |$ | |$ |
|Cost Avoidance | |$ | |$ | |$ |
5.6 Source of Funding
INDICATE THE SOURCE OF FUNDING ANTICIPATED FOR THE PROPOSED PROJECT. IF THE PROJECT IS TO BE FUNDED FROM MULTIPLE SOURCES, LIST EACH SOURCE. EXAMPLES INCLUDE THE STATE GENERAL FUND, SPECIAL FUNDS, FEDERAL GRANTS, INTERAGENCY REIMBURSEMENTS, REDIRECTION FROM EXISTING BASELINE FUNDS, AND CONTRACTS. ALSO, STATE IF THE FUNDS HAVE BEEN BUDGETED FOR THIS PURPOSE.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- program organization management ocm plan
- the project charter gives a clear picture of the project
- doit enterprise architecture planning project
- new mexico department of information technology nm doit
- business impact analysis bia business questionnaire template
- development project plan template
- project oversight sow west virginia
- sample project plan search
- project team roles and responsibilities
Related searches
- duties of the project manager
- role of the project manager
- detailed picture of the knee
- picture of the knee muscles
- picture of the element table
- picture of the water cycle labeled
- responsibilities of the project manager
- picture of the future
- picture of the stomach organs
- picture of the abdominal organs
- picture of the devil satan
- picture of the anatomy abdomen