Project Management Training

From W3C Wiki

The main deliverables of W3C are specifications that arise from W3C Working Groups. Each Working Group can be viewed as a "project" that begins when it is chartered by the W3C Advisory Committee, and completes, typically with a W3C Recommendation (followed possibly with some errata). Since this is the main deliverable of W3C, W3C has decided that it should develop a basic training course in the unique ways to manage these projects.

Project management training is available broadly in the context of a company completing a product deliverable or fulfilling a government contract. Such training is complementary to our focus and is useful in a W3C context, but is different from our focus here. Here we focus on unique aspects of W3C projects. One unique aspect is the challenge of getting disparate parties to a consensus recommendation. Another unique aspect is that we drive completion not through a de jure set of enforcement mechanisms (such as would exist in the commitments for a government contract), but through a consensus of a common goal (Leading the Web to its Full Potential). A third unique aspect is that in this material, we weave in salient aspects of the W3C process.

The original motivation for starting this work was from an effort of some members of W3C Team to look at how we can improve the ability of W3C Working Groups to produce specifications on a known and reasonable timeline. One way we identified to support this is to develop a project management training program to support the ability of chairs, staff contacts, and editors to lead the work. This work was identified by the Schedule Delay Task Force Project Management Training (Team-only link) deliverable and continued in a Geek Week 2012 Project Management Training Project (Team-only link). The outline below constitutes a preliminary input into the structure of a project management training program, for reference and exploration.

In addition to this outline, work on project management training is expected to result in enhancements to the The Art of Consensus (the W3C Guidebook). A W3TechCourses course (Team-only link for now) is being developed from output of this work.

Project planning

Requirements gathering

Clearly scope requirements and defer others to v.next

Testable requirements

Perform in advance of milestone forecasting

Milestone forecasting

Minimal timelines (ChrisL)

  • Minimal time in each stage
  • Time to prep draft for TR publication
  • Length of comment / review windows
  • Time to process comments

Plan number of working drafts before LC

Avoiding more than one LC

Advance comment solicitation

Advance testing

Active discussion with community

Efficient CR passage

Test suite completely ready to go at start of CR

Clear CR exit criteria

Ensure continued relevance of spec

Monitor that community at large maintains interest in spec

Ensure spec not “overcome by events”

Effort forecasting

Identify central roles: editors, primary authors, test suite developers, etc.

Identify how group members without these roles contribute: action items, review / approval, etc.

Estimate person-hours for each role to complete their task, at particular stages of the spec

Estimate group-hours for group review, discussion, etc.

Identify availability of individuals per week and divide into their time contribution expectation

  • Account for vacation, sick time, pull-away from W3C focus by their organization, fluctuations in energy level, etc.

Progress and deviation monitoring

Action item completion tracking

Project management software

Monthly or Quarterly status check

  • Real vs planned time inputs
  • Real vs planned time requirements
  • Status of spec wrt plan by that time

Test planning

Test editor

Test harness tool

Develop tests along with spec features

Prototype

Execute tests early if possible

Make test suite available to public

People management

I am thinking of setting up a group of questions and approaching team and chairs who are particularly good in those areas to ask how they handled these situations. It would be fun to get people together to discuss them and video it to save for the future, but that may be more than we can manage during Geek Week.

Completing action items

Dealing with recalcitrant individuals

Responding to organizational blockage

Addressing flame wars

Responding to external / public perception issues

Keeping commitment and energy level up

Congenial environment

Visible progress

Impactful spec

Effective meeting management

Planning

Agenda

  • 48 hours in advance
  • Preparation required of participants
  • Clear outcomes expected

WBS to collect advance input

Make meeting valuable and essential

Avoid tangents in discussion

Using agenda deferral or issue tracker for would-be tangents

Taking clear minutes with headings

Scribe rotation

Avoid meetings for the sake of a regular meeting

Work effectively within W3C Process

Publication on TR

Maintain publication-ready editors’ drafts

Begin checklist at least two weeks before anticipated publication date

  • Transition calls
  • Secure review commitments
  • Link and pubrules checks
  • Spelling and grammar checks
  • Content accuracy and consistency checks

Send publication request only after staging a completely publication-ready document

Formal comment processing

Definition of what constitutes a formal comment

Tracking receipt and handling progress of formal comments

Transition reviews

Patent policy

Ensure basic understanding of the policy

Identifying potential patent issues early

Ensuring WG members understand patent obligations

Optimizing tool use

WBS

Survey candidate decisions before meetings

Survey calls for objections on new decisions after meetings

Tracker

Recording issues and actions effectively

Action item reviews

Would be good to add a “whine” to overdue actions

Issue processing

Formal comments

Internally raised issues

Externally raised issues

Test management

Resources