Project Weblog plans arise

Project Communication is a common problem. One current practice at bodyleasing or project companies are project diaries… I guess a lot of consulting dudes have to do that anyway to document their billable hours in a more or less good manner.

Of course a weblog - reachable from everywhere - is a proper solution nowadays… and it’s more than the personal diary one might keep on his notebook access application or similar…

  • Piz came across with the fab idea I guess yesterday…
  • Navigating Business with Technology by Kimberly Black talked about it last week and what I found then
  • Halma Comber proposed a project weblog specification as β€œP-Log” back awhile.
  • There’s even already a RDF vocabulary for meta-data description of a project although at the moment this seems much to technical compared to the soft-goals I have in mind for a project blog.
  • Another nice idea: CVS Blogger - Bill has the similar idea to document - well project wide I guess - all the major changes (code interfaces would be a fine idea) / fixes that various coders perform, great achievments, etc… in a blog… for some reason Bill thinks he needs a direct CVS to blog-integration while there are Viewcvs.cgi and other tools for querying CVS… and of course you could run CVS directly in a perl-shell script with Brad Choate’s plugin…

I wonder if there is anyone out there already using a project blog in his life project… - additional to defect databases, task-lists, etc…

Read on for my inspirations and comments on Hal’s specification… comments / feedback warmly welcome!

My comments on Hal’s specification of a p-log - often from an MT implementation point-of-view, but also some basic requirement comments…

The functions:

  1. Sections are like categories I guess - no need for something special if we use MT
  2. Workflow implies several functionalities:
    - user, roles and rights management - that’s not typically in Blog implementations
    - process definitions - configuration for states and the workflows on a Per-Project basis
    ( anyhow we want to use the same repository for all project blogs of a company, won’t we? so we can increase the communication outside the project aswell… and if senior management has time for reading detailled project blogs - well - why shouldn’t they?
    - to make it shorter - I do not think that defect / task-tracking can be done WITH a blog-tool, but more integrated with the blog-tool… don’t forget that the workflow of a project is typically already handled by an existing process and we are not starting at ground-zero normally…
  3. Categories was my understandig for various sections - did you mean - graphical sections for various info, so just a page-layout??
  4. Comments = OK
  5. Ratings is a great thing - we used it for a type of knowlegde management tool (KM tool) I built 2 yrs ago using Oracle Text (Intermedia) and the usage increased massively because we also created competition by publishing a rating with a rank of all users who contributed…
  6. Permalink = OK
  7. Trackback - sure, btw: why doesn’t your blog have one??
  8. Files - uploading stuff to my MT blog works fine - that’s sufficient so far, or?
  9. Images aswell
  10. Blogrolling - why not install something like Active PHP Bookmarks for the whole project or company? - the hairball *g* problem would still persist
  11. Search is a basic function for a blog - again: I guess yours would deserve an upgrade πŸ™‚
  12. Subscription services are sort of important for especially outside-people from the company or in hot phases… after all people usually read their mails, but to the frequent other virutal info-sources when it’s hot on the project? Anyhow - that’s a culture problem - I was on a death-march project with a nerd-projectmanager refusing to read/answer his mails… I would have fired him the first month… ok… back now… Subscriptions at least for normal content could be implemented in normal office software e.g. via RSS to NNTP-converters… or are there RSS to e-Mail converters out there?
  13. Notifications is a feature of MT I have not tested so far… good plan πŸ™‚

Sections - or I guess better: categories

  1. the Story is often lost in the end - good to write it down…
  2. Role description, staffing, responsibilities in addition to hopefully existing role-descriptions like Project Manager, Designer, Developer, etc…
  3. Key Project Assessments… huh!?! - do you mean some sort of Risk Management as it should be standard in high profile project methodologies? or more a task list ?
  4. a common project-calendar is probably not the issue of a P-Log - maybe an integration with some other tool might be nice - but you will always hear: β€œwhy shall I maintain more than one calendar?” and I agree.. there can be only one! and if it’s outlook, ok - why not find a way to get this data out of it automatically… But in fact the idea to present events and important milestones from the project plan is a good issue… - I guess the new MS Project Suite with it’s collaboration features could do so - otherwise extract it via ODBC+perl somehow…
  5. Issue Tracking (Defects, Tasks,etc…) shall not be topic of this β€œsofter” tool as these are real hard-facts of the projects…
  6. Agreements:::: woahh… are you talking about Requirements Management as you need it in these details for every software project that shall not be doomed to fail or explode in costs and schedule? I think this needs more focussed explanation…
  7. Project Deliverables: you are right if you mean configuration management - management of all deliverables in a version management or similar… but I don’t think it fits in here… even if each project needs it… there are too many existing solutions for that - again the integration buzzword could maybe do it…
  8. Metrics and Measures… how should the existing project tracking & controlling & measurement be integrated in the blog? hand-type-in by the Project Management - to just publish it for the senior management or do you mean a more sophisticated metrics-calculation in the P-Log?
  9. Project Documents… hmmm - sources? build-results? quality standard guidelines? how does this differ from the deliverables?

The additional sections are sort of a more detailled part breaking down above sections… comments later…

Conclusion:>

What I noticed after these comments are written is that Hal (like me) started to dream of the wonder-project management (and -planning/-execution/-controlling/-reporting) all-in-one tool a project manager could dream of… yes sir! I want that - or give me two of them… πŸ™‚

Unfortunately these massive functionality can and shall not all be handled alone by a project weblog. After all we (or I) are seeking to improve the soft factors of our projects - introduce more history, stories and storytellers… new people joining the project shall be able to dive into these stories… Good projects always had stories while worse sanctioned stories and storytellers…

Hal - please comment on these so far - and maybe - trackback-enable your blog πŸ˜‰

Tom