Skip to content

Project Workspace Changes#

Important

Any changes to any of the Project Workspace sheets, reports or dashboards must follow an agreed procedure and must be properly documented. The steps to achieve each of these requirements are described in this section.

Important

Since Portal is using Smartsheet ID of the Project Workspace, any changes of the Project Workspace contents can only be done in the existing version of the workspace which cannnot be replaced by a newer worspace version as a whole. This is reflected in the workspace release procedure described further in this section.

Changes to the Project Workspace are prepared and issued in batches after a reasonable collection of changes has been prepared. In many occasions the changes relate with each other, especially when they are part of a major improvement/project implementation which affects more than one sheet and potentially also affects the workspace structure.

Changes to the workspace are effected on the SOURCE:xxxx_GTE-ProjectWorkspaceTemplate workspace. This workspace is identical to the live template workspace xxxx_GTE-ProjectWorkspaceTemplate at the time of releasing a new Project Workspace version, and will gradually deviate with new functionality and changes that are prepared and not yet released.

Releasing Changes#

Routine Changes via Release#

Typically, changes to the workspace will be released to the template workspace and apply only to future projects created using that version of the template.

Note

Before project workspace release, make final checks of the new workspace version, including:

- all cross-sheet references are correct
- sharing of all sheets/reports/dashboards is correct

The GTE Project Portal uses the Smartsheet ID of the Project Workspace for project provisioning. Therefore the ID of the new workspace needs to be stored in the Portal database after the release of a new version. To publish/release the current SOURCE version of the Project Workspace, follow the below procedure:

  1. Update release version number in '10 Integration / _System / PW Release Version' sheet.

  2. Rename the existing template workspace for roll-back purposes.

    • Login to the GTE Smartsheet account.
    • Right-click the workspace and select 'Rename'.
    • Name the workspace Z_BKUP-yymmdd:TEMPLATE:ProjWorkspace:Vx.y (Vx.y indicates previous release version number).

  3. Save a copy of the SOURCE to be released.

    • Right-click the workspace and select 'Save as New'.
    • Name the workspace copy as xxxx_GTE-ProjectWorkspaceTemplate.
    • Set up sharing of the copied workspace to be identical with the original workspace renamed in the previous step.

  4. Stop sharing the renamed workspace - remove all shared groups from the "Workspace Shared List" Share list, leaving only "GTE Group" as the Owner.

  5. Replace [SOURCE] in the names of all sheets, reports, and dashboards in the live template workspace with [TEMPLATE].

  6. Update smartsheet ID in the Portal database (after this step is complete, the new workspace is 'released')

    • Right-click the new workspace template and copy its ID into clipboard
    • Login to GTE Portal admin website and navigate to Configs section GTE Portal Configs
    • Edit templateStandardWorkspaceId parameter, replace the current vcalue with the workspace ID from the clipboard

  7. Save an additional copy of the SOURCE to be released for record purpose.

    • Right-click the workspace and select 'Save as New'.
    • Name the workspace Z_BKUP-yymmdd:SOURCE:ProjWorkspace:Vx.y (Vx.y indicates current release version number), ensuring to 'Include recipients & permissions settings' and leave all other settings as defaults.

  8. Consider deleting the previous backup workspaces (both the template and source versions).

Deployed Changes via Portal Update#

Occasionally, it may be necessary - or just possible - to deploy changes made to one or more template workspace sheets to the corresponding sheets in existing live projects. This is achievable using the maintenance functionality in the GTE Project Portal. Where such deployments are made, the changes must also be deployed to the SOURCE and live template workspaces using the same functionality, ie by including the relevant sheets in these key workspaces in the deployment list in the Portal.

It should be noted that such deployments are not easily tracked by the workspace versioning process so it is critical that these changes be recorded in the Workspace Template Change Log in accordance with the below versioning and documenting guidance.

Versioning & Documenting Changes#

All changes to the Project Workspace are documented in the PMF Template Change Log Smartsheet as follows:

  1. Each release is assigned a version number in the Vx.y form, x being a Major release and y a Minor release.

    Note

    A Major release is defined as substantial change of the Project Workspace structure, typically associated with some overall change in other systems/tools or a major change of used techniques/technologies. A Minor release is a change affecting only one or a few templates and implements an existing feature improvement, a new feature implementation or a fix of an issue in a current template.

  2. Each release description is formed by a group of rows, each containing a single change description (sub-grouped into 'Schedule' and 'Other').

  3. Each release has a header row, indicating a version number (e.g. Release V1.3) and a release date (entered into the Date column in the time of release).

  4. In case the individual change is also implemented in the live Project Workspace version, the corresponding checkbox in the 'Applied to Live' column is ticked.

  5. The following columns of the change log are intended for distributing to users as a change description:

    • 'Release Changes' - short change description.
    • 'Date' - date of the change implementation (not the release date, which will always be later). This date will be equal to the 'TEMPLATE BUILD DATE' sheet summary field value in the corresponding template, unless there is a further change to the same template in the same release batch.
    • 'Template' - name of the affected template.

  6. The following columns are intended for PMO internal purposes only:

    • 'Type' - User or Background change. User changes are to be announced via notification to the GTE PM mailing list; Background do not need to be announced.
    • 'Change Details' - further internal change details which do not need to be announced to public, and so may include additional technical context that may be useful for later reference.
    • 'Changed By' - indicates who implemented the change.

Important

To further increase change traceability, it is recommended that the release version number is also entered into the associated ticket entry column 'Group Tag' in the PM Framework Improvements & Issues - Ticket System Smartsheet. This way it is possible to match the individual entries in the change log with the PMF ticket. In addition, there is a column 'PMF Ticket #' in the PMF Template Change Log which should be used to reference the related PMF ticket.