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.
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.
The project reporting relationships are explicitly drawn out using a tool such as MS Visio. For projects of large scale and multiple work groups within the project, this representation is important in order to clarify roles and responsibilities.
The Roles & Responsibilities Examples is a comprehensive list of project roles and responsibilities – governance, delivery and some stakeholders common to many projects; at the same time, only some of the roles and responsibilities will be relevant in projects we undertake. Part of the planning of the project involves assessing the composition of the team to ensure the project team has appropriate responsibilities and skills to getting the job done, and adequate representation of stakeholder interests. The examples can be used by the Sponsor and PM in setting accountabilities and identifying team gaps early in the process.
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:
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 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:
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.
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.
The procurement management plan describes how procurements for the project will be managed. Some aspects covered will be:
Purchasing Services provides help throughout the process; the Purchasing Services website is a useful reference.
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.
Plan for Managing Issues
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.
Statement of Intended Operations Organization
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.
Schedules - Full
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.
The change request is used to formalize agreement to changing scope, budget or schedule.
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.
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.