Skip to content

REQUESTS FOR TECHNICAL INFORMATION#

INTRODUCTION#

All queries to the client of a technical nature for projects undertaken by GTE, should be raised as either a TQ or an RFI using the Smartsheet form. This form generates an entry into the enterprise wide TQ/RFI Register providing a uniform approach that assists with tracking and management with benefits such as automated approval workflows and email follow ups.

TECHNICAL QUERIES#

TQs are contractual documents requiring formal contractual replies. The project manager must manage the client relationship such that it is accepted that TQs will be raised for any client response upon which GTE will rely technically. Queries made via other means such as email cannot necessarily be relied upon contractually in the event of a dispute and are not tracked and managed with the attention afforded by GTE’s Smartsheet process.

GTE can appear overly commercial if the client communication is not managed appropriately, and this has the potential to adversely affect the relationship with the client. The project manager should ensure that TQs are seen as presented as routine process and a necessary means for clarifying the scope and ensuring the client receives the product it expects, rather than a commercial coverage exercise. The TQ wording is important in this messaging.

All TQs must be signed as approved by an appropriate client representative under the contract.

Where dispensation or deviation from a specific scope stipulation or applicable standard is required, the TQ will expressly state that approval to deviate is sought.

REQUESTS FOR INFORMATION#

RFIs should be used to formally register requests for client input data which may include site survey data, existing software or settings files, vendor drawings forming a basis for design, etc. Whilst it is possible that simple email requests may suffice for such data in many instances, using the Smartsheet process again provides tracking and management at minimal additional burden, and is consequently highly recommended for all projects. Upon commencement of the execution delivery elements, the technical team should raise RFIs for all client input data set out in the original proposal.

As with TQs, the messaging is important around RFIs to ensure these are seen as a valuable part of GTE's project management process that will deliver a benefit for the client's project in the form of transparent communication of necessary inputs that assists the client in providing these in a timeline that supports the project schedule.

GLOSSARY#

Term Definition
Limbo counter A counter that counts the number of days since the RTI has last been actioned.
Limbo state An RTI reaches limbo state when it has not been actioned within a certain pre-defined period and thus it is not clear if it’s stalled or is not being actioned due to a user’s inactivity.
RFI Request for Information – simple request for a specific technical information
RTI Request for Technical Information – an umbrella term that includes both TQs and RFIs.
RTI re-trigger Manual or automatic repetition of the recent RTI action, i.e. re-sending of the most-recent Update/Approval request.
RTI Register A central Smartsheet register, containing all RTI items for all (active) projects with all detailed RTI information.
SME Subject Matter Expert, who can be engaged by a Client PM to help responding an RTI.
Stalled RTI An RTI that will not progress in the RTI workflow without user’s intervention. Such stalled state can be reached if the Update Request is not actioned properly. There is an automated mechanism which tries to move RTIs out of stalled state.
TQ Technical Query - includes a request for deviation from a standard or specification as well as can define an impact on the project (cost, schedule or other). With the TQ, GTE will provide a recommendation that the Client PM may either choose to approve or disapprove without the need for further details.

PROCESS OVERVIEW#

  • “RTI” or Request for Technical Information is GTE’s umbrella term for Technical Queries (TQs) and Requests for Information (RFIs). GTE uses a specialized system, as part of its Smartsheet project management solution, to process RTIs via a workflow and obtain client responses.
  • Anyone in the GTE project team can raise an RTI but all must be authorised by the GTE PM before they are issued to the client.
  • TQs are additionally reviewed by a technical approver before authorisation.
  • An RTI, issued by GTE, will be first sent to the Client PM.
  • Client PM has the option to either respond to GTE directly, or to delegate the RTI to an appropriate Subject Matter Expert (SME) to provide a technical response. Any SME’s response is first reviewed by a Client PM, who uses it as basis for compiling a final RTI response to be sent back to GTE.
  • TQs differ from RFIs in that they can include a request for deviation from a standard or specification as well as can define an impact on the project (cost, schedule or other). With the TQ, GTE will provide a recommendation that the Client PM may either choose to approve or disapprove without the need for further details.
  • GTE may request further information upon receipt and review of the client’s initial RTI response.

RTI IMPLEMENTATION#

  • RTI data and logic is built into a single smartsheet 1000_RTI_Register (“RTI Register” henceforth).
  • RTI Register contains all RTI’s for all active projects. It is recommended, that this sheet is not accessed directly, but rather through a set of reports which are available in the Project Workspace for that purpose.
  • Each RTI is identified by a unique ID, the format of which is: GTE-pppp-RTI-xxx [type], where:
    • pppp is Project ID
    • xxx is a per-project unique sequence number (starting from 001)
    • [type] – RTI type, either [TQ] or [FRI]
  • After an RTI is raised (via a web form), it progresses through individual steps in a complex workflow, during which it is first reviewed and approved internally, then submitted to the client to provide a response and then sent back to GTE for approval and closeout.
  • Each step in the workflow requires user action, which can be one of the following types:
    • Update Request – user receives an email providing information about the update request. This email contains a View Request button that must be clicked, which opens a web form. In this form, there is a set of editable fields and the Submit Update button. The user updates the fields and then clicks the Submit Update button to submit the entered information and progress RTI to the next step. There is always one field (in most cases a dropdown menu) which MUST be changed so that the RTI progresses to the next step. If this field is not changed and Submit Update is clicked, the RTI gets stalled (see RTI In Stalled/Limbo State section).
    • Approval Request – user receives an email providing information about the approval request. This email contains a View Request button that must be clicked, which opens a web form, containing buttons for approval and rejection – one of these must be clicked, after which the RTI progresses to the next step.
  • There is an option to enable a user to indicate during the initiation of a new RTI that the RTI will be issued in a PDF form, in which case the internal RTI approval process remains unchanged, but the workflow does not send email notifications to the client – it is assumed that this is done manually by a GTE PM.
  • RTI is automatically transferred into PDF and attached to the respective RTI row. This is done at two points:
    • If the "PDF Verion Used" has been selected during the RTI creation, then PDF version is created after it is authorized by GTE PM.
    • After the RTI is closed
  • In the workflow automation engine, there is a set of tools that help with progressing each item in case it is stalled for any reason:
    • Manual re-trigger – a current workflow state is re-initiated and associated Update/Approval Requests are re-sent.
    • Manual trigger – an RTI item can be manually moved to any point in the RTI workflow. It is highly recommended that this function is done by Project Services only.
  • After project closeout, all project-related RTI’s from the RTI Register are archived into an Excel spreadsheet as a part of overall project workspace backup. In addition, all the RTI’s are also exported into PDF files (one PDF file per RTI) and stored in the archived copy of the Project Folder. See RTI Archiving section for further details.

Using Legacy Word RTI Template

In cases, when space and formatting constrains do not allow to use Smartsheet form for raising an RTI, it is possible to use a legacy Word template. In this instance, it is still necessary to raise an RTI via the automated RTI system so that it is added to the project RTI register, and use the auto-generated RTI number when filling in a Word RTI template. For more details see this section.

TQ WORKFLOW#

The RTI workflow for a Technical Query is outlined in the following picture:

TQ Workflow Steps Overview#

  1. Raising a TQ. This is done from the GTE Intranet menu Smartsheet Forms, New TQ / RFI Request Form (see this section for more details). One of the information fields that has to be filled in is a GTE Recommendation – this will be reviewed by the client and either approved or rejected. Once the information on the form is filled in and the Submit button is clicked, the new TQ is added to the RTI Register and the Approval Request is sent to a Technical Approver (as specified in the TQ / RFI Request Form).
  2. TQ Technical Review and Approval – Technical Approver reviews the TQ and then selects one of the following actions:
    1. Approve TQ – Approval Request is sent to a GTE PM to review and authorize the TQ.
    2. Reject TQ– Technical Approver receives an Update Request, requiring selection of one of the following actions:
      1. Cancel TQ - TQ is cancelled, no further workflow steps will be actioned.
      2. Request TQ Revision – TQ is sent back to its originator (in the form of Update Request) for amendments to be done (requested amendment details should be entered by Technical Approver in the form of a commentary).
      3. Approve TQ – TQ is sent to GTE PM for review and authorization.
  3. TQ Authorization – GTE PM reviews the TQ and then selects one of the following actions:
    1. Authorize TQ – TQ is sent via an Update Request to the Client PM.

    Note

    If the PDF Version Used checkbox has been ticked during the creation of the TQ, it is not sent to the client since it is expected to be sent manually in the PDF format. In this case, the PDF version is generated automatically and attached to the TQ row. Also, GTE PM receives an Update Request email, that requires the PDF Version Closed checkbox to be ticked once the client has responded to the TQ, which initiates the client’s response review and TQ closeout.

    1. Reject TQ – A GTE PM receives an Update Request, requiring selection of one of the following actions:
      1. Cancel TQ - TQ is cancelled, no further workflow steps will be actioned.
      2. Request TQ Approval – TQ is sent to the Technical Approver for review and approval (step 2 above).
      3. Request TQ Revision – TQ is sent back to its originator (in the form of Update Request) for amendments to be done (requested amendment details should be entered by GTE PM in the form of a commentary).
      4. Approve TQ – TQ is sent to the Client PM to review and respond to the TQ.
  4. TQ Responding – Client PM reviews the TQ and in response selects one of the following actions:
    1. Approved As Recommended – GTE’s recommendation is approved and the TQ is sent back to the GTE PM (as an Approval Request) for response review and TQ closeout. The client can add commentary text to the TQ before the approval is submitted.
    2. Not Approved As Recommended – GTE’s recommendation is not approved and the TQ is sent back to the GTE PM (as an Approval Request) for a response review and TQ closeout. The client can add commentary text to the TQ before the approval is submitted.
    3. Delegate to SME – an Update Request email is sent to a Subject Matter Expert requiring assistance with collating a response to the TQ.
  5. Reviewing TQ Response – GTE PM reviews the client’s response to the TQ (i.e. approval or non-approval of GTE’s recommendation) and selects one of the following actions:
    1. Accept Response – the client’s response is forwarded to the TQ originator and the TQ is closed (no further workflow steps will be actioned).
    2. Reject Response – GTE PM receives an Update Request, requiring specification of the amendments that are required in the TQ response. The TQ (with the required amendments specification) is then sent back to the Client PM in the form of an Update Request.
  6. TQ Response Amendments – Client PM reviews the required response amendments and selects one of the following actions:
    1. Approved As Recommended – GTE’s recommendation is approved and TQ is sent back to the GTE PM (as an Approval Request) for response review and TQ closeout. client can add commentary text to the TQ before the approval is submitted.
    2. Not Approved As Recommended – GTE’s recommendation is not approved and TQ is sent back to the GTE PM (as an Approval Request) for response review and TQ closeout. client can add commentary text to the TQ before the approval is submitted.
    3. Delegate to SME – an Update Request email is sent to a Subject Matter Expert requiring assistance with collating the response to the TQ.

    Note

    The TQ can be sent back to the client as many times as required before the final response is accepted and the TQ is closed.

  7. SME’s Actioning – SME reviews the TQ and instructions given by the Client PM (or previous SME), followed by collation of the Technical Response and selection of one of the following actions:
    1. Delegate TQ to Another SME – the TQ is forwarded to another SME (as specified by the current SME).
    2. Submit Technical Response – SME collates a technical response and the TQ is sent back (as an Update Request) to the Client’s PM.
  8. Client PM’s Review of SME’s Response – Client PM reviews SME’s technical response and uses it as a basis for responding to the TQ. The selection of one of the following options is to be made:
    1. Approved As Recommended – GTE’s recommendation is approved and the TQ is sent back to the GTE PM (as an Approval Request) for response review and TQ closeout. The client can add commentary text to the TQ before the approval is submitted.
    2. Not Approved As Recommended – GTE’s recommendation is not approved and the TQ is sent back to the GTE PM (as an Approval Request) for response review and TQ closeout. client can add commentary text to the TQ before the approval is submitted.
    3. Delegate to SME – an Update Request email is again sent to a Subject Matter Expert requiring assistance with the collating response to the TQ.

    Note

    The TQ can be sent to SME(s) as many times as required before the final response is collated and the TQ is eventually sent to GTE.

RFI WORKFLOW#

The RTI workflow for Request for Information is outlined in the following picture:

