Foreign Affairs and International Trade Canada

international.gc.ca

Common menu bar

• Français
• Home
• Contact Us
• Help
• Search
• canada.gc.ca

Breadcrumb

1. Home
2. >
3. About the Department
4. >
5. Accountability

Audit Of Information Technology Project Management

(October 2004)

• Executive Summary
• Detailed Findings
  • 2.0 Reliability of Information for Decision-Making
  • 3.0 Methodology
  • 4.0 Risk Management
  • 5.0 Training
  • 6.0 Best Practices
  • 7.0 Conclusion
• Appendices
  • A - Proposed Project Management Deliverable Checklist
  • B - Capability Maturity Model
  • C - Control Objectives for Information and Related Technology
  • D - Project Snapshots
  • E - Contract Planning

Executive Summary

• Key Findings
• Audit Approach

Background

DFAIT is distinctive in its use of Information Technology (IT) since it works primarily through a worldwide network collecting and using information to deliver its programs and services. Within DFAIT there is a growing awareness of the importance of effective management of information and related technology "enablers".

From April 1, 2001 to March 31, 2003, the Department spent approximately $194 million (excluding salaries) on IT costs. Although it is impossible to attribute these costs solely to the Project Management component of new systems and upgrades to existing systems, it is reasonable to assert that the figures indicate a significant Departmental investment. The personnel charged with managing this investment in systems initiatives are gaining recognition as key players necessary to achieve Departmental performance objectives.

To further explore issues related to the management of IT Projects, the Audit Division (SIV) conducted an audit of 12 projects with combined budgets of $50 million, 87 staff and 42 contractors.

The objectives of the audit were to:

• Assess whether mechanisms exist to ensure that IT projects are aligned with corporate objectives;
• Assess whether senior management has reliable information on IT projects for decision-making purposes;
• Assess whether DFAIT has an effective project management approach for systems initiatives; and,
• To identify and promote Best Practices and pre-conditions for the success of projects.

The audit team used criteria drawn from the TBS Enhanced Management Framework, the Software Engineering Institute's Capability Maturity Model, Control Objectives for Information and Related Technology, DFAIT Policy on Approvals Process for Proposed Information Management and Technology Projects, and the DFAIT Project Life Cycle.

Audit findings are presented in the following categories:

• Reliability of Information for Decision-Making
• Methodology
• Risk Management
• Training

The audit includes recommendations which will improve Departmental IT Project Management practices and help to create the preconditions for success on IT initiatives. The report comments on the need to establish consistent performance indicators for use in the management of IT projects. As well, the Department needs to "train for success" by equipping its Project Managers with appropriate work "tools" and ensuring that they receive the training necessary to achieve the "core competencies" required by TBS - before assuming leadership of multi-million dollar projects. In support of these initiatives, the audit recommends the creation of a central Project Management Office (PMO) concept under the auspices of the Chief Information Officer (CIO). As such, the PMO would house expertise with demonstrated project management skills and proven experience to assist all areas of IT development in the Department.

The report identifies weaknesses in the reliability of information reported to senior management on IT initiatives and provides specific measures to improve quality of project information used for decision-making.

The audit notes that, SXE has taken concrete steps to enhance and develop work "tools" to assist project managers. In addition, Best Practices observed during the audit and "success stories" from PRIME, COSMOS, ITAMS, EQAMS, and e-CRM are included in the report as a "lessons shared" exercise.

The audit assessed whether mechanisms exist to ensure that IT projects are aligned with corporate objectives, that is, "are we doing the right things?" To answer this question, the audit team reviewed the New Strategic Planning and Priorities Framework document along with the key results used to measure the achievement of the objectives. The Department's strategic objectives were matched to the objectives of each project. All projects contained elements which were linked to at least one of the Departmental strategic objectives.

However, the Department does not have the mechanisms to measure how successful these activities are because there are no standard project performance indicators in use at DFAIT. Without these criteria, although projects may be "doing the right things", it is not possible to know "how well" they are doing or whether they are successful.

Top of Page

CIO Comments

The audit report's main focus was on the expansion of a Project Management Framework (PMF) throughout the Department and on ways to provide standard Project Management support through the operation of a Project Management Office (PMO).

Over the past year, SXE has been developing a standard PMF, in line with Treasury Board Secretariat Guidelines and Industry Best Practices. This PMF is initially being deployed throughout SXD to test the applicability and fine-tune the process, before we can consider disseminating it within the Department.

IT projects are currently decentralized within the Department. Program Managers can, and do, initiate IT projects without reference to the CIO, let alone SXD.

In 1997, a policy was drafted (Policy on Approvals Process for Proposed Information Management and Technology Projects) to provide a foundation for guiding IMT projects within the Department but was never fully implemented.

SXE intends on presenting to the IMTSC an amended version of this policy which would include the processes to support all Departmental IMT initiatives. The policy would also confirm the need for a PMO to provide standard services as identified within the audit findings.

The PMF developed within SXD has already generated very positive feedback from IT organizations in other Departments. During the IT/IM Global Solutions Day hosted by SXD on June 18, at least five Departments expressed an interest in following up with us on using the Framework: Canadian International Development Agency (CIDA), Passport Office, Canada Customs and Revenue Agency, Correctional Services Canada (CSE) and Citizenship and Immigration Canada (CIC). To date we have met with CIDA and the Passport Office and both expressed an interest in using the PMF in establishing a working group for continued process improvement for the framework. This should help to convince bureaux within the Department of the benefits of the PMF.

The Audit team was very helpful in reviewing their audit observations with us to ensure that we had a full understanding of the observations.

Key Findings

• IT project plans do not consistently provide the required baseline information required by CIO project management standards. Project plans do not identify the resources responsible for project activities.

Reliability of Information for Decision-Making

• Financial reporting on IT Projects does not provide reliable information on costs for decision-making by senior management. The Department needs to implement the use of consistent cost elements which are reported to senior management using one source of information, the corporate financial system (IMS).
• There was no comparison of baseline project plans against updated project plans; accordingly, management does not know whether projects are using resources as originally estimated.
• There are no standard project performance indicators in use at DFAIT. Projects require a written statement of the criteria for success. Without these criteria, although projects may be "doing the right things", it is not possible to know "how well" they are doing or whether they are successful. Similarly, with no success criteria defined, project managers can not demonstrate their success objectively.
• Procurement strategies were not found in project plans even when the projects involved purchasing hardware, software and/or professional services.

Risk Management

• Projects are identifying risks, but they are not documenting strategies for mitigating risks. Therefore management does not know whether risks were reduced or even whether risks materialized and had an impact on the project.

Methodology

• The Departmental governance of informatics is viewed as effective for sharing information, but needs reinforcement in order to strengthen and support a coordinated planning process for managing projects and for establishing Departmental IT priorities.
• There is no coordinated planning process in place within DFAIT for managing projects and no formal process for establishing overarching IT priorities. Although the IMT Steering Committee is viewed positively as useful for information sharing among key IT stakeholders, it requires a more structured process for project approvals on new systems.
• The Department has inconsistent sets of project management deliverables and standards.
• The review of IT project plans showed that Departmental IT project plans do not consistently provide the required baseline information according to the CIO project management standards. Improved reporting and monitoring in this area is needed.

