Skip to main content

Information Technology Strategy Team

Pilot IITB Procedures on Product Management

Last modified: 2022-02-25
This is a DRAFT (v0.4) document

DISCLAIMER

This document does NOT attempt to explain all aspects of Product Management (such as vision setting, user research, and the different phases a product goes through in its life cycle). These are well documented already, such as on PMI.org and PDMA.org.

Instead, this documents seeks to provide structure to ESDC Programs and IITB in the transition from project to product, within a Canadian federal government context. In particular, the methods to fund cross-functional and cross-branch product teams.

The Directive and Standard strive to be as succinct and to the point as possible, without repeating rules in existing policy instruments that teams are expected to comply with (such as Financial and Security). To help the reader understand the rationale behind them and provide guidance in implementing them, a Guidance document has been written.

Table of Content

Effective Date

These are pilot Procedures, as part of the 2021-IITB-37 Branch Initiative.

Authorities

This standard is issued pursuant the authority indicated in the Pilot IITB Directive on Product Management.

Procedures

The following procedures are used pursuant the Pilot IITB Directive on Product Management.

Establishing and Approving the MOU

  • Involvement of BRM and IPPM (funding)
  • Approved at PPRC, endorsed by PPOC by validating the following:
    • Sources of funds secured
    • Product Brief created
    • Organizational structure documented
    • Governance structure documented
    • Inventory of Applications from the Corporate Solution Directory is up to date
    • MOU has been validated by DG-level from Sponsoring Branch and IITB’s
    • Product Roles have been defined
    • Location(s) of the Product Team’s requirements repository(ies) is up to date

Performing Oversight

  • IITB personnel enter their time in CATS
  • At any time, an auditor (from ???) may audit the product team regarding artifacts expected to be produced as mentioned in the Directive (section 5.3 Oversight and Reporting)
  • PPOC gets the number of cybersecurity vulnerabilities report for the CSD applications under the ownership of the product
  • PPOC gets a copy of the APM assessment for the CSD applications under the ownership of the product

Endorsing the Product Roadmap Annually

  • In Q4, Product Manager produces next year’s Product Roadmap
  • Product Roadmap is endorsed at PPOC
    • PPOC may challenge, at their discretion, the roadmap’s outcomes sought based on the cybersecurity vulnerability reports and APM assessments
  • Product Roadmap is approved at PPRC
    • PPRC may, at their discretion, request the roadmap to be require Enterprise Architecture Assessment
  • Once approved at PPRC, product’s CATS code is renewed

Engaging Architecture

Enterprise Architecture intake is only engaged should:

  • a significant architectural change be planned as part of the Product’s Roadmap, and/or
  • PPRC requested it

Within a fiscal year, periodic touch points between the Product Team’s IT Manager and the Solution Architecture’s Manager are established to evaluate the scope of architectural change from the product’s roadmap ambitions. The number of touch points during the year is at the discretion of the Product Team’s IT Manager and is no less than one.

One touch point in Q4 with the Solution Architecture Manager is to provide assurances to PPRC before endorsing the Product Roadmap for the fiscal year.

The Solution Architecture IT Managers are:

  • (email)
  • (email)

The EA Intake functional email is: (functional email)

This image depicts the business process modeling notation (BPMN) for engaging the Architecture domain when making produce improvements. The BPMN includes 5 horizontal swimlane labeled Product Team IT Manager, Solution Architecture IT Manager, Enterprise Architecture, Architecture Domains, and EARB. The process flow is as follows: Start in Product Team IT Manager swimlane, goes to Schedule Informal Meeting with Solution Architecture, goes down towards Solution Architecture IT Manager swimlane to Evaluate Roadmap Potential Impact to Architecture, goes to a decision point called Potential Impact? If no, goes to End (in the Product Team IT Manager swimlane). If yes, goes up to Product Team IT Manager swimlane for Engage EA (email), then goes down to Enterprise Architecture swimlane for Schedule Domain Meeting with IT Manager, goes to Architecture Domains swimlane for Evaluate Architectural Impact, then continues right to Recommend Changes, then goes down to EARB swimlane for Secretarial Approval. The BPMN finishes by going back up to the PRoduct Team IT Manager with END.
Figure 1. How Architecture is engaged for each touch points

Performing Audits

  • PPOC may, at their discretion, perform audits.
  • Auditor requests most recent copies of expected artifacts as mentioned in the Directive section 5.3 Oversight and Reporting
  • The Product Manager sends artifacts to the Auditor
  • Auditor assesses level of compliance (i.e. whether artifacts exists and their level of completeness)

Reporting Non-Compliance

  • Audits and annual renewals are events that may trigger non-compliance records
  • Records are kept by PPOC and may be used as justification to gradually increase the severity of consequences (as mentioned in the Directive).
View this page on GitHub