RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 -- Chartering

["Mike O'Connor" <mike@xxxxxxxxxx>]

At 12:13 PM 8/12/2008, Greg Aaron wrote:
> Dear Mike:
>
> I guess I'm looking to you for the plan of how the group will deliver a
> report for October as per charter, in addition to seeing how we can revise
> the charter for past October.  Energy needs to be expended on both the
> former and the latter.
Yep, which really means that we need to deliver a report within the 
next week or 10 days, given the 30-day Constituency-review cycle that 
we have to adhere to.
I'm completely stumped on how to pull a "answers to the questions" 
report out of our hat -- for all the reasons that we've discussed on 
the list.  One approach might be for each WG member to write *their* 
answers to the questions, then we smash that together and report it 
out.  Would others be up for this kind of approach?  I am overwhelmed 
by the idea of trying to summarize 1000+ emails, especially given 
that our opinions have moved a bit during the conversation.

> Missing tools may be useful, but are not a panacea.  I think the charter
> already addresses many categories you list below, and gives us some freedom
> to define things as we see fit.
>
> Here are your categories, and my notes about them:
>
> Problem Statement: The existing charter allows us to define the problem
> (which we have spent a lot of time on).
Could we go so far as to redefine-away Fast Flux (a technique) to 
address the broader "find ways that the ICANN community can, within 
it's purview, help reduce fraud and abuse on the Internet by 
identifying measures that can be taken while protecting the rights of 
lawful users and stakeholders." ?

> Stake Holders: the charter asks us who is affected and how.  All GNSO
> stakeholders are represented.
I could see leaving the next phase (say, Assess Need) within GNSO, 
but reach out to other Constituencies who wish to participate.  Would 
that work?

> Scope, Size, and Perspective: The GNSO is basically asking us to define this
> for them.  We can say what we know so far, and what needs more work.
Agreed.


> Preferred Problem-Solving Approach: Again, the GNSO is basically asking us
> to define this.  Also, the WG is not necessarily tasked with finding a
> solution or solutions at this time.  Approach is for us to define within the
> general WG guidelines that were given -- consensus, consideration of
> constituency statements, etc.
I could see issuing a report that defines the charter for the next 
(Needs Assessment) phase, but it would be sketchy, given the time we 
have remaining.  Or, we could recommend that the next phase be a 
"chartering" phase that would go into more depth.  Preferences, folks?

> Goals & Objectives: The charter asks us to answer 10 questions to the best
> of our ability.  Any unknowns or suggestions may be stated, and that's fine
> to do.
I'm ok with making the attempt -- but I need help figuring out the 
"how" of it, given the dispersion we've got in our respective answers 
right now.

> Critical Success Factors: this perhaps assumes too much and gets ahead of
> things.  We should let the process proceed and not assume any conclusion is
> "right."
Eh?  Just don't follow this comment.  I agree -- don't presuppose the 
solution, but a critical success factors devolve to answering the 
question "what do we need to do *well* in order for this project to 
succeed?"   For example one critical success factor that I'd like to 
focus on for the next phase is "what's the mechanism to get opinions 
to converge rather than diverge?"

> Readiness: we have already been given instruction to state what we know,
> what we don't, and in what areas there is disagreement.  You bring up the
> issue of GNSO scope.
I could write this -- but most of the answers would be "things we 
don't know right now."

