Dear All, Please find below the action items and notes captured during the small team call on Tuesday, 3 September at 13:00 UTC. Staff has posted to the wiki space the action items and notes. Please note that these are high-level notes and are not meant as a substitute for the recording and chat room records, which are posted on the wiki at: https://community.icann.org/x/eY-kBg Best Regards, Ariel Ariel Xinyue Liang GNSO Policy Support Specialist Internet Corporation for Assigned Names and Numbers (ICANN) == ACTION ITEM * Staff to re-share the documents related to #12 on the list and SLACK channel, and ask specific questions to solicit input from the Small Team. NOTES #12 Notification to Council of changes in work plan * The objective of this improvement is to increase accountability of working groups and enhance the Council oversight * One component is the physical notification to the GNSO Council in terms of the change of workplan, especially regarding the delivery date. Secondary component is about communicating the change and a procedure related to it. * Work for improvements #11 & #16 also have a chance to satisfy #12. * The escalation procedure developed for #11 may satisfy the procedure related to submitting the project change request form. We have plenty of existing, real use cases to help folks understand how the procedure works. Almost every active PDP working group and non-policy working group have missed their expected deliverable dates which were set on Day 1. Some of them missed deliverable dates several times. There should be a recognition that missing delivery dates would likely be unavoidable. * The PDP change communications form may be too formal, so need more guidance from the Small Team on how to satisfy the requirement. * The project change request procedure is flexible and can be less regimented. This is a transaction-based procedure. One transaction applies to one specific project in one specific time. This procedure needs to be performed on a monthly basis at a minimum. * When the codes of a project change, it is a fair indication something went wrong. There should be some kind of response and reaction to the change. If everything is green, then there is no issue to resolve. If the project has yellow or red condition, the WG needs to think of what should be done to get out of it, and how it got into an at-risk condition to begin with. * The escalation process diagram is split into two. Left side is all about status, and right side is all about condition. Condition carries more weight, as it includes assessment tasks that may lead to the decision of terminating a project. Status is related to scheduling of a project. Condition is an indication of the overall health of a project. Too many schedule changes may trigger the change of the condition. For example, CCWG Auction Proceeds (1,300 days alive) has revised schedule (status code) several times, so the condition is labeled “at risk”. However, some changes that cannot be reflected by schedule, such as a filing of 3.7, can drastically affect the condition of a project. * The WG leadership and Council liaison also need to be participating in the assessment of the conditions, not just staff. When assessing the condition of a project, it immediately becomes an emotional subject. We need to have more predictability and structure, and truly identify who is doing what, by what role, when they are doing it. * With the help of the escalation procedure, project list, and project change request procedure, the Council hopefully can be in a better position and have adequate attention to rectify it when a project switches from on target to at risk. The Council leadership may choose which At Risk projects should be discussed at the next meeting. Perhaps invite leadership to present to Council on what they will be doing to return the project to “on target” condition? * There is a need for a WG to developing a pipeline for what is in front of us for the next 3-4 months and a year. The goal is to understand everything the WG has been working on and whether the WG has the bandwidth to handle what they are working on. * Need to better quantify the activities in the Council action item list. Those action items can lead to more formal work, e.g., Issue Report, Sub Team producing comments for the Council, Drafting Team. While the Council action items are not the ultimate scope here, they are useful to be part of the project work. We have not been able to track the action items or create a report from the list. Staff haven’t met to discuss the next steps regarding the Council action item list tracking. In the EPDP Team, there is a google form of action items, so a report can be developed based on it. Put in flight Council actions onto a Google sheet may be the next steps. * The Project List has been converted into a Google Doc to facilitate simultaneous updates by staff. The numbers on the bar chart in the project list are the numbers of tasks / action items related to each project. * ACTION ITEM: Staff to re-share the documents related to #12 on the list and SLACK channel, and ask specific questions to solicit input from the Small Team.