ARCHIVED - Audit of IT Systems under Development – Phase 1
Internal Audit Report

This page has been archived.

February 2007

Table of Contents

• Executive Summary
• Introduction
  • Background
  • Objectives and Scope
  • Audit Criteria
  • Approach and Methodology
  • Purpose
• Overview of CBSA System Development
• Audit Findings
  • Project Management Framework
  • Prioritization of the Portfolio of Projects
  • Business Unit Involvement
  • Quality Management System
  • Risk Management
• Appendix A - Audit Criteria
• Appendix B - List of Acronyms

---

Executive Summary

The audit of Canada Border Services Agency (CBSA) IT systems under development - Phase 1 was identified as a high priority of the CBSA’s Risk-based Multi-year Audit Plan. This plan was approved by the Audit and Evaluation Committee on March 17, 2005. The audit was conducted by Interis Consulting Inc. between March and May 2006.

The principal objective of this audit was to provide the necessary assurances to the CBSA that its integrated project management and system development practices and procedures for automated business systems under development are adhering to the internal policies and procedures that have been established by the CBSA and the current Management Control Framework (MCF), including governance, risk management and control over the IT systems under development projects. Additionally, a further objective of this initiative was to identify improvement opportunities to the existing internal CBSA policies and procedures for managing IT systems under development. This report presents the findings from Phase 1 of the audit, which was to review the management framework for the development of automated business systems.

Audit Findings

Based on the work conducted in Phase 1, the audit noted that a management control framework for the development of automated business systems is in place. However, opportunities exist to strengthen this framework to ensure adequate governance, risk management and control over IT systems under development projects. The conclusions reached in this phase of the audit will be further examined for their impact in Phases 2 and 3.

The audit noted a number of strengths in the controls over IT systems under development that can provide the foundation for building a strong management control framework over IT systems under development, namely a governance structure and a project management framework. Given the newness of the Agency reorganization, many of the processes are still in early development and have not matured in the organization. New committees are being formed, roles and responsibilities are being clarified, and specific deliverables are being developed. These activities are indicators that the Agency is making progress toward enhancing its control over IT systems under development.

The following key areas of control that should be strengthened include:

• Project Management Framework - The Project Management Framework is not fully defined and does not include processes such as:
  • gate approvals where predefined gates are established for management’s formal evaluation of the continued realization of benefits and a go/no-go decision;
  • project status reporting on project cost tracking against budget;
  • processes to consolidate individual project schedules into one master schedule.
• Project Prioritization - The process to realign priorities and resources in-year for the portfolio of projects, when new initiatives are introduced, has not been sufficient, given the capacity limitations of the Agency. Prioritization of projects is a particular challenge for the Agency. The Agency does not have full control over its priorities to drop or realign existing priorities, given the external influences and pressures.
• End User Involvement - End users are not always sufficiently engaged in the system development process, particularly in the acceptance of the functional design, final testing and approvals of the system before it is put into production, and the formal review and acceptance of scope changes.

Management’s Response

Management has carefully reviewed the report and provided management action plans to address the audit recommendations and the expected date of implementation for each action.

1.0 Introduction

1.1 Background

The audit of CBSA IT systems under development has been identified as a high priority of the CBSA’s Risk-based Multi-year Audit Plan. This plan was approved by the Audit and Evaluation Committee on March 17, 2005. The audit was conducted by Interis Consulting Inc. between March and May 2006.

1.2 Objectives and Scope

The principal objective of this audit was to provide the necessary assurances to the CBSA that its integrated project management and system development practices and procedures for automated business systems under development are adhering to the internal policies and procedures that have been established by the CBSA and the current Innovation, Science and Technology Branch’s (ISTB) Management Control Framework (MCF) including governance, risk management and control over the IT systems under development projects.

Additionally, a further objective of this initiative was to identify improvement opportunities, to the existing internal CBSA policies and procedures for managing IT systems under development.

To achieve these objectives, the internal audit plan was broken down into the following three phases.

