2019-09-17 PDP3.0

Notes/ Action Items

ACTION ITEMS

• Staff to send the Final Call message for Improvements #11, #12 & #16 documents. Final Call: 20 Sep; Interim Finalization Target Date: 25 Sep.
• Staff to remind the Small Team to review the proposal for public comment response and GNSO community consultation.

NOTES

1. Welcome and roll call

2. Package 2 Improvements

#16

• The catalog of work products is about deploying consistent status/work products to ensure consistency in messaging. It helps feed into the management of the projects.
• It is an inventory of work products that the Small Team has seen before. It provides what the product is. Who owns a particular work product. How often it should be updated. What the primary audience is. A real-life example from EPDP Phase 2 has been included. It is a working example of using all the work products enumerated in the catalog.
• Not every project is a PDP, but we have a number of groups that mimic the procedures of PDP WG.
• The situation report should be used frequently by the group for any communications need. It consolidates different types of status reporting. Status and condition code.
• Live use cases/examples: Work plan now has built-in dependencies and critical paths; action items are migrated to a spreadsheet from the wiki. Both work plans and action items are kept short and tactical.
• Although some of the work products look scary, the expectation is that staff will do the heavy lifting for developing/completing these work products. It is a shared package, so the WG leadership needs to be familiar with them, so should the Council liaisons.
• Not all work products need to necessarily deploy to all WGs. There is a proposed deployment schedule.
• Some WGs already use similar work products but they do not have consistent look and feel. It is up to the leadership for the inflight groups regarding when/how they are going to use the proposed work products.

#11

• Project List: the updated version has already been rolled out to the Council.
• Status and condition change procedure: When you get to the nuts and bolts about it, it is really not that complicated.
• The ultimate goal for the procedure is for the leadership to manage various groups and be responsible for the PDP. Introduce discipline and predictability during the decision making process when the Council needs to get involved.  
• If we properly scope, resource, and have obtainable delivery date, we will never get into the procedure.
• The left side is strictly for the status portion and all about schedule updates, using the keys in the legend. The right side is about condition change other than schedule (e.g., filing of 3.7). Condition carries much more weight than status, and it is more troubling. One should address the condition component of the procedure first, and then evaluate whether the status (timeline) needs to be adjusted. When getting into the condition area of the procedure, whether terminating the project is also on the table.
• The middle part directs the leadership/staff to consider whether condition or status needs to be modified. There may be a situation that both condition and status need change.
• It is a transactional procedure. If a project is on hold, the procedure will look like an endless loop (from the top). Mainly use this procedure when a project has entered the troubled land.
• It is a procedure to help the Council make decisions in a consistent way. The flowchart is being processed by human and we can figure out how to use it. We need to give it a try and see whether it can work. What being proposed is not written in stone and we can course correct.
• There is seriousness to enhance the project management discipline. When emotion runs high, without the discipline, the emotion will go unchecked. It is a big deal when schedule changes due to resources spent among the community and staff.
• Use CCWG-Auction Proceeds as a real-time example. It is similar to RPMs. It has hit the fourth-year mark and has shifted schedule 3-4 times. Timelines for that effort were more set as a target to encourage progress than realistic timelines.
• End the flowchart with the “Finish” tabs (and in case of hold projects, it should remain on hold). One arrow to finish, another arrow to lift hold and proceed further. Add some kind of 'finish' when it is decided that a project is put on hold so it doesn't go into an endless loop. There may be some kind of trigger by which it would go into the process again? Perhaps two more elements branching from there. One that says "project remains on hold”, and one that says "project comes off hold". 

• Staff will be mainly responsible to assign the status and condition codes. More importantly, what the Council is going to do when reviewing the project list? If the Council continues seeing projects have yellow/red codes, it should consider whether to manage them up or manage them out.

#12

• Due to time constraints, the Small Team did not cover the document in detail.
• After sending the documents to the Council, we will have a chance for dry run.
• This isn't a final delivery. We live process and procedure, not implement and forget.
• ACTION ITEM: Staff to send the Final Call message for Improvements #11, #12 & #16 documents. Final Call: 20 Sep; Interim Finalization Target Date: 25 Sep.

3. Draft Proposal for GNSO Community Consultation & Public Comment Response

• ACTION ITEM: Staff to remind the Small Team to review the proposal for public comment response and GNSO community consultation.

4. AOB