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

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

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