[gnso-osc-ccc] CCT Concepts and Ideas: Ken Bour

["Ken Bour" <ken.bour@xxxxxxxxxxx>]

CCT:

 

In thinking about Chris Chaplow?s comments (below) and the conference call
we had with ICANN Staff on Wednesday, I thought I might share a bit of
explanation and background along with my own ideas about how we might
proceed.   All comments are welcome.  

Scope Questions:

With respect to scope, as best I can recall, the placement of website and
related technical improvements into the ?Communications and Coordination
Team (CCT)? was done by Operations Steering Committee (OSC).   The BGC
actually included those specific elements in its Section 5, which was titled
?Recommendations re: GNSO Council.?   While the CCTs charter is generally
about improving communications and coordination within GNSO as well as
between it and other ICANN structures, there were several specific
technology tasks mapped to it by the OSC (see
https://st.icann.org/icann-osc/index.cgi?operations_steering_committee_osc).
Presumably, if those tasks are artfully executed and successfully
implemented, communications within the GNSO will be enhanced.   For
everyone?s quick reference, I pasted below the relevant section of the BGC
report (Section 5, pgs. 28-29), which has been organized into the CCTs
scope.  

?We also note that each review of the GNSO Council and constituencies that
has been conducted has documented shortcomings in the Council?s
communication methods, which serve as a barrier to broader participation and
inclusiveness. Improvements are needed in a number of areas. For example,
GNSO Council and constituency documents should be more broadly accessible,
informative and understandable by the global community. Most importantly,
the GNSO website and online public comment processes should be redesigned
and (to the extent possible) made multi-lingual, along the following
guidelines:

 

?        The GNSO website should be simple for everyone to understand and
use;

·         It should be easy to locate information about all current policy
issues, and for each issue there should be a succinct summary, links to more
detailed information, a status report, and next steps;

·         There should be access to archives of all GNSO Council activity,
including Council minutes;

?        There should be links to all constituency websites; and

?        There should be links to other relevant ICANN structures and
activities.

 

We also recommend that the Council work with Staff to improve the GNSO
Council?s document management system and to develop an improved means to
solicit meaningful public comments, and to use project management
methodologies to implement these improvements and to better support policy
development activities.? 
(Source:
http://www.icann.org/en/topics/gnso-improvements/gnso-improvements-report-03
feb08.pdf) 

In interpreting the above general requirements, I note that it encompasses
several categories that are often associated with web-based technology
improvements:

1)      Ease of Use:  simplicity and effectiveness

2)      Consistency:  in look/feel, portal design, access, and navigation

3)      Content Management:  document sharing across the organization with
clear and understandable taxonomy and effective search capability

4)      Multi-lingual support:  to facilitate global access and
participation

5)      Collaboration:  workspaces/forums for teams to coordinate schedules,
organize/share documents, and participate in discussion boards for
brainstorming ideas, building knowledge bases, creating blogs/wikis and/or
simply gathering information.  

6)      Document Management (see below)

Document Management ?Issue?

In my frame of reference, the term ?Document Management? implies a set of
automated tools/capabilities that allow users to ?Author and manage
documents easily with effective workflows (life-cycle), supporting common
industry standard software packages/tools and ensuring integrity with
enhanced features including version tracking, document check-in/check-out,
view/restore past revisions, and document-specific access/security.
Requirements in this section also include multi-language translation and
localization support.?  (Excerpt from Business Requirements for GNSO Web
Site Technology Solution, Sep 2008).   As David Conrad mentioned, finding a
set of affordable tools that accomplish the above in a multi-platform
environment (e.g. different authoring SW, operating systems, etc.) is an
enormous undertaking.   The ICANN Staff is able to launch an internal
document management project primarily because it can constrain the technical
environment, business processes, and client applications such that a
cost-effective solution becomes feasible.   Any such system, though, would
not port to ICANN at large or, more specifically, the GNSO.   Having said
that, the fact that this ?requirement? is technically challenging does not
take it off the table in my view.   ICANN is committed to solving the
problem once it has a clear statement of the GNSO?s requirements for a
document management improvement effort.   My understanding is that it would
be in this team?s scope to help fashion those requirements statements to
inform/guide ICANN?s Information Technology (IT) organization in this
specific area.  

Team Deliverables (Partial):

In terms of moving forward on our technology-related tasks, what became
clearer to me during Wednesday?s call is that we might consider there to be
two distinct deliverable groupings:    

(1)   Requirements (i.e. how we would like the GNSO website to
behave/perform) and 

(2)   Implementation (i.e. development -- including tool/platform selection
and customization)

I think ICANN is looking for our team to specify the entire set of GNSO
business requirements that it considers vital, whether they can be
implemented in a short- or long-term period.   In other words, our initial
focus should, perhaps, minimize if not exclude entirely the importance of
?doability.?  A starting set of such requirements is contained in the
document that I sent to the team last week, which could be modified based on
the team?s deliberations and, possibly, some expert outside help.   For some
manageable subset of those requirements (e.g. content management), we
possibly could move into an implementation phase (e.g. ?beta? Drupal site);
whereas, for others (e.g. collaboration, document management), we may have
to stop at the requirements level and leave any future development to the IT
organization.   Since I was one of its authors, I would be pleased to walk
through that document with the team and offer my thoughts as to how we might
proceed to reformulate the material (including why that is warranted) in
such a way that it could become one of the team?s first important outputs.


Based upon what the ICANN Staff stated in our conference call, the very
first step is creation of a Project Management Charter (Joyce and Ken have
the action) that will outline the scope of technology improvements to be
considered in this effort.   While we have our own Charter already, we want
our outputs to be officially sanctioned within the overall ICANN
infrastructure.   Participating within this umbrella project discipline, we
can be more assured that any products/outputs we develop will be
crafted/formatted in way that is considered actionable by the appropriate
ICANN Staff organizations.   Concerning this new charter, I would argue that
the scope should be broadly configured (consistent with the Board
recommendations above); however, we should keep in mind that, even though we
might recommend a wide range of technology improvements (driven by
requirements), that does not imply anything about how they are implemented
and in what timeframe.   That prioritization can occur after we generate the
high-level business requirements.   

Thanks to Chris for his stimulating comments and inquiries.   I am eager to
hear other team members? thoughts?

 

Ken Bour

 

 

From: owner-gnso-osc-ccc@xxxxxxxxx [mailto:owner-gnso-osc-ccc@xxxxxxxxx] On
Behalf Of Chris Chaplow
Sent: Wednesday, March 18, 2009 6:30 PM
To: gnso-osc-ccc@xxxxxxxxx
Subject: [gnso-osc-ccc] Document Management

Hi all, 

Thanks to the ICANN web staff for demonstrating the current test website and
the background and Document Management vs. Website issues.

It is interesting to note that in the team charter goals the "Improve the
GNSO's document management capacity" was initially a goal and then
downgraded (agreed by us last week) to come under the Website requirements.
I am trying to think back to the rationale for this.   Was it alignment with
board's recommendations?   If so in "Summary of Board Actions -Attachment A"
is not so black and white.

On one hand Document Management is such a major topic in its own right
which is probably why staff have pulled it out in as a problem in The "ICANN
board recommendations draft checklist", but the recommendation and action
items underneath do not appear to address this problem. 

It is worth noting that the CCT has perhaps a more difficult task of setting
the boundaries than other work teams. I say this because a close examination
of the LSE report, and the BCG WG and the Sharry and others make many
references to "communication". We have to decide what issues to focus on and
what to ignore as passing mentions. The public and constituency comments are
not very enlightening. Lots of agreement that communication and website must
be improved but not much on substance or detail. On the subject of
constituency reorganisation by comparison there are lots of detailed
proposals and submissions. 

I expressed caution earlier on the blind use of the checklist. There are
many other minor 'communication' issues mentioned in the reports that we
should either acknowledge and include in our report scope or acknowledge and
discard.

I agree with Mason that I recommend "we use this to manage our work, rather
than create a separate (and duplicative) plan document" but I think we all
need to examine it carefully along side the reports, update it or not, and
above all be comfortable with it as a starting point.    

 With best regards, 

----------------------------------
Chris Chaplow
Managing Director
Andalucía.com S.L.
Avenida del Carmen 9
Ed. Puertosol, Puerto Deportivo
1ª Planta, Oficina 30
Estepona, 29680
Malaga, Spain
Tel: + (34) 952 897 865
Fax: + (34) 952 897 874
E-mail:  <mailto:chris@xxxxxxxxxxxxx> chris@xxxxxxxxxxxxx
Web:  <http://www.andalucia.com> www.andalucia.com 
Information about Andalucia, Spain.

Please think of the Environment before you print this email