Overview#
Project Register Workflow#
Process#
Categorization
Projects undertaken by GTE undergo a categorization process. This categorization, and in particular the underlying classification, determines the types of project management and engineering records and the general level of rigour required to manage the project, in accordance with the Output Applicability Grid. The categorization also considers the category of project and the disciplines involved.
Output Applicability Grid
Certain activities must occur, and certain outputs must be generated, throughout the execution of a project undertaken by GTE. The Output Applicability Grid handles the mechanics of determining, from the project categorization, which activities and outputs – and detail within these – are necessary.
In many cases a particular output or activity may be mandatory across all projects, however the underlying detail could differ vastly through the Output Applicability Grid stipulations for the components of that output.
Phases, Processes and Delivery Elements
Projects generally span one (lifecycle phase)[#lifecycle-phase] of a client project. These lifecycle phases are outlined to clarify their difference from the distinct project phases within the performance of a project undertaken by GTE.
GTE projects are generally structured from a work breakdown perspective in accordance with typical phases of execution that include design, development, and testing. However, the recognition that there are overlapping and enveloping bodies of project management work – or "process groups" – that occur alongside this direct delivery effort leads to what GTE terms delivery elements.
Within the delivery elements that can be considered "indirect" to the technical delivery – or execution – of the work, project management processes such as cost and schedule management must occur. GTE aligns with PMBOK standards on these processes, and the overall GTE project management process is based around these.
Fundamentals
All projects, regardless of categorization, are managed for cost and schedule performance using Earned Value Management techniques.
Fundamental to the consistent management of projects at GTE is the use of standard tools and templates and the standard processes and procedures covered in this documentation. The GTE project management 'framework' essentially comprises:
- The Standard Project Management Plan [PMP],
- The PMPs constituent plans and underlying documents and procedures, and
- The activity and output expectations dictated by the Output Applicability Grid.
This documentation intends to assist in meeting the requirements of the framework by summarising and explaining standard requirements, elaborating on expectations of the Project Manager for these, and centralising resources and references.
Categorization#
Projects undertaken by GTE are categorised by:
These categorizations are initially determined even before the project is awarded, in the prospective (or potential) project phase. This initial assessment is completed by the Proposal Manager and helps inform the bid/decline decision.
Upon award of a project, the initial assessment must be revisited and confirmed or amended. The discipline categorization is unlikely to change, however the classification is subject to an additional factor – Cost Contingency – which may impact the project classification.
Lifeycycle Phase#
Category#
Projects undertaken by GTE are categorised by:
- Project - Lump Sum
- Project - Rates Based
- Audit
- Secondment
- On-Selling
- Internal
Discipline#
A project will generally involve one or more disciplines which will dictate some of the deliverables necessary for management of the project. The principal disciplines for projects undertaken by GTE are as follows:
- Electrical
- SMP
- Project
- Control
- Communications
- Drafting
- Functional Safety
It is important to categorize a project by discipline as it impacts the internal deliverables required, and multi-disciplinary projects typically involve a greater level of complexity that necessitates additional project management rigour.
Classification#
All projects fall into one of four classifications as defined in the table below. The classification is determined through an assessment of the project value and complexity.
| Classification | Description |
|---|---|
| Extreme | High to extremely high project value and high complexity. |
| High | Low project value and high complexity, or extremely high project value and low complexity. |
| Moderate | High to Low project value and medium to low complexity, or low project value and high complexity. |
| Low | Low project value and medium to low complexity. |
Specifically, the classification is determined using the matrix below with the value banding and complexity determinations made through reference to the sub-sections further below.
| Classification Matrix | Value Banding | |||||
Low
| Medium
| High
| Very High |
Extremely High |
| ||
Complexity Rating 5
| High (11) |
High (16) |
Extreme (20) |
Extreme (23) |
Extreme (25) |
|
4
| Moderate (7) |
High (12) |
High (17) |
Extreme (21) |
Extreme (24) |
| |
3
| Low (4) |
Moderate (8) |
High (13) |
Extreme (18) |
Extreme (22) |
| |
2
| Low (2) |
Low (5) |
Moderate (9) |
High (14) |
Extreme (19) |
| |
1
| Low (1) |
Low (3) |
Moderate (6) |
High (10) |
High (15) |
| |
Value Banding#
A project will fall into one of five value bandings – Low, Medium, High, Very High or Extremely High – as in the table below where the value banding is the total awarded project fee or sell price, exclusive of any contingency.
| Value | Banding |
|---|---|
| Low | < 50k |
| Medium | 50k - 300k |
| High | 300k - 700k |
| Very High | 700k - 1.5mil |
| Extremely High | > 1.5mil |
Complexity#
Project complexity is determined through consideration of the risks for each "Factor' listed in the table below.
| Factor | Weighting (Total 100%) | Banding | |
| Capability & Experience | 15 | Low (1) | High expertise/capability for the work |
| Medium (2) | Adequately experienced and capable | ||
| High (3) | Marginally capable or no relevant experience (and/or 3rd party support required) | ||
| Schedule & Resource Availability | 15 | Low (1) | Comfortable timeline and preferred resources available to achieve it |
| Medium (2) | Schedule achievable and resources available or obtainable to achieve it | ||
| High (3) | Unrealistic or unachievable schedule and/or desired resources not available | ||
| Commercial | 15 | Low (1) | Contract in place |
| Medium (2) | Vendor Number only | ||
| High (3) | No Commercial Agreement | ||
| Technical & Reputational | 15 | Low (1) | Problem and solution are understood, and the solution is easily achievable |
| Medium (2) | Problem is unclear, and solution is unclear or difficult to achieve. Reputational risk of failure is manageable | ||
| High (3) | Both problem and solution are difficult to define or understand, and solution is difficult to achieve. GTE’s reputation is at risk in the event of failure | ||
| Strategic | 15 | Low (1) | Directly relates to key strategic objectives or initiatives |
| Medium (2) | No definitive alignment to strategic objectives, but not contravening operational intent | ||
| High (3) | Misalignment with strategic objectives or operational intents | ||
| Cost Contingency | 25 | Low (1) | Greater than 15% |
| Medium (2) | 10 to 15% (inclusive) | ||
| High (3) | Less than 10% | ||
Once all risks and cost contingency are established, the weightings are used to calculate an overall score. The score is translated into a Complexity rating based on the following bands:
| Complexity Rating | Banding |
|---|---|
| 5 | 2.6 - 3.0 |
| 4 | 2.2 - 2.6 |
| 3 | 1.8 - 2.2 |
| 2 | 1.4 - 1.8 |
| 1 | 1 - 1.4 |
Systems#
Coming... Smartsheet, Avaza, M-Files, Sharepoint
Project Roles#
Coming...
- Project Manager
- Project Engineer
- Cost Controller
- Document Controller
- Resource Lead
- Technical Lead
- Engineer
- Designer
- Developer
- Tester
- Reviewer
- STA (Safety Technical Authority for Functional Safety Projects)
Lifecycle Phases#
GTE projects may span one or more phases in the lifecycle of an overall client project, depending on the requirements of the scope and/or the level of problem definition provided in the scope. GTE aligns with client naming for lifecycle phases, and such naming may include:
- Order of Magnitude or Identification
- Pre-Feasibility or Selection
- Feasibility or Definition
- Detailed Design
- Execution, including Testing, Commissioning & Ramp-Up
- Closeout
The project lifecycle phases are generally independent and sequential.
Depending on the specifics of a project, a lifecycle phase will generally be treated as an independent GTE project. As GTE will often be involved with multiple projects for the multiple lifecycle phases, all efforts to leverage project management work from any prior lifecycle phase (GTE project) should be made.
Note
GTE refers to "phases" such as design development, testing and site works. These phases are distinct from the project lifecycle phases here.
These lifecycle phases are outlined to clarify their difference from the distinct project phases within the performance of a project undertaken by GTE.