Welcome to the 'Plogging' World

Roland Piquepaille writes "No, it's not a typo. A plog is short for 'project log' like a blog is short for 'web log.' And plogs start to be used as tools to manage projects, especially in the IT world, as discovered Michael Schrage of the MIT. He reports his findings in an article published by CIO Magazine, "The Virtues of Chitchat." Schrage found that if plogs are not really commonplace, they're not exactly rare. And they are even used to manage large IT projects, such as ERP rollouts. I totally agree with him that a plog is of great value to integrate people in a team or to keep track of the advancement of a project. And you, what's your view? If you're a project manager, do you use a plog for better control? And if not today, will you use one in the future? This overview contains selected excerpts from Schage's article which will help you to answer the above questions."

Ah, like the old .project file

[Mick Ohrberg]

Brings back memories, when we would check out each others' .project files... Hopefully this tool will be a little easier to manage.

one word

[Anonymous Coward]

pwiki.
They make for excellent documentation both for old and for new developers/users

SF

[Leffe]

Could you consider SourceForge [sf.net] a 'plog'?

interesting...

[kistral]

I'm not sure that this site [plogs.net] is working under the same definition of "plog", but then again, I had never heard of a "project log" before this article.

tlog?

[lacrymology.com]

If a web log is a blog, then shouldn't project log be a tlog?

-m

Workplace Wikis are useful

[mikemacd]

I've found that WIKIs [wikipedia.org] can be useful as a collaboration tool in the workplace.

It can be a free form tool to coordinate various teams and projects. Its important to bear in mind though that even the best tool is no replacement for good management.

The WIKI I'm currently using is TWIKI [twiki.org] which is GPL'd.

Re:Basecamp for Plogging

[nounderscores]

hmm have to check that out.
my uni uses tutos [tutos.org].

and the software engineering documentation subject has "Document the building of your very own team management software" as their semester project [mu.oz.au]

actually, in order to manage all the docs our team used a combination of roundup, mailman and B2 blog to make our own rapidly developed team work space...
it was kinda ironic - using a collaborative online project management system to design a collaborative online project management system

in the end, though, the strain of having 7 people work on 1 document through a webbased interface got too much so we ended up using CVS on the school unix servers

My experiments in my team with a blog.

[thehive]

A few months back i setup a blog to help out our team to help manage the knowledge we acquire throughtout the projects duration. My managers fourtunately approved it. Though it was well recieved throught the team, very few knew what a blog actually is and very few have actually used it. It is rather unfortunate that some employees do not do anything other than things which are manadatory. I'm sure people would have used it much more if it was made mandatory to record all their experiences but we know that it's not possible. An oft quoted excuse is time. Blogging does take time and i totally agree with that but what is not being considered is the time that would be saved by someone else who would come across the same problems after a month or two.

Re:Do we need more types?

[ericspinder]

In response to an internal tech newsletter about "what you wanted to see", I anwsered with an idea about an "internal forum" with postings about every project, it's general status, design and questions (and hopefully answers) on technology. Apparently only the name stuck, our "Forum" is an web page form to ask questions, which are to be answered by (appenently) the newsletter staff. In fact, I am only quessing about my idea being turned into an email page becuase I never heard a word back on my suggestion, not even a "hey, thanks" to indicate that it was even read; I suppose other people may have suggested such a "forum" (or even just the general idea).

I glad the idea has a specific name, now that there is a buzz word attached to the idea maybe someone who matters will pick up on it and champion the idea, it would be useful, no matter what it's called.

In theme with other posts...

[lpangelrob2]

We too also use a Wiki to communicate. Unfortunately a quick glance at the "Recent Changes" page shows the last change was made on February 28th despite three large projects between then and now.

About the only thing proven here is that when e-mail is shown to be sufficient, it's sufficient, and developers won't be quick to jump to other technologies, even when they are more useful.

Logs on the JPL Mars Exploration Rovers

