Project Management Policy
Posted by Pamela Kistler-Osborne on 07 February 2012 04:40 PM
Goshen College IT Project Management Guidelines
Goshen College is committed to continuously improving the delivery of IT solutions within budget, on schedule, within scope and in such a way as to best contribute to accomplishing the college's strategic mission. To this end, these guidelines have been developed to assist IT project leaders in planning and managing their projects.
Definition of Project
Project: A project is a temporary endeavor undertaken to create a unique product, service, or result.
Maintenance and Operational Activities: Activities undertaken in support of an existing product or service, will not be defined as projects so long as the bulk of the effort involves continuation, with improvement, to the current product or service. This may apply whether or not the activity involves significant cost or extensive procurement. For example, routine software upgrades and network component replacements are not necessarily projects. Utilization of of project management principles and techniques in the management of operations and maintenance activities is encouraged whether they are defined to be projects or not.
Research Projects, Research Initiatives, and Instructional Programs: Research projects, research initiatives, and instructional programs are not defined to be projects.
Project Scorecard Terms
Total Expenditures: should include any procurement costs, any contractual costs, and expected budget for new FTEs. It should not include local staff labor costs.
Effect on Business Goals: effect of the project's overall success or failure on the business goals of the unit.
Schedule Risk: degree of schedule compression, schedule uncertainty, amount of schedule dependence between this and other projects, harshness of penalty for schedule overrun
Budget Risk: degree of underfunding, degree of budget uncertainty, amount of budget spent on outside vendor or consulting agency product, harshness of penalty for budget overrun
Quality/Performance Risk: lack of margin of error in results, uncertainty in requirements, presence of externally mandated requirements, harshness of penalty for errors in performance
Complexity: number of departments/units actively working on project, size of staff, duration
Novelty: amount of new technology, new procedures, new management approaches
Planning for Project Success
For any project, it should be the goal of the project manager to consider these guidelines and to take appropriate actions to ensure the success of the project. This should include a) the preparation of documentation that is appropriate to the complexity of the project, and b) the establishment of a plan for oversight, the extent and frequency of which should approprate to the complexity of the project.
Assessing Project Complexity
Assessment of the complexity of a given project should be the responsibility of the project manager, in consultation with the project's sponsor. The Project Scorecard is intended to provide a rule of thumb to help project managers assess the risk and complexity of a project. The risk level can also be assessed by comparing project characteristics to the table of project level indicators in Appendix B below. The Project Management Methodology in Appendix A below can be customized to fit each level, and gives further details on suggested project management techniques.
The project manager should provide documentation that is appropriate to the complexity of the project:
Low-Risk Project Documentation: This can be very simple and brief. The goal is to communicate and document the essence of the project, primarily for informational purposes, both within the college and to the outside world. The Low-Risk Project Worksheet provides a template for providing this information. A low-risk project will typically be described by a sentence or two of text in each of the sections of the worksheet. The level of detail in this documentation should be agreed upon mutually by the Project Manager and the Project Sponsor, with additional input and guidance as appropriate from the ITS or Executive Leadership.
Medium-Risk Project Documentation: Documentation for medium-risk projects should be more detailed than for low-risk projects and the level of detail should be commensurate with the complexity of the project in any case. It may be advisable to consider the use of project planning software, e.g., Microsoft Project, in assembling the project plan and schedule. The project plan should include a Scope Plan, which includes the project objectives and the project deliverables, and which includes at least a simple Work Breakdown Schedule. The Resource and Staffing Plan should indicate clearly the resources to be used and should indicate key or required staff. The Communication Plan should articulate the extent and nature of communications involved in the project. The Budget Plan should be appropriate to the needs of the Project Sponsor. The Quality Assessment should include the processes required to ensure that the project will meet the needs for which it was undertaken. The Security Plan should identify anticipated security issues and indicate how they will be addressed. The Testing Plan should be consistent with the complexity of the project and the associated risks. A Training Plan, if appropriate, should outline plans for training of all anticipated and intended users.
High-Risk Project Documentation: As a rule, Goshen College does not undertake high risk IT projects.
An example of a worksheet for a Low Risk Project is provided here. For most low-risk projects, the full documentation package could be as brief as 2-3 pages. The documentation for higher-risk projects, on the other hand, will be significantly longer.
Appendix A. Project Management Methodology/Life Cycle Overview
Appendix B. Project Level Indicators
Projects at low, medium or high risk levels show some or all of the following properties: