Audit of Research Portal 2.0 (Phase I)

Corporate Internal Audit Division
Natural Sciences and Engineering Research Council of Canada
Social Sciences and Humanities Research Council
Recommended by the Independent Audit Committee on June 22, 2017
Approved by Presidents on July 12, 2017


PDF version




1. Executive Summary

Background

In 2015, an Independent Third-Party Review (ITPR) was conducted of the Research Portal (RP 1.0); the ITPR identified a number of deficiencies and put forth important recommendations for improvement. The agencies are now collaborating to replace RP 1.0 and the other legacy systems with a new grants management system (called Research Portal 2.0) as part of their shared commitment to streamlining the delivery and administrative processes of their programs. Progress is needed on the ITPR recommendations to ensure RP 2.0’s successful implementation.

Why it is important

The Audit of the Research Portal was approved in March 2016 by the Independent Audit Committee (IAC) as part of the CIA Division’s 2016-19 Risk-Based Audit Plan (RBAP). The Research Portal project supports the strategic direction and objectives of both agencies.

Audit objective, scope and methodology

The objective of this audit was to determine the extent to which management has addressed the recommendations in the 2015 report from the ITPR, including the status of management actions and determining whether action plans are adequate in addressing these recommendations. The audit considered the implications of these responses on RP 2.0.

The scope of the audit was limited to those recommendations and the action plan described in the management response.

The audit involved extensive review of project documents, as well as interviews of project management staff and NSERC and SSHRC executives.

Findings and Conclusion

The agencies defined detailed action plans and deliverables, including accountabilities and timelines for the actions, to address each of the recommendations in the 2015 report.  Through those actions, the agencies have made significant progress in addressing the recommendations of the report.

Subsequent to the 2015 report, the agencies made the decision to replace RP 1.0 and the other legacy systems with a new grants management system, Research Portal 2.0.  In the context of that shift, there are some areas that will continue to need action to enable the success of RP 2.0.




2. Background

Overview

Starting in 2008, both NSERC and SSHRC dedicated significant financial and human resources to develop and implement a single grant management system. In 2013, the Common Administrative Services Directorate completed the Research Portal 1.0 IT system and transitioned some of the agencies’ grant programs onto it. Following its launch, the agencies attempted to expand RP 1.0 to host all of the grant activities; however these efforts were not successful.

In 2015, senior management at both NSERC and SSHRC decided to revise the objective of the RP project to put greater focus on business process simplification and harmonization. While the RP 1.0 system hosts about 14 per cent of the total grants managed by the two agencies, all further development on it has ceased and the system is in “maintenance” mode.

The agencies are now collaborating to replace RP 1.0 and their respective other legacy systems with a new grants management system (called Research Portal 2.0), as part of their shared commitment to streamlining the delivery and administrative processes of their programs. The RP 2.0 project mandate is to support the strategic direction of the agencies through business transformation, coupled with the migration to a new technology platform.

The agencies engaged an independent third party in the spring of 2015 to perform a review of RP 1.0. The report from this Independent Third Party Review (ITPR) identified a number of areas for improvement in the agencies’ project management governance and processes. The ITPR report included six recommendations. Agency management agreed with all six recommendations and developed action plans to implement corrective measures.

This is a follow-up audit to determine if management has implemented actions to address the six ITPR recommendations as agreed in the six management responses.


Structure of Findings

The Findings section is structured based on the ITPR recommendations, with a sub-section for each of the six recommendations. For each finding, the original recommendations as well as the planned management actions are presented. These are followed by analysis of what we found, a conclusion, and where applicable, recommendations. A Summary Conclusion follows the Findings section.




3. Audit Rationale

The Audit of the Research Portal was approved in March 2016 by the Independent Audit Committee (IAC) as part of the CIA Division’s 2016-19 Risk-Based Audit Plan (RBAP). The Research Portal project supports strategic direction and objectives of both agencies.




4. Audit Objective, Scope and Methodology

Objective

The objective of this audit was to determine the extent to which management has addressed the recommendations in the 2015 report from an Independent Third Party Review, including the status of management action and determining whether action plans are adequate in addressing these recommendations. The audit considered the implications of these responses on RP 2.0.

Scope

The scope of the audit was limited to those recommendations and the action plan described in the management response. The scope of the audit work considered documentation from July, 2015, to January 31, 2017.

Methodology

Audit work included an extensive review of project documents, as well as interviews of project management staff and NSERC and SSHRC executives.




5. Conformance Statement

This audit conforms with the Internal Auditing Standards for the Government of Canada, as supported by the results of the quality assurance and improvement program. These standards require that sufficient and appropriate audit procedures be conducted and that evidence be gathered to provide a high level of assurance on the findings contained in this report. The conclusions were based on a comparison of the situations as they existed at the time against the audit criteria (Appendix I).

Peter Finnigan, Chief Audit Executive
Corporate Internal Audit Division, NSERC and SSHRC



6. Follow-Up Audit Findings


6.1 ITPR Recommendation 1: End-State Vision

Develop an end-state vision, including full analysis of the “harmonizing” business and system requirements (What is the benefit statement on automating each Program?). The vision needs to be articulated, documented and agreed to by both agencies. This will facilitate the Business Case, especially analysis of the options and benefits statement.

6.1.1 What Management Planned

A comprehensive vision that is understandable by all project team members and stakeholders will be developed. The vision will communicate the need to harmonize business process and business requirements. The concept of harmonized business processes will be described to ensure alignment by all partners. The well-articulated vision will provide clear understanding of where the project is going and what it is trying to achieve. In addition, it will articulate the principles that will be adopted by the project, including the need to automate all requirements. The vision will reflect lessons learned from the currently closed project.

6.1.2 What We Found

A high-level end-state vision for RP 2.0, including full analysis of the “harmonizing” business and system requirements, has been developed including extensive engagement internally to ensure alignment between the agencies. The vision is aligned to the strategic direction of the organization; this is documented in multiple sections within the Project Strategic Assessment and Concept Document for RP 2.0.

There is concern by some internal stakeholders that the current end-state vision is defined at a very high level and that more work will be required in the Detailed Planning phase to achieve a comprehensive picture of the end-state. Stakeholder engagement planning, in particular external stakeholders lacked details on the processes, as part of the business requirements definition, as well as the end to end System Architecture renderings.

Regarding Organizational Change Management, there is evidence of internal working groups and internal stakeholder consultations being planned; these have yet to be executed based on the delay in obtaining approval for the next stage. Although, the Research Portal Executive Committee (RPEC) has had some discussions on the need to engage and communicate with external stakeholders as the project moves forward, external stakeholder engagement is on hold until there is more certainty regarding the project.

Within the Project Strategic Assessment and Concept Document for RP 2.0, there are sections defining:

  • Scope and Out-of-Scope elements
  • Assumptions and Constraints
  • Lessons Learned, specifically “Based on lessons learned from Research Portal 1.0, the agencies have made a significant investment in strengthening their project management culture and practices through the appointment of several senior executives with significant experience with comparable initiatives.”

6.1.3 Conclusion

There has been foundational work completed to develop a high-level end-state vision for RP 2.0, including full analysis of the “harmonizing” business and system requirements. At this point in the project there is not a detailed end-state vision including architectural renderings. Late engagement of external stakeholders could result in missed requirements and potential resistance to adoption and acceptance of the solution.

6.1.4 Recommendation deriving from the follow-up audit

To enable the success of RP 2.0, it is recommended that the project director:

  • Ensure work during the Detailed Planning phase includes development of a detailed end-state vision for RP 2.0 that includes adequate architectural renderings.

6.2 ITPR Recommendation 2: Business Case – Options Analysis

Develop a business case. The agencies need to consider future options relevant to current environment, such as insourcing, co-sourcing, partnering or outsourcing. The options need to consider costs, benefits, effort / resourcing, risks, transition impacts, maintenance/steady-state considerations and overall project management in both project and steady state environments.

6.2.1  What Management Planned

The agencies will outsource the development of an options analysis that takes into consideration the needs of the agencies, the current direction of the Government of Canada and the agencies’ capacity to deliver the solution.

To assess the options, each option needs to be compared with the others using an objective and effective means. Assessment criteria must be defined. These include the description of the criteria; the weight that a criterion holds for the agencies, the measure to which the option meets the requirement of the criterion, etc. Deal breaker criteria will also be identified. The total of all the scores for each option will assist in determining the recommended option.

In addition to identifying the technological path, the options analysis will identify a variety of opportunities, including development by the agencies, hiring resources for the development, partnering with additional GOC agencies or departments and outsourcing. A comprehensive list of opportunities will be screened to identify viable options.

The options analysis will then build on the preliminary analysis of options and provide a more rigorous analysis of viable options.

The options analysis will provide a full comparison of each viable option against the evaluation criteria identified in the preliminary analysis and provide a recommendation of a preferred option based on the net advantages of the viable option over all others.

The business case will identify the vision and the core issue, followed by the investment proposal required to address it. The options analysis is part of the business case.

The business case will also identify a cost-benefit analysis for each of the viable options identified and the time frame of the cost-benefit analysis based on the expected life cycle of the project, i.e., from when costs begin to be incurred to when the benefits are expected to be achieved.

6.2.2  What We Found

An options analysis and associated Evaluation Criteria Deck for RP 2.0 were developed with the assistance of an outsourced resource and provided descriptions of criteria including:

  • compliance requirements with Government of Canada (GoC) standards for web and application development; and
  • alignment with GoC / TB Technology Decisions.

The agencies established the options analysis framework and evaluation criteria for RP 2.0, which were approved by RPEC. Within the Options Analysis – Evaluation Criteria Deck the agencies program priorities were considered and included as part of the weighting, including “Deal Breaker” criteria.

The final Options Analysis Report delivered included a high-level Solutions Architecture and the expected list of possible options, with a high-level costing analysis of the viable options, including the first year in which savings would begin accruing.

The options analysis did not include a recommendation among the options, or a clear technical end-state architectural vision. This led to an agency-led environmental scan, which helped to enable the selection of a recommended option to bring forward within the business case and subsequent request for approval for the next stage. The version of the business case available at the time of this audit (dated November 28, 2016) states “The cost-benefit analysis for this project is at the preliminary stage. The exercise will be completed in Detailed Analysis stage, when the project costs will be more accurate for the execution phase of the project.” As well, the sourcing option had not been confirmed.

6.2.3  Conclusion

An options analysis and agency-led environmental scan was completed and concluded with the selection of an option to bring forward within the business case and subsequent request for approval for the next stage. The business case is in progress as part of work to complete such request. Elements of the recommendation that have not been fully addressed are the sourcing strategy, complete cost-benefit analysis and the impacts to resourcing, transition and steady state.

6.2.4  Recommendation deriving from the follow-up audit

None


6.3 ITPR Recommendation 3: Support Management Plan

Determine clear ownership of the steady state, including comprehensive roles and responsibilities and release management disciplines, processes and procedures documented and approved to support the programs that are active on the Portal.

6.3.1 What Management Planned

The current product support plan will be updated to address a number of sustaining issues such as program performance requirements, product attributes, support processes, performance measurement and resource requirements.

A framework to prioritize changes, including governance of those changes and prioritization evaluation criteria that include program and IT needs will be developed. The changes will need to be balanced with new development requests.

The plan will be updated on a yearly basis.

6.3.2 What We Found

A support plan was developed for the Research Portal 1.0. The plan describes the process and approach to be followed for supporting incident and problem management for Research Portal 1.0 CRM (Client Relationship Management) system and its Portal interface in the production environment.

In analysing the key elements of the current RP 1.0 Support Plan, the following aspects were noted:

  • It is intended that the RP 1.0 Support Plan will serve as a foundational piece for the RP 2.0 Support Plan scheduled to be prepared in Stage 6-Project Execution (May 2018-May 2021). According to PMBoK best practices, this work should be completed before stage 6 in the project lifecycle.
  • The existing RP 1.0 Support Plan is clear on the processes for changes to this environment and the sub-processes and governance that need to be followed, as well as alignment to the Change Management process for requests through Information and Innovation Solutions (IIS).
  • The RP 1.0 Support Plan details the roles and responsibilities of the various teams participating in support of the CRM and Portal in steady state for supporting incident and problem management for Research Portal 1.0 CRM (Client Relationship Management) system and its Portal interface in the production environment.
  • The Support Plan for RP 2.0 Project and Steady State is not yet documented, nor is there clear ownership for the steady state nor the framework to prioritize Program and IT needs and transition activities from project to steady state. Note the project brief accompanying the request for approval specified “Ensure a support plan is developed and implemented”.
  • Although there is an understanding on roles and responsibilities within the RP 2.0 Project among internal stakeholders, there is more work to be done to define and formally document roles and responsibilities for both the project and steady state.

Other documents and elements to consider that will contribute to a robust Support Plan for RP 2.0 are as follows:

  • Within the Organizational Change Management document for RP 2.0, transition activities are described at a high level in the Business Transformation section. Although the Dependencies section indicates some of the technical requirements, such as data migration strategy, these transition activities are focused on the “people-side of change” and not the IT environment transition activities. It is noted that transition strategy is scheduled in a later stage (Detailed Project Plan and Functional Specifications).
  • There is a Change Management Plan (Scope Change) for RP 2.0 that defines the guidelines, roles and responsibilities and procedures associated with a Project Change Request The document is comprehensive and details the identification of a change, assessing impact of a change, governance of a change and identifies associated processes and templates required. It is noted that the Project Change Control Board (CCB) will be carried out by the Business Operations Committee (BOC) for RP 2.0.
  • The Scope Management Plan for RP 2.0 documents how the project will develop the product and project scope through the Business Requirements Development (BRD) and Work Breakdown Structure (WBS) respectively. Although there are references within the section entitled, “Monitoring and Control on Processes for Scope Review,” more clarity is required on what process will be involved to document the traceability of changes throughout the project’s lifecycles and any impacts to benefits or declared objectives.
  • There is an active CCB within IIS for broader portfolio change with the appropriate guidance and governance on change requests. It is expected that the IIS CCB will be engaged for deployments into production for the RP 2.0 project.

6.3.3 Conclusion

A Support Management Plan has been defined and implemented for RP 1.0. With respect to RP 2.0, there is no clear ownership for the steady state and the framework to prioritize program and IT needs and transition activities from project to steady state within the Support Plan. There is a need to advance the development of the RP 2.0 Support Plan. 

6.3.4 Recommendations deriving from the follow-up audit

To enable the success of RP 2.0, it is recommended that:
The project sponsor, in consultation with the members of RPEC:

  • identify ownership for the steady state of RP 2.0 and clearly communicate the information to the RP 2.0 Project team, and as deemed appropriate across the agencies.

The project director:

  • ensure timely development of the Support Plan for RP 2.0;
  • engage the owner of the steady state in the support planning; and
  • identify the transition phase from project state to steady within the project schedule, including high-level activity milestones and roles and responsibilities.

6.4 ITPR Recommendation 4: Organizational Change Management – Current State

Engage an Organizational Change Management resource and disciplines to develop an outreach and engagement program to ensure stakeholders (both internal and external) understand the business drivers for the current change, how it will impact them and what is in it for them from a benefits perspective.

6.4.1 What Management Planned

Since a significant portion of project deliverables are dependent on harmonization of business processes and a comprehensive set of business requirements document, a full-time organizational change management lead is required. Some of the key roles of this individual include: engagement, communications, transition, training, etc.

To minimize risks and maximize efficiencies, an industry standard for organizational change management approach that will align with the project's activities will be adopted. A strategy and supporting plans (e.g., communications, training and transition) will be adopted. The final documents will be part of the Project Management Plan.

6.4.2  What We Found

An Organizational Change Management (OCM) Strategy based on industry leading best practice (the PROSCI – Adkar model) was developed by the project team. The principles of the OCM Model were employed internally within the organization during a software version upgrade in the summer of 2016. The OCM Strategy is heavily focused on internal stakeholders, with only a brief section on External Stakeholder Engagement within the OCM Strategy document.

Management advised that work on external stakeholder engagement would be on hold until there was more certainty regarding the project’s approval. Once the project moves forward, Stage 5 (Detailed Project Plan and Functional Specifications) will include RP 2.0's Transition Strategy. This strategy, along with the OCM Strategy and Communications Plan, will be the vehicles for driving the stakeholder engagement activities.

There is an undated Stakeholder Catalogue that is high level and a work in progress; there are descriptions of the stakeholder groups, however, no details on role, impact assessment or communication requirements.  As part of the OCM Plan, the outreach strategy/plan and stakeholder map should normally include identification of stakeholders, the expected impact to the stakeholder group, their level of influence to the project, anticipated frequency of engagements and communications, type of vehicles, e.g., Communiqués, town halls, roadshows, etc.

There is a RP Project Communications Restart 2015-2016 document. It documents primarily the internal status reporting and only for the fiscal 2015-16 year. It is stated “External stakeholders will be involved in defining requirements. These activities will be identified later. NSERC and SSHRC communications sections will assume the leadership role with external communications.” A Communications and Training Plan supporting the OCM Strategy has not yet been developed.

Within the RP 2.0 Project Charter the OCM Lead is mentioned and the role is described in the RP Project HR Plan. However, the role is not on the project structure nor clearly defined nor communicated in either the Project Charter or the OCM Strategy.

In September 2015, the agencies recognize the relevance the OCM function by appointing an internal resource as the OCM lead. As this person has recently moved to another position, the agencies are currently looking for a new OCM lead.

6.4.3  Conclusion

An Organizational Change Management (OCM) Strategy has been developed. This strategy requires additional detailed processes for engagement and awareness, including a communication and training plan, especially for external stakeholders. Late engagement of external stakeholders could result in missed requirements and potential resistance to adoption and acceptance of the solution.

6.4.4  Recommendations deriving from the follow-up audit

To enable the success of RP 2.0, it is recommended that the project director:

  • clearly communicate to the RP 2.0 Project team, and as deemed appropriate across the agencies, both the role and the responsibilities of the Project OCM Lead, and adequate information on the project's OCM processes;
  • ensure work continues on coordinating the OCM Strategy and implementing the related action plan, during the search for a new OCM Lead; and
  • ensure the OCM Strategy includes detailed information on all OCM Planning activities, including those related to external stakeholder communication and engagement.

6.5 ITPR Recommendation 5: Project Management Framework

The agencies need to establish a Project Management Framework that can be leveraged by the Research Portal Project or any subsequent projects taken on in the future. The framework needs to include the following fundamentals:

  • Scope Management – anchored in detailed baselined business requirements and solution design with clear scope change processes and traceability.
  • Schedule Management – anchored on baselined scope and work breakdown structure elements. Schedule should be baselined and a critical path defined to ensure impacts can be assessed to scope and costs along with schedule.
  • Finance Management – anchored on a robust cost model built on detailed work breakdown structure and reporting against estimates to completion.
  • Vendor Management – dependent on procurement option, an appropriate delivery based vendor management processes and procedures need to be established before the vendor is formally engaged.

6.5.1  What Management Planned

The agencies’ Project Management Office will create a project management framework, governance structure and templates that are consistent with Treasury Board Secretariat (TBS) guidelines and reflect requirements. Although the framework will be developed for IT-enabled projects, other types of projects could benefit from the framework. These leveraging opportunities will not be track by this action plan.

These will increase the effectiveness of project management and provide controls to support the delivery of projects including compliance with the Policy on the Management of Projects.

Through the Project Management Office, the agencies will receive ongoing project monitoring through a dashboard which also identifies and assesses project risks with mitigation strategies to address the portfolio of projects.

To develop detailed scope, a schedule and project costs the detailed business requirements are required. The business requirements will be based on the harmonized business processes.

In addition, the project team will adopt standard project management dashboard for monthly reporting. The project governance will oversee the rigour and thoroughness of these deliverables. These evergreen deliverables will be updated on a yearly basis.

6.5.2  What We Found

The IIS has created a Project Management Framework (PMF) for providing guidance and direction on approved agency projects. This includes establishing common processes and tools to be used as well as the appropriate governance oversight based on the size and complexity of the project. The PMF was developed considering TBS requirements and the agencies’ processes, procedures and vocabulary.

With the recent completion of the PMF, the focus is on the approval of the PMF through RPEC or JIMC, depending on the most appropriate channel decided by RPEC. A formal process for ensuring the PMF remains current and relevant has not yet been developed.

A Project Management Plan (PMP) exists for the RP 2.0 Project and was approved at the appropriate level (RPEC). The PMP includes the required sub-processes hyper linked in the document, which allows for version control and alignment of source data. As the project moves into the next phase, the process to ensure the adherence and alignment between the Organizational PMF and the Project’s PMP needs to be established.

RPEC approved the Project Scope Management Plan as well as Time Management Plan and Cost Management Plan. Thresholds and tolerances, e.g., for re-baselining schedules and risk tolerances have been defined. The schedule approach is iterative, with separate schedule reviews for each release.

A Communication Plan was developed for RP 1.0, however with the departure of the project director and delay in receiving approval for the next stage, there is a significant impact on the commitment to complete the RP 2.0 Communications Plan and Support Plan, including training. The need for a Vendor Management Plan will be assessed when the sourcing strategy has been finalized.

The RP 2.0 Dashboard is comprehensive in its content. The IIS Project Dashboard template is similar but there are minor differences between the formats.

6.5.3  Conclusion

A draft version of the Project Management Framework (PMF) has been developed, including Project Management processes that are consistent with TBS guidelines. For RP 2.0, a Project Management Plan (PMP) was developed and approved at the appropriate executive level. A process to ensure alignment between the organizational PMF and the Project’s PMP has not yet been documented. The draft PMF does not include detailed guidance for Communications and Training Plans.

6.5.4  Recommendations deriving from the follow-up audit

To enable the success of RP 2.0, it is recommended that the project director:

Provide more detailed information on planned communications and training activities in the Project Management Plan, and establish a process to ensure the RP 2.0. Project Management Plan remains aligned to the IIS Organizational PMF and its associated processes throughout the project lifecycle.


6.6 ITPR Recommendation 6: Resource Management

To proceed with establishing the recommendations presented, there are critical gaps in resources and skills that need to be addressed. Immediate requirements are for:

  • skilled/experienced project manager(s);
  • business analyst(s); and
  • IT manager/lead.

6.6.1 What Management Planned

Resourcing strategies will be discussed with DG Human Resources and a Resources Management Plan will developed and presented to the project Executive Committee. The plan will address identified gaps as well as the need for a solution architect.

Skilled resources (project manager, business analysts, IT manager/lead and solutions architect) with experience commensurate with the project complexity (size and risks) will be secured either through hiring of term employees or contractors.

Additional resources may be secured as required by the proposed approach recommended in the options analysis.

Costs for these skilled resources will be provided in the project cost plan and at other planning opportunities.

6.6.2 What We Found

The skills gaps identified within the ITPR Recommendation were addressed for RP 2.0, however, skilled capacity has been affected by significant turnover in the key resources of the project, for example, both the project director and the resource that was hired to perform primarily the role of IT manager/lead have left the project.

There is a Human Resource Management Plan, dated June 2015, which focused on the 2015-16 fiscal year. Factors that were assessed within the plan were: organizational capacity versus current capacity; and resource hiring strategies. However, it was developed before the decision to end the RP 1.0 project and launch RP 2.0, and thus it is not aligned to RP 2.0 requirements.

A comprehensive assessment based at a project plan level has not yet been developed although a working document exists and describes some resource requirements. 

6.6.3 Conclusion

There were actions taken against the skills gaps indicated at the time of the ITPR and all three key skills gaps were filled, however at the time of this audit, three key resources were no longer part of this initiative; the project director, IT manager/lead and the OCM lead.

The existing Human Resource Plan is out of date and not aligned to an identified project lifecycle and approved schedule at this point in the project. If the Project Director position is not filled with the appropriate resource in a timely fashion, there is a risk of key plans and processes not being completed on schedule. This resource will ensure that a strong communication and training strategy be implemented for RP 2.0, involving all stakeholders.

6.6.4 Recommendation deriving from the follow-up audit

To enable the success of RP 2.0, it is recommended that the project director:

Update the HR Strategy and Plan to ensure it is aligned to the RP 2.0 Project schedule and timelines, and includes information on the approach for (a) ensuring project continuity in the event of turnover in key positions, and (b) orienting new project staff, steering committee members and contracted resources.



7. Conclusion


The agencies defined detailed action plans and made significant progress in addressing each of the recommendations in the 2015 report. Subsequent to the 2015 report, the agencies made the decision to replace RP 1.0 and the other legacy systems with a new grants management system, Research Portal 2.0. In the context of that shift, there are some areas that will continue to need action to help to enable the success of RP 2.0.


8. Management Response to Audit Recommendations


Item Recommendation Management Response Target Date

1.

Ensure work during the Detailed Planning phase includes development of a detailed end-state vision for RP 2.0 that includes adequate architectural renderings.

Agreed.
The project director (starting in his position on June 14) will be responsible for achieving Gate 5 approval, including the detailed business requirements and the detailed solution architecture to support that end-state vision for RP 2.0, as per the RP 2.0 Project Management Plan approved by RPEC in Stage 4.
The project director will also be responsible for ensuring these deliverables are completed with appropriate stakeholder (internal and external) consultation.

Dec 2017

2.

None

 

 

3.

a) Identify ownership for the steady state of RP 2.0 and clearly communicate the information to the RP 2.0 Project team, and as deemed appropriate across the agencies.
b) Ensure timely development of the Support Plan for RP 2.0
c) Engage the owner of the steady state in the support planning.
d) Identify the transition phase from project state to steady within the project schedule, including high-level activity milestones and roles and responsibilities.

Agreed.
a) Agreed.
A Memorandum of Understanding (MOU) between the agencies is currently being developed to formally establish those elements. The proposal is that the solution will be co-owned by the agencies
b, c and d) Agreed.
Support of the production solution will remain the responsibility of the project team until the transition from project state to steady state, planned for release 6.
The project director with the CIO will ensure detailed plans are formulated to deliver an interim support plan for RP 2.0 by the end of Stage 5 and a steady state support plan before release 6 (transition from project-state to steady-state).  Further details will be developed on transition phase (Project Manager) during Stage 5 (detailed requirements and planning).

 

Q4 2017- 18

 

 

b, c and d) Interim support plan Q3 2017-18

Steady state support plan Q4 2017-18

4.

a) Clearly communicate to the RP 2.0 Project team, and as deemed appropriate across the agencies, both the role and the responsibilities of the Project OCM Lead, and adequate information on the project's OCM processes.
b) Ensure work continues on coordinating the OCM Strategy and implementing the related action plan, during the search for a new OCM Lead.
c) Ensure the OCM Strategy includes detailed information on all OCM Planning activities, including those related to external stakeholder communication and engagement.

a) Agreed
Within the actual OCM Strategy, in collaboration with business champions, the project director will ensure the roles and responsibilities of the project’s Organizational Change Manager are clearly defined and communicated to the project’s stakeholders as appropriate.
The project manager will ensure the project’s organizational change management processes are clearly documented and communicated to interested stakeholders.
b) Disagree.
Coordination of OCM is limited to external stakeholders to validate requirements (Through the project manager) until a new OCM Lead is hired, shortly after the arrival of the project director.
c) Agreed.

 

5.

Provide more detailed information on planned communications and training activities in the Project Management Plan, and establish a process to ensure the RP 2.0. Project Management Plan remains aligned to the IIS Organizational PMF and its associated processes throughout the project lifecycle.

Agreed
The RP 2.0 Communications Plan is a subsidiary plan to RP 2.0 Project Management Plan to be updated in Stage 5.
The project director will ensure that these updates are completed as planned and that the communication plan is aligned to the Organizational Change Management Strategy.
The RP 2.0 Training Strategy will be developed in Stage 5 as planned as a product deliverable (not part of the PMP), and the subsequent training plans in Stage 6 (project execution), to enable timely and effective training for users (internal and external) of the delivered solution.
The project director will ensure the RP 2.0 PMP is aligned to the agencies’ Project Management Framework throughout the project life cycle.

Q3 2017-18

6.

Update the HR Strategy and Plan to ensure it is aligned to the RP 2.0 Project schedule and timelines, and includes information on the approach for (a) ensuring project continuity in the event of turnover in key positions, and (b) orienting new project staff, steering committee members and contracted resources.

Agreed
The RP 2.0 Human Resource Management Plan is a subsidiary plan to RP 2.0 Project Management Plan and, as per the project schedule, is to be created in Stage 5. The RP 2.0 Human Resource Management Plan will include details regarding the orientation of project team members and associated stakeholders to the project as well as risk mitigation measures to address project continuity in the event of turnover in key positions.

Q3 2017-18



9. Appendix I – Audit Criteria

Line of Enquiry Audit Criteria Report Reference

LOE 1: End State Vision

1.1. A comprehensive vision that is understandable by all project team members and stakeholders will be developed. The vision will communicate the need to harmonize business process and business requirements. The concept of harmonized business processes will be described to ensure alignment by all partners. The well-articulated vision will provide clear understanding of where the project is going and what it is trying to achieve. In addition, it will articulate the principles that will be adopted by the project, including the need to automate all requirements. The vision will reflect lessons learned from the currently closed project.

Pages 6-7

LOE 2: Business Case – Options Analysis

 

2.1. The agencies will outsource the development of an options analysis that takes into consideration the needs of the agencies, the current direction of the government of Canada and the agencies’ capacity to deliver the solution.
2.2. To assess the options, each option needs to be compared with the others using an objective and effective means. Assessment criteria must be defined. These include the description of the criteria; the weight that a criterion holds for the agencies, the measure to which the option meets the requirement of the criterion, etc. Deal breaker criteria will also be identified.
The total of all the scores for each option will assist in determining the recommended option.
2.3. In addition to identifying the technological path, the options analysis will identify a variety of opportunities including development by the agencies, hiring resources for the development, partnering with additional GOC agencies or departments and outsourcing. A comprehensive list of opportunities will be screened to identify viable options.
The options analysis will then build on the preliminary analysis of options and provide a more rigorous analysis of viable options. 
The options analysis will provide a full comparison of each viable option against the evaluation criteria identified in the preliminary analysis and provide a recommendation of a preferred option based on the net advantages of the viable option over all others.

Pages 7-8

LOE 3: Support Management Plans

 

3.1. The current product support plan will be updated to address a number of sustaining issues such as program performance requirements, product attributes, support processes, performance measurement and resource requirements.
A framework to prioritize changes, including governance of those changes and prioritization evaluation criteria that include program and IT needs will be developed. The changes will need to be balanced with new development requests.
The plan will be updated on a yearly basis.

Pages 8-10

LOE 4: Organizational Change Management – Current State

4.1. Since a significant portion of project deliverables are dependent on harmonization of business processes and a comprehensive set of business requirements document, a full-time organizational change management lead is required.
Some of the key roles of this individual include: engagement, communications, transition, training, etc.
4.2. To minimize risks and maximize efficiencies, an industry standard for organizational change management approach that will align with the project‘s activities will be adopted.  A strategy and supporting plans (e.g. communications, training, and transition) will be adopted.
The final documents will be part of the Project Management Plan.

 

Pages 10-12

 

LOE 5: Project Management Framework

 

 

5.1. The agencies’ Project Management Office will create a project management framework, governance structure and templates that are consistent with TBS guidelines and reflect requirements. Although the framework will be developed for IT-enabled projects, other types of projects could benefit from the framework. These leveraging opportunities will not be track by this action plan.
These will increase the effectiveness of project management and provide controls to support the delivery of projects including compliance with the Policy on the Management of Projects.
Through the Project Management Office, the agencies will receive ongoing project monitoring through a dashboard which also identifies and assesses project risks with mitigation strategies to address the portfolio of projects
5.2. To develop detailed scope, a schedule and project costs the detailed business requirements are required. The business requirements will be based on the harmonized business processes.

 

Pages 12-14

LOE 6: Resource Management

 

 

6.1. Resourcing strategies will be discussed with DG Human Resources and a Resources Management Plan will developed and presented to the project Executive Committee. The plan will address identified gaps as well as the need for a solution architect.
6.2. Skilled resources (project manager, business analysts, IT manager/lead and solutions architect) with experience commensurate with the project complexity (size and risks) will be secured either through hiring of term employees or contractors.
Additional resources may be secured as required by the proposed approach recommended in the options analysis.

Pages 14-15