[goatbar]

Not too surprising. We used this all the time for the MER rovers at JPL. We used aim chat groups with a logging robot (easy enough to write one using say Net::AIM). Lots of design discussions and training sessions were done through IM and then became a part of the project documentation. Then grep and search when you forget something. Just don't say anything too obnoxious while chatting...

Re:Do we need more types?

[generic-man]

"Blogs," "moblogs," and "plogs" are not words. They are ill-conceived marketing creations, no better than "information superhighway" and "top-speed technology." They exist to perpetuate the myth that personal publishing is going to reinvent the web as a means of communication.

Weblogs are personal web pages or journals. Plogs are project logs. Photologs are photo journals. Sure, the terms are longer, but they actually sound reasonable compared to "blog."

What do the rest of you use?

[broothal]

I've been looking for something like this for a long time. Unfortunately, plogging doesn't satisfy my every need. So - let me ask the project managers of slashdot (I know you're out there) - what do you use as project collaboration/management tool? Someone posted a link to "Basecamp" which seemed ok (unfortunately it require credit information just to try a free demo). Are there other tools like that? How do they measure up?

I've been thinking about wiki, but it's a tad to difficult to be useful - my teams usually consists of developers, DB people, graphic designers, customers etc. They'd never learn the simple wiki markup.

Nostalgia...

[igrp]

We used to use .project files to keep track of schedule changes, progress and project-related problems we had run into, too. It actually worked very well in small to medium-sized development groups.

We would timestamp our .project files and each of us would have their login script finger the other group members, compare the timestamp to the one stored in a flat database (ASCII file) and then, if there were any changes, display the output of the finger command.

Simple, yet effective (plus, it was geeky enough to make sure that nobody outside of R&D or Coding ever bothered to check the status of projects).

These days, unfortunately, hardly anyone seems to be running fingerd and it's virtually always firewalled off to the outside world.

Plogs

[Anonymous Coward]

I used to keep all my Project Logging in my .plan file, so that when people used the php-based finger on my team member profile, it would list what I was working on. Older updates got appended to a .plan.old file after at the beginning of each month, so that my thoughts/ideas/plans/etc. never got deleted.

I have a ton of neat ideas and thoughts on improving development, but in that same respect, I'm extremely forgetful. If I can keep from re-inventing the wheel, so much the better. Plus, what if I were to die in a horrible shopping cart accident? How would my (now ex-)employer recover from the loss? Well, if they were smart, they would look at my home directory and see my project info in plain sight and pick up the pieces in an instant (which they did when they laid me off in 2001), just as I would if I were to take a vacation for a week and come back to work I had left idling.

Re:Workplace Wikis are useful

[JaredOfEuropa]

It can be a free form tool to coordinate various teams and projects. Its important to bear in mind though that even the best tool is no replacement for good management.

IMHO, a free-form logging tool or discussion board serves two valuable purposes:

1) On a free-form weblog or discussion board, it is much easier to be honest about problems. Compare that to formalised documents such as progress reports, where most people tend to play down issues because they think they can fix them themselves before the next report is due, or because they don't want to make their boss (or themselves) look bad on a formal and perpetually archived document. Good management requires good and timely information... our company has an unmoderated board with lots of flames, gripes and complaints, and if I were the CEO, I'd take a peek at that board every now and then.

2) Formalised document hierarchies can sometimes be rather a discouragement to recording the odd thought, idea or issue. Should this be a memo, briefing note, how-to, FYI bulletin, technical subsystem spec or should it go on the ARID log? Where do I file it? Does it need to be reviewed? Sometimes, not having a lot of structure can be good, and weblogs can provide such an environment.

Hey, I just did that.

[dmorin]

Here at work we have two primary ways of communicating, when you don't count chance meetings in the hall. First is a Twiki, second is a developer's mailing list. In putting up a blog I'm hoping to address some of the weaknesses of both:

• Twiki seems best at spec and document level stuff, but not ongoing conversation. You have to put forth a medium amount of effort to set up a twiki topic properly (i.e. don't just put it up and then email people the link -- LINK TO IT from a main contents page someplace!)
• Twiki gets out of date way too easily. I started working here and found a page called "Todo Items" for my project. Cool, I read it - it was like 2 years old, I had no clue whether anything was still even relevant.
• Developer's mailing lists, which are great for conversation, are too easily branched and forgotten. I always see email to "developers" and "cc tom and steve" even though tom and steve are developers. Why? PRobably to get more attention in their inbox. Fine. But inevitably a part of the conversation will then go only to tom and steve when somebody hits the wrong reply button.
• Another problem with developer lists is that not everybody wants to know everything all the time. We already all get enough email. Plus, what if somebody who is not on the developers list is interested in the topic?
• Email ends up all over the place. I get my work email at home. Sometimes, for whatever reason, I respond from my home address - and then replies sometimes go there, sometimes to work, depending on how people reply. Or I'm at home and I want to see a particular message that I had already popped on my desktop at work - so now I'm grepping through my workstation's filesystem looking for it. A blog would centralize all that, and provide nice searching functionality.

My team has a number of large projects going at any time. If everybody project reported it's progress regularly to the "all" mailing list we would quadruple our traffic, and nobody would read anything. So instead I plan to set myself up a blog, tell people that it exists, and maintain it. If people want to read it, super. If they want to get into conversation, even better. I was gonna say "If it flops..." but I dont think it will, because at the very least it'll be a place where I can keep all my own thoughts on things and be my own braindumping ground.

Been doing it for years

[rasqual]

In our case, I wrote a little VB applet that reads an authenticated user's name, formats a header, and so forth. The app simply appends the contents of a file to the newest entry and writes the file out again -- to the share the team uses for other stuff. The file is parked on Active Desktop, and includes a refresh tag in it. Every five minutes the user gets a refresh. This has been wildly popular -- the idea being that a lot of quotidian factoids whose relevance is brief is nevertheless at least very relevant while it is, and may be relevant to some, or all of the team. They can glance at the "tickler" as we call it, and decide for themselves. It took me a while, once blogs became commonplace, to realize that we'd been doing it for some time -- without a web server.

Stupid .plan tricks

[Rufus88]

I used to be able to tell when someone was fingering me. My .plan was a named pipe fed by a shell script. The script would netstat looking for fingerd connections, rsh to the source host, "ps -aux" for finger processes, and send me the results. I'd then send email to the person, asking "why are you fingering me?".

Re:Basecamp for Plogging

[TedTschopp]

I am also a subscriber. I think the system is great. Area's of imporvement: 1. HTTPS 2. Groups 3. Protected catagories (so you can hide stuff from one group and not the other) I sent the developers a request on each item and recieved a response within 15 - 20 minutes saying that those features were in the works. I upgraded my account to a paid account at that moment due to the fact that they had responded personally to my email quicker than most companies respond with automated responses. I can't say enough of this product. It's been a God send to us at Tolkien Online. Ted Tschopp

Wiki success.

[mahlen]

In contrast, our internal Wiki (a JSPWiki [jspwiki.org] instance) grows by leaps and bounds, currently at the rate of 400 new pages a month, and typically 50+ edits a day. There was never any official pronouncement to make it so; I actually started it here just for myself.

I think it took off because it was adopted by some high-profile and prolific people, and thus "It's in the Wiki" and "put it in the Wiki" became common phrases. I think that these combined to make it the "official" place to keep vital information. Quite a few developers have personal blogs and todo lists on the Wiki. The ease of corrections and low barrier to entry have really helped people get into it, though adoption is certainly far from universal. But I've seen meetings where the principal focus seems to be editing a Wiki page until it's correct, which is a great way to arrive at consensus and publish the consensus at the same time.

mahlen