Training

• The Department needs to "train for success" by equipping its Project Managers with appropriate work "tools" and ensuring that they receive the training necessary to achieve the "core competencies" required by TBS - before assuming leadership of multi-million dollar projects.

Best Practices

• Some Best Practices were noted during the audit and these "success stories" from SXEM, PRIME, COSMOS, ITAMS, EQAMS, and e-CRM are presented in the report.

Top of Page

Audit Approach

Preliminary Survey

The purpose of the preliminary survey was to gain a general understanding of informatics initiatives underway within DFAIT, obtain information on project governance, and identify any performance metrics that would be useful for a comparative analysis of the Departmental projects. The survey was also used to establish the lines of enquiry used for the audit.

During the preliminary survey, a web-based questionnaire was circulated to project managers to collect tombstone information on projects, practices and performance standards.

Field Work

The field work phase provided an in-depth examination of the lines of enquiry. The audit team developed a list of projects to include in the audit ensuring that the sample of projects included different types and sizes of IT projects in various branches. Project plans, milestones, resourcing, budgets, expenditures and project status reports were reviewed. The projects audited were:

• Electronic Question & Answer Management System (EQAMS)
• Inventory Technology Asset Management System (ITAMS)
• Micro Mission Project (MM)
• Infrastructure Renewal Initiative (IR)
• Consular Management & Operations System (COSMOS)
• Real Property (RE, PM SAP Modules)
• Ministerial Correspondence Management System (MCMS)
• Electronic Client Relationship Management (eCRM)
• Business Intelligence System (BIS)
• Doing Business with Canada (DBC)
• Virtual Trade Commissioner (VTC)

See Appendix D, Project Snapshots, for a brief description of each initiative.

Detailed Findings

2.0 Reliability Of Information For Decision-Making

• 2.1 Financial Reporting
• 2.2 Project Resourcing
• 2.3 Procurement Planning
• 2.4 Project Monitoring and Control

2.1 Financial Reporting

Financial reporting on IT Projects does not provide reliable information on project costs for decision-making by senior management.

This audit assessed the adequacy of information reported to senior management for decision-making. The audit considered the extent that managers receive consistent financial reporting sufficient to monitor the system's progress through development. Based on information received from the survey questionnaire, it is apparent that DFAIT IT projects do not follow a standard budgeting and costing framework. A more uniform process based on one source of financial information is needed.

None of the projects audited used the Integrated Management System (IMS) reports to monitor their expenditures. The audit team was told that the information in the IMS is not at a sufficiently detailed level for managers. To meet this need, managers are creating their own budgeting spreadsheets, but in doing so, compile IT costs differently. For example, the table below illustrates the different components that the various IT projects include in their budgets.

Top of Page

Table of Budget Components:

It is clear that there are discrepancies in the comparability and completeness of project cost information reported to senior management. In some cases, those Project Managers who are diligent in capturing all project costs may be disadvantaged in comparisons with other Project Managers who understate their project costs. Resource allocation and priority setting decisions, including decisions on further project funding approvals by senior management are, under these circumstances, less than optimal.

These findings are corroborated in a study of Application Management initiated by SXD which reported that the resources assigned to application management activities and the costs allocated to activities and applications were not available in many cases⁽¹⁾.

The issue of consistency of project cost reporting was also identified in the Business Intelligence Post Mortem Report⁽²⁾ which noted that DFAIT lacks a central coordinating agency for maintaining Fund Centre Hierarchies (FCH). Rather than have four systems (IMS, PS, SMS, BI) each maintaining different FCHs, DFAIT would benefit from a central, independent co-ordinating agency to ensure the consistency of the hierarchy.

Recommendations for SMSF

2.1.2 SMSF should implement one central source of Funds Centre Hierarchy within the Integrated Management System. This source should be the one place where all applications can obtain the appropriate detail for managing their IT project costs.

Recommendation for CIO

2.1.3 CIO, in consultation with SFO, should require that a consistent set of cost elements be used for all project financial reporting.

Action and Time Frame

2.1.1 SMSF Response: There are several possible ways financial reporting using IMS at the level of detail recommended could be provided. This requirement could be met using the Project Systems module. Project Systems is currently being used by a small number of users within SRD to manage their projects. Alternatively Internal Orders or Cost Centers within the Controlling Module could be used. SMSF will meet with the main stakeholders to review their financial reporting requirements to determine which functionality would better meet their needs. The level of effort required to implement this functionality could then be assessed.

Time Frame: Underway

2.1.2 SMSF Response: Obtaining a new Fund Centre is a two-step process: obtaining approval from the Human Resources Policy and Strategic Planning Division (HRP) to create a new organizational unit and obtaining approval from SMSF to establish a new fund centre in IMS. The groups responsible for IMS, SMS, HRMS, and BI recently met with HRP to confirm the business process to create new FCs and to make recommendations to ensure that consistent information is created within each system for new FCs. As noted for recommendation 2.1.1 IT Project Managers should use either the Project Systems module or the Controlling module to monitor and track their IT project costs.

Time Frame: Underway

2.1.3 CIO Response: The new PMF (see 2.2.1) already contains cost templates that define a consistent set of cost elements. This will be further refined with the SFO. Project reporting is also being refined and improved project costing is part of this process.

Time Frame: Complete

Top of Page

2.2 Project Resourcing

Resource estimates for IT projects were based on the activities required, deadline imposed and resource availability. However, these baseline estimates are not being compared against the most current resources utilized.

Assigning resources to activities ensures that there is accountability throughout the life of the project for performing the activities and achieving the specified results. The people assigned must have the appropriate authority to perform the assigned responsibilities. The SEI CMMI Software Capability Model indicates that the project manager assigns responsibility and authority for performing processes, developing the work products, and providing the services of the process.⁽³⁾

Resources to be used in the IT projects reviewed were based on the skills available for the specific activities. High level estimates were provided either in Business Cases or Project Initiation Documents. Refinements to the estimates were made as the project progressed and resources became available.

The CMMI model⁽⁴⁾ requires the project manager to monitor the actual values of the project planning parameters against the project plan - specifically to monitor resources provided and used.

In the projects reviewed, it was noted that the resources were listed on project plans next to the activities responsible. However, there was no tracking of actual time against activities in the plan and, therefore, the project managers were at risk of not knowing the accuracy of their work effort budgets.

For example, the following practices were noted in various projects audited:

• No level of effort in the plan.
• Plan does not indicate whether completed activities and resourcing costs were completed to budget.
• Actual duration to complete the project was not shown and the plan did not indicate whether the activity was completed on time or not.
• For project teams with DFAIT employees, estimates were developed by the project team and placed into the project plans. It was not possible to determine whether the activities went over their budget since there was no baseline project plan established.