RFI Workflow Steps Overview#

  1. Raising an RFI. This is done from the GTE Intranet menu Smartsheet Forms, New TQ / RFI Request Form (see this section for more details). Once the information on the form is filled in and the Submit button is clicked, the new RFI is added to the RTI Register and an Approval Request is sent to the GTE PM for RFI review and authorization.
  2. RFI Authorization – GTE PM reviews the RFI and then selects one of the following actions:
    1. Authorize RFI – RFI is sent via an Update Request to the Client PM.

    Note

    If the PDF Version Used checkbox has been ticked during the creation of the RFI, it is not sent to the client since it is expected to be sent manually in the PDF format. In this case, the PDF version is generated automatically and attached to the RFI row. Also, GTE PM receives an Update Request email, that requires the PDF Version Closed checkbox to be ticked once the client has responded to the RFI, which initiates the client’s response review and RFI closeout.

    1. Reject RFI – GTE PM receives an Update Request, requiring selection of one of the following actions:
      1. Cancel RFI - RFI is cancelled, no further workflow steps will be actioned.
      2. Request RFI Revision – RFI is sent back to its originator (in the form of Update Request) for amendments to be done (requested amendment details should be entered by GTE PM in the form of a commentary).
      3. Approve RFI – RFI is sent to Client PM to review and respond to the RFI.
  3. RFI Responding – Client PM reviews the RFI and in response selects one of the following actions:
    1. Submit Response – response to the RFI has to be collated first before this option is selected. RFI is then sent back to the GTE PM (as an Approval Request) for response review and RFI closeout.
    2. Delegate to SME – an Update Request email is sent to a Subject Matter Expert requiring assistance with collating a response to the RFI.
  4. Reviewing RFI Response – GTE PM reviews the client’s response to the RFI and selects one of the following actions:
    1. Accept Response – the client’s response is forwarded to the RFI originator and the RFI is closed (no further workflow steps will be actioned).
    2. Reject Response – GTE PM receives an Update Request, requiring specification of the amendments that are required in the RFI response. The RFI (with the required amendments specification) is then sent back to the Client PM in the form of an Update Request.
  5. RFI Response Amendments – Client PM reviews required response amendments and selects one of the following actions:
    1. Submit Response – response to the RFI has to be amended first before this option is selected. RFI is then sent back to the GTE PM (as an Approval Request) for amended response review and RFI closeout.
    2. Delegate to SME – an Update Request email is sent to a Subject Matter Expert requiring assistance with collating a response to the RFI.

    Note

    The RFI can be sent back to the client as many times as required before the final response is accepted and the RFI is closed.

  6. SME’s Actioning – SME reviews the RFI and instructions given by the Client PM (or previous SME), followed by collation of the Technical Response and selection of one of the following actions:
    1. Delegate RFI to Another SME – the RFI is forwarded to another SME (as specified by the current SME).
    2. Submit Technical Response – SME collates a technical response and the RFI is sent back (as an Update Request) to the Client’s PM.
  7. Client PM’s Review of SME’s Response – Client PM reviews SME’s technical response and uses it as a basis for responding to the RFI. The selection of one of the following options is to be made:
    1. Submit Response – response to the RFI is collated and RFI is sent back to the GTE PM (as an Approval Request) for response review and RFI closeout.
    2. Delegate to SME – an Update Request email is again sent to a Subject Matter Expert requiring assistance with collating a response to the RFI.

    Note

    The RFI can be sent to a SME(s) as many times as required before the final response is collated and the RFI is eventually sent to GTE.

SHARING PROJECT RTI REGISTER WITH CLIENT#

There is a project-specific report, contained in the 20 – Scope folder of the Smartsheet Project Workspace, called Pxxxx_RTI_Report-ClientPM which contains a list of all RTIs that are currently waiting for client’s action (either Client PM, or SME) and only includes columns that are relevant for the client.

The report CANNOT BE DIRECTLY SHARED with the client since the source sheet (RTI Register) is not accessible by the client. The correct way of providing access to the report is publishing it and sending a client a URL:

  1. Open the report.
  2. In the right navigation menu bar, select Publish icon:
  3. In the displayed window, turn the Read Only – Full switch ON.
  4. Change the radio button in the next displayed window to Available to anyone with the link.
  5. Copy the URL from the Publish Link text box to the clipboard.
  6. Send the copiede URL to the client via an email.

Sharing a report with the client via a published link ensures that client will not make any changes to the contained data and will not have access to any other information outside of the shared report.

Important

Never share RTI Register with the client – it contains information about other clients’ projects which must not be shared elsewhere.

RTI IN STALLED/LIMBO STATE#

When the Update Request is sent to a user, it must be properly actioned so that an RTI is moved to the next workflow step. “Properly actioned” here means, that the value in the specific (“key”) field in the Update Request web form is changed. Each Update Request has such a “key” field, which must change its value so that the RTI is moved to the next workflow step. In most cases this “key” field is a dropdown menu, which is initially set to ---Select Action--- and which must be changed to one of the provided values before the Update Request response is submitted. There is only one case – GTE PM requesting client for RTI response amendments – when the “key” field is a text field (Amendments Required) and it’s contents must be edited before the Submit Update button on an Update Request web formed is clicked.

