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:
It is the ultimate shared platform – all you need is a browser
Wiki pages are always up-to-date by their very nature
All versions are captured and available in case of an audit or mistake
No training or software required
Here is an example of a wiki page we used to manage a release of GroupSwim:
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?
Most of us use spreadsheets to track information that involves no math or calculations. The spreadsheet becomes a glorified table to hold and update information. There are several reasons why this is a bad idea:
Spread sheets are good for making calculations, they aren’t good and tracking who made what change and when
Spread sheets are files and are not built to make version tracking easy
Spread sheets need to be sent back and forth using email or downloaded changed and then uploaded
I’m not bagging on all spreadsheets because I use them all the time. However, I use them when I’m doing math or require sorting, not tracking information.
The alternative is using wiki pages instead. Here are the reasons why this is a good idea:
There is only one version and no file to worry about
All changes are tracked and can be backed out with one click
No software required – all you need is a browser
Updates and notifications are automatic
Issue logs, status reports, customer records, lists, text based documents are all ideal candidates for a wiki page versus a spreadsheet. I’m not suggesting that all spreadsheets are bad and never use Excel. I am suggesting the next time you automatically assume you need a spreadsheet to track or list things, you should consider using a wiki page instead.
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.
We hosted a great webinar today with Brian Krug from newScale. He covered how their company uses GroupSwim to improve professional services projects and outcomes. They also use it during the sales process and post implementation. Here is the video of the session. Let us know what you think. My thanks again to Brian for all his preparation and excellent delivery.
[Note: I've had to remove the video unfortunately. Appears that the software didn't record Brian's piece so it is silent after the first 10 minutes. My apologies.]
We hosted a great webinar yesterday on how to use wikis to improve productivity in your business. Stewart Mader and I hosted over 40 people for the session. Here is what we covered:
Defined wikis and their use in business
Described how wikis can be used for project management and knowledge capture
Demonstrated how GroupSwim works in this use case
Explained how Stewart used a wiki to write his book (WikiPatterns) and the benefits associated with this method
Showed how GroupSwim works in this use case
Discussed adoption strategies and tactics for using wikis in business
Answered questions
Here is a recording of the webinar if you would like to watch it. We enjoyed the experience and will do more in the future.
Update: The webinar participants asked questions during the session. Here they are with our answers:
1. Can you import XML into GroupSwim?
No. You can import HTML and copy and paste from other wikis. We will be adding XML importing features in the future
2. Is your wiki available as a virtual extension of your book to continue the conversation online?
The best place to continue the conversation online is Grow Your Wiki. You’ll find lots of articles on wiki uses, case studies, adoption strategies, and ongoing conversation among readers. Here are a few articles you may find helpful:
Yes. For example, you can embed video, images, and audio files in GroupSwim wikis
4. What was the process of going from a wiki to a hard copy book?
In some cases, I directly exported content from the wiki as XML, then inserted that XML into the publishing templates. In a few instances where more complex formatting was required, I simply copied and pasted content out of the wiki and into the publishing templates. The bottom line with a wiki is that it doesn’t store content in any proprietary file formats, so putting content in or taking it out of the wiki can simply be a matter of copying and pasting text.
5. Is WikiPatterns available as a PDF?
Wikipatterns is currently available as a softcover book through Amazon.com and major bookstores. If you’d like to see the book become available in an electronic version, you can vote for Amazon to create an electronic version for their Kindle ebook reader.
6. How is a wiki different than an intranet?
A wiki can be the intranet for your organization. Especially in smaller organizations that don’t have a lot of other content management and collaboration tools, a wiki is a great choice to serve as your central knowledge management and collaboration hub. In larger organizations, the intranet often serves as an organization-wide information dissemination tool, but not a knowledge and collaboration hub for individual teams. A wiki is complementary to the intranet because it gives teams and departments a virtual workspace to organize their meeting agendas & minutes, project materials, documentation, and shared knowledge.
7. Is there any interface between wikis and bberrys?
You may be able to access wiki pages using the browser in your BlackBerry, but perhaps the better way to use a BlackBerry in connection with a wiki is to subscribe to wiki pages for updates via RSS or email. Those updates can be sent to your BlackBerry, and you can stay up-to-date as others on your team update content on the wiki.
8. Do you have any strategies for convincing wikiphobic (and/or technophobic) coworkers to make the switch?
Some people look at Wikipedia, and become concerned about all wikis being a free-wheeling, anonymous, potentially anarchic “mess”. But wiki use inside an organization and Wikipedia are two completely separate worlds. Inside an organization, the audience is much more stable and easily identified – it usually consists of employees, business partners, and – in some cases – customers. Therefore, the need to have a wide-open, publicly accessible site to attract users isn’t necessary. The more important considerations inside an organization are: interoperability with other business tools, ability to organize content by department, team, or project, and the ability to assign read and edit permissions to the appropriate content for each person.
9. In a company of about 70 employees, how long would you estimate the adoption process would take before fully utilizing a wiki?
It depends. Some factors include:
Current tools and infrastructure
Management support
Company culture
Incentives
In our experience, we have seen some customers adopt them aggressively and quickly once they see how effective wikis are. In other circumstances, it could be a month or more.
10. Is it possible to port mediawiki content to GroupSwim?
The best way to move is copy and paste. We’ve had other customers use this method, and I just tried posting an article from Wikipedia into GroupSwim and it worked perfectly; we don’t currently have an automated method for doing this.
11. Is this permission/community based so that different departments can maintain their pages but keep others from editing their pages?
GroupSwim is organized by groups within a site, so you can set the permissions to allow departments to limit who can see or edit their wikis. The group and permission structure is extremely powerful and you can do all sorts of things to organize your site.
12. Are users added to GroupSwim or can Active Directory be used?
You can use either method. We can integrate with a company AD, or site membership can be managed from GroupSwim; it is up to you.
13. Is GroupSwim hosted?
Yes. GroupSwim is software as a service and is not available any other way.
14. What is the best way to publish content on a wiki into a document, if needed?
GroupSwim allows you to copy and paste the content (or HTML) directly into other applications. We are adding the ability to export wiki content as PDFs and/or Word documents in the future.
15. Can you recommend some wikis that are easy to edit?
We are very pleased to be hosting a webinar tomorrow. The topic is how to use wikis in a business setting to improve productivity. Wikis are incredibly powerful collaboration tools that many people not only don’t use but also don’t know what they are. Please join us for this interesting session. Talk to you tomorrow.
We are very pleased to be working with Stewart Mader of GrowYourWiki on our webinar. Stewart is an industry leader and renowned expert on wikis. The point of the webinar will be to educate ourselves on wikis and how they can be used in business to improve productivity. Stewart will cover real-life examples from Fortune 500 companies. This is going to be a great session. Please join us and register here.
Sarah Perez did a great review of GroupSwim on ReadWriteWeb. In fact, she deserves major props. I never spoke with her or demonstrated the product. She did all her own research on our demo sites. Thanks Sarah!
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:
It is easy to develop a living template that can change dynamically as the team learns on the project (this always happens)
Version control goes away because each document only has 1 copy that everyone uses and shares
There are no software issues because everything is done using a browser
All versions are saved so it is easy to revert back if necessary
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.
We are very excited to announce a major new release of GroupSwim. This is another key piece in our strategy of creating comprehensive collaboration software for our business customers. The highlight of the release is an integrated wiki application. After using many other industry leading wikis in my career and researching for our design, I can tell you this is one of the best wikis you will ever use, hands down. Here are some of the wiki and release highlights:
Integrated wiki
WYSIWYG (what you see is what you get) editor that is remarkably easy to use
Robust access control permissions to configure who can edit specific wiki pages
Insert capabilities including drag-and-drop tables, files and images, and widgets inside the wiki pages
Wiki pages can be linked with your discussions and files across all groups
Powerful version compare and recovery capabilities
Redesigned home page for feed style information across all groups
Hidden groups that are invisible unless user is member of group
New email notification permissions let you tune who can send email notifications
Improved auto-tagging capability
Insert files and images directly into discussions and wiki pages
Performance enhancements
New system APIs to enhance integration
This event is a huge step for us. We have plently more to build, but the customer and press feedback on the previews we’ve given are nothing short of spectacular. Please let us know if you have any questions or comments. And, feel free to check the software out in our demo sites or create your own. Go GroupSwim!
