RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 -- Chartering
- To: <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: RE: [gnso-ff-pdp-may08] Proposed Recommendation and FAQ, v1 -- Chartering
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Tue, 12 Aug 2008 10:17:12 -0500
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) = =
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?
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?
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?
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
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
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.