With no success criteria defined, project managers cannot demonstrate success objectively. The Department needs to put in place measures which reinforce and support demonstrated successes by the Project Managers. Some examples that should be emulated include the following Best Practices:

• The COSMOS.NET project used contractors with a contract which documented the required deliverable. The contractors provided a fixed cost to deliver the product, therefore there was no risk to the Consular Affairs Bureau for any cost overruns.
• Implementation of the Virtual Trade Commissioner was also contracted. The contractor was responsible for developing a detailed project plan using MS Project which included:
  • activities, milestones and critical path;
  • level of effort required to complete each activity; and
  • resources required to complete each activity.

The contractor was required to use the project plan as a baseline and compare any changes in the plan to the original baseline.

The COSMOS.NET and VTC projects had contracts in place to easily access resources when required. Other IT projects using contractors used standing offers to quickly obtain required resources. Contractors were given specific task assignments and asked to provide estimated work efforts and deadlines. Once these estimates were approved, the contractors were responsible for completing the activities, as required. Since contractors provided fixed cost work efforts, there were no cost overruns.

In its project charter, ITAMS described a resourcing strategy for the ongoing support of the application after development⁽⁵⁾. This was the only case noted of an IT project planning for the support of its application.

Recommendations for SXEM

2.2.1 SXEM should modify the DFAIT project management standards to include a provision to place specific project team member names as responsible for each activity.

2.2.2 SXEM project reporting requirements should include the activity duration, work-effort required, and whether resource usage is above, below or on target.

Top of Page

Action and Time Frame

2.2.1 SXEM has developed a standard Project Management Framework (PMF) in light of Treasury Board Secretariat Guidelines and Industry Best Practices. This PMF is currently being deployed throughout SXD, to test the applicability and fine-tune the process prior to disseminating the standard throughout the Department. MS Project is the de facto standard for project planning and has the capacity to record team member names responsible for each activity.

Time Frame: Complete

2.2.2 Project reporting requirements are established to inform the SXD Bureau Management Committee (BMC) of tracked projects identified by BMC. SXEM is investigating the use of MS Project Server 2003, which provides enterprise project reporting and allows for the roll up of project information to the required level of detail for each management level. (See 2.4.2) In the meantime, SXEM will investigate the impact of adding the information recommended into the existing reporting tool.

Time Frame: Fall

2.3 Procurement Planning

There were no procurement strategies or procurement activities outlined in the project plans reviewed.

Past research conducted by the Auditor General⁽⁶⁾ showed that failure to consider the time required for procurement activities during the acquisition phase of an IT Project and its related procurement activities was one of the factors contributing to the failure of IT Projects to meet targets for completion. In addition, the Departmental Review of IT Professional Services Procurement Modernization (May 2002) found there is a large consensus that major problems with lead-time are due to lack of formal procurement and project planning⁽⁷⁾. The review also found that the procurement process is rarely reflected as a critical element on implementation plans.

The Enhanced Management Framework (EMF) for the Management of Information Technology Projects is designed to ensure that government information technology projects fully meet the needs of the business functions they are intended to support, deliver all expected benefits and are completed within their approved time, cost and functionality. It comprises best practices, principles, methodologies, tools and standards that were identified in an inter-departmental initiative and which provide solutions to project management concerns experienced in the federal government.

