Proposal for a P-Log Specification
A Project Team Tool for Lean/Agile Project Methodologies
Why another Solution?
I haven't found any references to the term P-Log. Project weblog shows up in numerous citings. The idea of a free-form rich-text team-based project collaboration environment has been around for quite some time. The solutions for a persistent collected place for asynchronous communication are now viewed as an obvious tools for teams. However, we've been recreating the same environment with different programming tool sets.
The project weblog is envisioned as a team-based circumstance-driven, even idiosyncratic, environment for supporting history-making. Yes, project teams make history. Out of nothing they create something. Successful teams innovate, learn, and evolve along the way. However, success is not the usual outcome for teams. All too often teams get discouraged, drift from their purpose, are disengaged or detached from one another and their customer, and oh...then go on to something else before finishing. The p-log can be the instrument the team uses to keep their focus during the game.
What will it be like using a p-log?
A tool for the team, it's use determined by the team. History in the making...but only when recorded? Perhaps. Uncertainty is the nature of the beast. It is what makes projects exciting and challenging. Ignoring uncertainty or treating the future in a deterministic fashion is a sure path to failure. The p-log is envisioned for embracing uncertainty.
I see this as a multiple-blog blog. Different sections of the p-log would all be updated by blogging tools. This complicates the design of the p-log requiring challenges in configuration. however, it limits the tweaking and editing of html by any of the team members. Would plan for moblogging, IM-blogging, email blogging, and a usual web-based editor.
The elegance of the p-log is it's reliance on standard generally available technology. The list of functions is impressive by its usualness rather than its novelty. There is no attempt here to recreate environments such as Lotus Notes or Groove. And we certainly are not interested in this looking like a Yahoo! Group.
This is not a be-all and end-all environment. Many project environments will have standard practices that fall outside of the p-log. Construction has a practice of submittals. Software development uses a check-in check-out process. Ease of use would prevail over comprehensivity.
P-log Functions
- Multiple Sections
This is somewhat tricky with available tools. A single p-log page would be updated with blogging tools in each section rather than just one running list of postings.
- Workflow
This could be the distinguishing aspect of the p-log. Coordinating with one another is central to project performance. We make assessments (something is missing or needed) followed by a request for someone to perform. Performers make promises to deliver which others then rely as preconditions for starting their work.
- Categories for Postings
One of the key reasons for a p-log is for organization-wide learning. Categorization enhances search while creating a basis for establishing best practices and collecting new knowledge. (Need to investigate the best practices of k-logs.)
- Commenting
This is as fundamental as the posting itself. Comments must be permanent elements of the site. Would want an editing capability for correcting and purging as appropriate. Linking will be available to and from comments.
- Ratings
Provides the opportunities to engage the team in quick polls of what would be useful to them, gauge how they are doing, and to generally assess project performance. Would work in conjunction with commenting.
- Permalink
Anything else to say?
- Trackback
Teams operate to work instructions and standards which can change during a project. Knowing who has linked to a particular entry provides the opportunity for correction and investigation.
- File Repository
This is not a document management system. Fine ones are available. At the same time, there are key documents that the team will want to make readily available.
- Image Repository
This may simply be a moblog or could be separately indexed storage.
- Blogrolling
While this is standard weblog fare, it could also be a big hairball. Sharing useful references as URLs is not done well in other project environments. Would collect links in groups. Have a mechanism for enabling all team members to blogroll or to limit it to a few.
- Search within Site
Simple may be better. Google within this site might do the trick. Don't see the need for creating and maintaining indexes.
- Archiving
May need to vary by type of posting or section the posting was made. Key to have referenceable titles, categories, and authors, as well as the usual date of posting.
- Subscription Profiles
by category, posting type, comment activity, and workflow state
- Notifications
based on subscriptions
The usual case is for many authors. Some authors may be restricted as to what they can do posting for one section while others based on their role on the project may post throughout the p-log. Anyone with access to the p-log would have permission to comment. Would not attempt to manage the permissions of posting beyond what is provided by the blogging tools selected.
P-Log Sections (Basic)
- The project story
This is the novelty of the p-log. The story sits above the fold. It includes the promise(s) of the project, context, and how both change through time.
- Project Team
Individuals, roles, contact info
- Key Project Assessments
What is going well, what is not. What the team is learning, where they need to learn. The coming challenges and opportunities.
- (Up-coming) Events
This keeps the team focussed. Could be done with a visual calendar, or not. May include reports on how the events turned out. Would not be redundant to
- Issues Resolution
This would be workflow-enabled. Watching the state and promises of the issue resolution. (More to say here.)
- Agreements
Could include the big, yet specific, promises of the project. Would also chronicle how promises changed. Might serve as a change-order function for limited cases.
- Project Deliverables
Could include work structuring/packages
- Project Metrics
We would encourage the use of metrics for use by team members while playing rather than the usual stats discussed on the sidelines. In the world of project uncertainty we would stress measures of reliability. These measure would be easy to update by team members on an everyday basis. A plug-in (Javascript) could be used to display simple charts: histograms, pie charts, and spider charts.
- Project Documents
Additional/Alternate Sections for Scrum Projects (don't let me be stupid)
- Daily meeting notes
- Backlog
- Phases
Planning, Sprints, Closure
- Deliverables
- Refactoring
- Teams within Teams
Other Alternate Sections
(Anyone have a proposal?)
Technology (Give me some help here -- PLEASE)
Need to provide a robust environment. While the basic skills for building weblogs are widely available, the easy thing to do should be setting up the p-log. Skinning will be used as a configuration tool for hiding and revealing different functions (like Scrum sections) and to provide company and team identity. RSS is required particularly for project participants who work on multiple projects.
