Dear All, Please find below the action items and notes captured during the small team call on Tuesday, 30 July at 13:00 UTC. Staff has post 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/17CjBg Best Regards, Ariel Ariel Xinyue Liang GNSO Policy Support Specialist Internet Corporation for Assigned Names and Numbers (ICANN) == ACTION ITEMS: - Small Team to review/digest the status & condition escalation procedure (related to Improvement #11) and see how it can be used in reality, what changes need to be made, if any. - Staff to upload the status & condition escalation procedure into a Google Doc to facilitate input/comment from the Small Team. - Small Team to discuss the challenge mechanism for PDP leadership (Improvement #13, slide no.8) during the next PDP 3.0 call. NOTES: 1. Welcome & Roll Call 2. #11 Enforce deadlines and ensure bite size pieces (project list and status/condition) - Presentation of the GNSO Project Status and Condition Framework - Predominant feature of the next generation project list is the status and condition (code) of a particular project. - Escalation procedure, its components rely on other projects. Workplan, action items, etc. have informed the status and condition of a project. - The final deliverable of this effort needs to be discussed (e.g. GNSO operating procedure imports this procedure?). - Those items need to be updated on a monthly basis, and the escalation points may need to be updated more frequently. It will help to have the summary timeline, workplan, and situation report. Have a basket of tools and the PDP leadership decide which tools would be more helpful. - Summary timeline should be available for the entire community, published on the wiki. - Project situation report: staff will update the content of this report. - Project plan: Gantt chart based, being tried for EPDP Phase 2. It has more detailed inventory for the tasks, each task has set duration and dependency. Strictly for PDP leadership and staff. - Work plan: a sub section of the project plan. Scope of the work plan should not extend beyond 2-4 weeks of what the WG is going to work on. - Action items: care should be taken on how they are going to be assigned out and completed. Since they are unplanned event, need to make sure they are not consuming the overall work of the WG and minimize the impact on the work plan. - Fact sheet: overall communications tool. For groups that have dedicated funding, they track the overall budget, currently done in the spreadsheet form. The other feature is that it allows the total number of hours consumed based on the number of calls, number of people attending the calls, number of FTE (staff) assigned to the project. Fact sheet is being built into the CRM, so in the near future, the CRM will be able to leverage things in the fact sheet. - Project change request (PCR) form: Related to improvement #12 – this group hasn’t discussed it yet but it is put in the parking lot. This product will complement the escalation procedure. It helps document what happened in a project and changes. - Page 4 (Project Status and Condition Escalation Procedure): first part tries to provide context/definitions/status, which are reserved around the scheduling of a project. Missing a target date is the primary offender of budget/timeline. Conditions vary and not are influenced by the status/context of a project. If behind schedule, it may affect the condition of a project but not always affect the condition of a project. - When a project becomes at risk or is in trouble, the GNSO Council needs to intervene and helps correct the condition proactively. When you step through the conditions, activities bring in leadership focus. - Ask for Staff (Berry): is it possible to change black color of planned to some other color (usually black is for dead items)? - Process diagram, initially wanted to use the swim lane diagram (top/down, left/right), but it became messy. Better with the process flow diagram. - In page and off page references: labels are corresponding to each other. It should be a 3D exercise on a 2D flow chart. “Out” means dropping out of the process flow. - The review of work plan and project plan should happen on the monthly basis to make sure the PDP is still on schedule. Any project that might be behind schedule should receive more attention from the GNSO Council. - There may be a situation that both status and condition need a change. The condition of a project carries more weight than the status of a project. Left side reserved for status, right side reserved for condition. Condition coding depends on the review by the PDP leadership/staff. - When the status is in the yellow condition, the flow won’t change much, but need to adjust the dials of the process. Need to make a determination on whether it makes sense to have the increase attention as the GNSO Council will get involved immediately. Need to start work on the mitigation plan. Need to update to the status to on schedule if the risks have been mitigated. If the mitigation does not correct the issue, does it warrant a further downgrade of the condition? Do we need to adjust the dials here? Not necessarily. - When the status is in the red condition -- when a project is on hold, need to understand whether it warrants a condition downgrade. - Condition carries heavier weight. Any time when the condition is changing, there should be an automatic notification to the Council leadership. In the communication, there should be some mitigation strategy that should be implemented. The condition can be downgraded/upgraded based on the implementation of the mitigation strategy. WG leadership, liaison, Council leadership, and even the full Council need to be involved when the condition is red. The most extreme case, the Council may determine to terminate the project. - Comment from Maxim: The procedural tree should have no loops like we see with points B. it should be a tree structure , or we are doing something wrong. The creation of the cycles is not needed. Do not recommend using the algorithm. Only need one procedure to understand how the situation changes, and the Council deliberates on what to do next. - The more formalized, the better it would be. It is not over-engineered. Project management, and change requests, are a complicated process. Let’s take some time to digest and figure out how it can benefit the PDP management process.
 - Draft summary project list: color codes themselves are not enough, they all need explanation on why the conditions are the way they are. Extra attention needs to put on those. - After Council deliberations, when the project is at the board vote level of the process, the Council is not directly involved. When a project is on hold, what does it mean if the Council needs to get involved? What are the things the Council can do to get them rectified. - We’ll have to put it into practice to know for sure, but this new view gives the Council a far better view of what’s going on, where we may need to engage, where delays are occurring, etc. - ACTION ITEM: Small Team to review/digest the status & condition escalation procedure (related to Improvement #11) and see how it can be used in reality, what changes need to be made, if any. - ACTION ITEM: Staff to upload the status & condition escalation procedure into a Google Doc to facilitate input/comment from the Small Team. 3. AOB - ACTION ITEM: Small Team to discuss the challenge mechanism for PDP leadership (Improvement #13, slide no.8) during the next PDP 3.0 call.