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

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

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. 

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).  

Stake Holders: the charter asks us who is affected and how.  All GNSO
stakeholders are represented.  

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.

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.  

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. 

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."

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.  

Resource Requirements: state it in our report, sure.  We have plenty of
access to experts already, though, and are free to get more.

All best,
--Greg


-----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