• Phase 1 - Review of the ISTB management framework for the development of automated business systems
• Phase 2 - System under development audit of a selected system
• Phase 3 - System under development audit of a selected system

The audit deliverable for Phase 1 was to:

• Provide an assessment of the adequacy and effectiveness of the CBSA’s current management control framework, which will include current project and system development management practices in the CBSA;
• Select two of the CBSA’s current system development projects for a more comprehensive audit review of their application of current controls and governance processes.

The audit deliverable for Phases 2 and 3 will be to:

• Provide an assessment of the degree to which the two selected system development projects are effectively and appropriately applying:
  • internal CBSA policies and procedures for system development projects, and
  • internal CBSA system development methodology.
• Provide recommendations for improving policies and procedures within the CBSA for future system development projects.

1.3 Audit Criteria

Audit criteria for this two-staged initiative were developed based on risk elements inherent in system development projects, as well as public sector trends for effective governance of system development project lifecycles. A detailed set of audit criteria was established, factoring in the primary influences that can significantly affect system development projects in the federal government; i.e. management structure and processes, system development lifecycle policies and standards, as well as planning and acquisition process and procedures. The detailed audit criteria were used to assess CBSA practices. These audit criteria will form the foundation for a more comprehensive assessment of the two selected business system development projects (i.e. Phases 2 and 3).

It was noted during the initial audit planning that business system development projects at the CBSA are inherently exposed to risk, given the following conditions:

• The system development methodology has been combined to include both the project management and the system development lifecycle stages;
• The CBSA has undergone significant re-organization;
• The CBSA has had to adopt and adapt separate system development processes, including separate IT infrastructures that were established in the predecessor departments (primarily the Canada Revenue Agency (CRA) and Citizenship and Immigration Canada (CIC)); and
• The CBSA faces challenges from aggressive delivery timelines that are externally imposed.

Key control areas addressing inherent risks were identified, based on the Treasury Board Enhanced Management Framework, and the Control Objectives for Information and related Technology (CobiT) Framework issued by the IT Governance Institute. The audit criteria to be used for the initial assessment of the CBSA’s overall business practices, general controls and governance processes for IT systems under development projects, have been organized into the following six categories:

• Governance
• Business Benefits
• User Requirements
• Project Management
• Technical Solution
• Business Transformation

The audit criteria are presented in Appendix A.

1.4 Approach and Methodology

The approach and methodology was risk-based and compliant with the TBS Policy on Internal Audit and Institute of Internal Audit (IIA) Standards. The audit was conducted in accordance with an audit program that defined audit tasks to assess each criterion. Through interviews and a documentation review, we assessed the current practices against the criteria and formally assessed the effectiveness of each practice.

Interviews were conducted with representatives of the ISTB, including Planning and Architecture, Major Project Design and Development, Border Systems and Technology Services.

Phase 1 of the audit was conducted between March and May 2006.

1.5 Purpose

The purpose of this document is to present the findings from the Phase 1 of the audit.

2.0 Overview of CBSA System Development

The Canada Border Services Agency (CBSA) was created in December 2003 and brings together the Customs Branch of the former Canada Customs and Revenue Agency (CCRA), as well as parts of the Appeals and Compliance branches that supported customs; the intelligence, interdiction and enforcement program of CIC, and the import inspection at ports of entry program from the Canadian Food Inspection Agency (CFIA). In October 2004, the immigration functions at ports of entry were also transferred to the CBSA. The Agency is part of the new Public Safety and Emergency Preparedness portfolio and its mission is to ensure the security and prosperity of Canada by managing the access of people and goods to and from Canada. The Agency is responsible for the administration and enforcement of approximately 90 domestic acts and regulations on behalf of other federal departments and agencies, as well as international agreements. The Agency has 1,200 points of service and 40 foreign operations. The 2005-2006 budget is about $1.12 billion and the Agency employs over 12,000 staff.

The mission of the Agency is to facilitate the movement of commercial goods and people into and out of Canada in a manner that supports the prosperity of the national economy, while ensuring that security and safety concerns are addressed.

