Posts Tagged ‘Project’

Use Wiki Pages for Project Management

May 13, 2009

Most project managers have horror stories about trying to manage projects using some combination of spreadsheets and Microsoft Project.  The vast majority of the time they are totally overkill.  Most projects have a workable number of tasks that get the majority of a project manager’s focus.  The previously mentioned tools are good when the number of tasks is large, but fall on their face in terms of ability to update quickly and disseminate information.  Using these tools creates a morass of file versions, software compatibility issues, etc.. I personally have experienced problems many times where I put together a project plan and then find out the client doesn’t have project or the right version of excel to see my plan.  THERE IS A BETTER WAY.

Use wiki pages (GroupSwim of course) to manage your projects.  There are good reasons:

  1. It is the ultimate shared platform – all you need is a browser
  2. Wiki pages are always up-to-date by their very nature
  3. All versions are captured and available in case of an audit or mistake
  4. No training or software required

Here is an example of a wiki page we used to manage a release of GroupSwim:

Tasklist

  • The schedule is at the top of the page and available for everyone to see
  • Each row represents a feature we built (or could be a task or phase of a project)
  • The narrow columns represent the different engineers participating in the release and how many hours of work they have (all zero since the release is complete).  At the end of each day, they updated their work with the remaining time
  • The final column was for status or issues
  • The links in the table connected to actual designs or other relevant documents that could be other wiki pages, documents, or discussions
  • The list below the tags shows every person who contributed to the wiki page or updated it
  • The list below this shows other related wiki pages, discussions or documents associated with this project
  • After updating the wiki page, you can blast out an email to all contributors letting them know there is an update for review

This one page represents an excellent snapshot of the project at any given time and does not require a complicated symphony of document updates and email exchanges.  Furthermore, if there is a question about the project or any specific line item, the user can launch a separate discussion that is linked back to this wiki page for context.

Using wiki pages to manage projects is clearly a better way provided you don’t need the feature of something like project that include automatic dependencies, critical path calculations, etc.  In my experience, few projects require these feature and even fewer project managers know project well enough to justify the effort of creating and updating the plans.  What’s your experience?

Tags:, , , , , ,
Posted in CMC, Enterprise, Methodology, Random | 2 Comments »

Manage Collaboration Like a Project – Or Else

January 27, 2009

In order for a collaborative effort (requires more than 1 person and has an end goal) to achieve a successful outcome, it is useful to treat it like a project.  The “project” should have a goal(s), time-line, common tools and roles.  I’m not talking about creating a formal project plan, but some basic planning and organization at the front end of the collaborative effort is an excellent investment of time and potentially money.

Most collaboration is poorly managed or not at all.  While there is a HUGE variation in the level of effort, number of people involved, etc., the things good project managers do are helpful no matter how big the project is.  Even when two people are collaborating on the smallest of projects, the likelihood of success hinges on very predictable things.  First, the collaborators should agree on deadlines for when the work should be complete and if there are any interim milestones to consider.  Second, they should decide who is in charge or at least responsible for packaging up the final deliverable.  Or, they should at least give one person the responsibility for coordinating the work, even if they aren’t “in charge”.  Third, if it isn’t obvious, they should coordinate the tools or software they might use so they don’t end up with incompatible work that they need to rework in order to consolidate.  Finally, they should also agree on goals or what the end of the collaboration will achieve.  Is it a document, or a decision, or a piece of art, or meeting up at a ballgame, or some combination of many things?

Let’s review a recent example.  I led a team where we needed to collaborate on a long, multi-part document as part of a sales effort.  The content and data this document required did not exist, and it was both long and complicated.  It required focus, creativity and discipline in order to get it done by the time we needed it.

The team included 5 people in different parts of the company in different parts of the world and time zones.  We used GroupSwim Collaboration for the majority effort.  Two of us spent time mapping out the collaborative effort.  We developed the following “plan”:

  • Set deadlines over the course of 3 days, which is how long we had
  • Divided the document into separate sections
  • Assigned primary authors to each section
  • Created a wiki page for each section of the document and added the questions each author needed to address
  • Tracked people’s progress with a central wiki showing status and hand-offs
  • Reviewed each section as people completed them
  • Consolidated each section into one comprehensive document
  • Performed final edits and cleaned up language, voice, grammar, etc.
  • Formatted the document and then published

The process worked to perfection and we yielded a high quality piece of work.  It would have never worked without basic planning in the beginning to ensure everyone knew what to do, when to do it, and how to do it.  We saved countless hours of potential rework and produced a great outcome by treating the whole effort like a project.

Tags:, , , ,
Posted in CMC, GroupSwim, Methodology, Strategy | Leave a Comment »

Wikis at Work – Defining Requirements in a New Way

September 29, 2008

GroupSwim_Wiki_Example

This is cross-posted with GrowYourWiki. We will be hosting a webinar on using wikis with Stuart Mader, which we will announce shortly.

Projects of all kinds usually involve writing requirements or designs of some kind.  The requirements define what is being done, how something should work, how the customers will use it, etc.. These are critical documents that can make or break a project. More often than not, multiple people contribute to these project requirements.  The usual process teams follow is:

  • Someone on the team develops a template in Microsoft Word or Excel
  • They post it somewhere or email it out to the team
  • Each requirement document becomes a separate file that the team sends around via email to complete
  • The requirements eventually get done, but not without a significant waste of time and level of frustration

This process, which I’m sure we’ll all agree, is far too common and both costly and painful.  People experience issues with version control, email problems, software issues, etc.  There is a much better way!

While many people know what a wiki is, few use them effectively in the course of doing business.  Developing project requirements using a GroupSwim wiki is a perfect use case.  It addresses the problems I mentioned above, and yields measurable benefits:

  1. It is easy to develop a living template that can change dynamically as the team learns on the project (this always happens)
  2. Version control goes away because each document only has 1 copy that everyone uses and shares
  3. There are no software issues because everything is done using a browser
  4. All versions are saved so it is easy to revert back if necessary
  5. Documents are fully searchable and you can track who contributed and what specific changes they made

We have one client working with Ford that is using the wiki to draft requirements.  They created a template, use it to start new requirements documents, and then work collaboratively with the clients to fill them out and update them.  The permissions are tuned so only the appropriate team members have edit access to the specific wiki pages.  The project is very efficient, and the customer is very happy to have full visibility into the process as it unfolds.  They are now using wiki pages for other project deliverables like meeting notes, testing plans, and other important documents.

Tags:, , , , ,
Posted in CMC, Enterprise, Methodology, Random | Leave a Comment »