Project Management Reference Guide

(1)

Project Management

Reference Guide

G o v e r n m e n t o f N e w f o u n d l a n d L a b r a d o r ,

O f f i c e o f t h e C h i e f I n f o r m a t i o n O f f i c e r

S o l u t i o n D e l i v e r y : P r o j e c t M a n a g e m e n t O f f i c e

9 / 5 / 2 0 1 4

The purpose of this document is to provide a reference guide for Project Managers engaged in projects with the Office of the Chief Information Officer (OCIO). Project Managers are responsible for ensuring their Project Team complies with the referenced project guidance.

(2)

(3)

Project Management Reference Guide Version 2.1 Page 2 of 44

Revision Log

Version

(Release)

Date

Description of Revision

Version 2.0 May 2014 Major formatting, organization layout, and content changes Version 2.1 Sept 2014 Updated technical information around browser versions

(4)

Document Ownership

The information contained in this document is confidential and proprietary to the OCIO and may not be used, reproduced or disclosed except as authorized by the OCIO. This guide is owned and maintained by the Project Management Office (PMO) of the Office of the Chief Information Officer (OCIO). Please direct questions about this guide to the PMO, email [email protected].

(5)

Preface

This is a guide for project managers, delivery managers, delivery directors and project teams to understand the Office of the Chief Information Officer (OCIO) project delivery methodology. It is not a “How to Manage Projects” manual and should be used to guide you through the project life cycle.

Project managers should consult with their delivery manager and/or directors where there is deviation from the standard guidelines and best practices in developing their project plans. Project management is not an exact science as each project will bring its own challenges, thus flexibility in adopting different approaches and methodologies may be considered if it will lead to a more efficient and cost effective project delivery.

Where exceptions to the general practice are considered and have been discussed with your delivery manager/director, please consult with the Project Management Office (PMO) and ensure the exceptions are documented and approved.

(8)

1.0 Introduction

This Project Management Reference Guide will provide the project manager with general guidance on how projects are delivered in the OCIO. It will guide the project manager to the proper source of information.

If there are issues not covered by this guide but are relevant to the delivery of projects, please advise the Project Management Office so that the document can be updated.

1.1 OCIO Organization

Please refer to the OCIO’s official website www.gov.nl.ca/ocio for more information about the organization. A copy of the OCIO’s Organizational Chart can be found at:

https://ocio-intranet.gov.nl.ca/sd/Documents/OCIO%20Organizational%20Chart.pdf

Below is the organizational chart for the Solution Delivery branch management team.

1.2 Application Delivery

The Application Delivery division is responsible for delivery solutions to our clients. In this division there are two directors and nine delivery managers. Project managers will report to a delivery manager on all projects and is the first point in escalation on project issues. In the early stages of a project, the project

(9)

Project Management Reference Guide Version 2.1 Page 8 of 44 manager, delivery manager and client services consultant will work closely in the project start up to assess client and OCIO readiness.

1.3 Project Management Office (PMO)

The Project Management Office (PMO) is a supporting arm of the Solutions Delivery Branch; it defines and maintains standards for project delivery and is also the source of documentation, guidance and metrics on the practice of project management.

The PMO maintains the Project Portfolio Management system (PPM) and the Systems Development Life Cycle (SDLC) methodology for all projects. For orientation and quick overview of PPM and the SDLC, please contact the PMO at [email protected]. More information on the PMO can be obtained from the website http://www.ocio.gov.nl.ca/ocio/pmo/index.html

1.4 Enterprise Architecture (EA)

There are two divisions in Enterprise Architecture (EA). They are the Strategy and Planning group and the Solution Design and Implementation (SDI) group. Both these groups contribute to the project delivery. The project manager is responsible for ensuring the project follows the OCIO Enterprise Architecture guidelines and best practices as outlined in the Enterprise Architecture (EA) Guidelines and Best

Practices for Government Technology Solutions.

The Enterprise Architecture (EA) Guidelines and Guidelines and Best Practices for Government

Technology Solutions is located on the OCIO Website.

http://www.ocio.gov.nl.ca/ocio/itresources/

Refer to Appendix A for details on the EA services. Strategy and Planning (S&P)

The strategy and planning group plays a significant role in the life cycle of the project. A technical prime is assigned from this group to the project and should be engaged throughout the project and not just in the design phase. It is especially important that the technical prime is engaged in the implementation phase

to verify that the solution being delivered is in accordance with the DAD.

The Strategy and Planning group provide services and consultations in the following areas:

• Detailed Architecture Design (DAD) consultations, including DAD approvals

• Architecture information, standards, support for architecture design

• Project Architecture Review Board (PARB) process

• RFP technical questions & presentation questions

• Technical requirements & technology consultations Solution Design and Implementation (SDI)

The SDI group provides infrastructure design, implementation and support for a project, such as development, test and production. The SDI group should be engaged throughout the project from the

design to close phases and incorporated directly into the project team. Below is a list of services provided

by the SDI group:

(10)

• Database support services

• Server creation (physical/virtual)

• Tenders - software and hardware

• SSL Certificate – request for SSL certificates

• Setting up development/test/staging/production environments

• Vulnerability assessments

• Network and firewall rule changes

1.5 Client Services

Improving service delivery provided to departments and supported agencies, boards, and commissions is a priority for the OCIO. Through focusing on developing relationships with its clients, the OCIO will be in a better position to provide IT support to employees and departments. Representatives from the OCIO meet with departments on a regular basis to provide IT advice and support.

Client services consultants are available to support project managers in the client relationship issues during a project. Project managers should engage the client services consultant, through their delivery manager on issues relating to client commitment, availability and meeting with senior officials who are not part of the project team.

1.6 Terms of Project Engagement

When conducting projects for the OCIO, project managers and project teams are required to adhere to the following terms:

• To the client department you are a representative of the OCIO; you will conduct yourself in a professional manner and project a positive image of the OCIO.