The operations of the Agency are highly dependent on information systems and technology, which are developed, implemented and managed by the Innovation, Science and Technology Branch (ISTB). The organizational structure of the CBSA and ISTB [ 1 ] is presented below.

CBSA / Innovation, Science and Technology Organizational Structure

When the CBSA was formed, the Major Projects Design and Development (MPDD) Directorate was moved intact from the Customs Branch of CCRA to the Innovation, Science and Technology Branch (ISTB). This brought together the business directorates, including MPDD, which traditionally represented and reported to the business sponsor, with the IT directorates reporting to the same Vice-President. The final organizational structure within ISTB continues to evolve. For instance, the organization of the architecture function is currently under review, since it is now split between two Directors General.

The scope of system development activity at the CBSA is significant, with annual spending on the development and maintenance of systems, infrastructure and related technology expected to be in the $150 to $250 million range over the next few years. There are currently 32 major systems projects, mostly systems under development projects, in the ISTB plan, with several more identified as potential future projects. Systems projects are clustered into three categories, as shown in the table below:

Cluster	Number of System Projects [ 2 ]
People	13
Commercial	6
General	13
Total	32

All the people and commercial systems projects are in support of the Enforcement and Admissibility branches, which act as the project sponsors, both individually and jointly. Many projects are multi-year with multi-million dollar budgets, split into many sub-projects that have evolved and grown over the life of the project. Many of these initiatives are externally driven and a response to evolving government policies.

Since its creation, the Agency has been challenged to integrate disparate systems development environments that address complex business issues, while responding to a wide variety of initiatives. The Agency currently uses different systems development methodologies due to the reorganization, but is moving toward one standard, the Rational Unified Process methodology [ 3 ]. The systems development process is largely driven by dictated schedule requirements and the production release cycle. Currently, there are two to four main releases annually. Much of the CBSA IT infrastructure continues to be supported by the CRA.

3.0 Audit Findings

Based on the work conducted in Phase 1, the audit noted that a management control framework for the development of automated business systems is in place. However, opportunities exist to strengthen this framework to ensure adequate governance, risk management and control over IT systems under development projects. The detailed audit findings for Phase 1 are described below. The audit criteria will be further examined for their impact in Phases 2 and 3 of the audit.

3.1 Project Management Framework

The project management framework is being used for many of the newer projects and development continues in order to have a fully defined framework.

A project management framework (or lifecycle) to manage systems under development is currently in development and refined with supporting tools and templates for implementation. The framework is currently being aligned to the project stages defined in the Treasury Board’s Enhanced Management Framework for IT Projects. The six key phases of a systems project development in the CBSA are defined as:

• Initiation - where the key outputs of the phase are a conceptual business case, an approved scope statement and an approved project charter;
• Feasibility and Planning - where the key output of the phase is a feasibility and options report, an update to the business case and class D-type cost estimate;
• Analysis and Design - where the key output of the phase is the final approved business case (with class A-type cost estimates) and approved requirements (as defined in the business use cases and the system use cases);
• Construction (Development and Testing) - where the key outputs of the phase are approved implementation plans, change requests, test plans and results, and the completed solution is ready for implementation;
• Implementation - where the key outputs of the phase are training, deployment of the solution and corrective actions; and
• Post-implementation - where the key output of the phase is the post-implementation review.

This framework provides the foundation for building a strong management control framework over systems under development. For some outputs, templates, based on CRA processes, existed. The new templates and processes for the early development phases are being used for many of the newer projects. However, given the newness of the Agency reorganization, many of the processes and document templates are still in early development and have not yet been implemented. This is characteristic of a new organization that has not yet matured in its processes. Nevertheless, these activities are indicators that the Agency is making progress toward enhancing its control over systems under development.

The audit noted that the project management framework could be enhanced by implementing or improving the following components:

• Gate Approvals - The CBSA project management framework separates the system development into clear phases. However, this framework could be enhanced by having predefined gates, where management is engaged to evaluate the continued realization of benefits formally and provide a go/no-go decision. The auditors noted that approval decisions are made at the project outset and informally at various times throughout the development, but not as a formal gate decision. Neither were decisions well documented. With a formal gating process, we would expect to see a summary of key criteria used to assess the potential success of a project at the conclusion of each milestone for presentation to senior management with the decisions clearly documented and communicated. A formal gate approval process with predefined milestones would minimize the risk of continued project funding where benefits are not being realized or where a project is under-performing.
• Project Status Reporting - Project status is reported through the quarterly Executive Dashboard (Dashboard), which identifies the project health (green, yellow, red), and is informally determined. The Dashboard provides high-level summary information on schedule delays or scope changes. To supplement the Dashboard, presentations are provided to the Innovation, Science and Technology Committee or other governance committees, when requested, to highlight the changes from the previous Dashboard as well as to identify the higher-risk projects (yellow, red). We noted, however, that financial performance against budgets was not included in the Dashboard or in the presentations that we reviewed. A good management practice would be to provide management with all project status information, including performance on budgets, for effective decision making.
• Cost Monitoring - Costs are reviewed at the responsibility centre level for project deficits or surpluses. Costs for individual projects are included at this level, but are not identified or tracked separately. As well, there is no accumulation of costs by individual project that involve two or more responsibility centres. Tracking total project costs from all responsibility centres would enable appropriate oversight, so that potential cost issues are identified sufficiently in advance and discussed with senior management.
• Master Schedule - The planning and scheduling of resources is addressed through the release schedule, which integrates all projects planned for the next and subsequent releases. However, the audit found that the release schedule is focused more on deploying the specific systems for the next release, rather than integrating project schedules to manage resources over the long term. There is no master project schedule that integrates individual project schedules and identifies key milestones and interdependencies. A master schedule could improve the long-term allocation of resources, identification of interdependencies and efficiencies through an integrated schedule.
• Benefits Realization - Business benefits are identified within the business case and could be improved through better definition; i.e. key success factors, measurable controls and expected progression schedules, to assist in monitoring all projects. Through extensive interviews and a comprehensive review of a specified business case, we identified that business benefits were not fully explored or defined within the documentation. A post-implementation review is conducted in some cases to assess the realization of benefits; however, a formal procedure would help to guide how business benefits should be defined at the project outset and monitored for realization.

Recommendation

1. Agency management should continue to develop a project management framework that includes the following:
   1. The formal evaluation at predefined gates by management to ensure the continued realization of benefits with a formal go/no-go decision. The approach to project gate approvals should be risk-based, such that larger, higher-risk projects require more rigorous review than smaller, low-risk projects.
   2. A project status reporting regime such that project managers regularly provide information on project performance for budgets (in addition to schedule and scope, which are currently being reported). Financial reporting should include quantitative financial data such as the sources of funds, spending to date, forecast costs to year end and anticipated shortfalls or surpluses.
   3. A process to track total project costs across all responsibility centres regularly, to ensure that projected deficits (or surpluses) by project can be identified and discussed in a timely manner.
   4. A project planning regime that includes the establishment and regular maintenance of an integrated master project schedule that identifies key deliverables and interdependencies across projects.
   5. A benefits realization framework, where the benefits are clearly defined at the outset as part of the selection process, then monitored and tracked for realization on completion.

Management Action Plan	Completion Date
1a) Management has implemented a process to ensure that gates are clearly defined within the project management lifecycle and the realization of benefits is fully documented.	Completed
1b) A project status reporting regime such that project managers regularly provide information on project performance for budgets (in addition to schedule and scope, which are currently being reported), combined with a process to track total project costs regularly across all responsibility centres to ensure that projected deficits (or surpluses) by project can be identified and discussed in a timely manner.	April 2007
1c) Management will further develop its integrated master project schedule to identify interdependencies between projects clearly.	February 2007
1d) Management will develop a business case process to ensure that key requirements for building a business case are clearly defined and documented. A benefits realization framework will be incorporated within the process.	March 2007

3.2 Prioritization of the Portfolio of Projects

The process to realign priorities and resources in-year for the portfolio of projects, when new initiatives are introduced, should be strengthened to ensure the Agency’s capacity is given appropriate consideration.

Priorities within the portfolio of projects are established iteratively through negotiations at all levels, but particularly when managing the release schedule. However, prioritization of projects is a particular challenge for the Agency. New projects are introduced as a result of new CBSA initiatives, but also because of external influences or pressures. Even as these new projects are introduced, existing projects often remain a top priority. As such, the Agency has difficulty in realigning its priorities to drop or modify existing projects. Nevertheless, the Agency has capacity limitations and, as a result, there is a risk that resources are being spread too thinly and the time to complete projects is growing long. The audit team was informed that priorities are regularly discussed at the Innovation, Science and Technology Committee; however, the documentation of the priorities or decisions was not provided. The Agency could benefit from a formal process that identifies, assesses and communicates the risks and impacts on the portfolio of projects from introducing new initiatives mid-year in order to make informed decisions on realizing priorities.

Prioritization for system development is not always driven by the CBSA long-term business strategy or vision. Although the business needs and objectives of the branches are monitored at various levels, they are not consolidated to inform longer-term system planning. A formal client relationship management model that liaises with the business groups to identify and consolidate business requirements would facilitate the planning function. A planning calendar was recently prepared to identify the system releases planned for the current fiscal year 2006-2007, but should be extended beyond one fiscal year to identify where new projects can be accommodated.

Recommendations

Agency management should:

2. Establish a formal process that fully assesses the risks and impacts on the portfolio of projects from introducing new initiatives in-year for senior management decision making on realigning priorities and resources.
3. Ensure the system requirements of the business groups are identified, prioritized and planned sufficiently early.

Management Action Plan	Completion Date
2) A planning framework is under development by management that will clearly define formal processes and evaluation criteria to support senior management decision making for priorities and resources.	June 2007
3) Management will ensure the feasibility and planning phase process includes project planning activities for system requirements, where full business and system requirements are captured and aligned to the corporate infrastructure.	March 2007

3.3 Business Unit Involvement

Business units are engaged in the system development process, but the audit noted some stages where their involvement could be improved.

Governance over IT systems under development is evolving at the CBSA as the role of business units in the development process has not been fully established and relationships are still being formed. Many senior managers are new to the CBSA and its predecessor departments.

Within ISTB, a governance structure is in place where Directors General and Directors from all directorates meet regularly to discuss project activities. As a result, communications and relationships within ISTB have evolved to improve the level of project oversight within the branch. The following committees exist within ISTB to discuss IT systems under development:

• ISTB Director General Forum - whose mandate is to discuss project management issues and risks, and to provide a project status update. It is attended by all Directors General within the ISTB.
• ISTB Directors Forum - is similar in mandate to the ISTB DG Forum, but is attended by all Directors within the ISTB.
• Other project management and technical committees are established to discuss and manage individual project progress and technical issues and risks.

Business units are formally engaged in system development through the following committees:

• Innovation, Science and Technology Committee (ISTC) - whose mandate is to review and make decisions on major projects and which is attended by members of the Executive Management Committee.
• Director General cluster meetings to discuss travellers, commercial or general ISTB projects. They are attended by the relevant Directors General from the business branches and the ISTB. The status and risks of many projects are discussed throughout system development.
• Project teams - in some cases, business representatives participate in project teams throughout the system development.

Business unit representation and engagement during the project lifecycle is defined by the designated project sponsor and documented within the project charter. Project sponsors and other business unit representatives are typically highly involved at the outset of the project, in preparation of the business case and identification of the requirements, but less so through the development and testing phases. Business units are supported at the end of the system development through training provided by MPDD for the implementation of new system projects. Trainers and the training facility in Rigaud, Quebec, are used on a selective basis. End users are supported through a help desk that provides users with a point to call with questions or problems.

The audit noted stages in the development where business units tend not to be involved:

