Forum OpenACS Development: [dotWRK] what it should become - part deux
- project management
- project repository
- wbs and scheduling
- cost-estimation
- resource mgmt
- collaborative task/todo
- linked with projects
- stand-alone
- facility booking
- holiday booking
- timekeeping
- expense booking
- statistical package (?)
- calendaring
- reporting/charting
- wiki
- construct a fictious company and personas
- create a number of use-case scenarios
- use that to come up with a functional design and a datamodel
- implement.
- I kind of missed the point about the 'statistical package'. Can someone elaborate on that?
- man-time and facilities are both 'resources': they are in limited supply, sometimes available and sometimes not, etc.
- Holiday is actually a cause of unavailability for man-time. Just like 'maintenance' is a cause of unavailability for tennis-courts.
- They also have a certain unit cost per time period.
- To cut it short: perhaps we should implement the generic concept of a 'resource', of which 'man-time', 'tennis-courts' and 'meeting' rooms are special descendants.
- Perhaps holidays can be seen as 'events', just like maintenance? Can the ACS-events package do some good here?
- Reasoning this way it actually makes sense that calendar items are 'events' (a task is also an 'event' - and makes a particular (human) resource unavailable for other things!).
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.
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 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!)
The basic idea is that one defines content-types and those content-types are 'all-in-one'-packages. They define a datamodel (leveraging the cr) as well as an API and templates for using them. It's then possible to use a generic explorer-like interface to interact with them. Each time a user wants to do something with the item, the generic interface figures out what template to use (standard cr functionality) and forwards the user to that template.
However, Roger's remarks actually triggered another (variant of that?) idea. How about creating an MS Outlook like application? Basically outlook is nothing more than a tree of folders containing objects. Each folder contains a particular type of object. E.g.
- inbox: folder with only mail objects
- tasks: folder with task items (shared by a group --> collabotive todo list)
- contacts: folder with contact objects
- notes: ...
- ...
Most objects allow the user to attach other objects to it (e.g. tasks object allows files to be attached).
Folder views can be customized and there are aggregate views, like 'outlook today' that combine information from multiple folders.
It's just a rough idea - I've not yet a precise idea how I'd see this in the context of dotWRK. Perhaps as a concept for the personal portal?
Some thoughts:
-- Every user or workgroup has their own set of folders, with the content-types they need. By using queries or symlinks we can e.g. make shared todo's, defined in the todo list of the group, popup in the users personal todo list as well.
-- A projects wbs could be expressed as a folder containing 'project task items', phases expressed as subfolders. This WBS/schedule folder then can have several views (e.g. a GANTT-view or a PERT-view).
Would this pig fly?
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...?
You are right on the money, Roger. Everything in the workplace stems from work products (and that's a fit name for them as well).
At my company, the email system is expected to shoulder the burden of shuttling every work product back and forth. Revision control is nonexistant and everyone's inbox is choked with hundreds of megabytes of redundant attachments. Plus, if you weren't cc'd on the message, you won't be part of the conversation.
One would like at the core of dotWRK a repository of all such work-related data. The ability to freely organize and associate the work products into meaningful hierarchies and structures is what will make the system powerful. Ideally, revision control would be automatic and nearly transparent. We shouldn't make any assumptions about the formats that these work products will use, nor the tools used to author and interact with them.
An excellent resource for motivating this design is just about everything written by Jon Udell, especially his excellent and overlooked book: Practical Internet Groupware.
As far as setting up a demo company, I might have a usefull addition. As of next week I will start publishing a secretary handbook, 50 pages of minute business procesess of one of the Dutch secretary's in my network. It will include every aspect of day to day opeations of the Automotive department of a major european car company. The idea is to to find out how the info in this work document can be translated into OACS functinality. I have a group of 10 secreetaries onstnaly testing the ideas I come up with, (daily on-line) so that could be usefull for the project.