If however the “key” field is not changed and the Update Request response is submitted, the RTI becomes “stalled” i.e. it will not progress further to the next step in the automation workflow. To overcome this issue, there is a built-in mechanism which will detect stalled RTI’s and will attempt moving them to the next workflow step. This mechanism works as follows:

  1. Whenever an Update/Approval Request is sent to a user, the current date is saved in the RTI Register.
  2. There is a counter (called "Limbo Counter") which is increased every day, monitoring the number of elapsed days since the Update/Approval Request has been sent.
  3. If the Limbo Counter reaches a certain predefined value (see Maximum Days in Potential Limbo parameter description), it is assumed that the RTI is either stalled, or has not yet been actioned by the user. At this stage, one of the following will happen:
    1. Update/Approval Request is re-sent to the user (via a Reminder email).
    2. Email notification is sent to a GTE PM, requesting a follow-up action. The GTE PM can find out the reason for delay and can re-send the request manually (see Re-trigger RTI At Current State).
  4. After re-sending the RTI Update/Approval Request, the Limbo Counter is reset and the stalled RTI detection process starts again.

When the above mentioned Limbo Counter reaches the limit, it can be either caused by wrong actioning and the RTI being stalled, or by the user’s delay in the RTI response. For this reason, such an RTI is called to be “in limbo”. There are three possible types of “limbo” state, each of which is processed differently:

  1. Same person limbo state - Update Request, which was sent to the same used immediately after the Approval Request has been actioned. It is expected that this will be actioned immediately (within the same day) and if not, most likely the RTI is stalled. A specific time limit can be set for this type of limbo, with the default value being 1 day (see Maximum Days in Potential Limbo parameter description).
  2. Other person limbo state - Update Request, which was sent to another user. If it has not been actioned after a pre-set period of time, it can either be stalled or user has not yet actioned the Update Request. A specific time limit can be set for this type of limbo, with the default value being 5 days (see Maximum Days in Potential Limbo parameter description).
  3. Approval limbo state – Approval Request, which has not been actioned within a pre-set time. Since Approval Requests do not get to the stalled state, the reason for this type of limbo state is solely the user’s delay in actioning. A specific time limit can be set for this type of limbo, with the default value being 5 days (see Maximum Days in Potential Limbo parameter description).

The “limbo” state processing is configurable and the following logic is used:

  1. For each of the above three “limbo” types there is a per-project configuration checkbox (Retrigger Potential Limbo) that can be ticked or unticked (see Retrigger Potential Limbo parameter description):
    1. If ticked, the RTI will be retriggered once the limbo state is reached. The exception to this is when the client is actioning the RTI and the Required Response Date has not been yet reached (in this case, the RTI is handled as if the checkbox was unticked – see the following item).
    2. If unticked, the RTI will not be retriggered, but a notification email will be sent to whoever is set up as receiver of Limbo Notification Emails (see Issue Limbo Notification Emails To parameter description).
  2. After the RTI limbo state is actioned (re-triggered, or notification email sent) the limbo state counter is reset and the process of stalled RTI’s monitoring starts again.

The above-mentioned logic has been built to make sure that none of the RTI’s will be not actioned/lost in an unknown state.

In addition to the above, there are a few fields in the RTI Register that can be used to monitor the current status and move it to any arbitrary point in the overall workflow:

Workflow Log – indicates the current state the RTI is in (refers to state numbers in the RTI Workflow Diagram).

Person Actioning – indicates a contact name that is currently actioning the RTI and in case it is needed it can be contacted and asked to make the action.

Manual Trigger – a dropdown menu that enables selection of any specific step to which the RTI will be moved after the selection is saved (by saving a sheet or report). This action has to be done with caution and Project Services assistance is recommended. A danger is, that the RTI is inadvertently retriggered to a different type of related step (i.e. TQ is moved to RFI state and vice-versa) and that can cause further issues. As a part of this action, limbo-state counters will be reset automatically.

Manual Resend Trigger – a checkbox that will re-trigger a current workflow step. This can be used in many scenarios, mostly in cases when the original Update/Approval Request email has been lost or wrongly actioned. After the Manual Resend Trigger is checked and sheet/report is saved, the Update/Approval request associated with the current state (as indicated by the Workflow Log field) will be resent.