• Acceptance of functional design - Although business representatives may be involved in the discussions of functional design, it is the project manager from MPDD that accepts the functional design through formal sign-off, not the project sponsor. MPDD engages the business unit during the initiation phase and represents it in approving the business use cases. Improvements could be made to business-requirements documents to include a section for sign-off or approvals. A formal sign-off by the project sponsor from the business unit would demonstrate a direct commitment to the detailed design and agreement with the requirements and solution being implemented.
• Testing - Interviewees indicated that MPDD team members perform the testing. Business representatives are typically not involved in the final testing and approvals of the system before it is put into production. Involving users in final acceptance testing would provide assurances that the system will meet their needs and permit modifications before it is put into production.
• Change Control - A Change Advisory Board is in place within the IT Directorate to assess and approve changes. However, project sponsors or business unit representatives are typically not involved in the formal review and acceptance of scope. Change requests are formally documented, using a standard form with approvals from individuals from the IT Directorate. Scope changes are largely discussed within the ISTB, and, often informally, with the sponsor. A formal process for involving the business units in identifying and assessing the impact of the change would help ensure that the full impact of the change request on cost, time and scope is assessed and understood and documented.

Involvement of the business unit at key stages of the development will ensure that sponsors are fully informed of the final solution being developed, such that it will ultimately meet their needs and expectations.

A working group, Increasing and Strengthening External Partnerships Group, was recently created as part of the new ISTB Partnership Toolkit initiative, to develop strategies, mechanisms and an action plan to improve relationships and partnerships in the Agency. The working group identified the need for a strong, consistently applied governance model to ensure the smooth working and success of all major projects. A key theme identified by the group was the need to engage program partners in decisions on the scope of new initiatives at the initiation phase. One of the group’s recommendations included the need to reach out to partners to identify roles, responsibilities and processes clearly, to engage partners to ensure mutually successful outcomes.

Recommendation

4. Agency management should improve the processes to engage the business unit better in system development through:
   1. final approval of business use cases;
   2. final approval for user acceptance testing; and
   3. participation in a formal change control board, with formal criteria for approving changes after consideration of the full impacts of the change.

Management Action Plan	Completion Date
4a) Management is developing the analysis and design phase process, which includes business use cases and requires final approval by the sponsoring branch.	June 2007
4b) Management is developing the construction phase process, which will incorporate processes for final approval of test plans and results by the VP of the sponsoring branch.	September 2007
4c) Management is developing a formal change management strategy, which will include establishing a formal change management control board.	June 2007

3.4 Quality Management System

Quality management processes vary, depending on individual project managers. A system for the portfolio of projects is not in place.

The Project Management Office (PMO) of the Planning and Architecture directorate produces high-level project information quarterly for executive management through the Executive Dashboard. However, it does not assume a quality assurance role. Quality management processes for adhering to the project management framework requirements vary depending on the individual project manager. Overall responsibility for quality over the portfolio of projects has not been assigned.

A quality assurance function would require the collection of detailed project information such as achievement of budgets, scheduled deliverables and scope delivery for reporting and highlighting to executive management. Such an activity would help to ensure that appropriate project management and steering committees are sufficiently aware of projects that may exceed budget, miss timelines or deliver a reduced scope.

Recommendation

5. Agency management should establish a quality assurance program where responsibilities are assigned for individual projects, as well as for the portfolio of projects.

Management Action Plan	Completion Date
5) Management is implementing a quality management strategy to support the Major Project Governance and Project Lifecycle Framework.	June 2007

3.5 Risk Management

Risks are managed informally at the project level, but a broader assessment and integration within the portfolio of projects could strengthen the risk management process.

A formal project risk-management process involves the identification, analysis, mitigation and monitoring of risks that could jeopardize the success of the project with respect to product quality, schedule and cost. The potential consequences associated with the risk and the tolerance for the risk exposure would be discussed to determine the formal risk response (avoid, mitigate, assume or transfer/escalate). The project team would determine whether the risks are acceptable and what can and could be done to remedy or manage the risk better. A formal escalation process would ensure that senior management is engaged in the risk discussions at the appropriate times.

