Last week, I made a request to begin a project milestone to a committee (the OpenSFS Project Advisory Committee). One of the diligent members of the committee jumped onto the wiki where I had been drafting the Scope Statement for the project and raised a number of serious concerns about this document.

Among the claims of the Scope Statement were a wildly inaccurate completion date and imprecise claim on scope. As the PM - and responsible for the Scope Statement - addressing these issues was time-consuming and a minor embarrassment. Developing a project with a committee and on a wiki presents some interesting challenges for me and this blog post is about recording the challenges and leanings from this particular incident.

Observations

This episode had a positive outcome.

While I may have suffered some minor embarrassment - having early critical engagement with the scope document is extremely valuable. The PAC, Andreas, Bryon and Di rapidly rallied around to get a clarification of the areas of concern. The result is that uncertainty has been reduced and the document is well read.

This episode had a cost.

This incident triggered flurry of internal and external email correspondence. The architect and the engineer were repeatedly interrupted resolving this issue. Unplanned interruptions are costly. An additional cost is to the confidence of the PAC with Whamcloud. The PM has a primary role in maintain this relationship and in that role, I have identified some simple changes to enhance our ability to avoid similar issues in the future.

Changes

Scheduled release.

The OpenSFS work has an interesting requirement that beginning milestones must be agreed. In order to keep ourselves busy, we assume some risk and begin some work early. I began scope statements on the wiki. In this case I drafted a scope statement a month ago, and left it to gather dust. While early, frank dialog is valuable, inaccurate claims are distracting. To ensure that a accurate document is available to OpenSFS, the architects and engineers should be aware of the document first, and the schedule of start and delivery.

Annotating document phases.

Previously, when you visit the wiki pages, it is not clear what phase a document is in. Jira provides some handy markup that I will begin to attach to the top of all relevant wiki pages.

This can be used to identify a document in draft.

This can be used to identify a document that has been submitted.

This can be used to identify a document that has been agreed.

This can be used to identify a document that is a state that is not draft, submitted or agreed.