ICT is using the Confluence wiki tool for collaborating during projects as well as keeping a repository of past project information.

For information about when the project artifacts below should be produced, and for information about setting up a project wiki space, see the Project Life Cycle.

Project Proposal

The project proposal outlines what is to be done. It provides enough information for the business process owner and sponsor to understand the terms of the work being undertaken. Information contained in the Project Brief appears in the Project Charter as well; more information is sought up front in larger and more complex projects - additional project assurance and limit information is included.

Governance Structure

Complex projects often face multiple competing needs. Guiding principles support making decisions. As these principles are unique to each project, a template is not applicable.

Example statements for guiding principles:

• Wherever possible and appropriate, the system should facilitate self-service through secure, role-based and real-time access.
• We will take the opportunity to simplify and to reduce redundancy and duplication.

Team Contract

This is a set of guidelines that project team members each agree to live by during the term of the project. It includes team meeting ground rules, meeting guidelines and procedures and any other guidelines the team members want to use in handling meetings, conflicts and decisions.

Risk Assessment & Management Plan

The risk management plan must acknowledge actual and potential threats to the successful delivery of a project and determine the activities required to avoid, eliminate or mitigate the risks. A major concern is the appropriate communication of risk information, in particular where escalation is required. Two techniques for documenting risks are used: the Risk Table in a traditional document or a burn down chart.

Budget Plan

Budget information continues to be developed through the planning of large and complex projects as expected project expenditures are confirmed. All prices need to be discounted to a common base and extended over a 10-year cost of ownership. For larger projects, each of the following cost elements should be covered:

• in-house costs and expenses (including all central support services, administration, overheads etc)
• consultancy fees and expenses, including professional development costs
• new construction or refurbishment costs
• anticipated operating costs in phased implementations
• maintenance costs in phased implementations
• disposal costs
• insurance costs
• others as may be particular to a project

Meeting Notes

Decisions and actions are recorded. Basic meeting notes capturing the discussions held help team members understand the context of decisions or need for additional information. Separate and comprehensive decision records are kept.

Scope Statement

The deliverables that will be produced by the project for the customer or the supplying organization are identified during the project planning stage. Identifying what is and is not included in the project can take different forms depending on the type of project being undertaken. The example shows a high-level scope that can complement the project milestones in a software implementation and integration release schedule.

Procurement Plan

The procurement management plan describes how procurements for the project will be managed. Some aspects covered will be:

• what types of contracts to be used
• who prepares independent estimates
• what policies guide obtaining independent estimates
• how required lead times are handled

Purchasing Services provides help throughout the process; the Purchasing Services website is a useful reference.

Staffing Plan

The governance structure is an aid to detailed organization planning for the project. The staffing plan includes recruiting, skill development, reporting structures, and roles and responsibilities. Contractual agreements are consulted as the staffing plan is developed.

Quality Assurance Plan

This plan describes how the project team will meet the quality requirements. It is created and confirmed early in the project so that the quality of designs and tests meet standards or normal practice. For example, Administrative Information Systems supports software design and code reviews as part of quality management.

During the course of a project, issues that can block the team from achieving project objectives will arise. How issues will be managed, such as the appropriate procedures for escalation, will be addressed in the plan for managing issues.

Project teams are temporary. When the project concludes, the customer's organization takes over the day-to-day operation of the system. In some cases members of the project team will return to the customer's organization or become new members of that organization. Clarifying the expected operations requirements at this stage helps in setting correct responsibilities through the project life cycle.

Most of the projects in ICT that require full oversight are software or network implementation and integration projects. High-level schedules containing gross effort estimates, expected milestones and contingency produce a timeline over the full project (all releases). Detailed 60-day iterative work breakdown and assignments are managed to produce required outcomes regularly; earned value is visible as the team works to complete features within the iterations.

When the communication plan is developed, the media choices and formats for communication bulletins are decided. A template is not provided; however, examples of bulletin formats in use at the U of S can be found at http://www.usask.ca/its/about/news.php

Status Reports (includes risk log)

Every project defines what status reporting is required, for which audience and the frequency. For example, in iterative development, every sprint may end with a status report. Materialized risks, along with the team's response, are brought forward to management formally in the status report.

Issue Resolution Log

The log helps the team monitor issues to closure. An issue is stated as a question and assigned to a team member for follow through to resolution. Issues that are significant have issue resolution documentation prepared; this document much like meeting notes provides context for the recommended action to resolve the issue.

Project Delay Log

Delays are recorded as a support to schedule or scope change during the project. During closure, the project delay log is investigated in order to improve the project process in the future.

Change Requests

The change request is used to formalize agreement to changing scope, budget or schedule.

Lessons Learned

The success and failures of the project process, the technical aspects and the managerial processes are examined by the project team, by the customer and sponsors. The focus is on recommending ways to improve future project performance. Lessons learned are best accumulated through the course of the project and provide valuable team-building exercises.

Closing Report

The closing report is prepared by the project manager as a method to share lessons learned and recommendations for improvement with other project teams. It contains an executive summary of the project's processes and any variances that were approved through change requests.