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

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

Hi Greg,

Here's another in the threads triggered by your great note.  Here's 
the snippet I'd like to respond to in this thread
"It's beyond scope of this WG to figure out how to re-engineer ICANN 
processes, which is what you're getting into below. "
I heartily agree that re-engineering ICANN processes is far outside 
of our scope.  But it seems to me one of the things that we *can* 
contribute to those future efforts is a clear description of the 
difficulties we had within the current process -- and first-try ideas 
on how to address them.
First, the problem

We've been charged with a puzzle to solve, and a tool to solve that 
puzzle (the GNSO PDP process).  I would argue that part of the reason 
we're having so much trouble is because the tool doesn't fit the 
puzzle.  What are some of the dimensions of the tool?  Here are some 
of my observations;
- It's a process optimized to support policy-making (really 
policy-approval).  Its designers weren't building a process to do 
research, needs-assessment, design, process-development, brainstorming, etc.
- It's a process exists within the boundaries of GNSO, and can't 
easily be applied outside of that entity
- Other Supporting Organizations (SOs) have PDP processes too, but 
they're separate and different
- The process is intended to culminate at an up-down policy vote in the Council
- The schedule/timing is defined in the GNSO bylaws

That's all fine.  But what happens when the ICANN community runs into 
a problem that spans more than one SO, as I think we've agreed we 
have?  Or a problem that takes longer than 90 days?  Or one that 
addresses a different kind of work than policy 
making/approval?  There appears to be a void.  This is a void that is 
likely to cause heartaches for other working groups and I think it 
*is* appropriate for us to throw up our hand and say "we need help on 
this one, and here's our best guess as to what that help could look 
like."  Who better than us?  We're the folks on the ground, doing the 
real work, facing the real problems, coming up with practical suggestions.
This is not a problem unique to the ICANN community (or the ICANN 
corporate structure).  As organizations get bigger and more 
compartmentalized they run into this problem more and more.
The proposal

Let's presume that the cross-constituency notion is valid, and that 
my problem-statement above is correct.  What to do?
One option would be to continue inside the GNSO PDP process, but the 
shoe doesn't fit very well and would probably have to be severely 
customized to fit our need.  We could go to the GNSO Council with a 
series of "bylaw exception" requests to change timing, participation, 
process, deliverables, etc.   But it would probably have to be a 
hack-job and repeated for each cross-constituency, non-policy 
project.  Could be done though...  Maybe this is the way to get this 
next phase done...
Another option would be to run parallel PDPs in all the SOs -- but 
that strikes me as likely to be a logistical nightmare.  Maybe we 
could designate a "sponsoring SO" and accommodate the parallel PDP 
processes in the work-plan, but it would be really complicated and 
might break fairly easily.  Still, it's a possibility...
The option I threw out isn't terribly radical, it's just a new thing 
for ICANN.  Lots of projects are undertaken that span more than one 
functional unit within an organization.  Let's do that.  Surely 
there's an example of such a project we can point to.  If not, it's 
ok to be the first.  Let's not call it a PDP (so's not to invoke that 
process), but let's weave PDPs into the project plan in such a way 
that acknowledges the ultimate accountability and authority of the SOs.
PDPs (90-day, focused policy processes that lead to an up/down vote 
of an SO) are *great* for a lot of things, and represent a huge 
advantage that ICANN has over most large organizations.  Most 
organizations are *terrible* at making policy, whereas ICANN has a 
lot of practice and experience to bring to bear.  So let's not throw 
the baby out with the bathwater.  For example...
PDPs would be great as checkpoints between project phases -- the team 
could produce a bunch of deliverables (including a detailed charter 
for the next phase), each SO would know that they'll have a chance to 
offer course-corrections and go/no-go approvals every step along the 
way.  Which would address the fear of a run-away team, or of being 
railroaded by another SO.  Not to mention provide a periodic review 
and approval of the resources expended and projected.  Completely nifty.
PDPs would also be great for approving policy-changes, if the team 
discovers that they're needed.  Again, this check/balance would 
reduce the fear of having policy rammed down people's throats.
Both of these things would make it easier for the *team* to operate, 
because they would know that there's a backstop for them if things go 
off the rails, which would reduce the fear of "giving too many 
concessions" or "hurting my constituency" during the 
project.  Reducing fear is always a Good Thing.
So there's a longer version of the little snippet I stuck in the 
proposal yesterday.  I'm not wedded to this, and could drop the whole 
thing out of the draft.  But I think we could help the community by 
championing something along these lines.
Sorry about the long rant.  Others can take up the process 
re-engineering banner, and perhaps learn from our pain and 
experiences.  Greg, I don't want to make this one a show-stopper when 
it comes to getting on to the Next Thing, but I still like the idea.
Thanks!

m




voice: 651-647-6109
fax: 866-280-2356

web: www.haven2.com