Kickoff and Workshop Sample Clauses
Kickoff and Workshop. Prior to kicking off the project, SSP will internally meet to review the goals, roles, risk items and plans for the project. This shall ensure all SSP project personnel have a clear understanding of the plan ahead of work beginning. Next, the SSP Senior Consultant and PM will remotely host a project kickoff meeting with DME. This meeting will consist of a review of the project goals, roles, personnel and schedule. Time will be allowed for questions and answers. IT team members from DME and technical representatives from Trilliant are required to attend and participate. Upon the Kickoff Meeting’s conclusion, SSP will conduct remote workshops with DME Rx administrators, Trilliant, and the CIS department to determine the exact approach for integrating the systems. The integrations will all be based on a services oriented architecture (SOA) approach utilizing web services. ▇▇▇▇▇▇▇▇▇ will be responsible for designing the AMI side of the integration and the CIS department will be responsible for designing the CIS side of the integration.
Kickoff and Workshop. Prior to kicking off the project, SSP will internally meet to review the goals, roles, risk items and plans for the project. This shall ensure all SSP project personnel have a clear understanding of the plan ahead of work beginning. Next, the SSP Senior Consultant and PM will remotely host a project kickoff meeting with DME. This meeting will consist of a review of the project goals, roles, personnel and schedule. Time will be allowed for questions and answers. IT team members from DME and technical representatives from Clevest are required to attend and participate. Upon the Kickoff Meeting’s conclusion, SSP will lead a review of the touch points between the two products, where in the workflow they will be used, and what they will do. The four integration touch points are described below, as understood at the creation of this SOW: - GetOutageReasonCodes is called in an on-demand fashion by an administrator as needed. The goal of this is to pull all of the legal outage cause codes from the OMS so that Clevest can present those codes to field workers for selection and then ultimately the code(s) selected by the field worker for an individual outage are sent back to the OMS when restoration occurs. This method is generally called once during the initial setup and then again if the list of valid cause codes is ever updated in the OMS. DME has requested that the outage reason codes will not be the full set that is available in the Responder system, and will be configured for this integration touch point on the Responder side of the interface. - GetAllActiveOutageEvents is called on a configurable polling interval. This is generally set somewhere around every 1 to 15 minutes with the utility being able to balance system performance against how quickly new information moves from the OMS to Clevest. This call will effectively create new outages in Clevest and update existing outages in Clevest with the latest information from the OMS. - UpdateOutageStatus is called multiple times per outage as the assigned crew(s) work the outage. Most of these updates are related to crew status (Acknowledged, Onsite, etc). At this time, DME has requested to Clevest that the ETOR will not be passed in from the field for the outage, though this data may be passed in the future. - RestoreOutage is called once per outage at the time the field worker concludes their work and believes the faulting device has been repaired or replaced. Additionally, comments will be entered by the fiel...