• Be accountable for ensuring appropriate professional conduct of all project team members.

• Be responsible for initiating all OCIO project setup processes for contractors on the project.

• Ensure that you understand the scope of the project and all required project deliverables prior to commencement of the project.

• Ensure project planning considers what can be realistically achieved from a vendor, department, and OCIO perspective.

• Take responsibility for ensuring that the project is financially sound and that financial projections are accurate and complete.

• Ensure that project deliverables are completed and provided to the OCIO within agreed timelines. You are responsible for the delivery of all project deliverables even though they may be prepared, reviewed, and approved by resources in other OCIO branches. Project managers should take the lead in initiating the deliverable(s). If you are unsure of the content to include, first review the template and if necessary speak to the delivery manager to obtain a sample(s) completed from a previous project(s). The template will serve as a guide to lead discussions with the deliverable owner(s).

• Assume responsibility for the quality of all project deliverables and ensure an appropriate quality review has taken place within your organization prior to presenting them to the OCIO and department for sign-off.

• Ensure all project information is reviewed by the delivery manager prior to being presented to departmental representatives.

(11)

• Document project changes and decisions and discuss with the delivery manager prior to presenting them to the project sponsor and steering committee.

• Seek prior approval from delivery manager, client services and the client for any meetings with departmental representatives above the project sponsor; or for any presentations to departmental representatives related to a change in project scope or client expectations.

• Meet with the client and delivery manager on a regular basis to ensure that they are aware of the project status and any project issues.

• Contact the delivery manager if attempts to resolve issue(s) related to client and OCIO commitment to a project have not been successful.

• Take responsibility for escalating project issues within the Solution Delivery Branch. Any issues that cannot be resolved in a timely manner by the project manager should be escalated to the delivery manager. Escalated items should be forwarded via email with a title of ESCALATION: (Project

Name) and (Issue) and be identified as “Important”. The delivery manager should also be contacted

via telephone to ensure s/he is aware of the issue. Important Note: Appropriate protocol will be followed when escalating project issues within the OCIO. The delivery manager will be engaged first; the director and executive director (in that order) should only be engaged if it is deemed that the issue is not able to be addressed at the delivery manager level.

• A Project Steering Committee is required for all projects and should include the project sponsor (Chair of the Steering Committee – role may be delegated), the delivery manager, and the project manager. Other members of the steering committee will be determined from the Stakeholder’s

Analysis.

• Follow the OCIO Steering Committee Agenda template for meetings.

• Be knowledgeable of the latest release of this Project Management Reference Guide located on the PMO website http://www.ocio.gov.nl.ca/ocio/pmo/pmrg.html.

2.0 OCIO SDLC Orientation

2.1 Orientation Meetings

At the start of every new project, the project manager will need to schedule a meeting with the delivery manager, and the Project Management Office (PMO), for an OCIO SDLC orientation session. To schedule PMO orientation meeting, email: [email protected]

Activities covered in the Delivery Manager Orientation meeting will include:

• Complete necessary forms for the project manager to gain access to the OCIO network and facilities.

• Determine project approach, review the Preliminary Scope Document, and define planning activities and timelines.

• Review available project documentation (E.g. Project Initiation Document (PID), Business Case, Preliminary Scope, & Lessons Learned from similar projects)

Activities covered in the PMO orientation meeting will include:

• Review the System Development Life Cycle and the use of OCIO project reference materials.

• Review the use of CA Clarity PPM.

2.2 Reference Material

(12)

Project Management Reference Guide Version 2.1 Page 11 of 44 All project managers will have access to the OCIO’s Project and Portfolio Management (CA Clarity PPM) solution and will be required to manage their projects using this system. Project managers will monitor their resource requirements, project tasks, milestones, risks, issues, and status reports within PPM. PPM also provides a collaboration space for the development and management of project documents.

The PPM Quick Start Guide is located in the PPM Knowledge Store under ‘Administrative Documents’. Note that the PPM Knowledge Store contains Administrative Documents and Quick Reference Guides. For assistance with PPM, email: [email protected]

2.3 PMO Website & SDLC Templates