Project risks are usually identified in the project charters at the outset of each project. However, no one is formally assigned responsibility for follow-up to ensure continual monitoring and updating of mitigation strategies. Many interviewees noted that individual project risks are discussed at the various committees and judgement is used to escalate the risks considered to be high. Problems and issues associated with each project are managed at the project level through formal processes to record and track their development. As well, risks are not integrated and assessed for the portfolio of projects. Meeting minutes reviewed did not reference a list of consolidated project risks or discussion of actions taken to mitigate the risks. Consolidated risk lists were not provided. However, a template has recently been developed to document project risks, although it has not yet been implemented.

Recommendation

6. Agency management should establish a formal risk management framework such that project risks are regularly identified, assessed, treated and monitored.

Management Action Plan	Completion Date
6) Management is implementing a risk management strategy to support the Major Project Governance and Project Lifecycle Framework.	March 2007

Appendix A - Audit Criteria

The audit criteria used for Phase 1 of the audit were:

Control Category	Audit Criteria
Governance	Authority and accountability are defined.
	Projects are prioritized to achieve CBSA objectives.
	Stakeholders are engaged and committed to the project.
	Project performance is regularly measured, reported and monitored.
	Effective oversight bodies are established and include roles with respect to governance, risk management and control.
	Approval decisions are made at key milestones.
Business Benefits	Business benefits are identified and have quantifiable and/or qualitative metrics to track and measure their actual realization.
User Requirements	User requirements are identified, verified, validated and properly documented.
	Management controls exist to manage changes and conflicts across business systems.
Project Management	An integrated project plan is prepared that clearly guides the project execution and control.
	Scope-management processes are in place to ensure that the project scope includes all the work required, and only the work required for completion.
	Cost-management processes are established to ensure that a project is completed within the approved budget.
	Schedule-management processes are properly established and used effectively to ensure the project will be completed on time.
	A quality management system is in place to ensure that the needs for which the project was undertaken will be satisfied.
	Risk management processes are in place to identify, analyze and respond to project risks regularly.
	Project status is regularly monitored and reported.
	Problem and issue-management processes are in place to identify, deal with and monitor problems.
	Communication processes are in place to ensure optimal coordination within and outside the project team.
	Processes are in place to ensure that the project makes the most effective use of the people involved.
	Processes are in place to manage partner and supplier relationships.
Technical Solution	A technical solution is viable in terms of implementing the new technology. System development standards and procedures are established. Feasibility of the technical solution is assessed. Application software is developed in accordance with design specifications, development and documentation standards and quality requirements. Information security requirements are met by all components. Testing is sufficiently planned, performed and documented and covers all components of the information system (e.g. application software, facilities, technology and user procedures). Final test results are reviewed and approved by user management and the IT function. Formal procedures are in place to promote the system from development to testing to production.
Business Transformation	Appropriate governance processes and procedures are in place to address the impacts of changes to users generated by the implementation of these new system development projects; i.e. (listed below): An implementation plan is developed and approved by management from all stakeholder groups, to guide the rollout and releases. Users are sufficiently trained in a timely manner. End user support is clearly established and communicated to users. Calls from users are tracked and acted upon. Escalation procedures are established.

Appendix B - List of Acronyms

Acronym	Description
CBSA	Canada Border Services Agency
CFIA	Canadian Food Inspection Agency
CIC	Citizenship and Immigration Canada
CRA	Canada Revenue Agency
ISTB	Innovation, Science and Technology Branch
ISTC	Innovation, Science and Technology Committee
MCF	Management Control Framework
MPDD	Major Projects Design and Development
PMO	Project Management Office
RUP	Rational Unified Process

Notes

1. As at March 31, 2006. [Return to text]
2. Reference: CBSA IST Committee Executive Dashboard April 2006 [Return to text]
3. The Rational Unified Process (RUP) is an iterative software development process, first released in 1998. The RUP is an adaptable process framework that can be tailored by development organizations to select the elements of the process that are appropriate for their needs. [Return to text]