A framework for the management of all IT projects must be established to ensure the correct prioritization and coordination of all projects according to priorities established by the Board of Regents, the Chancellor, and institution presidents. This framework may include, but is not limited to, the following:
- Business case
- Project scope to include deliverables and requirements
- Sponsor engagement and appropriate sign off
- Schedule, preferably including resources
- Method for tracking issues, risks, and decisions
- Change management approach
- Risk management approach
- Testing and implementation
- Post-implementation review
The project management framework should define the scope and boundaries of managing projects, as well as the method to be adopted and applied to each project undertaken. This approach:
- Ensures project risk management and value-added delivery to the organization;
- Reduces the risk of unexpected costs and project cancellation;
- Improves communications to, and involvement of, stakeholders and end users;
- Ensures the value and quality of project deliverables; and,
- Maximizes their contribution to IT-enabled programs.
As a goal, a proven, full life cycle project administration methodology must be implemented, enforced, and integrated into the culture of the entire organization. An ongoing initiative to identify and institutionalize best project management practices should be implemented. An IT strategy for sourcing development and operational projects should also be defined and implemented. Organization-wide planning of programs and projects ensures that user and IT resources are best utilized to support strategic initiatives.
Reference: Institute, P.M. (2008). A guide to the project management body of knowledge. (4th ed.). Newton Square: Project Management Inst.
A project management approach should be established commensurate with the size, complexity, and regulatory requirements of each project. The project governance structure should include the roles, responsibilities, and accountabilities of the various personnel involved in the project, and the mechanisms through which they can meet those responsibilities. These personnel may include, but are not limited to,
- Program or executive sponsor(s)
- Project sponsor(s)
- Project leads
- IT steering committee
- Project manager
- Project management organization
- End users
All IT projects must have sponsors with sufficient authority to own the execution of the project within the overall organization strategic plan. To the degree possible, these sponsors should exist outside of the IT department. Stakeholders and end users should be engaged in the work of the program, including projects, to ensure success and collaboration.
The project manager and project management organization should work with the appropriate personnel to develop the appropriate documentation for the project during initiation. This documentation may include several types of documents, such as a business case, a project scope, and other documents that define key aspects of the project such as goals, benefits, risks, resources required, sponsor, success criteria and metrics, etc. Templates for a business case, project scope, change management plan, and risk management plan are shown in Section 2.3.
A formal, approved integrated project plan should be established to guide project execution and control throughout the life of the project. The project plan should be maintained throughout the life of the project, and changes to it should be approved in line with the IT governance framework. Planning should include documentation of program and project interdependencies so as to minimize risk to all projects undertaken within a program or service.
Working with the project team, the organization should develop the project plan, including the project schedule, change management and communications plans, and the way in which risks, decisions, and issues will be tracked and managed during the project lifecycle. The change management plan should establish the mechanism by which all changes to the project baseline, including cost, schedule, scope, and quality, will be appropriately reviewed, approved, and incorporated into the project plan.
Project risks should be eliminated or minimized through a systematic process of planning, identifying, analyzing, monitoring, controlling, and responding to the areas or events that have the potential to cause unwanted change. Risks should be identified and centrally recorded. Refer to Section 6.0, Risk Management, of this Handbook for more information.
During the execution phase, the project team should execute the project plan in compliance with the project scope. Approval of the project should be based on IT governance decisions, while approval of subsequent phases should be based on review and acceptance of the deliverables from the previous phase. In the event of overlapping project phases, an approval point should be established by program and project sponsors to authorize project progression.
2.2.4 Monitoring and Controlling
The project timeline, scope, and budget must be monitored and controlled per the project and change management plans during the controlling phase of the project. Project performance should be measured against key project performance scope, schedule, quality, cost, and risk criteria. Deviations from the project plan should be identified and assessed for impact on the project, and results reported to key stakeholders. Remedial action should be recommended, implemented, and monitored, when required, in line with the program and project governance framework.
A project should be closed when the project sponsor agrees that the project scope has been satisfied. At the end of each project, the project stakeholders must ascertain whether the project has delivered the planned results and benefits. Any outstanding action items that are required to achieve the planned results of the project should be identified, communicated, and disposed of as needed. Project documentation should be archived, and lessons learned for use on future programs and projects should be identified and documented.