My Learning Blog

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 soc

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

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 rev

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.