RTI OVERDUE MONITORING#

Two checks are done to monitor the RTI overdue state:

Response Required by Date#

A required value that must be entered during the RTI creation in the RTI setup web form. If the client’s response for the RTI is not received by this date, the RTI is marked as Overdue which will be indicated by red text/orange background in the RTI Register/Report. A notification email is sent to a GTE PM. The indication of an overdue RTI will disappear after the RTI is responded to by the client.

Maximum Response Date#

This is a configurable per-project value and serves as an indication that the client’s RTI response period, that has been contractually agreed to, has been exceeded and some action may be required (informing client of contractual consequences e.g. overall project delay or cost increase). When the RTI is not responded to by the set date, the RTI row is changed to bold red text/red background and a notification email is sent to the GTE PM. The indication of this state being reached will not disappear after the RTI is responded by the client. The default setting for this value is intentionally high (500 days) which renders the monitoring of non-responded RTI’s not functional. However, this value can be set should this functionality be required for a specific project (see Agreed Maximum Response Date parameter description).

RTI PROCESS CONFIGURATION#

The RTI process can be configured on a per-project basis via a dedicated sheet – 1000_RTI_Parameters (RTI Parameters henceforth). The sheet is stored in the same location as the RTI Register. Once any of the parameters is changed and the sheet is saved, the change is immediately applied to the process. The following parameters can be configured:

GTE PM#

By default, a contact set in the Project Register as a GTE PM is used automatically in the RTI process. If this needs to be changed for any particular project, it can be edited in the GTE PM column of the RTI Parameters sheet.

Client PM#

By default, a contact set in the Project Register as a Client PM is used automatically in the RTI process. If this needs to be changed for any particular project, it can be edited in the Client PM column of the RTI Parameters sheet.

Issue Limbo Notification Emails To#

Contains contact details of a person who will receive notification emails once any of the RTIs reaches a limbo state. By default, this is set to the project GTE PM, however it can be changed to any other value if required.

Maximum Days in Potential Limbo (Same/Other Person/Approval)#

Pre-defined value of the limbo counter. Once the RTI is not actioned (responded) by the time this period is expired, the automated action is taken (re-trigger or email notification – depending on the Retrigger Potential Limbo checkbox – see next item). The default values are 1 day for the same person and 5 days for both the other person and the approval limbo state.

Retrigger Potential Limbo (Same/Other Person/Approval)#

Controls the action taken when the RTI reaches a limbo state (retrigger the current state, or send a notification email). By default these checkboxes are ticked, i.e. RTIs will be re-triggered once the limbo state is reached.

Agreed Maximum Response Date#

Defines the time period for the RTI to be responded to before it reaches a non-responded state (see Maximum Response Date section). By default this is set to 500 days, rendering the monitoring of non-responded RTIs intentionally as non-functional.

Workflow Automation#

Enables or disables the workflow automation for a specific project. It should only be used for by the Project Services team for service/maintenance purposes.

RTI ARCHIVING#

Upon a project completion, as a part of the project closeout process, all project-related RTI items are archived as follows:

  1. Each RTI item is exported into a PDF and then stored in the SharePoint project folder under the 10_TQsRFIs subfolder. This is then archived together with the rest of the Project Folder following the overall project SharePoint folders archiving procedure and if required, can be accessed at a later stage.

  2. As part of an overall Project Workspace archiving procedure, each RTI reports (with all underlying data) is exported into an Excel spreadsheet before the Project Workspace is eventually deleted from Smartsheet. These Excel archives are then saved (together with the rest of the Project Workspace archive) in the root of the SharePoint Commercial folder which is then archived following the overall project SharePoint folders archiving procedure and if required, can be accessed at a later stage.

HOW TO…#

Raise a New RTI (automated version)#

  1. Open the GTE Intranet main page.
  2. Under Smartsheet Forms menu, select New TQ / RFI Request Form item.
  3. A TQ/RFI web form opens on which the following must be filled in:, as a minimum, all required fields must be filled in.
    1. Project ID (enter four digits only, without any prefix)
    2. Select type of request (TQ or RFI) - after selecting the RTI type, "use Automated RTI System" checkbox appears on the form
    3. Enter the RTI Subject/Title (short description of the RTI)
    4. Tick the "Use Automated RTI System" checkbox - more fields fileds will be added to the form, depending on the RTI type
    5. Fill in all the required fields
  4. Click a Submit button. A new RTI item is created in the RTI Register.

