Forum OpenACS Development: Re: [dotWRK] what it should become - part deux

I'm a little late in contributing here but would like to describe my focus. Most of what I have to add is at least implicitly present in what's gone before but I'd like to make a couple of things more explicit. The background on this is that I'm currently involved in a process improvement project at work as well as an intranet prototype (OpenACS in fact) to support a complex software product and organization, and I'm wishing dotWRK were finished!

The central object of processes we're trying to improve is information. Specifically, the information is realized in the large number of artifacts that are produced and used by various work groups during the various life cycle phases of a project. I think these basically constitute what's referred to elsewhere in this forum as the "project repository" or the "document storage". But these are central, not incidental.

The artifacts we'd like to have in the project repository include RFPs, contracts, emails, minutes, requirements, designs, code modules, sources, executables, environment setups, scripts, test scripts, test results, deficiency requests, etc. There are also less tangible items such as processes, roles, tasks, schedules. These can be in the form of documents, spreadsheet, code modules, etc. They may be internal artifacts or external deliverables. They may have multiple revisions, baselined versions, released versions. They may be part of a composite artifact or identify group of artifacts -- they have structure and relationships and owners. There are processes, owners, and different repositories. These artifacts correspond to Software Configuration Items (SWEBOK term) but we're just calling them CIs (configuration items) since some aren't software.

The first point about these CIs is that they are the tangible results of work.

• Work products are the whole point of workplace collaboration and seem to be the key central objects of the entire organization.

To be explicit, nearly everything else on the intranet is related to these artifacts in some way -- creating, reviewing, approving, publishing, scheduling, time tracking, task management, departmental structure, etc. If we were finished then requirements could be traced to original sources, fixes to code modules, enhancements to functional modules, estimates to code metrics, etc, etc. The artifacts are the information. And there's a lot of them. This is almost starting to sound like an MIS!

The last point is that the intranet's reason for existence (in our view) is to provide support for workplace collaboration.

• The workgroup is the producer and a consumer of work products.

I think the concept of Workgroup might also be key and useful for dotWRK. The interesting thing about workgroups is that they may, or may not, reflect organization structure. A workgroup might be composed of strictly departmental members, or organized by product, or by client, or it might be a cross-organizational team that doesn't fall under any department or product or client. The cross-organization type of workgroup is the one that can benefit the most of all from the intranet if communication across organizational boundaries is sparse, as is frequently the case. So departments, products, projects, and workgroups may be interrelated in various ways. And of course the input for some workgroups is the output from other workgroups, etc.

I know much of this is specific to software development but it isn't all. There are contracts, requirements, designs, deliverables, documentation in non-software settings.

In summary, I'm suggesting that rather than accumulating a set of things that seem workplace-related, like project scheduling, timekeeping, expenses, holidays, document storage, etc. (all probably needed), instead choose a core concept for the center and build around that. I suggest the core concept might be work product (or a better term) which is an information asset that is the result of the work of a work group in the workplace (and supported across the entire lifecycle by dotWRK... if only!)

I like Jeroen and Roger's ideas here about work products.

For example, our company has a lot of information that we want to keep associated with a project.

In the same way that Outlook has a lot of different types of information that can be viewed throughout the inbox, I think a project should allow you to associate:

- queries on tables (our company would like to associate each product with a project, for example -- so we'd like to see a list of products in each project page).

Perhaps there could be some sort of a service contract for items that are viewed on the project page. They have to implement a certain function or something, and then they'll automatically be included on the project page...?