Status Report
Date - August 8, 2008
Summary Status
Are there review and approval problems? Yes
Will target dates be missed? Yes
Are there scope changes? Yes
Are there estimate problems? Yes
Are there technical problems? No
Are there resource problems? Yes
Accomplishments this week
- Continued to reach out for data -- Dave, Greg, Rod
- Continued to reach out for legitimate users -- Mikes, Wendy, Greg
- Completed round-1 Constituency input cycle
- Developed Initial Report first-draft
- Continued active discussion of proposed definitions and proposed next steps
Plans for next week
- Finalize form and format of Initial Report
- Finalize Initial Report draft and release to Staff Manager
- Develop draft of Round-2 Constituency-statement template
Issues and concerns
- There is a general sense in the group that we're floundering (of foundering) -- primarily due to issues in the charter we were given
- We have had a very difficult time defining Fast Flux (we still don't have a good definition of the "What?" of Fast Flux)
- There is a wide range of opinions as to whether this is the right problem to solve (this may be a narrow case of a broader problem, or a problem that is likely to have a very short lifespan as techniques in this arena are changing very rapidly)
- It's not clear that we have the right stakeholders involved in the discussion -- this is not a problem that exists in the isolation of GNSO, and probably can't be solved there either
- We have had a hard time specifying what kind of data we need in order to determine the nature, magnitude and victims of the "harm" caused by Fast Flux (so we can't articulate, the "So what?" of Fast Flux at this point)
- Even if we were able to specify the data we need, current data is uneven at best, anecdotal at worst and difficult to obtain and analyze.
- Without a solid understanding of the nature and scope of the problem we find it very difficult to describe solutions, never mind evaluate or recommend them
- During the weekly conference call we agreed that we need to alert the GNSO council that we are having difficulty and attempt to recast our charter into something that we can accomplish within the time-frame and resources we have.
- Given our schedule and resource-availability, I am leaning toward building consensus around an Interim Report that consist primarily of a revised charter. That charter could then be reviewed/refined during the Constituency Statements cycle and released as our Final Report. If there's broad agreement, the next phase of this PDP could be launched after the GNSO Council approves the revised charter.
- I am leaning toward suggesting that we charter the first in a series of phases in the project. Likely to be refined, here are some possible phases that come to mind (based on generic Systems Development Lifecycle Methodology) as I write this:
- Assess Need -- Define and investigate nature and scope of the problem and define the benefits and beneficiaries of solving it (this is the phase that would be chartered in detail, down-stream phases would be described at a high level in this charter, and detailed charters for subsequent phases would be a key deliverable of each)
- Determine Feasibility -- Describe alternative approaches to solving the problem, evaluate costs and impact of each, determine which if any are feasible and recommend a preferred approach
- Define requirements -- Develop a high-level design of the preferred approach -- including roles, responsibilities, obligations, tools, metrics and goals
- Design and build -- Develop the tools and techniques needed to deliver the solution -- including contracts, targets, systems, training/education materials and an approach to outreach
- Test -- Confirm that the solution will deliver the desired outcomes -- conduct: reviews of contracts and policies, walkthroughs of procedures and educational materials, system tests if required, pilot-projects with "early adopters", 1st-round training/education, "early adopter" deployments
- Deploy -- Move the solution into "production" mode -- Depending on whether there are technical or policy solutions, this could mean turning on new systems, establishing contracts, changing to new policies, formalizing relationships with stakeholders outside ICANN, etc.
- Maintain -- Address issues and improve the solution as conditions change -- These are problems that are very unlikely to remain static, so nimble response to changes in the environment would likely be a good thing.
- My apologies to all for not recognizing these charter issues sooner.