Raise a New RTI (Word template version)#

  1. Open the GTE Intranet main page.
  2. Under Smartsheet Forms menu, select New TQ / RFI Request Form item.
  3. A TQ/RFI web form opens on which the following must be filled in:, as a minimum, all required fields must be filled in.
    1. Project ID (enter four digits only, without any prefix)
    2. Select type of request (TQ or RFI) - after selecting the RTI type, "use Automated RTI System" checkbox appears on the form
    3. Enter the RTI Subject/Title (short description of the RTI)
    4. Leave the "Use Automated RTI System" checkbox unticked
  4. Click a Submit button. A new RTI item is created in the RTI Register. A notification email will be sent to the RTI originator, containing a number of the newly created RTI.
  5. Wait for the notification email to be received and copy the RTI number contained in the email into clipboard.
  6. Alternatively, open a Pxxxx_RTI_Report-GTE_ProjectTeam report (located in Smartsheet Project Workspace 20 - Scope subfolder) and in that report, lookup the newly created RTI and copy RTI number ('RTI #' column) into clipboard.
  7. Open RTI Word template (GTE-1002-TQU-001 or GTE-1002-RFI-001 respectively) and paste RTI number into it.
  8. Fill in all necessary RTI details, then use the final RTI form (preferrably in pdf version) for sending it to the client and solociting the response.

Force Close an RTI#

An RTI can be closed irrespective of its current state:

  1. Open a Pxxxx_RTI_Report-GTE_ProjectTeam report (located in Smartsheet Project Workspace 20 - Scope subfolder).
  2. In Manual Trigger column, in the row corresponding to the RTI item to be closed, select a [6.1] RTI Closed item.
  3. Save the report.
  4. The RTI moves into a closed state.

Note

By forced closing of an RTI item, no notification emails are sent as they would be if the item was closed in the proper way following a normal workflow.

Force Cancel an RTI#

An RTI can be cancelled irrespective of its current state:

  1. Open a Pxxxx_RTI_Report-GTE_ProjectTeam report (located in Smartsheet Project Workspace 20 - Scope subfolder).
  2. In Manual Trigger column, in the row corresponding to the RTI item to be closed, select a [1.4, 2.4, 3.4] RTI Cancelled item.
  3. Save the report.
  4. The RTI is cancelled and moves into a closed state.

Note

By forced cancellation of an RTI item, notification emails are still sent as they would be if the item was cancelled a proper way following a normal workflow.

Re-trigger RTI at current state#

  1. Open a Pxxxx_RTI_Report-GTE_ProjectTeam report (located in Smartsheet Project Workspace 20 - Scope subfolder).
  2. In the row corresponding to the RTI item to be re-triggered, tick the Manual Resend Trigger column checkbox.
  3. Save the report.
  4. The current state of an RTI is re-triggered and that includes re-sending update/approval request or/and any other notification emails related to the current RTI state.

Move RTI to a different state#

  1. Open a Pxxxx_RTI_Report-GTE_ProjectTeam report (located in Smartsheet Project Workspace 20 - Scope subfolder).
  2. In Manual Trigger column, in the row corresponding to the RTI item to be handled, select an item, corresponding to the state, to which the RTI is to be moved.
  3. Save the report.
  4. The corresponding RTI workflow step is triggered.

Important

This is generally a safe operation, however care must be taken that the state to which an RTI is moved to corresponds to its type. That is, the TQ should only be moved to TQ-related states (indicated by ‘T’ in the state number, e.g. 1.0T, 3.1T, 6.2T etc) and RFI to RFI-related states (indicated by ‘R’ in the state number, e.g. 1.0R, 3.1R, 6.2R etc). See “Change the RTI type” below for further information.

Note

It is recommended that manually moving RTI’s to different state is done by Project Services.

Simulate That Client Has Responded RTI#

It is possible to simulate that the client has responded to an RTI, however this operation should only be done by Project Services – please raise a request and in it specify all the necessary details.

Nominate Different Client’s Representative#

It is possible to specify a different client’s representative (other than a default Client’s PM), however this operation should only be done by Project Services – please raise a request and in it specify all the necessary details.

Change the RTI type#

It is possible to change an RTI type (TQ <-> RFI), however this operation should only be done by Project Services – please raise a request and in it specify all the necessary details.