Tuesday, September 07, 2010

A constant tussle


At work, I like to take time to think, reflect, and then respond to an issue. In urgent situations, my focus just gets sharper but I still manage to carve time for reflection. I have always believed quick hasty responses impact efficiency as they  lead to communication overheads either now or later. However, these days I have been wondering if this strategy is dated. 

I find that while I am trying to articulate different aspects of an impending project issue, another colleague will sometimes race ahead with a quick (often half-baked) response (mostly including a senior to the communication). Sometimes, reporting managers expect one-minute responses. In my current project, I often receive comments, feedback, and suggestions from the Wikipedia volunteers. I find 60 minutes too long a response time for these interactions. By that time, the discussion sometimes gets more complex because of incorrect assumptions and misinformation shared by others on a public forum.  

In social, crowd sourcing models, since people expect quicker responses, it is probably smart to respond fast as well. When you respond quickly, you have better control and influence on the discussion (and hence your project). If certain facts are incorrectly understood by the group, you are able to immediately step in with accurate/up-to-date information.  

This is how I currently cut my response time: 
1. Control the scope of the response. I ask myself if the recipients really care about a detailed response. 
2. Respond with high level project scope/design messages. I find this information suffices most queries.
3. If I know I need more time, I send out a  "I am working on it"/"I will get back to you" message. Yes, I still value reflection. A response ought to be worth everyone's time.
4. Follow up on #3. I need to be trusted so that my projects succeed.

Obviously the above strategy is function of the workplace culture. But now I know how to cut out my response time to 5 minutes for most of my project communications.
 

Wednesday, August 18, 2010

Using Wikis: Project Process (Details)


Content collection, draft, stakeholder review

  • Contact the sources/SME who will help you define the key talking points
  • Create the structure aligned to similar deliverables already created
  • Create your first draft
  • Validate the talking points and the draft with the key stakeholder for text content
  • Clean up the content with the new data from volunteers and the stakeholder review
  • Send the wikipage to the copyeditor for the first review 
Note: Although, I prefer the industry standard of one copyediting cycle per product,  for the Bookshelf project I added two copyediting reviews because I had concerns around quality of the final product. Here are the reasons for that concern: 1.In the Wikipedia/Wikimedia world, everyone is encouraged to access the page and edit content to help improve the article. 2. The project team, including the writers and copyeditor are geographically distributed or working in a remote setting. 3. English is a second language for a couple of writers and a key content stakeholder. 

Copyediting

  • Ensure the writer follows the writing guidelines. Help the writer understand by explaining what and why the change was made so it is easier for the next time
  • Ensure that the deliverable is aligned to the design standards established for the project
  • Contact the Project Manager to define and establish standards for new styles
  • Best practice: Writer to not touch the content till copyediting is complete
  • Best practice:Writer to direct the community to Discussion page for any other edits or comments (and not edit the page directly while the copyeditor is reviewing the page)

Final stakeholder review

  • Give a heads up to the key stakeholder on the day when you will have the content ready for review (maybe a week in advance)
  • Best practice: Highlight specific areas you want the key stakeholder to focus on. For example, you added a new topic since the last revision
  • Ensure that your deliverable is ready, final, and of a quality that you might want it to be printed (you do not want to change the text too much once the key stakeholder has given a final approval)
  • Implement stakeholder review and send for copyediting
Also published here.

Thursday, August 12, 2010

Using Wikis: Project Process


In my current role as the Project Manager, Bookshelf (Wikimedia Foundation), we use wikis (obviously!) for project management, content development, and testing. As we charged ahead with the first deliverable, I found myself struggling to define a project process that included the Wikipedia community (particularly in content development) and manage risks associated with everyone editing the same content with the need to control the overall product quality and minimize communication overheads between teams. 

Here is the summary of the overall project process that I created and currently use (think funnel):
Step 1: Content collection, where everyone is welcome to edit, contribute, and help us define the content elements for that deliverable. The project team needs your perspective and knowledge (and access to information sources)
Step 2: Structure and initial drafts, where the page is edited by the copyeditor, writer, and the key stakeholders. Everyone is welcome to review the page but please use Discussion to post your comments and ideas.
Step 3: At this final stage, only the copyeditor and the lead writer edit the page.
For all the stages, you will find the writers/leads on the deliverable communicating with you using a banner at the top of the page.

Why this process?
We are trying a fine balance between leveraging crowd knowledge and ensuring high quality of deliverables.

Owners
  • Project process, schedule, managing risks and stakeholder expectations: Project Manager
  • Deliverables: Lead assigned to each solution
  • Wrting styleguide: Copyeditor
  • Design: Graphical designer
Also published here.

Wednesday, June 09, 2010

Gaming Techniques for Fund Raising?

Check out how Wikimedia Foundation used gaming techniques for fund raising.

This technique can so easily be extended to make learning fun and encourage students to complete their learning path for a particular competency.