• The Web site below provides the TBS EMF solutions as defined with the appropriate implementation Plateau. Once a solution or tool has been initialized, its use is expected to be refined and continued through the remaining Plateaux (http://www.cio-dpi.gc.ca/emf-cag/about/abu-ans04_e.asp).

• Plateau 0: Baseline: Ensures that Departments have in place the basic project solutions required to initiate and manage a project including such things as a business case, procurement strategy, project charter; a gating and review process; planning and control mechanisms; and a risk management approach.

• Plateau 1: Project Focus: The objective of this Plateau is to achieve proper planning for projects in DFAIT and to establish sufficient visibility into actual progress to allow senior management to take effective action when the project deviates from plan. It is also in Plateau 1 that actions are taken to ensure project managers have the required knowledge and experience and the tools to support them and the project.

• Plateau 2: Product Focus: This Plateau seeks to establish, at a project level, consistent and effective controls and processes for change management, product integrity and product quality.

• Plateau 3: Organizational Effectiveness: The third Plateau deals with consistency to ensure that the best processes implemented in one project within a department are carried through to the other projects within the organization.

• Plateau 4: Continuous Improvement: The final Plateau deals with improving the organizational effectiveness of DFAIT on a continuous basis (e.g. deliver projects faster, better, cheaper). This Plateau includes quantitative techniques to measure processes, and proactive activities to streamline and improve these and other existing practices.

EMF principles⁽⁸⁾ describe the role of PWGSC. PWGSC is supposed to devise a contracting plan and contract terms and conditions that best meet the requirements of an IT project and the application of the enhanced framework. EMF principles also indicate that Government procurement is complex because it is governed by regulations designed to give equal access to government contracts to all eligible companies. Therefore, projects should involve procurement managers at an early stage of a project. This allows the procurement managers to develop a procurement process that reduces delays, and best aligns the contracting plan with the project plan while still meeting legislative, policy and treaty requirements, and which aligns the contract with the stated benefits of the project.

The SXEM and CIO project management standards require the development of a Procurement Plan for all large IT projects. The procurement plan identifies and tracks the procurement actions required to purchase goods and/or services. The procurement plan should be developed as early as possible during the project life cycle to allow adequate time for the procurement activities and facilitate project planning. None of the large projects reviewed contained documentation that indicated that a procurement strategy and plan had been established. In consultation with contracting and procurement specialists within DFAIT, a process model and generic requirements for contracting were developed and are presented in Appendix E.

The projects reviewed purchased their hardware, software and contractors using one of three methods. One method involved dealing directly with PWGSC to issue a Request for Proposal (RFP) on MERX and to solicit the most cost effective proposal for services and goods. The second method was to use DFAIT procurement staff to liaise with PWGSC when issuing an RFP. The third method involved using a Standing Offer to obtain services. Two of the IT projects which dealt directly with PWGSC were extremely pleased with the results and had no significant delays resulting from using this means of procurement.

On one project a RFP was placed on MERX for 20 days. Then at the request of a Vendor, the posting was extended an additional 20 days. Therefore, the project was delayed at least one month from the original plan. The Project Charter indicates that COTS software purchasing was completed, but there is no mention of procurement as a risk. However, due to issues with TBS on possibly not using a shared system solution, the RFP was further delayed. These issues should have been resolved prior to placing the RFP onto MERX.

On another project, the project plan identifies the task "acquire new servers", but does not identify the time required for the procurement, which in this instance took four months.

Best Practice(s):

• EQAMS and ITAMS provide examples of IT Projects where procurement was documented in the project plans⁽⁹⁾ (see Section 6.0 Best Practices).

Recommendations for SXEM

2.3.1 SXEM, in consultation with the CIO, should update the DFAIT project management standards to ensure that procurement plans are included as a project risk and as an activity in the project plan.

2.3.2 SXEM, in consultation with the CIO, design and promulgate a template for project plans which reinforces the development of project plans which present all deliverables required. (The template should be designed to ensure that all projects of the same size utilize the same plan format.)

Action and Time Frame

2.3.1 This comment was valid at the time of the audit but the PMF has been updated since. There is now a template available for a procurement plan within the Project Management Framework.

Time Frame: Complete

2.3.2 This comment was valid at the time of the audit but the PMF has been updated since. SXEM recommends a project plan template for each of the three project sizes. SXEM also provides some examples of different types of projects such as Infrastructure deployment, Application development etc. to assist project managers.

Time Frame: Complete

Top of Page

2.4 Project Monitoring and Control

There are no standard project performance indicators in use at DFAIT.

In an effective performance management approach, measures are used to create and facilitate action to improve performance. Measures and performance information must link to strategic management processes.⁽¹⁰⁾

An effective performance management system produces information that delivers the following benefits:

• Provides an early warning indicator of problems, and the effectiveness of corrective action;
• Provides input to resource allocation and planning. It can help DFAIT prepare for future conditions that likely will impact program and support function operations and the demands for products and services, such as decreasing personnel or financial resources or changes in workload. Use of measures can give DFAIT lead times for needed resource adjustments if these conditions are known in advance; and,
• Provides periodic feedback to employees, stakeholders, and the general public about the quality, quantity, cost, and timeliness of products and services.

The Treasury Board's Enhanced Management Framework (EMF) for IT Projects describes using an Executive Dashboard⁽¹¹⁾ to provide a quick snapshot for senior management on the overall health of an IT project.

The Executive Dashboard provides quick information on the project's status and highlights critical areas of interest. The Dashboard is used to quickly measure the portfolio of IT projects.

Recommendations for SXEM and CIO

2.4.1 The SXEM and CIO project management standards should be updated to include specific instructions for measuring performance of IT projects. The extent and type of metrics and their reporting should be relative to the size of the project.

2.4.2 Project Management standards should adopt the Treasury Board's Executive Dashboard type of reporting to DFAIT senior management.

Action and Time Frame

2.4.1 SXD project management standards will be updated to include performance measurement of IT projects for each of the three project sizes.

Time Frame: Within this fiscal year

2.4.2 SXEM has had an initiative over the past year to develop an executive dashboard. Due to budgetary constraints the purchase of the MS Project Server 2003 software required for enterprise reporting has been deferred.

Time Frame: To be determined

3.0 Methodology

• 3.1 Governance Structure
• 3.2 Project Approval Process
• 3.3 IT Project Standards
• 3.4 Planning

Top of Page

3.1 Governance Structure

The Departmental governance of informatics is viewed as effective for sharing information, but needs reinforcement in order to strengthen and support a coordinated planning process for managing projects⁽¹²⁾ and for establishing Departmental IT priorities⁽¹³⁾.

IT governance provides the structure that links IT processes, IT resources and information to DFAIT strategies and objectives. Furthermore, IT governance integrates and institutionalises good (or best) practices for planning and organising, acquiring and implementing, delivering and supporting, and monitoring IT performance to ensure that DFAIT's information and related technology support its business objectives. IT governance thus enables DFAIT to take full advantage of its information, thereby maximising benefits, and capitalising on opportunities.

In 1996 the Department reorganized IMT and senior management established an IMT Steering Committee to coordinate all IMT activities in the Department. A Chief Information Officer (CIO) was appointed and participates in the Department's Executive Committee on all discussions involving IMT. The CIO chairs both the IMT Steering Committee and IMT Operations Forum. The CIO also provides mechanisms for the alignment of IMT direction and investments with Departmental objectives.

The governance structure for IT Projects defined by the CIO is:

The governance structure defined by the CIO for the Department is different from the governance structure defined for some of the large IT projects. In two large projects, there is no linkage in the project governance structure to the IMT Steering Committee nor to other governance committees developed by the CIO. No evidence was seen that the IMT Steering Committee approved these projects as required by DFAIT standards.

Conversely, the ITAMS project charter provides an excellent diagram of the project governance and organization. The charter indicates that the CIO is the Executive Sponsor and the Project Director is the Director of SXM Business Management. The project was organized with several committees each with a specific set of responsibilities described in the Project Charter.

Best Practice(s):

• IT governance activities are integrated into DFAIT's governance process and leadership behaviours since the CIO is accountable for providing mechanisms for aligning IMT direction and investments with Departmental objectives.
• IT governance focuses on DFAIT's goals, strategic initiatives, the use of technology to enhance its business and on the availability of sufficient resources and capabilities to keep up with the business demands by requiring the CIO to report to the Executive Committee.

Recommendations for CIO

3.1.1 The CIO should establish a Project Office that will ensure all IT projects adhere to the Departmental governance structure and reporting.

3.1.2 The Project Office should be a centre of excellence for project management within DFAIT by providing (or by assisting with the procurement of) qualified project managers (including consultant resources) to IT projects as required and by acting as a library for project plans.

3.1.3 The Project Office should provide a consistent set of tools and methodologies to projects and act as a repository of reusable project components (e.g., project plan templates, estimating models).

3.1.4 The Project Office should report through the CIO to Executive Committee on whether IT project goals are achieved.

Action and Time Frame

3.1.1 As IT projects are decentralised within the Department, Program managers can, and do, initiate their own IT projects without reference to SXD or the CIO. The existing Policy on Approvals Process for Proposed Information Management and Technology Projects (Nov. 14, 1997) is not fully implemented. The CIO office will review the policy and incorporate the recommendation from this audit. The CIO will present the revised Policy to the IMT Steering Committee for approval.

Time Frame: Winter 2004/05

SXD has established a project office (SXEM) for the SXD Bureau. Once the usefulness of the PMF has been proven within the Bureau, the CIO will propose it as a PMF Standard for the department.

Time Frame: To be determined

3.1.2 The establishment of a Departmental project office as described, would be dependant on the approval by the IMT Steering Committee of the revised "Policy on Approvals Process for Proposed Information Management and Technology Projects". If established, the use of the Project office resources should be mandatory for any project and the Project office would have to be adequately financed, either on a cost recovery basis or through corporate funding. Budgetary constraints on new initiatives will also be a consideration.

Time Frame: To be determined

3.1.3 SXD has a consistent set of tools and a Project Management Framework (PMF), including templates and models. These will be deployed throughout the department by the CIO once we are satisfied that the PMF is ready.

Time Frame: To be determined

3.1.4 The establishment of a department wide Project Office with a mandate to report through the CIO on IMT projects would require greater delegation of authority to the CIO from the Executive Committee.

Time Frame: To be determined

Top of Page

3.2 Project Approval Process

A project approvals process has been established. However, no evidence was seen that the approval process setup by the IMT Steering Committee was used to approve the projects it was responsible for approving, nor has any documented criteria been seen for project approval.

The IMT Steering Committee (IMT SC) is supposed to focus on issues concerning business line leadership of Departmental IMT operations: planning, policy, management, reporting, prioritization of investments, communications and education. It approves IMT strategic plans, policies, projects with medium or high cost, risk or operational impact.

A project approvals process⁽¹⁴⁾ was established and includes the following items:

1. Any proposed IMT project whose total cost of ownership (capital plus five-year operation) is estimated at $200,000 or more, or whose risk and/or impact is judged to be "medium" or "high" shall be subject to the Departmental approval.

2. Proposals to undertake such projects shall be submitted to the IMT Steering Committee through the office of the CIO. The Steering Committee may fully approve such proposals, reject them, or approve them subject to any conditions that it may deem appropriate.

3. Full or "effective" project approval conveys authority to proceed to project completion in the absence of substantive changes to budget, functionality, technology or business objectives sufficient to alter the rationale for which the approval was granted and hence require resubmission (all projects granted full approval will require annual progress reports that will allow the CIO to monitor such changes, as well as a project completion report).

The CIO exercises its authority only on the recommendation of the IMT Steering Committee for new projects with a total cost of ownership of $400,000 or more and for replacement projects with a total cost of ownership of $1,000,000 or more. Projects involving lesser costs may be approved by the CIO without reference to the IMT Steering Committee unless he or she determines that risks and/or impacts are sufficiently high to warrant such consideration.

The CIO's accountabilities include⁽¹⁵⁾:

• Developing the Department's IMT strategic policy and program priorities;
• Consolidating the plans/budgets for all IMT expenditures in the Department;
• Ensuring the establishment of an IMT governance framework, including chairing the IMT Steering Committee and the Major Application Owner's Group and providing overall governance support;
• Providing mechanisms for alignment of IMT direction and investments with Departmental objectives; and
• Ensuring the establishment of IMT performance indicators to measure the return on the IMT investment.

During the audit, a review of project files and IMT SC minutes was undertaken. The audit team was unable to identify any evidence that the approval process set up by the IMT SC was used to approve the project. The TBS EMF principle 4.2.1 states that "IT projects should be aligned with, and support business directions and priorities."⁽¹⁶⁾ This requires that a full business case analysis be performed and that the project approval must be based on how the business case analysis relates the investment directly to the business function. The Business Case must also demonstrate the benefits of the investment to DFAIT or the government and define the business need.

Recommendation for CIO

3.2.1 The CIO, as Chair of the IMT SC, should ensure that Minutes of IMT SC meetings clearly document those IT projects requesting approval, those IT projects approved by the IMT SC, and any projects not approved. Justification for any decision should be documented within the minutes of the IMT SC.

Action and Time Frame

3.2.1 The minutes of the IMT SC presently document requests for approval and approval/rejection. However, not all projects are submitted to the IMT SC for approval. Efforts will be made to ensure that all proposed projects are brought to the attention of the IMT SC and that the IMT SC strengthens its role as a decision making body.

Time Frame: On-going

Top of Page

3.3 IT Project Standards

The CIO has developed project management standards for the Department. SXEM has also developed project management standards for the Department and there are inconsistencies between them. In addition, even with standards, projects are not producing the deliverables required by the standards.

The CIO IT Project standards identify the project life cycle in three phases.

Phase 1 Project Initiation begins at the conception of an idea and concludes at the development and evaluation of a business case.

Phase 2 During the project execution the project activities are executed, tracked and measured.

Phase 3 The Project Close-Out and Wrap up Phase includes evaluating the successful aspects of the project as well as identifying opportunities for improvement, identification of project "best practices" that can be leveraged in future projects, and evaluating the performance of project team members.

SXEM has introduced on its intranet site a set of templates for project planning. The templates follow the same project life cycle as defined by the CIO but the SXEM templates are somewhat different from the CIO templates. For example, the SXEM website identifies three documents required for the Project Initiation: Project Initiation Form, Business Case and Impact Assessment Questionnaire. The CIO identifies the Business Case, Project Brief, Project Charter, Requirements Specification and Project Plan.

Although the majority of the deliverables between the CIO standard and the SXEM standard are the same, there are a number of differences between the two standards.

SXEM also has developed further project management standards that were piloted within SXD. The standards appear to be more flexible than the current standards and define the deliverables required based on the size of the project. The proposed standard defines a Small Project as a project with a budget under $100,000 and requiring up to three staff. The estimated duration of a small project is under six months. A Medium Project is defined as a project with a budget from $100,000 to $500,000 and requiring from six to ten staff with an estimated duration of 12 to 18 months. Finally a Large Project is defined as having a budget of $500,000 or more with ten or more staff and an estimated duration over 18 months.

This differs from the CIO's definition of small, medium and large projects. The Policy on Approvals of IMT Related Projects⁽¹⁸⁾ defines small, medium and large projects based strictly on their approved budgets. A Small Project has a budget under $400,000. A medium size project has a budget under $2,000,000 and a large project has a budget over $2,000,000 requiring Treasury Board Approval.

In addition, the CIO standards do not differentiate deliverables required for small, medium and large projects, whereas the proposed SXEM standards do differentiate deliverables required according to the size of a project. The proposed SXEM standards⁽¹⁹⁾ can be found in Appendix A. (Note: These are currently under revision and were extracted as at the date of the audit.)

Treasury Board also has deliverable requirements that are outlined in its Project Management Guide. The Guide is based on industry best practices, supplemented by lessons learned through government of Canada IM/IT projects. For additional details, see http://www.cio-dpi.gc.ca/emf-cag/pmg-ggp/intro/intro_e.asp. The document contents include the principles of the Project Management Institute's Project Management Body of Knowledge (PMBOK), are based on the International Standards Organization's Software Life Cycle Process (ISO/IEC 12207), and support the principles of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) and other relevant Treasury Board Secretariat (TBS) and external reference materials.

The review of the deliverables developed from the projects included in our audit showed inconsistencies in the deliverables produced. Not all projects created the deliverables required by the CIO Project Management Standards. Where deliverables were produced, it was found that they were inconsistent in their contents and did not adhere to the format prescribed by the CIO project management standards.

Only five projects had project plans and those plans differed in the level of detail produced. Only five projects developed a risk management plan and the detail within the plan differed between the projects. Seven projects had project initiation documents used for approval of the projects and only six projects had requirements definitions. The lack of requirements definitions is significant because it is the document that describes the business needs that are to be met through the application. It is the business requirements that the application must be designed to satisfy.

Recommendation for CIO

3.3.1 The CIO should specify one set of project management standards for DFAIT with a consistent metric to define the size of a project. The standards should allow for differences in the size and risk of projects.

Recommendation for SXEM

3.3.2 The established Project Office should implement a review process to ensure all IT projects produce the required deliverables for the type and size of project.

Action and Time Frame

3.3.1 The project standards have been defined for use within SXD. These definitions are part of the PMF. This Project Management Framework is currently being tested within SXD. Once refined it will be presented by the CIO for use within the Department.

Time Frame: To be determined

3.3.2 Three levels of project have been established depending on size, budget and impact. Each level of project has a set of requirements for reporting required deliverables. This project management framework is currently being tested within SXD.

Time Frame: Underway

Top of Page

3.4 Planning

This review of IT project plans showed that Departmental IT project plans do not consistently provide the required baseline information according to the CIO project management standards. While it was found that all project plans identify activities and milestone dates, not all are identifying resources responsible for project activities.

The audit reviewed a sample of eight IT project plans and found that none of them contained all the information required by the CIO's project plan standard. It was also found that the plans were inconsistent with one another. For example, the audit found all the IT project plans reviewed identified activities (tasks) and start/end dates, however, only three of those plans identified the resources responsible for each activity.

In addition, some of the IT project plans did not identify tasks to develop the deliverables required by the CIO project management standards.

Recommendation for SXEM

3.4.1 SXEM, in consultation with the Major Application Owners' Group (MAOG), ensure that all IT project plans clearly identify the relevant project activities required by Departmental Project Management Standards. This should include, but not be limited to identifying such items as:

• The resources responsible for each project activity;
• The milestone dates for publishing:
  • Quality Assurance Plans;
  • Test Plans;
  • Risk Management Plans;
  • User Training Plans;
  • Level of effort for each activity; and
  • Budget for each activity.

Action and Time Frame

3.4.1 The Project Management Framework established for SXD already requires a work breakdown structure as indicated in the recommendation. The level of detail required is function of the size and scope of the project level.

Time Frame: Complete

4.0 Risk Management

4.1 The project deliverables reviewed during the audit did not identify any risk management strategies. Risks were identified early in some projects but there were no updates to the risks and there were no mitigation strategies.

The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the project to mitigate adverse impacts on achieving project objectives.

According to the Software Engineering Institute (SEI),⁽²⁰⁾ preparing for risks is conducted by establishing and maintaining a strategy for identifying, analyzing, and mitigating risks in a documented risk management plan. The risk management strategy addresses the specific actions and management approach used to apply and control the risk management program including identifying the sources of risk, the scheme used to categorize risks and the parameters used to control risks for effective handling.

Identifying the sources of risk provides a basis for examining changing situations over time to uncover circumstances that impact the ability of the project to meet its objectives. Risk sources are both internal and external to the project. Additional sources of risk may be identified as the project progresses. Establishing categories for risks provides a mechanism for collecting and organizing risks, as well as ensuring appropriate scrutiny and management attention for those risks that can have more serious consequences on meeting project objectives.

Risk management in IT projects improves DFAIT's ability to deliver and manage IT projects. At the project level, the goals of risk management are to pro-actively assess what could go wrong with a project, determine which risks are important to deal with, and implement strategies to deal with those risks.

Treasury Board's EMF has adopted the Software Engineering Institute's (SEI) risk management process⁽²¹⁾. Each risk goes through sequential functions. Risks are tracked in parallel while new risks are identified and analyzed. The mitigation plan for one risk may yield another risk throughout the project life cycle.

Software Engineering Institute's (SEI) Risk Management Process:

The following table describes the risk management processes⁽²²⁾.

• Function
• Description
• Identify
• Search for and locate risks before they become problems
• Analyze
• Transform risk data into decision-making information. Evaluate impact, probability, and timeframe, classify risks, and prioritize risks.
• Plan
• Translate risk information into decisions and mitigating actions (both present and future) and implement those actions.
• Track
• Monitor risk indicators and mitigation actions.
• Control
• Correct for deviations from the risk mitigation plans
• Communicate
• Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks (throughout the duration of the project).

There are standard risks for all projects including: impact on Department, impact of other related projects, impact of staffing, impact on staffing, size of budget, availability of budget, number of activities in project plan, number of project deliverables, work effort, complexity, extent of change in the business function, skills and experience of the project team, the employment of new technology, and the number of organizations involved in the project.

In DFAIT, the audit team was able to identify two projects which demonstrated the use of a risk based approach to project management. The project charter for ITAMS identified ten risks and the risk reduction strategy⁽²³⁾ for each risk. Also, the RFP for eCRM⁽²⁴⁾ identified "Project Challenges". The RFP indicated that the "solution" will operate with the constraints identified in the RFP. These "constraints" were:

• the different topologies of the 135 missions around the globe;
• the technological constraints including desktop standards, network differences, security, server standards, and platform requirements;
• constraints of the Signet 2000 renewal project; and,
• server deployment.

In addition, the eCRM RFP described the aggressive timeline, conversion of existing legacy data, requirements for bilingualism and training as additional risks.

Recommendation for the Project Office

4.1.1 The established Project Office, in consultation with the CIO, should establish and maintain a formal risk management strategy for IT projects. The strategy should address at least the following items:

• The scope of the risk management effort;
• Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication;
• Project-specific sources of risks;
• How these risks are to be organized, categorized, compared, and consolidated;
• Parameters, including likelihood, consequence, and thresholds, for taking action on identified risks;
• Risk mitigation techniques to be used, such as prototyping, simulation, alternative designs, or evolutionary development;
• Definition of risk measures to monitor the status of the risks; and
• Time intervals for risk monitoring or reassessment.

Action and Time Frame

4.1.1 Although SXD does not have a formal risk management strategy, standardized project deliverables (available through the Project Management Framework) include a template for Risk Identification and Analysis.

Time Frame: Complete

SXEM has PM Advisors to work with Project Managers to aid them in the completion of information and to provide guidance on the execution processes that should be followed.

SXEM will review the PMF to ensure that the items suggested are included within the template.

Time Frame: End of October

SXD has an existing process to report the progress and status of the projects through monthly meetings with SXD BMC. All projects at risk are discussed at that meeting and action items are identified and recorded for discussion and follow-up at the next monthly meeting.

Time Frame: Complete

Top of Page

5.0 Training

5.1 Project Management Core Competencies

In order to achieve the first Plateau in the TBS Enhanced Management Framework, DFAIT should ensure that project managers have the required knowledge and experience and the tools to support them and the project.

Although some of the project managers in the audit did have a university graduate degree (MBA), only one of twelve included in our sample of projects indicated that they had received any formal training in project management. Consequently, our overall conclusion is that, within DFAIT, project managers require training in order to meet Treasury Board's core competencies.

Project management requires applying knowledge, skills, tools and techniques to project activities in order to meet project requirements. It is accomplished by using processes including: initiating, planning, executing, controlling, and closing. Many of the processes involved in managing projects are iterative.

Core competencies are the basic skills required by a person managing an information technology (IT) project in the Canadian federal government.

Project management requires the three areas of knowledge listed in the table below.

General Management: To ensure proper management practices.
The project manager must have skills in general management. Skills such as leading, negotiating, communicating and team building are necessary in any management position.

Project Management: To ensure quality project process and results.
The project manager must understand generally accepted project management skills, such as managing project scope, time, cost and quality.

IT Management: To create or acquire quality IT project.
The project manager of an IT project must have the IT management skills, such as life cycle phasing, estimating, and constructing software.

Recommendation for CIO

5.1.1 The CIO should promote through the Major Applications and Owners' Group and the IMT SC that, as part of their continuing education, all project managers attend courses on project management to achieve the core competencies described by Treasury Board⁽²⁵⁾ or by the Project Management Institute in its Project Management Body of Knowledge (PMBOK), 2000 Edition.

Action and Time Frame

5.1.1 Project management training has been provided within SXD over the past year, on a voluntary basis. Resources restraints have not made it possible to require project managers to attend these courses. If proven successful this training program may be extended to other Bureaux.

Time Frame: Underway

6.0 Best Practices

This section identifies those practices found in DFAIT which SIV considers to be best practices, along with some of the best practices found in private industry.

6.1 The Treasury Board's Enhanced Management Framework (EMF) consists of best practices, principles, methodologies, tools and standards that were identified in an inter-departmental initiative and which provide solutions to project management concerns experienced in the federal government. The individual plateaus within the EMF focus on the concrete steps towards significantly improving the government's ability to deliver and manage IT projects. It reflects the initial Enhanced Framework findings and the priorities of government Departments. (For more information on the requirements for reaching each plateau refer to http://www.cio-dpi.gc.ca/emf-cag/about/abu-ans04_e.asp.)

6.2 The Carnegie Mellon Software Engineering Institute has developed principles and practices of software process maturity in terms of a path from ad hoc, chaotic processes to mature disciplined software processes. The path consists of five maturity levels from 1 to 5. For further information refer to Appendix B.

6.3 Control Objectives for Information and related Technology (CobiT) has been developed as a generally applicable and accepted standard for good practices for Information Technology (IT) control. CobiT is based on existing Information Systems Audit and Control Foundation (ISACF) Control Objectives enhanced with existing and emerging international technical, professional, regulatory and industry-specific standards. For further information refer to Appendix C.

6.4 The Best Practices listed below are described by the Gartner Group in its report on the Project Office:

• Project teams should be encouraged to keep on track with regular, brief, mandatory meetings and identify critical success factors;
• Re-estimate IT projects when starting each major project phase;
• The Project Office can simply serve as a source of information on project methodology and standards. The Project Office assumes that the enterprise has embraced a cohesive set of tools for project design, management and reporting. This model occurs most often in organizations that empower distributed, business-centric project ownership;
• The Project Office can extend the repository. This model assumes a willingness to share some project management practices across business functions and uses the Project Office to coordinate the communication. Best practices are documented and shared, and project performance is monitored actively. Results are used as an opportunity to raise enterprise performance and train inefficient or new project managers;
• Organizations using rigorous gating criteria to move projects from the requirements phase to the development phase will save more than 25 percent in organizational costs for cancelled projects⁽²⁶⁾; and,
• Triangulation, in which estimates produced using different techniques are compared until no more than a 10 percent variance exists between any two sets of results⁽²⁷⁾.

6.5 SXEM - Project Office Concept

During the fieldwork for this audit, the audit team found that SXEM has already taken the initiative to put in place some best practices within SXD. These practices include:

• Producing an Enterprise Project management Report;
• Implementing some Project Office functions⁽²⁸⁾;
• Maintaining DFAIT's repository of reusable project-related artifacts (e.g., project plan templates, estimating models and components); and,
• Performing project close-out (i.e., collecting such metrics as project cost, size, quality and end-user satisfaction).

6.6 PRIME

Strict set of standards are used on every software release for PRIME. The CD containing the release information contains test results, user acceptance approvals, and business cases.

6.7 COSMOS

Contractors were given specific task assignments, using Task Authorization Forms, and asked to provide estimated work efforts and deadlines. The contractor was responsible for completing the activities within the work effort and deadlines provided. Since contractors provided fixed cost work efforts, there were no cost overruns. Use of the Task Authorization Forms on contracts ensures that requirements are met within the budget since the contractor provides a fixed cost quote.

6.8 ITAMS

A good example of incorporating procurement activities into a project plan is found in the ITAMS project. The ITAMS budget identifies amounts required for project management and external consultants. The November 2001 Business Case project diagram⁽²⁹⁾ also contains another reference to purchasing software licenses. The Project Charter for ITAMS (June 24, 2002) does identify the person responsible for providing procurement support and advice.

6.9 The Project Management Office can maintain a risk database from completed projects. The risk database should be a repository of all identified risks and mitigation strategies from all IT projects in DFAIT. Project Managers should be able to search the database to identify project risks that may impact on their IT projects.

Top of Page

7.0 CONCLUSION

The audit notes that basic project management processes exist within DFAIT and the Department has had some successes in its project management activities. However, because project management standards are not completely documented nor integrated throughout DFAIT, those successes are ad hoc and not necessarily repeatable.

Although there are a number of project management courses provided by CFSI and TBS, there is no evidence that all DFAIT project managers have taken the appropriate courses or have the core competencies suggested by Treasury Board. The Department must implement actions to ensure that all project managers have the required knowledge, experience and tools to support them - before assuming leadership of multi-million dollar projects.

Appendix A - Proposed Project Management Deliverable Checklist

Appendix B - Capability Maturity Model

The CMM describes principles and practices of software process maturity in terms of a path from ad hoc, chaotic processes to mature disciplined software processes.

Maturity Level 1: Initial

Processes are usually ad hoc and chaotic. Success depends on the competence and heroics of the people in the organization and not on the use of proven processes. These organizations frequently exceed the budget and schedule of their projects, tend to over commit and abandon processes in the time of crisis, and are not able to repeat their past successes.

Maturity Level 2: Managed

Projects are managed and processes are planned, performed, measured, and controlled. Existing practices are retained during times of stress, and processes, work products and services are managed. The status of the project is visible to management. Commitments are established among relevant stakeholders and are revised as needed.

Maturity Level 3: Defined

Processes are well characterized and understood, and are described in standards, procedures, tools, and methods. Standard processes are used to establish consistency across the organization and are tailored to the project from the organization's set of standard processes. As such, it is the conclusion of the audit team that DFAIT has not yet attained this level.

Maturity Level 4: Quantitatively Managed

The organization has subprocesses that significantly contribute to overall process performance through quantitative techniques. Quality and process performance are understood in statistical terms, are managed throughout the life of the processes, and are incorporated into the organization's measurement repository for future fact-based decision making. The causes of process variation are identified and, where appropriate, corrected to prevent future occurrences.

Top of Page

Maturity Level 5: Optimizing

Quantitative process-improvement objectives are established, continually revised and used as criteria in managing process improvement. Improvement of the processes is inherently part of everybody's role, resulting in a cycle of continual improvement. Describes principles and practices of software process maturity in terms of a path from ad hoc, chaotic processes to mature disciplined software processes.

Appendix C - Control Objectives for Information and Related Technology (COBIT)

Control Objectives for Information and related Technology (COBIT) were developed as a generally applicable and accepted standard to ensure that IT has an effective Management Control Framework and is able to meet client and management expectations. COBIT includes existing international technical, professional, regulatory and industry-specific standards and is now recognized by TBS as an applicable framework for the review and audit of information systems in the Government of Canada.

COBIT is designed to be used by three distinct audiences:

• Management: to help them balance risk and control investment in an often unpredictable information technology environment. Management needs generally accepted IT governance and control practices to benchmark their existing and planned IT environment. COBIT is a tool that allows managers to communicate competing requirements and bridge the gap between control requirements, technical issues and business risks.
• Users (i.e. Business Process Owners): to obtain assurance on the security and controls of information technology services provided by internal or third parties.
• Information systems auditors: to substantiate their opinions to management on internal controls.

The COBIT methodology indicates that there are a number of different processes consisting of many controls, and there is a systematic way to assess those controls.

COBIT consists of a framework for control in IT based on business information criteria and documented by control objectives organized by IT domains, processes and activities. Each of these areas has in addition to a set of control objectives, a definition and a rationale for control.

Business orientation is the main theme of COBIT. It is designed not only to be employed by users and auditors, but also, and more importantly, as a comprehensive checklist for business process owners. Business practice involves the full empowerment of business process owners so they have total responsibility for all aspects of the business process. This includes providing adequate controls. COBIT provides a tool for the business process owner that facilitates the discharge of this responsibility.

The COBIT framework starts from a simple premise: In order to provide the information that the organisation needs to achieve its objectives, IT resources need to be managed by a set of naturally grouped processes. The domains are identified using wording that management would use in the day-to-day activities of the organisation:

• Planning and Organizing - This domain covers strategy and tactics and concerns the identification of the way information technology can best contribute to the achievement of the business objectives.

• Acquisition and Implementation - To realise the IT strategy, IT solutions need to be identified, developed or acquired as well as implemented and integrated into the business process.

• Delivery and Support - This domain is concerned with the actual delivery of required services, ranging from traditional operations over security and continuity aspects to training. In order to deliver services the necessary support processes must to be set up.

• Monitor the Process - All IT processes need to be regularly assessed over time for their quality and compliance with control requirements.

For further information on COBIT see http://www.isaca.org.

Top of Page

Appendix D - Project Snapshots

EQAMS - Electronic Question and Answer Management System

Provides a single repository for Q&As. Allows all authors, supervisors and contributors to create, review, modify and print Q&As. Allows the translation of Q&As to be completed through the system and immediately available to users. Allows selected employees within the Ministers and Secretaries of States offices to review Q&As, create ministerial responses and mark each Q&A with a category.

ITAMS - Information Technology Asset Management System

The ITAMS project, along with supporting Departmental policy and procedures, is intended to provide SXD with the tools to better manage assets which it either owns or supports at headquarters or in the field.

Micro Missions

The Communication and IT services provided to micro missions is inadequate to support DFAIT business objectives. This project upgrades micro missions to the approved minimum baseline for communication and IT services. The project also establishes the support resources and mechanisms to maintain these services in the target micro missions.

IR - Infrastructure Renewal

To upgrade the operating system and replace outdated servers. This project will allow DFAIT to maintain interoperability with outside agencies.

COSMOS - Consular Management and Operation System

Provides consular staff at HQ and Missions with a set of tools designed to facilitate the management of consular cases.

Connex

A method for EGoB to maintain data on contacts and activities. In order to support ongoing consultations with Canadians, it is essential and urgent to build a central database of contacts/participants that would be used for analysis, reporting, monitoring, communications and marketing activities. The Contacts Database would centralise all current contacts and enable users to retrieve and update contact information. It would also be used to prepare, communicate and distribute information to stakeholders.

RE/PM - Real Estate/Plant Maintenance

The pilot testing of the SAP Real Estate/Plant Maintenance modules. This project also included an evaluation of the Prime Real Estate software package.

MCMS - Ministerial Correspondence Management System

Provides the Minister with a stable, secure and searchable system to efficiently store and retrieve Ministerial correspondence and related material to meet legislative requirements associated with the management of government information and Access to Information.

eCRM - Electronic Client Relationship Management

Replaces legacy contact management systems for Trade Officers (e.g. WIN Online, Mission WIN, Maximizer, and ContactsPlus) with a commercially available application(s). It also provides Trade Officers abroad with access to information and service requests anytime, anywhere via laptops, cell phones, and mobile personal digital assistants (PDAs).

BI - Business Intelligence

Provides accessible and accurate cross-functional business information to support decision-making and effectively address responsible stewardship of resources and accountability. It addresses the needs of headquarters and missions by integrating and deploying information from key corporate systems.

DBC - Doing Business with Canada

Provides foreign businesses and GoC offices with one-stop on-line information about doing business with Canada, by integrating the various GoC on-line programs and services pertinent for foreign businesses.

VTC - Virtual Trade Commissioner

Enables the Department to provide highly tailored and individualized online services to Canadian business exporters, trade commissioners, and foreign business contacts.

Appendix E - Contract Planning

General Notes:

1. Consult with your contracting officer at the beginning of the project planning phase.
   
2. Exceptions to these planning stages may be discussed with SMFG.
   
3. Consult with SMFG to determine the estimated time required from the definition of the requirement to contract award.

1. Definition of the Requirement

1. Preparation of the Statement of Work.
2. Cost Estimate.
   1. Total estimated value may not exceed 2 million dollars when using MERX (competitive process)
   2. Total estimated value may not exceed 400,000 dollars when using Traditional method (competitive process)
   3. Total estimated value may not exceed 25,000 dollars for Sole-Source and in some cases up to 100,000 dollars
   
   * If the total estimated value exceeds any of the amounts in (b). i., ii., iii., above Treasury Board approval must be sought or a requisition must be forwarded to PWGSC for contract award.
   
3. Preparation / Development of the solicitation document and the evaluation grid. (In cases of competitively awarded contracts).
   • Request for proposal
   • Request for standing offer
   • Request for supply arrangement

2. Applicability of the Trade Agreements and the Treasury Board Contracting Thresholds

Determine if the requirement is subject to the trade agreements. If one or more of the trade agreements apply, then the requirement must be posted on MERX for a minimum of 40 calendar days.

• Agreement on International Trade (AIT)
• North American Free trade Agreement (NAFTA)
• World Trade Organization ( WTO)

3. Evaluation of Bids and Preparation of Contract / Standing Offer and or Supply Arrangement

4. Contract Review Board Approval

5. Contract Award and Contract Administration

Top of Page

PWGSC

1. Definition of the Requirement

• Preparation of the Statement of Work.
• Preparation / Development of the solicitation document and the evaluation grid (In cases of competitively awarded contracts).

2. Applicability of the Trade Agreements and the Treasury Board Contracting Thresholds

Determine if the requirement is subject to the trade agreements. If one or more of the trade agreements apply, then the requirement must be posted on MERX for a minimum of 40 calendar days.

• Agreement on International Trade (AIT)
• North American Free trade Agreement (NAFTA)

3. Evaluation of Bids and Preparation of Contract/Standing Offer and or Supply Arrangements

4. PWGSC Contract Approval Process

5. Contract Award and Contract Administration

Office of the Inspector General

Primary navigation

Date Modified:

2008-11-10