> Resource Requirements: state it in our report, sure.  We have plenty of
> access to experts already, though, and are free to get more.
I think it's more the time-resource issue.  This one certainly soaked 
up a lot more hours for me than I was anticipating.  And likely for 
others.  One thing that would be useful for the next phase would be 
to do a better job of laying out the tasks, time-estimates and 
target-dates before we started so that folks could decide whether 
they can commit.
For example, my time-availability is going to fall to zero on next 
Wednesday night as I prepare to head into the hospital for some 
pretty substantial surgery -- and I'll be out of commission for a 
while (dang body -- it's outside the 55 year warrantee period).  I 
wasn't anticipating this, but there you go.  So I'm trying really 
hard to get as close to a report as we can before then.  It would be 
good to have a better estimate of these kinds of things so that 
people aren't caught by surprise.

> All best,
> --Greg
Thanks Greg, let's keep polishing.

People, I'd like to ask whether you could each put together your 
summary answers to the questions in the next day or two.  I will work 
on a draft of the "next phase" charter and we'll see where we're at 
on Friday.  Sound like a plan?


> -----Original Message-----
> From: owner-gnso-ff-pdp-may08@xxxxxxxxx
> [mailto:owner-gnso-ff-pdp-may08@xxxxxxxxx] On Behalf Of Mike O'Connor
> Sent: Tuesday, August 12, 2008 11:17 AM
> To: gnso-ff-pdp-May08@xxxxxxxxx
> Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 --
> Chartering
>
>
> Hi Greg,
>
> Here's the snippet from your post that I'd like to use to kick off this
> thread.
>
>
> >* I agree that the group seems to lack consensus on many points -- but that
> >is a potential outcome in any WG, and does not invalidate a WG's charter.
>
> I agree.   I'm not really lobbying to invalidate the charter we were
> given.  The charter's the charter.  But it's missing a few things,
> and those missing pieces are part of why we ran into such heavy
> weather.  To throw a notion in front of you (and the broader ICANN
> community), I'm going to paste a very basic set of questions that are
> usually answered by a project charter.   Larger projects require much
> more rigor, but this is a pretty good basic list that I've been
> incrementally updating for, gosh I dunno, 20 years or so.  Commentary
> follows the list...
>
> = = Project Charter -- Sections and
> Questions  (http://www.haven2.com/pdchecklist.html) = =
>
>
> Problem Statement
>
> What is the problem (or puzzle) to be solved?  How does not solving
> this problem get in the way of achieving the organization's
> objectives?  What is the chronology of the situation - how did you
> get here?  Are there trends at work - social, industry, financial,
> economic?  Is this a 'solution' that has turned into a problem - if
> so, what is the original problem that this solution-turned-problem
> was supposed to solve?  What alternatives have been explored?
>
> Stake Holders
>
> Who will be affected by the problem?  Which
> employees?  Stakeholders?  Customers?  Others?  Have they been
> involved sufficiently up to this point?  Should they be brought in to
> the project?  When?  To what degree do they share the belief that
> this is a problem that needs to be solved?  Who ought to 'champion'
> this project?  To whom should the project team report?  Has a project
> leader been selected yet?
>
> Scope, Size and Perspective
>
> What written definition clearly distinguishes between what is inside
> this project, and what is outside? What is the level of detail and
> precision involved in this effort - is this a sweeping global effort
> (like a vision or strategy) or is this a project to produce specific
> outcomes (like install a system, or build a house)? What's the point
> of view that should be taken during the project - there can be more
> than one, better to identify 'em rather than discover them at final
> review.  What's the degree of generalization being sought?
>
> Goals & Objectives
>
> What tangible, deliverable things do we want to see when this project
> is completed?  How do we know when the project is done?
>
> Critical Success Factors
>
> What things do we need to do well in order for this project to
> succeed?  What are the attributes of projects like this that have
> succeeded in the past?  Describe some projects of this type that have
> failed. What can we do to avoid those problems this time?
>
> Preferred Problem-Solving Approach
>
> Who will do what, with whom, by when?  What are the intermediate
> milestone events or deliverables that we can use as checkpoints to
> monitor the progress of the project?  Are they more than 1 or 2 weeks
> apart?  Do we need more (or fewer) objectives to keep the project
> under a reasonable level of control?
>
> Readiness
>
> How dissatisfied are people with the current state of affairs?  How
> clear is the vision?  Do people think this project needs to
> happen?  Do people have the tools and training they require in order
> to perform their role in the project team?  What do other people in
> the organization need to do in order to get ready?  Is the project
> team in need of some time to establish how they are going to work
> together, or have they succeeded as a group before?
>
> Resource Requirements
>
> What people, time, money, access-to-decision-makers, technology,
> space, etc. do we estimate this project to take?  How well do people
> understand the resources required to solve the problem?  Are those
> resources available, or do we need to redirect from somewhere
> else?   Is there wide support, and willingness to commit the
> resource, across the whole organization?  Do people think the change
> is worth the investment?  What are the organizational impacts (how
> broad, how deep)?
>
>   = = = = = = = = = = = =  [end]  = = = = = = = = = = = =
>
>
> I'd like to make several points, based on this little list.
>
> As you read through the list, you'll see that we are missing a few
> things.  Because of that, and this is important, we don't have all
> the tools we need to reach consensus.  A few examples, but not an
> exhaustive list;
>
> Problem statement -- we're struggling on several dimensions here,
> because problem statement could use some refinement.  Are we a
> research group trying to understand the definition and impact of fast
> flux?  A design group, trying to craft good responses for the
> community?  A policy group, trying to hammer out agreement across the
> Constituencies?  The questions we've been posed touch on all of these
> and more.  Which, to use an engineering example, is kinda like trying
> to buy the steel for a bridge at the same time that we're determining
> whether a bridge needs to be built.  Part of the vehemence of our
> conversation is based on real fear of making a huge mistake (building
> the wrong bridge), or missing a huge opportunity.
>
> Stakeholders -- several people have observed on-list, and others
> off-list, that we need to have more people at the table.  This is a
> *very* healthy observation.  Countless projects have failed because
> the project team didn't include participation from all parts of an
> organization.  An HR project will fail if they install an employee
> system without involving the security and regulatory folks, a
> manufacturing system will fail if they don't have cost-accounting
> represented, etc.
>
> Scope -- we're blinking back and forth between "yes" and "no" on the
> "scope-problems?" question in the status reports.  I had us as "yes"
> 3 weeks ago when we were struggling with a definition of Fast Flux,
> "no" the following week when I thought we had one, and "yes" in this
> last status report when we realized that we still needed more work on
> our scope.  It would be helpful to have those written
> scope-boundaries laid out before the group gets started.
>
> Approach -- here again, we're suffering from me building the engine
> of our plane while we're in flight.  The little task-plan with dates
> and deliverables that's laid out on the top page of the wiki is (he
> said humbly) a great contribution to the community and may be useful
> as people strive to improve the process going forward.  But it would
> have been useful to lay that out in advance.   As the work
> progresses, there should be a healthy debate about what those phases
> should look like (more on *that* in another post) but that debate
> should take place before the team is formed and launched.  Just for
> instance -- the phases I've laid out are based on classic systems
> development lifecycle methodology (SDLC for short) which may or may
> not be the best way to break up the work.  The chartering team should
> figure that out.
>
> Readiness -- this is a big one for me.  Given the questions in that
> section, I would submit the proposition that we as a team weren't
> ready to take on this task when we started.  This is not a
> condemnation, but rather tees up the very healthy question "what do
> we need to do to *GET* ready?"  An example -- I'm not ready to run a
> marathon today, but I could undertake to *get* ready to run a
> marathon and succeed some time in the future.  In our case, the very
> first question is the biggie -- we don't have agreement that the
> problem we've been presented needs to be solved.  There are a bunch
> of things that we could encourage people to do in the future to fix
> this, but that's the situation we face today.  That's not evil, or a
> mistake, it's just a readiness issue.
>
> There's more to rant about, but this is enough to give you a sense of
> where I'm at and I don't want to belabor your eyeballs.
>
> Back to your point about the charter.  No charter is invalid, it's
> just a charter.  But we're drawing to the close of our current
> charter, and I think it is useful to suggest positive ways to improve
> the next round.  The suggestion I'm making in our proposal is that
> the whole first phase of the "next thing" be devoted to a more
> rigorous chartering effort, which will lead to better buy-in from the
> community and remove some roadblocks for the group.
>
> Thanks Greg,
>
> m
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.6.0/1604 - Release Date: 
> 8/11/2008 5:50 AM