The Project Management Office website (http://www.ocio.gov.nl.ca/ocio/pmo/) is the official source for project SDLC templates. The site is also home to this Project Management Reference Guide, the SDLC documents register, frameworks and guides, presentations, and frequently asked questions. Questions or comments regarding PMO processes can be forwarded to [email protected].

New projects will be required to use the latest version of the SDLC template on the PMO website, under the relevant SDLC stage (http://www.ocio.gov.nl.ca/ocio/pmo/sdlc.html). For projects currently underway, Project Teams will not be expected to transition to a revised template, unless specifically notified by the PMO.

2.4 OCIO Help

OCIO Help (https://ociohelp.psnl.ca/SitePages/Home.aspx) is an internal site that contains a number of forms, best practices, directives, guidelines, policies, and standards that you will need to access throughout the project.

3.0 Project Startup

3.1 Network Accounts, Email, and/or Computer Equipment

OCIO Issued Laptop / Desktop

All contractors working on-site at the OCIO will be required to use an OCIO issued laptop or desktop. Note that this process may take up to ten (10) business days to complete.

Project-related Software

There may be costs associated with some software requirements; Director approval is required for software purchases. This process may take up to 10 business days to complete.

Government Network and Email Accounts

For all project teams, the project manager and senior analyst will be required to have a Government email account. A Government email account must be used for all project related communication, and to facilitate meeting arrangements with the OCIO and other Government staff. The delivery manager will first create the project manager account by submitting the form “Request for Network Accounts and/or

Computer Equipment”. Once the project manager account is created, then the project manager is

responsible for initiating requests for additional accounts for the project team.

To request an OCIO-issued Laptop / Desktop, Project-related Software, and/or Government Network and Email Accounts for the project team, the project manager will complete the Request for Network

Accounts and /or Computer Equipment and submit it online. Send all inquiries to [email protected]

or 729-HELP (4357).

The Request for Network Accounts and /or Computer Equipment is located on the OCIO Help website

(13)

3.2 Government ID Badge & Telephone

A Government ID Badge is required for all contractors and project managers working on-site at the OCIO. To request Government ID Badges and telephones for the project team, the project manager will complete the Employee/Contractor Request Form and send the form via email to OCIO Facilities Management ([email protected]).

The delivery manager will first submit a request for the project manager’s Government ID Badge and telephone. Once the project manager has been setup then it will be the responsibility of the project manager to initiate requests for the project team. To avoid processing delays, the project manager will include (cc) the delivery manager on the email. Note that this process may take up to ten (10) business days to complete. If a badge is lost or stolen you need to email OCIO Facilities Management immediately and advise your delivery manager.

The Employee /Contractor Request Form is located on the OCIO Help website

https://ociohelp.psnl.ca/Pages/Form.aspx).

3.3 Virtual Private Network (VPN) Remote Access

To request Virtual Private Network (VPN) access for the project team, the project manager will complete the Remote Access Request Form. All applicants are to first email their supervisor to ask for approval to have a VPN account. The returned approval email will be forwarded to the service desk along with the Remote Access Application attached. All sections of the form are to be completed, unless otherwise noted. Incomplete forms will be returned. Please allow 5-10 business days after this approval has been received.

Once the VPN token (either software or hardware) has been received, it can be activated by calling the service desk at 729-4357 during normal business hours. Activation is acknowledgement that the Terms & Conditions in the application form have been read, understood and accepted.

Send all inquiries to [email protected] or 729-HELP (4357).

The Remote Access Request Form is located on the OCIO Help website

https://ociohelp.psnl.ca/Pages/Form.aspx).

4.0 Project Administration

4.1 General Office Supplies

If the project team is located at an OCIO office location other than the Higgins Line location, the project team’s general office supplies should be treated the same as general office supplies for the Higgins Line location. General office supplies include such items as: paper, pens, pencils, file folders etc. Contact solution delivery administrative staff ([email protected]) to coordinate the purchase and delivery of general office supplies.

4.2 Booking Rooms at OCIO

OCIO meeting rooms can only be used by contractors working on the OCIO premises. Contractors completing project work offsite can only use the OCIO meeting rooms when OCIO representatives are participants in the meeting. Otherwise, contractors will have to use their own premises or a client meeting space. Additional meeting space is available within various government departments. Check with your client to determine if other facilities are available.

(14)

4.3 Booking Training Facilities

The OCIO has one training room equipped with computers (maximum 12 trainees) for project related training. If you will be conducting training sessions at the OCIO or at another government location, the project manager is responsible for coordinating the required computer setup.

Contact the OCIO training coordinator ([email protected]) to determine the availability of the training room. Other meeting rooms can be arranged though solution delivery administrative staff. You will be required to provide the name of your delivery manager, project name and the nature of the training to be conducted. You will also provide your contact information and identify the hardware / software requirements. Someone from the project team will need to be available to work with the computer support staff to configure and test the equipment prior to the training session.

4.4 Visitor Protocol

When a project team is hosting a meeting or training session at the OCIO and where attendees are external to the OCIO (including government employees), project managers will inform visitors of the following OCIO visitor protocol. You can contact OCIO Switchboard at 729-4000.

• Visitors should be informed of the visitor protocol prior to their arrival at the OCIO.

• Visitors should park in the Confederation Building parking lot, not the OCIO parking lot. OCIO reserved parking spaces are not to be used for visitor parking. There is limited visitor parking and taxi service should be considered as an alternative to parking.

• Visitors will use the OCIO front entrance. The visitor should be made aware of the OCIO host person’s name so they know who to ask for upon their arrival to the OCIO. A list of expected visitors will be left at the front desk security in advance of any meeting or training session. Visitors will wait in the lobby until escorted to the meeting / training room. If there is a group of participants expected, they should wait and go together as a group.

• All visitors will be signed in by an OCIO staff member or an in-house OCIO contracted resource. The OCIO front desk security will record the participant’s name in the visitor’s log and assign them a visitor badge. An OCIO staff member, or an OCIO contracted resource, will be responsible for all visitors.

• Visitors will be escorted to the OCIO meeting / training room even if they are familiar with the OCIO building. Visitors will wear their visitor badge at all times and are not permitted to wander around the OCIO unattended. When the meeting or training session has ended, visitors will be escorted out of the building and their visitor badge returned to the front desk security, even if it’s a lunch departure.

• At the start of a meeting / training session, preview the evacuation process and washroom locations with your participants.

• Visitors are to avail of the washrooms on the 2nd floor only; they are not to be given access to other areas. This does not apply to people who are in the classroom (3C).

• Visitors will respect the government’s scent awareness policy and not wear scented products.

• Clean up the room when you are finished your meeting: remove all flip chart notes, clean white boards, remove leftover coffee, food, etc.

Important Note: After hours meetings (training) are discouraged and will only be permitted in extenuating circumstances.

(15)

4.5 Wireless Guest Account Access

Temporary Account (One Day): Project teams requiring guest accounts for the OCIO boardrooms should contact the administration personnel in the branch ([email protected]) to obtain temporary access accounts. The request for an account will be made by OCIO managers/directors via email. For longer access, completed forms will be sent via email to the departmental guest administrator for processing. If you do not know who the guest administrator is for your department, please contact the OCIO service desk at 729-HELP (4357), or your client services representative. If access for a period exceeding five days is being requested, this form will be forwarded via email to the OCIO network operations team ([email protected]), with the required deputy minister approval attached.

The Wireless Guest Access Request form is located on the OCIO Help website (https://ociohelp.psnl.ca/Pages/Form.aspx).

For assistance on longer term access contact the IT service desk [email protected] or 729-HELP (4357).

4.6 Exit Procedures

Government ID Badge

All government ID badges will be returned to the OCIO delivery manager when the contract/project has concluded and forwarded to Corporate Services for deactivation.

Telephone

Note that when the contract with the OCIO concludes, the telephone’s voice mail password will need to be reset to the seven digit phone number.

Cubicle Assignment

Note that when the contract with the OCIO concludes, the branch administrative person must be notified that the cubicle/office space is now available in order to update floor plans.

Government Assets

When the contract concludes, the government asset will be returned to the OCIO; contact the IT service desk at [email protected], or 729-HELP (4357), to make arrangements for return of the laptop /desktop.

VPN Tokens

Hardware tokens that are no longer required will be returned to the OCIO (Operations Branch Remote Access Team).

4.7 Re-assigning Government Assets

Where government assets are assigned to a team member, such assets cannot be re-assigned to another member without contacting the IT service desk by phone at 729-HELP (4357) or by email at

[email protected].

4.8 Obtaining Overtime for OCIO Project Resources

Prior to overtime being incurred by an OCIO employee, a “Request for Overtime Performance” form should be completed and approved.

(16)

Project Management Reference Guide Version 2.1 Page 15 of 44 The project manager is responsible for completing and submitting the form to the applicable OCIO branch administrative staff that will review the request and seek the required approvals. Please refer to Section

10.0 Contacts: Branch Administrative Contacts.

Approved overtime requests will be assigned a tracking number which will be referenced by the employee when recording the hours worked on the applicable Record of Overtime form. It is the project manager’s responsibility to monitor the actual hours of overtime incurred to ensure the OCIO employee overtime hours worked does not exceed the number of approved overtime hours.

The overtime form is located on the OCIO Help website https://ociohelp.psnl.ca/Pages/Form.aspx).

4.9 Occupational Health and Safety (OHS)

Project managers, as supervisors, are accountable for the health and safety of project team members reporting to them. Safety should be as important as quality and productivity within the workplace. Note

the OCIO OH&S program is still under review and will be posted on the OCIO Help intranet site once approved. All OCIO employees and contractors will be required to become familiar with the OCIO OHS

Polices and Guidelines and participate in the OCIO on-boarding process.

Information on the OCIO’s OHS Committee is located on the OCIO intranet O@SIS: (

https://ocio-intranet.gov.nl.ca/forms/SitePages/Home.aspx).

5.0 Key Project Information

5.1 SDLC Documents Register

The SDLC Documents Register contains a complete list of OCIO SDLC templates and documentation. It provides document naming conventions, the relevant stage of the SDLC to begin and finalize the document, the location of the template, and the document owner.

A deliverable is not considered complete until all required approvals have been obtained and the approved document has been stored in PPM. Approvals do not require wet signatures as electronic or email approvals are acceptable in most cases. Upon project closure, the project manager is responsible to ensure all final versions of the project deliverables are stored in PPM. After closure, the PMO will initiate the process to have relevant project files copied to TRIM. All project deliverables will be approved by the OCIO, and the client when applicable.

The SDLC Documents Register is located on the PMO website.

http://www.ocio.gov.nl.ca/ocio/pmo/index.html

The SDLC methodology is based on the waterfall model. For the smaller projects a more iterative

waterfall approach may be used. The methodology is described at very high level below. Please refer to

the PMO website for details of deliverables based on size and type of projects.

http://www.ocio.gov.nl.ca/OCIO/pmo/fandg.html

5.2 Concept Phase

In this phase of the project the client services division provides a Business Case and a Preliminary Scope Statement. These documents are then used to initiate a project.

5.3 Initiate Phase

In this phase of the project the Project Management Office (PMO) creates a Project Initiation Document (PID). The PID provides background information on the proposed project. If it is a replacement of an existing solution or an enhancement, background information is included in the PID.

(17)

Project Management Reference Guide Version 2.1 Page 16 of 44 The PID also includes information on the key resources from the other branches of the OCIO that the project manager should consult in the planning of the project.

5.3.1 Client Readiness and OCIO Readiness Checklist

In this phase of the project, there are two checklists in the PM Tool Kit that every delivery manager is encouraged to use before their project start up. These two checklists are the Client Readiness Checklist and the OCIO Readiness Checklist (Under development).Please use these early to assess your project. If your assessment raises any concerns, discuss with your director who will engage client services and determine if the planning activities and engaging a project manager should proceed.

5.4 Planning for Analysis

In this Phase a detail plan for the Analysis phase of the project is completed. Here is where the PM confirms the scope of the project with the project sponsor. The scope of work should be finalized and be included in the project charter for projects that are not large or extra-large. At the end of this phase three key deliverables should be completed, the project plan, scope of work and the project charter. The project charter should be signed off before proceeding to the next phase of the project.

5.4.1 Stakeholder Analysis

While this is not a deliverable, it is a useful tool that the PM can use to get an understanding of who are the key players and assess their roles and influence that they may have on the project. This is useful information when completing a risk assessment of your project.

5.5 Analysis Phase

The Analysis phase is where most of the heavy lifting on a project is done. At the end of this phase a determination will be made on how to proceed with the project. It is a key Go/No Go decision point. Below are some of the key activities in the analysis phase. These may not apply to all projects. It is anticipated that the OCIO will be in a position to re-use existing technology as in house skill sets are developed, thus the analysis phase could be focused on a Fit Gap Analysis of existing technology.

5.5.1 Business Process Definition & Financial Business Process Definition

If your project has any financial transactions, then the project team will be required to complete the

Financial Business Process Definition template (contact the PMO for a copy of the template) and have it

reviewed and approved by the Department Comptroller and the Office of the Comptroller General (OCG). If there are any financial transactions in the project, whether or not it is integrated with the Financial Management System (FMS), the OCG should be consulted and it is recommended that they be part of the project team early in the process. The Financial Business Process Definition template includes the

Business Process Definition and a separate document is not required to be completed.

If your project does not have any financial transactions then use the Business Process Definition template to document the business process of the client. In the early stages of the project, the PM should have obtained the current business processes and review with the client. The Business Process Definition template is then used to update the future state of the client’s business.

This process does not apply to all projects; refer to the PMO website to determine when to do this according to project size and type. (http://www.ocio.gov.nl.ca/ocio/pmo/index.html)

(18)

5.5.2 Pre-TRA Business Requirements & Security

The Pre-TRA Workbook is completed at this stage by the Information Protection (IP) branch. The PID would have the information on how to engage the IP team. Below is the background for completing the Pre-TRA Workbook.

Security best practices within industry require that systems be implemented with the necessary security controls to protect the information within the system and the network upon which the system is deployed. The amount (and type) of security required is proportional to the sensitivity of the information in the system – the higher the sensitivity of information, the more security that is required.

• Collecting information that is deemed sensitive in terms of confidentiality requires additional security controls to protect the information from unauthorized access, use or disclosure.

• Collecting information that is deemed important in terms of integrity requirements requires additional security controls to ensure the information is not tampered with or altered inappropriately.

• Collecting information that is deemed important in terms of availability requires additional security controls to ensure the system and its information are accessible to end users as needed.

The amount (and type) of security required is also proportional to the exposure of the system to the internet. Exposing a system to the internet (e.g., via a Public/External Portal) requires additional security controls to protect the information and the network from cyber threats (e.g., hackers, malicious viruses), which are a significant challenge facing the IT industry today.

In addition to information sensitivity and Internet exposure, it is also worth noting that certain types of business functionality can also increase the complexity of a solution and/or the level of security required. For example, the following types of business functionality increase the complexity of a solution and as such, will likely increase the costs, resources and timeliness associated with a project:

• Integration with other IT systems

• Authentication of external users via the Internet

• Submission and upload of documents by external users via the Internet

• Display or download of documents to external users via the Internet

• Financial integration

The client, as the information owner, can ultimately determine how much risk they are willing to accept with regard to risks to their information (e.g., the information they would like to collect in the system and/or expose to the Internet). The OCIO, however, as owners of the government’s IT infrastructure, would determine the risks that are acceptable to the network or other IT systems outside of the client’s system. For more information related to Information Protection Division Services, email

[email protected].

5.5.3 Requirements Document

This document includes the business requirements of the client, the functional, financial and technical requirements of the solution. At the start of the requirements gathering it is recommended that the business analyst (BA) assigned to the project consult with the OCIO business analyst for guidance on completing this document. The BA should also engage the OCIO BA midway through the requirements gathering to ensure that the template is being completed as per the OCIO’s standards. Also at the end of the requirements gathering, the OCIO BA should be engaged for a quality check before seeking client sign off.

(19)

Project Management Reference Guide Version 2.1 Page 18 of 44 Prior to the completion of the requirements document and the issuance of an RFP or Tender, the project manager will consult with the web development team to ensure accessibility, usability, and brand compliance expectations are included in any client requests for a web based solution. Project managers should reference the Web Development Standards and Guidance on implementing standards for web development prior to consultation

5.5.4 Recommendation on How to Proceed

At the end of the analysis phase a recommendation on how to proceed will be completed. If a preliminary recommendation on how to proceed was done in the Initiate phase of the project, then the existing document will be updated. At this stage the delivery manager should be in a position to recommend a COTS, SaaS, Custom Build or enhancement to an existing solution. Also the project cost estimates that were provided from the planning phase should be updated with more accurate estimates.

5.5.5 Go/No Go Decision

At this stage of the project a decision will be made whether to proceed with the project based on the information gathered from the analysis phase.

5.6 Planning for Design

This is the planning for Design to Close out phases of the project. Planning in this phase is critical for project success. The key objective for these phases is to deliver a quality solution that meets the needs of the client on a timely basis and on budget.

Below is a list of factors to consider in your planning. These may not apply to all projects, please refer to the PMO website for the recommended deliverables based on project size and type.

Factors to consider:

Develop a deliverables matrix with a RACI chart. This has proven to be helpful on some projects;

Develop a Traceability Matrix, this would tie in to the requirements document and would be very helpful in developing testing plans, and would also verify that we are delivering what was requested.

Develop a Quality Assurance plan – it does not have to be an elaborate document, but it will outline how you plan to ensure quality is monitored throughout the lifecycle of the project. For custom built solutions, there is the Quality Assurance Checklist. Engage Application Services (AS) early and obtain their inputs and agreement. Get agreement on coding standards, discuss with AS the challenges that they have encountered on recent custom built solutions. Review some support requests from custom built solutions that have been recently implemented. This may guide you to avoid some of the same post implementation support challenges;

Risk Management Plan – once again this does not have to be an elaborate plan. For enterprise and large projects a formal risk plan will be required. The risk plan should include how the risk assessment is done, how risks will be managed and monitored throughout the project life cycle.

Change Management Plan – this is an overlooked activity on most projects. It is crucial that change

management examine the impact of introducing a new way of doing business to the end users, how to deliver the message and introduce the new solution, and how to get buy in. The Communication

Plan will be a key aspect of the change management strategy.

Test Plan – a test plan should be developed in consultation with all key stakeholders. Consider unit testing, system testing, integration testing, user acceptance testing, regression testing, stress testing and performance testing.

(20)

Project Management Reference Guide Version 2.1 Page 19 of 44 Training Plan – ensure the training plan includes end users, super users and support resources training. The plan should include how the training will be delivered, such as train the trainer, CBT’s, on site or offsite. The training plan should be reviewed with all stakeholders that will require training to obtain their input and acceptance of the plan.

Procurement Plan – start planning the procurement of hardware and software early. The procurement of hardware and software would be validated during the Detailed Architecture Design (DAD) approval. While it is the practice that all hardware and or software can only be ordered when the DAD has been approved, exceptions can be sought in consultation with the Director of Enterprise Architecture where the project time lines can be impacted if a tender has to awarded for procurement. Approval may be granted if the DAD has been submitted and feedback has been provided and the document is substantially completed.

Prior to the beginning of any application build, the project manager should consult with the web development team to obtain assistance in the planning process to ensure accessibility, usability, and brand compliance expectations are addressed.

Resource Plan – this plan should include all resources on a project such as vendor, client and OCIO resources. This plan should be for the whole project and not just the current work offer or SOW. If a resource name is unknown, list the role and the time frame. As with all plans these will be updated on a regular basis as the project progresses.

Complete the Project Charter and get client sponsor sign off before proceeding to the next phase of the project.

This is not an exhaustive list as the project manager is expected to bring his/her experience and knowledge to the project team.

Planning should be within the scope, time and cost estimated for the project.

5.7 Design

In this phase of the project the key tasks/deliverables include completing the DAD, obtaining approval and begin the procurement process. It is at this stage that the project team would request provisioning of the various environments such as development, staging, and production environments.

The DAD is reviewed and approved by the Strategy and Planning team in the Enterprise Architecture division. The approval process begins with the submission of the DAD to the EA Prime assigned to the project. This individual will review the DAD for completeness and will work with the project teams to complete the DAD if necessary. Once this is done, the DAD is forwarded to the Project Architecture

Review Board (PARB) for a compliance review according to best practices and OCIO standards.

The DAD is submitted to EA by email at [email protected]

Factors to consider:

Project teams may also conduct a Security Design Review of their proposed solution/architecture to minimize any rework that could potentially arise from a vulnerability assessment (VA) in later phases of the project. The security design review can be requested through the VA coordinator at

[email protected]

Application Prototyping – project teams may consider doing screen mock ups for look and feel and review with client and application services.

Complete the Transition Agreement. Application Services and Operations are the key stakeholders in this agreement. This agreement should be signed off at this stage. It is living document and changes can be made to it as the project progresses. Check the QuickReference guide on the PMO Website

:

(21)

Project Management Reference Guide Version 2.1 Page 20 of 44 http://www.ocio.gov.nl.ca/OCIO/pmo/Implementation_Transition_Quick_Reference.pdf

As part of planning, the project manager should allow two weeks for the drafted DR plan to be reviewed by Subject Matter Experts (SME). A DR plan is a mandatory deliverable for all solutions being implemented. If the project involves changes to an existing application, the project team will work with that DR plan owner to update as the current owner is responsible for updating the DR plan. If no DR plan exists, the project team will be responsible for writing the plan. Important Note: If the Category of IT Services is classified as “Critical” (as stated in the Corporate Asset Management Portfolio), then the DR Plan will be tested during the Implement SDLC stage.

The Disaster Recovery Plan template is located on the PMO website.

(http://www.ocio.gov.nl.ca/ocio/pmo/execute.html)

5.8 Execute

In this phase of the project coding begins for custom built solutions or configuration/customization is done for COTS/SaaS products. Testing is also done in this phase and the test strategy should be developed and reviewed with the project team and sponsors. Client sign off will be required of the test results and client acceptance of the solution will done in the Implement phase prior to Go Live.

Key factors to consider:

Provisioning of hardware for development, staging and production environments would be requested after the DAD has been reviewed and approved. This request is sent to the Solution Design and

Implementation (SDI) team of the Enterprise Architecture division

at

[email protected].

Any software licences required for the project will be requested through the SDI team. Project teams must include the first year support and maintenance costs for any software purchases in their cost estimates.

Use the traceability matrix to ensure that the solution being delivered can be traced back to the requirements. If there are significant variations from what was originally requested, then consider doing a Project Change Request (PCR). In some cases a Decision Document may be required if there are significant changes to the scope, cost and schedule and the project sponsor and Steering Committee will have to be engaged.

Complete a code review with Application Services, review the Application Quality Assurance Checklist and make adjustments as necessary.

Consult with the Web Development Team and provide them with screen shots or visual plans of screen shots for review.

Accessibility, Usability, and Brand Compliance Review – prior to a Vulnerability Assessment (VA), the

project manager will contact the web development to complete an Accessibility, Usability, and Brand

Compliance Review of the application/system. The review will document any deviations from

accessibility, usability, and brand compliance perspective.

Project teams will address all issues noted in the Accessibility, Usability, and Brand Compliance

Review. It is the project manager’s responsibility to ensure all issues are documented and forwarded

to the web development team. The response will address each issue, mitigated and unmitigated. Any issue that is not resolved will be documented by the web development team as a deviation. Once the identified issues are resolved, contact the web development team to review the issue resolutions. The client, in consultation with their Communication Division, will accept any unresolved issues/ deviations to close out the Accessibility, Usability, and Brand Compliance Review process. Project teams will not be able to proceed with “Go Live” until the deviations are signed off and accepted.

(22)

Project Management Reference Guide Version 2.1 Page 21 of 44 Web Browsers Supported: Where not specified by business requirements, internal web applications as well as Internet-facing applications not made available to the general public, should be capable of running in Internet Explorer versions 10, 9, and 7. Applications should be compliant with CSS3, and HTML.

Web applications for use by the general public should be useable in major browsers which include: Microsoft Internet Explorer;

Mozilla Firefox; Google Chrome; and Apple Safari.

Supported versions of recommended browsers should be the current version (at the beginning of the Implementation Phase of the SDLC) and the most-recent previous 2 versions.

Note: Although every effort is made to try and keep technical information as accurate and consistent as possible, the EA Guidelines and Best Practices will take precedence over this guide if there any inconsistencies found.

The Web Development Standards and Guidance on Implementing Standards for Web Development are located at (http://www.ocio.gov.nl.ca/ocio/itresources/).

Testing - the solution should be thoroughly tested and modifications made from the results of the test process. The project team should conduct unit testing and systems testing before engaging the client for UAT. Develop a test strategy and get client agreement. Other tests that may be considered depending on the size of the project include stress, performance and integration testing.

Prepare a Disaster Recovery (DR) plan that outlines the steps required to recover the infrastructure and the application. In the Planning for Design stage, the project manager should include planning activities to meet with the DR team and discuss the delivery and content of the DR plan. The project manager should engage the DR analyst to obtain guidance on the DR plan completion, by email at

[email protected].

5.9 Implement

In this phase of the project, client engagement will be crucial to the success of the project. The key activities will include, client acceptance, end user training, post implementation support planning, training for support resources, transition to support and vulnerability assessment.

Transition Agreement - this should have been signed off in the design phase. If you are in the

implement phase and this is not signed off, it is an indication that your project is in trouble. If it has been signed off, update the document with any new information and schedule regular meetings with AS and Ops to ensure that the terms of the agreement are still valid and all is on track.

Training – finalize the training plan and include training for all stakeholders including end-users, power users and AS and Ops resources. Decide on the approach to training, such in class, on line or train the trainer.

Prepare to test the DR plan if the application is classified as “critical”.

If a vulnerability assessment was done on the project, ensure all the remediation have been completed or resolved with Information Protection (IP). The deviation report must be signed by the director of IP before go live activities can proceed.

(23)

5.10 Close

In this phase of the project, the core project team would have finished and all government assets, badges and other requirements as per the exit procedure would have been completed. The only project resources still on the project are those involve in the stabilization and transition process.

Ensure all documentation have been completed and signed off and stored in PPM.

Update CAMP.

Discuss with your delivery manager a project celebration.

6.0 PM Tool KIT

On the PMO website (http://www.ocio.gov.nl.ca/OCIO/pmo/control.html) there are several tools that are available for the Project Manager to use on his or her project. The most commonly used and challenging ones are listed below:

6.1 Project Change Request

All project changes which affect scope, budget, or schedule will be documented in a Project Change

Request (PCR). Any changes to resources on a project, which may include substitution of resources, will

also require a PCR. Only approved Project Change Requests should be reflected in the project status report and project projections. Pending changes should be used as a notation only, not assumed in the baseline schedule or budget.

The Project Change Request template, Instructions, and a completed Sample are located on the PMO website (http://www.ocio.gov.nl.ca/ocio/pmo/control.html).

6.2 Request for Change (RFC) – Solution Delivery

All changes to production related environments will go through the Solution Delivery Change Coordinator (SDCC) and will follow the OCIO change management process. A meeting with the Change Coordinator is recommended once a project team begins planning their Request for Change (RFC). The SDCC is responsible for facilitating the change and the project manager is responsible for liaising with all required resources to ensure a successful RFC execution. The Change Coordinator will monitor the request and represent the RFC at the OCIO Change Advisory Board (CAB) meeting, if required. Note that not all changes will need to be reviewed by CAB. Contact the Solution Delivery Change Coordinator for further information at [email protected].

Normal A RFC: It is important to plan accordingly when submitting an RFC: there is a five (5) day change window required from the time of RFC submission to the start of the change window, with a Change Advisory Board Meeting somewhere within those five days to review the request.

The RFC will detail the resources required to implement the requested change. If the change requires OCIO resource(s) external to the project team such as Operations and/or Application Services then the Project Manager is responsible for contacting the required resource(s) and confirming their availability for the scheduled time. Important Note: If the Bell Aliant Service Management system is to be used, then a ten (10) day window is required; contact the AS or Operations team lead to determine if the Bell Aliant system is required for the change.

For any requests involving firewall rule changes, ensure the RFC is submitted at least ten business days prior to the implementation date. This will allow the various OCIO Teams to complete their responsibilities associated with these types of requests. The Firewall Rule Change form will be submitted with the RFC. Expedited requests, to implement a change in less than the five (5) day window, will require directors approval.

(24)

Project Management Reference Guide Version 2.1 Page 23 of 44 Project managers are required to complete an RFC for production changes, from which SM7 tickets will be created and then processed. Project managers will have VIEW ONLY access to SM7. Project managers can search for tickets using the assigned SM7 request number.

The Request for Change Form (RFC), Instructions, and a completed Sample are located on the PMO website at http://www.ocio.gov.nl.ca/ocio/pmo/control.html

6.3 Copy of Production Data

Project teams that require the use of production data for project “Staging and/or Go Live” activities will require client and OCIO approval. Requests for copies of Production Data will be sent to the Solution Delivery Change Coordinator at [email protected]. The Solution Delivery Change Coordinator will perform a QA and create SM7 tickets/tasks necessary to create the data copy. Please refer to the previous section titled Request for Change (RFC – Solution Delivery for more information.

Important Note: Production data should never be used in screen shots for documentation and presentation purposes.

The Copy of Production Data form is located on the PMO website.

7.0 Other Relevant Information

7.1 Service Manager 7 (SM7)

Service Manager 7(SM7) is ticketing system that AS and Operations used to track request for services and tasks assigned to their resources. Projects utilize SM7 for the RFC’s, Copy of Production Data and adding resources to the projects that were not in the project resource plan. Project Managers will have view only access to SM7.

7.2 Government Brand Compliance

Contractors will adhere to the Government branding standards for anything that requires the use of the Government Brand (presentations, documents, applications). Please refer to the Brand Signature website (http://www.gov.nl.ca/brand/) for more information. For additional information please contact the Web Development Team by email at [email protected].

7.3 Adding AS or Operations Resource

This section does not apply if Application Services or Operations resources have been previously identified in the Project Initiation Document (PID), as their Manager, Team Lead, and the resource(s) are already aware of the assignment.

However, if an AS or Operations resource who is not part of the core project team is to be added, but has not been identified upfront in the PID (i.e. unplanned) as being needed for a project, then a SM7 Request Fulfillment ticket would be required.

The Project Manager, team lead, and the resource will discuss the steps to add the resource to the project. Options could be team lead/resource enters the ticket in SM7 or the Project Manager sends a message to the IT Service Desk [email protected].

7.4 Cancelling (Closing) a Project

For OCIO projects that are cancelled, Project Managers are instructed to complete the same procedures and forms related to the normal closure of a project.

The Project Closure Report template is located on the PMO website.

(25)

8.0 Project Planning

One of the key success factors for any project is planning. The level of detail required for each project will depend on the size of the project and its complexity.

For Extra Small, Small and Medium size projects, the project plan may simply be a MS Schedule showing all the tasks in the WBS and resources required for each task. Project Managers may use Microsoft Schedule and then integrate with PPM or use PPM and export to MS Schedule.

For Large and Extra Large projects a more detailed plan is expected. In these cases, separate plans for Communication, Risk, Quality, Resource Plan, Training, Data Conversion, Implementation, etc. may be required. These plans are then rolled up in a Master Project Plan.

The Project Plan should be reviewed with all key stakeholders before seeking Project Sponsor approval. Projects Plans will be updated monthly and stored in PPM.

The Project Planning Checklist is located on the PMO website to guide Project Managers in preparing their plan.( (http://www.ocio.gov.nl.ca/ocio/pmo/control.html)

The project plan should cover the whole project not just the current fiscal year or work offer. If the downstream costs are not known, provide an order of magnitude cost and time line.

9.0 Resource Planning

Resource Planning is critical for all projects. Resources required for a project will be included in a detailed resource plan and updated monthly. The detail resource plan will include all resources anticipated for the project, including Client, OCIO, and Vendor resources.

If the name of the resource is unknown, then the role should be identified in the plan. It is especially important that not only Project Team resources be included, but also resources from Application Services, Operations, Enterprise Architecture, etc. who are needed for small pieces of effort, such as document reviews (Build Books, etc.) are included. This allows the other OCIO Branches to manage their workload and staffing levels.

The Resource Plan should take into consideration statutory holidays, provincial holidays, and vacations, and should also factor in summer working hours. The Resource Plan should be for the entire project and not just the Work Offer in effect at the time. Where the project spans multiple years, the current fiscal year should have detail resources (name or roles) identified and cost if they are external resources; and if internal, the salary allocation to be capitalized. For the resources that are not assigned fulltime to the project, their names and role should be listed.

The Resource Plan will be completed in Planning Stage to ensure assigned resources reflect the project needs. It is expected that the Resource Plan will detail all resources engaged in the project; their role and the expected engagement dates. The Resource Plan will be updated on a regular basis as details are elaborated and resource commitments confirmed.

The Project Manager is expected to provide forecasting for all resources required for project success. Although only estimates are required during planning, the Project Manager should reflect an accurate forecast of all resource requirements in the Resource Plan (PPM Tasks) at least for the current month and the next month.

The Project Manager should regularly engage AS and Operations to review the project Resource Plan validating all non-Project Team resource commitments. The commitment of all non-Project Team resources identified in the Resource Plan will be arranged and confirmed with their Manager. Project Managers should not assume that these resources are available, and should not contact these resources directly seeking commitment.

(26)

Project Management Reference Guide Version 2.1 Page 25 of 44 If the project timelines are revised throughout the course of the project, the project manager will reconfirm all time commitments for non-project team resources with their manager to ensure any revisions to the original commitment can still be accommodated. The Resource Allocations in PPM will be updated to reflect any revisions to the requested timeline.

9.1 Authorization of Contract Resources

Contracted resources are authorized to be engaged on a project when a purchase order (PO) has been issued. The PO is normally issued when a Statement of Work (SOW) has been received outlining the work to be done and approved by the vendor and the OCIO executive. Resources are not authorized to be engaged on any project unless a PO is in place. Plan ahead and make sure all the paper work is in place if resources are to be extended on a project. The fact that a project is in flight and a team is in place does not justify engaging the team without a PO. Thus resource planning and management of resources is extremely important.

(27)

10.0 Contacts

The following list identifies the contact areas within the OCIO that you may need during the project. These contacts are referenced in previous sections of this guide. Note that some of the contacts below are generic email addresses but are checked regularly by assigned OCIO resources; contact your Delivery Manager if you are not receiving timely responses for inquiries submitted to these generic email addresses.

Contact Information

Application Services

• Application Build Book

• Application Quality Assurance Checklist

• Chart of Authorities

• Copy of Production Data

• Database Build Book

• Operational Procedures Manual

• Post Implementation Support Plan

• Implementation Presentations to Application Services

• Source Code

Contact the AS Prime for the project as identified in the Project Initiation Document (PID).

Disaster Recovery Team

• Disaster Recovery Plan

Email: [email protected]

Production Services Team

• Application Decommissioning Form

Email:

[email protected]

ATIPP Office Sonja El-Gohary, Privacy Analyst, ATIPP

• Preliminary Privacy Impact Assessment Checklist

• Privacy Impact Report / Letter

Phone: 709.729.7128

Client Services Client Services Representatives http://www.ocio.gov.nl.ca/ocio/clientservices/contact.html Susan Wilkins, Director Client

Services

Phone: 709.729.3228

Email: [email protected] Service Level Agreements

Carl Noseworthy, Manager, Service Level Agreements Phone: 729.1417 Email: [email protected] Corporate and Information Management Services

Government Logo usage

• Jason Whiteway

Phone: 729.2162

OCIO Training Co-ordinator

• Project Teams should procure training through the OCIO Training Coordinator.

IP Division

• Pre-TRA and Information Security Classification (Risk Assessment Workbook)

• Vulnerability Assessments

• Security Design Reviews

• Threat Risk Assessments

Tracey Goulding, Manager of Information Protection, CIMS Branch

Phone: 709.729.3896

Project Management Reference Guide