Forum OpenACS Development: dotWRK: Project Manager

Posted by Jade Rubick on
Is it too early for us dotWRKers to start planning out how the Project Management package will work?

Here is some preliminary thinking about it: (and the whole thread:

My workplace is clamoring for a project management solution. Unfortunately, that means they want it right now, and I'm still on ACS 3.4, gradually porting everything to OpenACS.

So I can write it on ACS 3.4, and port it to OpenACS. However, then I'm out of step with the efforts going on with OpenACS. Perhaps I can write this as a "rough draft" of the project management package for OpenACS?

Anyway, back to the point.

1) I've looked at all the resources people have suggested for project management so far (the data model for MS Project was very interesting). Are there any other things I should be looking at?

I went to and ordered an evaluation copy of MS Project for $8. Anything else we should be evaluating?

2) Do we have a clear roadmap for dotWRK? We have the people who are on-board, we have a list of things we'd like to do, and what we're interested in working on. What happens next?

3) Here is a very very (very!) primitive prototype of some ideas I've been kicking around for the project management piece:

I'll be working on this some more, and posting updates. I'd appreciate feedback on it.

Bear in mind that this is not even a partially complete interface. I'm playing around with what is necessary to make a simple but expandable project management system.

Anyway, I'd welcome your feedback.

Posted by Caroline Meeks on
Sites we looked at before we started our project management solution were:
Posted by Jade Rubick on
I just went through the attask demo. It was extremely interesting.

Caroline, is there any way I could get a copy of the project management software Aristoi wrote? Could that be the foundation of the new dotWRK project management software?

Posted by Caroline Meeks on
We are going to try to give back as much of the reusable code and knowledge we have gained as we can over the next few months.  Our use case is pretty specialized.  Where we had trouble, had to write hacks, repeat code, and hard code ids and  the decisions we made that we later regretted are probably the most useful thing we have to give back.

I'll start by posting a description of the use case we have been coding to, as an example of a non-standard use case that does not seem to be well supported by existing out o the box software and that we were able to support using OACS.

An interesting philosophical question for dotWRK is are we trying to create a product that competes head to head with existing solutions or one that can be easily customized to meet non-standard requirements.  Or probably a better way to look at it is where on the spectrum between those two are we aiming for?

So here is a non-standard use case with a small but much greater then one company market.

The client sets up displays of seasonal merchandise for large chain stores. So the actors are:

Companies: My Client, and other similar companies that handle exactly the same project for other regions of the country.  Note it's important to keep different companies information separate as they are in competition in areas where their territories meet.

Stores: Literally thousands of different stores throughout the US and other locations, for more then one chain. Note it's important that each chain never see that a company does projects for other chains.

Manufacturers: The organizations making the products.

A "project" involves setting up displays of products produced by one or more manufacturers at many stores.

A "task" involves a "team" of workers spending one or more days doing a project at a specific store.

Where OACS has excelled at solving their problems is the ability to be both an intranet for the company and an extranet for representatives of the stores and manufacturers, giving each a custom view of the data that protects sensitive information and controls permissions to modify information.

I think this is very important as we move forward, to always think about multiple actors, insiders and outsiders, accessing the information with different views and permissions.

Also note in this case both the stores and the companies have hierarchies that effect permissions.  Store representatives may only cover some portion of the country and thus may at sometime have access restricted by region.  We want to support multiple hierarchies for both internal and external users.

Flexibility to change permissions is also crucial.  During the first two weeks after launch we refined who could do what, sometimes completely reversing, it at least a half dozen times. I think we should expect and support every instance to have completely different permissioning and work flow rules.

Dependencies:  (a few of them)
A team can't be in two places at once.
If a team takes an extra day to finish at one store all their other stores will be delayed.
Stores may have their own calendars, with inventory days where work is prohibited.

These tasks take place in physically distinct locations, which is different then what most project management software is written for.  OACS has the ability to have any object have contact info, so it's not a problem for stores to have location info.  Someday we may use the location info to assist in scheduling but we aren't there yet.

The 3.4 intranet was built by aD to support their software business. Its cool, but I think we can do better with the power of 4x and by thinking and working with a variety of use  Thus I hope that others will post their non-standard use cases so that we can write code that is at least easily modifiable to support many industries and different types of work.

Posted by Jade Rubick on
Thank you Caroline.

Even if the code isn't up to your standards, it can be helpful as a starting point.

<blockquote> are we trying to create a product that competes head to head with
existing solutions or one that can be easily customized to meet non-
standard requirements.  Or probably a better way to look at it is where
on the spectrum between those two are we aiming for? 

I propose this as a goal: dotWRK Project Management should initially provide a simple product that can be easily customized and extended by individual companies in a way that won't conflict with future upgrades. However, it should work for simple cases without any customization.

Our use case:


Employees (Sales, R&D, Graphics, etc)


Rolling out products for various customers
Typical project cycle is fairly complicated, but involves things like making the sale, then a huge mess of operations involved in getting the product to market for them. Each project involves up to 10-15 people in some way, sometimes more.
We keep track of information like which region this project is in, who is responsible for it, what products are involved, who in each department is involved, product numbers, etc... etc..

We have hundreds of projects, and are planning them throughout the year.

Scheduling of resources is a very large issue.

We don't have any particular need at the time to allow an extranet, although we have talked about it, and it is probably something we'll do at some point in the future.

We do have people in disparate locations.

We have frequent schedule changes. Entire projects can be rescheduled by months or weeks, cancelled, and brought back.

We are using the 3.4 Intranet right now, and I modified it to support our own company. A lot of it isn't being used at all. Mostly we're just using tickets, the calendar (with tickets hacked into them), time logging, and a bunch of proprietary stuff.

I've done a lot of reading these last couple of days about project management. Here are some links I found particularly interesting:

Edwart Tufte's discussion thread on project management software, gantt charts, and the issues involved in input and output. See especially the part at the end about the web-based design by Frog Design. I'd love to see that software.

Columbia's course on Project Management page. This has a great list of links for PM topics. Some of those links are really worth looking at.

For those just getting up to speed on PERT, activity networks, and critical paths:
The charts aren't great, but it does cover the territory:

One of our needs is to be able to associate arbitrary information with different project types.

For example, if we tag a project as a Graphics project, then we'd like to associate certain tables in the database with that project, and have the project page show information from those tables.

If we tag a project a Product project, then we can show information about the products.

Or something like that. I'm not sure of how to do this yet, but I think if we do something like this, we can avoid some of the problems I've seen with other PM software. It seems like because companies have such widely varying needs, something like this might be necessary in order to fulfill all of our needs.

A software company might be interested in linking in a completely different set of information for a project than a manufacturing company.

The way I see it right now there are:

Projects (and subprojects)

  Tasks (and possibly subtasks)

    Dependencies (a task is dependent on another task being completed)

  Project are broken down into Categories (may belong to more than one)


  Roles (a user can have several different roles)

There are also several views:

Task View (for each user)
Project View (for each user)
Gantt or improved-Gantt chart for a Project
PERT-like view for each project


- When a user looks at a task, I think they should be able to see what depends on it being done, and how much slack time they have to complete it.
- When planning out a new project, it should be easy for a manager/PM to move project deadlines around, add in new tasks, make tasks dependent on other tasks, and reschedule tasks.
- Users should also be able to reschedule their own tasks (sending out alerts).
- It should be easy to see the critical path in a project.

I'm just blabbering a bit about what I've been thinking of. Any thoughts?

Posted by Torben Brosten on
Regarding the simple user cases:

Here is a use case that seems commonly used in work teams, and I believe could be an initial extension  of OpenACS:

Group/Person A starts with a list  of items to do (this can be a budget, list of items to do  etc.). The list includes who can complete and sign-off each item. This list would be built and modified by Groupt/Person A

Then Group/Person B reports progress/completion on the list by entering date/time completed, perhaps actual amount spent in currency or hours. In a noncomputer application, their name would be placed in a "Done by" field.

Then Group/Person C (perhaps supervisor, inspector etc.) places checkmark on items completed (for verification). (This is an option, as sometimes group/person B has full authority/supervisory role powers)

Some lists may have items that require completion before others (dependent).By default, items are independent of each other.
--- end of simple use case.

As the dotProject increases in capability, I think it would be important to have resource lists, and be able to associate WBS reference "tags" to various OpenACS objects (so some kind of coherent reports can be generated from them).  Resources that get tied to calendar/scheduling attributes should include variations: initial, current/moving, and final value, such as date of each item, ie expected start date (initial), expected start date(moving), date started,  other options could be cost etc.. This information could be used for predicting specific  resource performance on future projects (thereby increasing predictability/reducing risk).

It would be nice to connect dotProject to schedule/calendar, but I just don't see it happening for general implementation as there are many cases to consider (in context of scalability/engineering  issues)  --but my opinion is weak here as I'm *not* an expert in OpenACS development (yet =).

Posted by Torben Brosten on
It would be nice to have some kind of way to tag some of the projects/subprojects to generate statical reports, because of the cyclic and repetitive nature of some of them.  For example, some projects might be described more as ongoing operations as part of an extended morphology of systems engineering.

Also, copy project frameworks to new instances for generating initial new projects  (templating projects)

I think  it's  important to note that subprojects/phases might overlap temporally, also (phase-in, phase-out). Something to remember when defining constaints in the data model.

ps. Everything above I've read seems fine.

Posted by Torben Brosten on
Have categories have been removed from the bboard package (?). I haven't seen it implemented at OpenACS in awhile.

The categories option could be useful as a starting model for tagging objects with WBS reference points. The software might suggest a reference (or set of) based on input. PM, supervisors etc would be able to modify any user chosen references.

Posted by Peter Marklund on
I think using the forums package and the new categories package provided by Timo Hentschel is our best option for categorized discussion forums.

I am planning to use the categories package for the Time Logger application as well. I'm hoping the categories package will finally serve our need for a site-wide-category service in OpenACS.

Posted by Jade Rubick on
Peter, I'm unable to find anything about Timo's categories package. Can you provide any more information about it, please?
Posted by Torben Brosten on
That's great news, Peter. I didn't realize a separate categories package existed. I'm going to re-read the package descriptions. I think a lot of latent dotProject functionality can be harvested from existing OpenACS site-wide packages.
Posted by Torben Brosten on
Some thoughts regarding scheduling, end-user autonomy

I think the PM/system can suggest/propose optimal periods for specific tasks done (by group/individiual), but that the final schedule should be made/confirmed individually by each participant (and changeable by them or their "supervisor").

This is important for projects that have external resource components (participating clients, subcontractors, temporary/part-time employees etc.) --and might be overlooked by organizations that tend to operate top-down authoritarian style projects. [I must do "this" because the computer says so.]

It's been mentioned before, but it's important to re-iterate:

In order to get everyone to participate fully in using the system, the system needs to cater to the end-users using it over any conveniences extended to the PM(s) (ie. respect the user--allow them the same degree of freedom as is available outside the system). This means that the system should offer users over-riding automony, even if it is at their own expense (and to the detriment of the project). The PM could be notified of such changes (or interest in changes), and address them accordingly.

Posted by Torben Brosten on
Anyone have any references we can use about GERT ( )

I think adding some of these capabilities to the PERT/CPM functions could be useful for dynamic projects where multiple outcomes or operating conditions need to be considered/managed.

Posted by Jade Rubick on
what is GERT?

Re: Torben's use case: I agree that all the items in a "Process" need not be interrelated. They could be completely independent of each other. And I agree that by default they should be independent of each other.

I'm not quite sure what WBS is.

I'm inclined to say that ongoing projects not be refered to as projects at all.

What would be examples of projects that could be ongoing? A study group? A safety club?

Torben, when you talk about connecting dotProject to schedule/calendar, what do you mean? Do you mean being able to export the schedule to Outlook/iCalendar/etc..? Do you mean being able to view it on a calendar?

Torben, good idea about cyclical or related projects. I haven't thought too much about that.

Torben, excellent points regarding catering to end-users. I think you're dead-on here.

Posted by Torben Brosten on
Hi Jade,

Let me know if this doesn't clarify things. I'm coming from a fairly abstract perspective, so I might have to write a few iterations to express myself clearly. =)

Gert is an less restrictive network diagram (PERT/CPM). From what I've read so far, Q-GERT seems to be the most popularly accepted revision, and is available as software called the same (I'm still looking into this).  I haven't found any really useful web references, though I'll be looking into some books in the next few weeks.

With Gert, some looping (repetition) of tasks is acceptable  Branching of network at sub-nodes is permitted, also. One might branch at a node, depending for example, on environmental circumstances not within control of the project: path A might be chosen over path B because C indicates A will not work (where the decision could not be previously determined). Each branch is given an estimate of likelihood for occurring (statistics based on history will improve accuracy of course).

WBS = Work Breakdown Structure.  WBS is the categorization/subcategorization of the project to tasks, before attaching scheduling and dependencies (order of implementation). Basically, the WBS answers the questions: What needs to be done to complete the project? Who will do each task?  How long is  each task (time)? What resources are required (costs, materials etc.)?

"Ongoing projects" might be better referred to as Operations Management. Based on the morphology of systems engineering I've read from Arthur D. Hall, III, senior member, IEEE ("Three-Dimensional Morphology of Systems Engineering" April 1969), Operations Management is a subset of Systems Engineering, which I believe resembles Program Management. Program here, refers to very large projects. I think dotProject should be able to apply to most any phase, whatever its called. So, for purposes of dotProject, I'd like to see "ongoing projects" or "Operations Management" applications also addressed. However, I don't think that dotProject should adopt any specific phase structure or categorization labels (though adoption of some consistent terminology will be needed).

With Operations Management, one can see how tactical decisions affecting daily operations can be expressed according to planned node branches discussed with GERT above.

Operations Management might include running a website (after it has been developed), or producing Woodstock 2003, or distributing humanitarian aid, where there's a phase-in, repetitive (perhaps daily) operation that lasts an extended period of time (arbitrary for purposes of dotProject), then perhaps a phase-out.

I imagine dotProject will have its own Calendar expressed, with connects to the WBS, with GANTT chart and network diagrams etc. And that the various players who perform tasks and manage resources will have their own calendars (that may share with other projects or their own external schedule entries). Scheduling-flow will have to be created so that the individual views affect the overall calendar, and changes to the overall calendar institute changes to the individual calendars.

Posted by Jade Rubick on
Do you think operations/ongoing projects should be treated the same as any other project?

Perhaps they should be. Some of the sources I've read have said that a project should have a definite goal and a clear measure of whether that goal has been accomplished or not.

Ongoing projects could have definite goals and measures of success too I guess.

Thanks for the comments, Torben.

What other aspects of the design do we need to resolve?

Posted by Jade Rubick on
I have a new mockup available at:

It shows one idea for an initial page.

People who only wanted to look at tasks could close the project window, and vice versa.

Processes are a set of tickets, kind of like a set of ticket templates, that have dependencies on each other.

Users can easily reschedule multiple projects and tickets, and see charts and so on even between projects.

It's rough, but it's a start. I'd love some feedback on it.

Oh, and as far as a general roadmap:

- should we work out the basic interface first
- then data model
- then do it?

That's generally how I go about it, although I am doing a lot of thinking about the data model right now too, I guess.

Posted by Jade Rubick on
Some thinking about the Task portion of dotProject:


Tasks include (among other things):

- title
- description
- assignees
- watchers (those who want status updates
- a start date, which can be entered, or it can depend on other tasks and/or the start date of the process or project.
- deadline, or it can be computed from the deadline of the project or process
- estimated number of days the task will take to complete
- estimated number of hours the task will take to complete

I think tasks should be categorized in some way, so that Tasks of the same categorization can give you information when you're entering them for time budgeting purposes.

For example, you're entering a Task to "Build a deck". The Task depends on other Tasks, like "get lumber delivery". "Build a deck" could be categorized as a "minor construction project", or it could be categorized as "Medium sized deck" or whatever. Then when you're entering a new Task of that type, in this case "Build a deck", you're given information like:

The 15 tasks in the past of this type:

Budgeted 2 days - Took 3.2 days (min 1.3, max 15, s.d. 2)
Budgeted 8 hours - Took 11.3 hours (min 3, max 55, s.d. 5)

And the default number for the budgeted amount would be 3.2 days and 11.3 hours.

- I need to do some more thinking about Processes, and how they relate to Tasks and Projects. Especially how they relate to Projects.


Different types:
- can start after other tasks starts (is this necessary)?
- end at the same time
- start when the other is finished

Any feedback is welcome. I'm especially curious how these ideas work in real practice. Anybody using project management software in their company? How do these ideas sound?

Posted by Jeroen van Dongen on
something perhaps also worth looking at is Roger Metcalfs ideas expressed here:

If I get it right he basically suggests to strongly separate the things (tasks, fases, documents, resources) from the processes or process-look-a-likes (scheduling, reporting).

As for starting with the ui and then doing the datamodel; I'm not really in favor of that.

UI mock-ups are great, to visualize what you mean. But at some point I think those need to be abstracted and turned into a datamodel before we do any real ui work.

When there is a solid datamodel in place, creating a ui on top of it is fairly straight forward. This, in combination with Rogers line of thinking, also partly solves Carolines "problem" I guess:

"""An interesting philosophical question for dotWRK is are we trying to create a product that competes head to head with existing solutions or one that can be easily customized to meet non-standard requirements.  Or probably a better way to look at it is where on the spectrum between those two are we aiming for?"""

From my point of view, 'non-standard requirements' are often in the way things are presented - to bring it closer to the window of reference of that particular usergroup. On a more abstract level, e.g. the datamodel, it's mostly the same - give or take a few extensions. Am I wrong on this one?

As to competing 'head-to-head' with existing products - don't know - if this beast does what we (or our customers) want it to do then who gives a damn about the other products? If we're desperately try to mimic e.g. MS Project Server as closely as possible, one might as well just shell out the buck to buy the 'real thing'.

On another note, I really like Jades idea of categorizing tasks in order to get statistical info that can be used for forecasting. This aspect is really usefull if you're in the business of doing a lot of similar projects. At least, as long as your not _forced_ to put each and every task in a category (like in achievo,

As for dependencies, I've never found any real good use for the "can start after other tasks starts" type. There're a number of other dependency types (see e.g. MS Project) but I'd say that the other two Jade mentioned are the most used ones.

As for seeing an operational situation as an on-going project, well, strictly by definition this is indeed a no-no, though from a practical point of view I'm very much in favor of viewing an operational situation as an 'on-going project'. Especially in modern-day IT operations, with SLA's etc. One has for a particular period, a defined deliverable. It's like running a project each month, that looks very similar to the project you ran last month.

I think Torben indeed has a good point with the 'end-user autonomy'. A thing Torben touches, and is often overlooked imo, is client-participation. E.g. I've some projects that run mostly within the clients organisation (i.e. we offer expert advice and pm-guidance, most 'real' work is done by the client). Those projects are quite small, but 'feel' very large because of the organisational distance between you and the participants (most of whom you can only address through 'middleman'), and the fact that you often work 'cross-country in an island-culture' (if that makes sense to anyone?). In those cases it would be really valuable if all participants could access and manipulate e.g. the wbs and work fairly autonomous, while allowing overall oversight at the same time.

Then on the todo list/roadmap I'd see things like:
- compile a list of functionality we need and document
  a general idea of the architecture we're looking at
  (using an imaginary company, ui-mockups etc.)
- design and implement a datamodel that supports the above
- design and implement an api to use the datamodel
- create a number of applications for the
  end-user to work with the datamodel

My 2c so far, halfway the coming week things will calm down at work and I'll have time again available for dotwrk.

Posted by Jade Rubick on
Perhaps we should categorize projects too (optionally of course), so that a yearly project could be compared somehow to the last year's project. I'm not sure what metrics you would want to compare, however.

The things I think you could get so far are:

- numer of hours worked
- on schedule, days ahead or behind.
- number of people involved.

I like the to-do list. I'll start getting to work on some of these this and next week.

Posted by Jeroen van Dongen on
Another short note - I tend to see the WBS as the ultimate basis of a project - GANTT, PERT, CT etc. are just different ways of looking at the same dataset, highlighting specific features.
Posted by Roger Metcalf on
I haven't kept up my reading of this thread but thought I post some more potentially useful links.  Steve McConnell's company Construx does training, consulting, tool development etc in this area and there may be some useful ideas or links at (free registration may be required):

Background reading could include chapter 8 of the SWEBOK

More on WBS at:
which is from:

Posted by Jade Rubick on
Building tools to support project management (has a few interesting points):

After reading this, does it seem like a good option to include risks in the projects? This could be optional, and I'm not sure if this is a good idea or not.

Posted by Torben Brosten on
Jeroen, I agree with you that the data model is worked out before the UI. I think the engineering documentation supports this perspective too, but it's a lame excuse at this point since I can't find the reference; Browsing the engineering requirements seems to indicate how central the data model is to planning. Of course, use cases help to shape it, and therefore underlying requirements of the UI also.

Developing dotProject according to existing project management software reminds me of a dog chasing its tail. Isn't our goal something greater?  There are plenty of opportunities here to create an outstanding package that's integrated into the resource pool as part of an enterprise system.  Comments I've read and heard from other PMs suggests that there is no leading canned PM software on the market; They all have significant quirks.

I agree also with "Jades idea of categorizing tasks in order to get statistical info that can be used for forecasting." This is useful when 1. doing lots of similar project 2. when using a pool of resources for lots of different projects and 3. when working on operations management "nonprojects".

Jeroen, you're right that operations management is strictly speaking not project management. However, project management and operations management are subsets of the system development cycle, and both share many MIS techniques we are discussing for dotProject.

The "can start after other tasks starts" dependency type may not be as popular as the ones Jade mentions, but it is useful in managing the system development cycle, and is consistent with starting new project phases while previous one(s) wind down (ie. clean-up tasks). Best to be thorough as possible by including this option to save having to rewrite this package due to oversight of an integral function.

Jade, you mention tracking hours, days/schedule and people. Perhaps we can generalize tracking to resource consumption, and split from there ie. time, cost, resource count (of a type such as role), and perhaps consumption of other materials/resources required (optional and able to add more choices).

Posted by Jade Rubick on
Torben, I'd like to hear more on your thinking about generalizing tracking of resource consumption. I'm not really clear on how that could/would/should be generalized.
Posted by Torben Brosten on
Hi Jade,

I'm curious about generalizing tracking of resource consumption also. =)

My mind is elsewhere right now.  Give me a day or so to transition back to this topic, and I'll have an answer for you.

Posted by Torben Brosten on

Jade, in short, you answer your own question. Your "idea of categorizing tasks in order to get statistical info that can be used for forecasting" (as summarized by Jeroen).

I also agree that:

we should categorize projects too (optionally of course), so that a yearly project could be compared somehow to the last year's project.

Categorizing projects would also be very useful for tracking project progress ie. comparing current status with the original project plan; and for improving estimates ie. comparing project plan with project performance data.

Using the proposed copy-project function mentioned earlier in this thread, a "project plan" version could be created, then copied to create an "implemented project version X", which gets revised during project implementation. Then a "final-completed" copy could be made from the terminated project.

To visualize this, for a moment, consider a dotProject database as a 2 dimensional spreadsheet (should dotProjects be so simple!). Large spreadsheets usually go through a few revisions by "copying" the spreadsheet to a new name, where an additional report-spreadsheet summarizes and compares values.

General resources tracking

The following explanation extends beyond the scope of general resources tracking. My intention is to provide context for further discussion.

A WBS does not formally have an assigned sequence of events (dependencies) within a project. Though developing an ordered list is possible in some cases. Sequential order is determined through scheduling and building the activity networks. The WBS refers to activities (action), whereas the Resource Type refers to either "action by" or "action on" objects; The only exception are labor Resource Types, which consist of skill-based action descriptions, such as "inspecting", "installing", "welding" etc.

Tracking resources by price is a way of cost estimating, where resource categories and the WBS are associated with payments (or parts thereof). For example, a construction remodeling company might write a check to a supplier for $5,000. In the books, the payment would be associated with a collection of expenditures resembling the associated itemized invoice(s). Each expenditure would then be related to a job-site, WBS code, resource type, and date purchased.

Expense Ledger
item ref   : item to             : project : WBS              : Resource type                  
20020418.5 : Supplier Corp       : SR2101  : 24.576. : FramedStructure.Windows(2.8.1) 
20020418.6 : Sub & Daughters : SR2101  : 24.576.10.1.6    : *                              

However, costs do not let you know how resources are being used compared to the project plan. Continuing the above example, installing windows may have been budgeted at $5000. The actual cost may have been $5000 with labor taking a few extra hours and using less quality materials (or maybe left out some materials or used less qualified labor etc.). Project managers need more detail.

Earned Value Analysis offers that detail. Resources are tracked by units consumed. Scheduling complies with any consumption or resource availability constraints. Labor resources are consumed by time (hours). Materials consumed by "unit" sometimes linear foot, each, square-meter etc. Machinery might be rented by the day. A fabrication company might have a start-up fee for each day's work (cost/day) etc.

Essentially, each consumption or task can be made of other consumptions and tasks. Continuing the example:

Payment ref 20030418.5 to Supplier Corp.
QTY : item absolute ref : project : WBS              : Resource type                           
  5 : 20x20vinyl window : SR2101  : 24.576. : FramedStructure.Windows(2.8.1)           
 12 : 4 x 6 headers     : SR2101  : 24.576. : FramedStructure.Windows.headers( 

Payment ref 20030418.6 to Sub-contractor & Daughters Co.
QTY : item absolute ref    : project : WBS              : Resource type                  
5   : 2 hrs install window : SR2101  : 24.576. : house.labor.carpentry(2.3.4)
0.5 : window inspect       : SR2101  : 24.576. : house.labor.inspection(2.3.19) 

"item absolute ref" could refer to a line of a bill of materials ie. bill of resources which could consist of other "child" bill of resources --this option is especially useful for manufacturing project management and product development.

Using Earned Value Analysis, various useful reports can be made based on WBS, resource usage (by category), and project. One can track schedule, costs, and budget variances to manage projects. Deviation from any of these 3 can significantly affect the project.

The WBS is likely to vary in depth (resolution) --depending on the level of detail of each job(project) --which varies by price, size and other factors. So, reporting should be able to provide statistical analysis at choice depths. For instance, some remodeling jobs might be replacing nonstandard windows with standard windows. "Standard windows" might be one categorization. "Custom windows" might be another categorization. Labor would be a resource associated by WBS, resource category/task/role, and project. For estimating purposes, it might be useful to know the rate for replacing all windows, versus installing windows in new installations. Collecting this flexible level of data can help answer these and many other questions while not compromising operational demands.

With PERT, resource scheduling is priority; Schedules are built to minimize the critical path (and time) resulting in fastest completion time of project.

If project performance is higher priority than speed, other heuristics can be used to determine resource allocation. The "minimum slack first" prioritizes by ordering activities with least amount of slack first. Secondary sort is commonly "shortest task first". Some researchers (references follow) conclude this sorting method is most consistent in finding "best" allocation of resources, while minimizing scheduling delays, and resource scheduling conflicts for other projects.

  • Fendley, LG "Towards the Development of a Complete Multiproject Scheduling System" Journal of Industrial Engineering. Oct 1968
  • Kurtulus, I and EW Davis. "Multi-Project Scheduling: categorization of heuristic rules performance." Management Sci, Feb 1982.
  • Kurtulus, I and SC Narula. "Multi-Project Scheduling: Analysis of Project Performance" IEEE Transactions on Engineering Mgmnt, Mar 1985.

PS. At some point it would be helpful to have dotProject (and the categorization package) include ability to import/export categorization trees via xml or soap.

the data model

Analyzing the general resource tracking, I see 3 separate categorization trees: Project, WBS, and Resource Type --each built from top-down, with increasing detail or depth-- and a bill of materials (BOM) tree --where part A is made of parts B, C, D and labor E and F.

At first, I was really concerned how the 3 separate categorization trees would impact scalability for dotProject. However, since these lists remain fairly stable over time, I think each of these trees can translate to a simple table with columns: reference, reference title, and perhaps reference abbreviation --if needing to integrate with existing alternate reference system.

Project categorization table example
Reference : Title
1         : planning
1.1       : progress, rev.0
1.2       : progress, rev.1
1.3       : progress, rev.2
1.4       : final

WBS table example
Reference   : Title
1           : Super WBS
1.1         : Construction WBS
1.2         : Space Shuttle WBS
1.3         : Open-air production WBS
1.24.576    : Job SR2101 Remodeling WBS
1.24.576.10 : renovate exterior walls

Resource categorization table example
Reference : Title
1         : Other, Super catch-all
1.2       : House
1.2.8     : FramedStructure   : Windows : headers
1.2.3     : labor   : carpentry  : inspection

The BOM's tree could similarly convert to a flat table, for example as engineering design phases out and production/assembly is phased in. Of course, many projects wouldn't generate a BOMS tree anyway, but it's value in dotProject would be significant.

These general ideas apply to a majority of projects I have encountered. I believe they are applicable to many others too. Please let me know if I haven't presented this clearly, as I think careful consideration of these topics now could significantly reduce changes to dotProject later.

Posted by Nick Carroll on
I've scratched out a datamodel that I am currently experimenting with.  It's very similar to what Torben was describing.  Fundamentally, my datamodel consists of four tables: Projects; Tasks; Historical Tasks; Resources.  There should be an "assignments" table, but I can't distinguish this from "tasks".  Would someone be able to tell me the difference between the two?  As there could possibly be a fifth table.

The Projects table only consists of high level project data, such as project name, manager, start dates (planned, baseline, actual), end dates, description, parent project, etc.  The parent_project column suggests that each project can only have one parent if they are a subproject, and will reference the parent project's project_id.

Each row in the Tasks table describes a task.  Each task will reference a project_id from the Projects table.

The Historical Tasks table contains old task data for a specific task in the Tasks table.  Everytime a task gets updated in the Tasks table, the old data will be inserted into the Historical Tasks table.  By keeping historical data, we are able to compare the baseline data to the planned data.  As well as provide for some other interesting metrics.

Similarly, each row in the Resources table describes a resource.  Resources are used to get a task done, and will therefore reference a task_id from the Tasks table.

I have spent the last week coding a package that I have dubbed "Projects".  It's basically the Project Repository of a much larger Project Management system.  So far I have the Projects table included in this package.  I am using the ACS Objects approach, and as a result my code has been heavily influenced by the Notes package.  I am not sure if the Tasks and Resources table should be part of this package.  Or in separate packages, where the Tasks package depends on the Projects package, and the Resources package depends on the Tasks package.

I'm leaning towards including all tables in the one package.  Other packages will therefore be considered as "Project Tools", and provide different UIs for presenting and interacting with the project data (eg Scheduler, WBS, Gantt all similar but presented differently).


P.S  Would it be possible to start a dotWRK discussion forum similar to the dotLRN forum?  I didn't realise this thread existed till today.

Posted by Jade Rubick on

1) Could you post your data model somewhere once it's in a state we can look at? I think agreement on the data model is a good first step for this project.

2) I'm now usually against creating new Forums for new topics, but I think it makes sense in this case. It would make it much easier to sort through the postings and figure out what is dotWRK related. Those posting have a much higher priority for me.

Posted by Torben Brosten on
Hi Jade,

I think there is no need for implementing a separate risk assessment package at this point.

With GERT built into the system, risk assessment can be added fairly easy using the generic planning tools we are discussing.  With PERT, one might have to treat each risk assessment as a series of separate subprojects, but it's still workable within the system as discussed.

Posted by Peter Marklund on
will you somehow be using the bug-tracker application that also functions for general task management / ticket tracking to manage project tasks? I think it's a really fine application, based on the new powerful workflow service, and it would be a shame if we didn't make the most use of it.
Posted by Jade Rubick on

I'm curious whether it makes sense to use the bugtracker or not.

We could definitely extend it to do the job, but it's not going to work without some changes (as far as I can tell).

Dependencies will need to be added, for example.

Also, I think for a corporate setting, other ways of viewing your Tasks may be necessary. The google style interface is fine and intuitive, but we're going to need to work on some Tuftesque dense information per unit area type interface issues.

Bugtracker might be the best place to start, though. I've heard good things about the code, and it seems to work well.

Also, I imagine using workflow is a good idea. I'm still not totally clear how it works, though. We'll all probably need to read the documentation on the new workflow package, as see what it does for us.

Posted by Nick Carroll on

I was planning to use the new workflow system.  However I am not sure where it will fit in at this point in time.  I must admit I haven't used either of the workflow or bug tracking packages.  I would appreciate any suggestions of how we can tie these packages into the system.


Posted by Nick Carroll on

I will upload the package I'm working on as soon as I have something working.  Its just a simple package that allows a user to create a project and subsequent subprojects, and display the resulting project breakdown structure in a table.  The aim behind this package is to demonstrate the datamodel, nothing more.


Posted by Andrei Popov on

I know that it was ditched a kzillion times, but is aD project-tracker really such a pile of manure that nothing could be re-used?

I have tried (never finished) to port it to Pg about a year ago, it was extremly limitted (aking more to what bugtracker does, rather than proper project mgmt), but stil...

Just a €0.02...

Posted by Jade Rubick on
If anyone has time to look at project-tracker, it is here:

Posted by Andrew Piskorski on
The aD Project Tracker package? Actually, I don't remember ever hearing any evaluations of it at all, either good or bad. Anyone have links to any old threads about it? Oh wait, here are a couple posts I found in search, and they and their threads do seem fairly negative about project-tracker: Dec. 2001, May 2002
Posted by Andrei Popov on
For one thing it relies on old acs-workflow to do the job.  With acs-workflow out of OACS, porting it a lot less feasible.

Like I said, it does not do much, really.  It has (had) a general "vision" of becoming an MS Project-like thing, that never came to life.

Posted by Jeroen van Dongen on
Nick (and others),

With respect to the four 'tables' - aren't those actually four 'object types' or 'content types'? I.e. what I'm hinting at would it make sense to model them as content-types, leveraging the CR (trees of objects/workitems ...) ?

What I'm currently (still) playing with is the idea, and implementation of it, of having something like 'file-storage' but then for any content-type. I won't go into details now - as soon as I've something that looks and feels like what I've in mind (it currently looks mostly like a nice demo of acs exception traces 😊 I'll post a demo-link.

Posted by Caroline Meeks on
Lars gave a  tour of the Workflow package in Copenhagen and I definitely think its the way to go for managing Task and project and task state (ie open, closed, awaiting approval).

I think we can also use Workflow to help audit tasks and keep historical task data without requiring a separate Historical Tasks table.  We should look at how bugtracker keeps track of historical data and try to follow the same pattern.

My understanding was that workflow was the engine behind Bug Tracker and had most of the reusable pieces. I think that Lars' vision is Bug Tracker is workflow implemented for bugs, and that similar applications, like project tracking, would be a separate packages that implement workflow in another specialized way.

Posted by Peter Marklund on
I am convinced that Bug Tracker is the place to start for managing tasks within .WRK project manager. I think the application represents the state of the art in OpenACS development right now. .WRK not using it would kind of be the equivalent of .LRN not using the forums application for discussions.
Posted by Jade Rubick on
After reading Peter and Caroline's postings, I for one am completely convinced 😊 That seems a good route to go.
Posted by Caroline Meeks on

I really like the new Bug Tracker and Workflow and definitely agree that is the technology that should be the starting place for any project management package. I'd like to learn more about what the difference between starting with Workflow and starting with Bug Tracker means. I haven't looked deeply at Workflow and Bug Tracker yet, can you help us understand what functionality is in which package?

Is your vision one of the following?

  1. The Project Tracker package would have dependencies (built on top of) both Workflow and Bug Tracker
  2. One package that could be configured as either a Project Tracker or a Bug Tracker
  3. Two similar packages; Bug Tracker and Project Tracker, and both depend on Workflow
Posted by Peter Marklund on
the Bug Tracker package can be configured to function as a task manager (yes the package name is now misleading). The workflow for these tasks is configurable.

Now, a projects has a set of tasks, so any new Project Tracker package would depend on the Bug Tracker package as it would use it for task management. The Bug Tracker depends on the Workflow package.

The Project Tracker package could also have a direct dependency on the Workflow package as project objects could be associated with workflows (i.e. a project goes through various stages).

Other types of objects mapped to a project object could be associated with their own specific types of workflows.

Posted by Nick Carroll on

Each table is an object type.  I'm actually having problems writing a tcl procedure that recursively pretty prints the structure of the projects and their respective sub-projects. eg...

Project A
    Project A1
        Project A1.2
    Project A2
Project B
    Project C

When I display the page that calls this procedure, the whole OACS application crashes.  The algorithm looks sound, but its probably due to poor tcl coding.  Haven't used the upvar command... not sure what it does.  I've seen a few recursive examples that use this though.


Posted by Ola Hansson on
Nick, you may find it easier to let the db (and templating system) do the indentation work for the visual tree structure, rather than to let the Tcl layer do it. I believe that's what you're trying to do.

set indent_pattern [parameter::get \
			-parameter IndentationPattern -default " "]
set indent_factor [parameter::get -parameter IndentationFactor -default 5]

db_multirow projects select_projects {*SQL*} {


select   item_id,
	 repeat(:indent_pattern,(tree_level(tree_sortkey) - 5) * :indent_factor)
	 || project_name as indented_name
from     projectsx
order by tree_sortkey

The above example should yield a result similar to your snippet, with proper indentation depending on hierarchy etc.

(My query is based on the CR and queries the 'content_type'x view, which does the proper joins for you so that you get the tree_sortkey. The idea is similar for acs objects only you'll have to do an explicit join against acs objects. *I think*)

Or did I miss something...?


Posted by Nick Carroll on

How do you create the hierarchy in the first place with acs_objects?  As I haven't implemented this part using acs_objects.  I was planning on doing this myself with a "parent_id" column in the projects table.  Are you meant to manipulate the tree_sortkey in some way?


Posted by Nick Carroll on
I've just read up on the acs_content_repository package, after reviewing previous postings.  I also agree that this is the way to go.  From my understanding it extends on acs_objects, and does what I intend to do anyway.  Just need to make the necessary modifications to use the CR api instead of the acs_objects.


Posted by Jade Rubick on
Some more thoughts about project management:

Tasks should allow you to enter either (your choice):

Estimated completion time
Optimistic, Estimated, Pessimistic completion time.

This will allow us to create PERT or CPM charts, depending on what they enter. We can also compute confidence intervals (which as far as understand it, is the chance that we will meet the projected deadline).

Should tasks be hierarchical?

It seems to me that it might be nice to provide a "Breakdown" option on tasks. That way, either the project manager or the individual concerned can break down a Task into several smaller Tasks. It would be nice to have the option to progressively break down a project into smaller and smaller pieces of work.


It looks like it's kind of standard practice to break down the Tasks using a decimal place system, where the number of the task shows the hierarchy of the tasks. So I guess having tasks hierarchical does make sense.

For example, 3.2.5 is a Task that is a subtask of 3.2.

However, at the company I work, I seriously doubt that people would accept numbers like 132.417.3135.31 as a unique identifier for a Task.

We use tickets currently, and people really like being able to refer to it by a number. They even use the number in ways I didn't forsee, like using it to keep track of what's being sent out to customers. I'd personally much prefer a unique identifier on each ticket to a long code. Perhaps that can be optional as well? Who would want the longer codes?

Projects and Tasks

I toyed with the idea of having these be the same thing. I don't think it makes sense, however, because there's going to be information about a project that you wouldn't need to keep track of for Tasks. I think.

What would some of that information be?

Deliverables - could be in both
Goals - could be in both
Team members - could be in both
Territory (northeast, northwest, california, etc) - not in both.

Hmmm, I'd like to hear other people's thought on this. However, right now it seems like it's not a good idea.


There seems to be some disagreement in the field about whether to have WBS be a list of deliverables ("nouns"), or a list of activitiess and their dependencies.

I think we should allow flexibility either way. Our company probably will want to break everything down and build the dependencies right away. Others might not. I'm not so sure how hard or easy this is going to be to do.

Individual member goals

Team members:
- I'm scheduled for more tasks than I can accomplish today. I want to know which task is most critical. Which tasks affect other people (critical path), and which ones have hard deadlines?
- I want to be able to see my schedule for several months out, and see if I'm over or underscheduled at any particular time.

Managers and Project managers:
- When I'm scheduling the tasks of a project, I want to make sure I'm not overscheduling an individual team member. I want to see how an individuals' scheduling will affect my deadline date.
- I also want to see who's doing what on a project, and if it is on schedule. I'd like to know how likely it is we'll meet the deadline. I'd like to know if there are any problems that I need to address.


Do we want to separately track important dates and milestones? I guess these should just be tracked as part of the WBS.

Scheduling again

We're going to eventually need a calendar tie-in. What about holidays, for example? They are going to affect the scheduling of Tasks, and affect deadlines, etc.. Also, what if a person goes on vacation?

Here are some listed cons to MS Project

(from the project management class link earlier)

- Illusion of control
- Workgroup features ok, still in-progress
- Scaling
- No estimation features


And we're in agreement that we're going to use:

- content repository
- workflow / bugtracker


Posted by Torben Brosten on
Hi Jade,

Here's my two bits, given my varied project management experience dealing with external client projects.

Should tasks be hierarchical?

Yes, the smallest WBS unit is essentially a task or resource unit. Some tasks consist of a host of other tasks, and therefore the WBS. Given that the resources (labor and materials) are classified hierarchically. Tasks are essentially classified hierarchically by WBS and Resource classifications.

"I seriously doubt that people would accept numbers like 132.417.3135.31 as a unique identifier for a Task."

I haven't found an external client who uses the x.x.x.x reference(though we do internally).  Still, its the most flexible system that's worked for all cases I've come accross. I actually thought I addressed external references above, but  it  looks  like it didn't make  it to the message from my draft. =(

The reference tables (WBS and Resource categorization) can (and most likely will) include a third column that represents the custom reference system. Usually this is an existing reference system that people are used to using, and perhaps has some logic beyond the WBS. For instance, in a manufacturing company, a part "3507" might have many variations. "A3507" might be the assembly. "3507" might be a welded part (of some other parts). There might be other parametric variations such as "A3507-150-6" that might mean cut to 150 cm and meeting number 6 standard specs etc. etc.  These can all be represented as the WBS "title" for each node.

The third "title" column for each hierarchical reference allows dotProject to work within most any existing framework.
Projects and Tasks

These are considered different animals. A project consists of tasks, and a "program" consists of many projects. Tasks are unit-based, and do not generally have the granualarity within the same project environment or else they would be  projects in their own right.

WBS is a "to do" action list according to James P. Lewis, a pm expert.

The deliverables (measured milestones) are handled in a separate tracking list.

I don't have a clue which package(s) can be used for starters (yet).

Posted by Torben Brosten on
I'll restate Projects and Tasks, because I wasn't completely accurate in my previous statement:

Projects and Tasks

These are considered different animals. A "program" consists of many projects. A project consists of smaller projects or tasks.  Tasks can also consist of other tasks.  Resources consist of the lowest level of tasks, and materials, and may also consist of higher-level tasks (if not subdivided further by the WBS for a particular project).

There is some ambiguity depending on how one defines these terms --clients I have worked with have defined them differently and sometimes completely opposite of each other. For example, one client's "task" might be another's "process", or "procedure"; And one's "job" might be another's "project".

At some point soon, we should set some general definitions for dotProject so we can be clear on what we're talking about.  The actual name shown in any displays and reports (I call them Titles) should be defined on a "package mounted" basis (to keep them consistent within a project system).

In the lowest WBS resolution, tasks are unit-based (as defined in the resource table).  They generally do not have the granualarity of a project within the same project environment or else they would be projects in their own right, and consisting of more specific tasks.

Hopefully, I have the terms straight this time.

ps. Lewis refers the WBS more precisely as a "list of activities" ("Project Planning, Scheduling, and Control", 3rd Ed.c2001.)  From a complete WBS, the PM continues by adding material resources and creating scheduling networks for estimating...

Posted by Jade Rubick on
Any progress recently on dotProject?

I think I'll make a couple of separate posts, to keep my ideas separate.

First of all, I think time-logging is an important part of this whole thing. Our company uses logged time for billing, and we also like to make reports of the outcomes, etc.. We're using the old ACS based timelogging.

Peter, could you share with us your time logger?

Posted by Jade Rubick on
I think the next item on our to-do list is developing a data model. Several people have said they're working on this, but apparently have not gotten to the point where they feel comfortable sharing their work.

My standards are pretty low for sharing work (so this is a little sloppy), but it might move the conversation along a little bit.

First, some caveats:

- I didn't tie things much into the object system. Of course we would do that, however.

- I have not yet added the following
  * workflow
  * content repository
  * constraints with pretty names
  * etc..

- this is just a dirty data model for discussion.


-- packages/dot-project/sql/postgresql/dot-project-table-create.sql
-- @author
-- @creation-date 2003-05-07
-- @cvs-id $Id$

-- use categories package to keep track of types of projects

-- use categories to keep track of the status of the project too?
-- closed projects, research projects, in-progress projects?

create table dp_project (
    project_id        integer
                constraint dp_project_id_fk
                references acs_objects(object_id)
                constraint dp_project_id_pk
                primary key,
    -- for subprojects
    parent_project_id      integer
                references dp_project,
    title              varchar(255)
                constraint dp_project_title_nn
                not null,
    goal                varchar(4000),
    description         varchar(4000),
    start_date          timestamptz,
    end_date        timestamptz,
    ongoing_p        char(1) default 'f'
                constraint dp_project_ongoing_p_ck
                (ongoing_p in ('t','f'))

-- could be called project template

create table dp_project_plan (
    -- contains all the items project does, and perhaps a few more.
    -- can be copied to make a project.
    -- hmmm, they should then be categorized as having come from that
    -- template

-- slack time be always computed, and therefore not in the data model?

create table dp_task (
    task_id        integer        primary key,
    parent_task    integer        references dp_task,
    description    varchar(4000),
    -- dates are optional, because it may be computed in reference
    -- to all other items
    start_date    timestamptz,
    end_date    timestamptz,
    deadline    timestamptz,
    estimate_hours_work    number,
    estimate_days_work    number,
    -- these are used for PERT type charts, optionally
    estimate_hours_work_min    number,
    estimate_hours_work_max number,
    estimate_days_work_min    number,
    estimate_days_work_max  number

-- use ACS groups to make the roles of various users, or use roles?
create table dp_role (
    -- description of roles (manager, etc..)

create table dp_task_assignee (
    task_id        integer        references dp_task,
    user_id        integer        references person
    role_id        integer        references dp_role

create table dp_task_dependency_type (
    dependency_type_id    integer        primary key,
    description        varchar(200);

-- would add in start_to_start, start_to_finish, finish_to_start,
-- finish_to_finish

create table dp_task_dependency (
    task_id        integer        references dp_task,
    parent_task_id    integer        references dp_task,
    task_type    integer        references dp_task_dependency_type

-- processes are templates for a set of tasks. For example: deploy website.

create table dp_process (
    -- not defined yet

Posted by Jade Rubick on
There is a very interesting post by Gordon Fuller on the Ask Edward Tufte forum on the usefulness of Gantt and PERT charts:

He asks the question: is it important to see the relationships of all tasks, or only the ones where problems are occuring?

It seems to me that he's making a very good point. Instead of showing all the tasks, and how they relate to each other, we should show what is most important:

- the critical path is important
- when looking at an individual task, the dependencies of surrounding tasks are important
- when looking at lots of projects at once, you don't care about individual tasks as much, unless there are problems.

Perhaps a better Gantt chart would show a project at once, with some sort of annotation showing tasks that are problematic (overscheduled, have no slip time, are behind schedule, have not been started even though they should be by now, etc..)

This may be something to think about later as we design the views for dotProject.

Posted by Torben Brosten on
Jade, I think it's fine to be working on the data model. We should also be refining the roles and their use-case scenarios, so that we can be certain that the data model will support each role's expectations according  to role perspectives and environments.

You ask: use categories to keep track of the status of the project too?

Yes and no. "project status" as a declaration, yes. This project is set at the "X" mode: pre-start, active, final, active-revision 2 etc. --realizing that each category has a separate set of data, so that project data can be used for simulation and analysis by stakeholders. I think the categories package would not track project status for the majority of roles.  Instead, each project would have a "stated" project-status. The chosen declared status would dominate as the current project that all scheduling and other actions would interact with. Otherwise, imagine the confusion as participants try to figure out how to associate resources and materials to multiple versions of projects?

We should start a list of defined terms. Meanings will change somewhat within roles, so we'll need to note any context. For PMs, I expect a "project status" to include some indexed based numbers and trend charts --information that helps a PM determine status --in addition to the PM declared status.

Looking at your honorable datamodel start, I am not sure about the separation of time and day time-units. I don't know about the performance implications from a scalability perspective, but I would think time calculations would be faster if a numerical date were used (assuming timestampz fits) where whole units are days, and hours-units are 1/24th day, much like spreadsheets. Perhaps the alternate of representing everying in fractional seconds is fastest from a machine perspective? In any case, relative times would be represented numerically in the same units or as a percent. As long as it's consistent, relative values can be  added to absolutes etc. as needed.

You ask:  slack time be always computed, and therefore not in the data model?

I envision slack time requiring two fields: a relative time-value (RTV), and a calculation field. For simple projects, the calculation field might default to 20% or something. The RTV would only be recalced on trigger of a change in the calc field or the time estimate.

You ask: use ACS groups to make the roles of various users, or use roles?

As I understand it, ACS groups handles permissions only. Even if I am wrong with that assumption, I expect there will be some additional data modeling needed for task-roles, where task-roles have resource and labor qualities.

I think you're on target with the suggestion of creating views that highlight different priorities. Let's define the role types etc. then work on the output objectives.

Posted by Jade Rubick on
*** Use categories for project status?

I think we also need to look into workflow here. I think this is exactly what workflow is for (managing the states between transitions). Otherwise, I think we could create a project_status table to store all the possible states of a project, and perhaps another table to store the valid transitions or something like that. The ACS 3.4 projects allowed you to arbitrarily set the state of the project.

Torben, I think another part of what you're saying with project status can be said another way: there are stages to a project, and those stages should be properly broken down into sub-projects, so that information for each stage is kept distinct. There might be documents attached to the Requirements sub-project, for example. But this should be determined by the project manager. It's their choice of how to break things down.

But I also might be missing what you're saying here.

What I'm thinking with project status: it's just a tag. Let's say your company decided the valid status values for a project are "Planning" "In development" "Completed". Then any project would need to be in one of those three values.

We can do this either with a separate table or with workflow. I haven't looked very much into workflow yet.

*** Terminology

Can we get an edit-this-page instance set up with a "terminology" page? If I'm given write access to this, I'll maintain it.

*** Day and time units for estimates

Torben, I think what you're suggesting is using timestamptz instead of number for the day and time estimates in dp_task.

The reason I separated the day and time units for Task Estimates is this:

Imagine you have a task that you think will take three days to accomplish, but only 2 hours of real work. The reason for that might be that it is a painting job, and you have to wait a day in between each painting to let things dry. This is a contrived example, but not unrealistic, I think.

How would you suggest improving this? I'm not really clear on what the alternative is.

*** Slack time

I'm not clear on what RTV is (relative time value).

If the person enters the low and high estimates of how long they think the task will take to accomplish, the slack time could be calculated.

*** It looks like we'll need to define Project Roles as a table.

I've added this into the data model, and put in some comments about implications of the way I have it set up now. I would welcome comments on proposed changes to this.

*** Changes to the data model (it's not my data model any more! 😊

- I took out deadline for dp_tasks. It didn't make sense, since end_date was already present.
- added in a table to keep track of users' project roles.
- I copied a lot from Nick's data model

*** Re: Nick's suggestions for the data model

In projects:

Is the owner the person who creates the project? If so, this is already created using the object system. Is there is another reason for having this? Same point with author. Also, I think author should refer to the users table.

I suggest we name all the tables with a prefix (whatever we decide on), to avoid namespace collisions. I've used "dp" (for dotProject), but we could use whatever the community agrees upon.

Category should probably refer to another table, not just a varchar. Actually, we might be able to take it out entirely. We'll need to look at the categorization package.

Company should refer to a company table. Good point. Should we build this from scratch? I know Jon Griffin has done some related work. See and look at his organizations package. It's still version 0.1d, so I'm not sure if it's a good idea to build on top of it or not. But if he's planning on building that out better, then perhaps we can just build on top of his Organizations package. That would give us things like Vendors, Customers, etc...  If we decide to go with that, then we'll refer to the organizations table. I'll do that in the data model I'm working on.

Status date refers to the date that the status was most recently changed?

I'm not sure about putting manager in the project table. The implication of this is that there can only be one manager per project. I'm not sure if this is flexible enough. Do we want the ability to assign more than one person to a project?

In the ACS 3.4 Intranet, you had to explicitly assign people to be a part of a project. Then you assign people to tickets to do things associated with that project. I think a better way to do it would be that anybody assigned any Task on a Project would be on the project.

Do we then need a mapping of "which users see which projects"? Maybe so. I'll put that in my data model...

I'm not sure what "subject" does.

I also don't really understand what these are:

hours_per_day        integer,    -- 0 to 24
days_per_month        integer,    -- 0 to 32
week_start_day        integer,    -- 0 to 6
year_start_month        integer,    -- 0 to 12
hours_per_week        integer,    -- 0 to 168

I like the division between planned and actual. Very good idea. I'll add those to tasks as well, so we can track how much time versus actual time.

Not sure what planned_work means, especially as an integer.

I haven't been thinking much about cost and resource tracking yet.

Not sure what baseline means:

    baseline_start        DATE,
    baseline_finish        DATE,
    baseline_duration        integer,
    baseline_work        integer,
    baseline_cost        integer,

Should we put the amount of remaining work to do in the data model? Or should that be computed based on the Tasks yet to be completed?

What is acwp, bcwp, bcws?

I'm not sure what you're doing with these:

    start_variance        integer,
    finish_variance        integer,
    cost_variance        integer,
    early_start            DATE,
    early_finish        DATE,
    late_start            DATE,
    late_finish            DATE,

Do we put these in the data model, or compute them?

    total_slack            integer,
    free_slack            integer

*** Response to Malte's comments: good idea about allowing more than one organization to be associated with a project. There could in fact be several, especially for complicated projects. Also, for example, there might be a separate distributor and manufacturer, for example. So, let's separate those out.

I'm not sure about how to break out the timing as you suggest. Any more concrete suggestions?

*** Regarding Dave's comment: I think we will need a calendar package to be (re)written. Eventually, all of this stuff will need to have several views, one of which is a calendar.

I'm going to work on the data model a little more, and then post a revised version. I might post it on my website, so I don't have to clutter up this forum with every revision.

Posted by Nick Carroll on
This is what I have for a projects object...

-- Project repository datamodel.
create table projects (
    project_id                  integer
                      constraint projects_id_fk
                      references cr_revisions on delete cascade
                      constraint projects_id_pk
                      primary key,
    owner_id            integer
                constraint projects_owner_id_fk
                references users(user_id),
    project_name        varchar(250),
    author            varchar,
    category            varchar,
    company            varchar,
    status_date            DATE,
    manager            varchar(250),
    subject            varchar,
    hours_per_day        integer,    -- 0 to 24
    days_per_month        integer,    -- 0 to 32
    week_start_day        integer,    -- 0 to 6
    year_start_month        integer,    -- 0 to 12
    hours_per_week        integer,    -- 0 to 168
    planned_start        DATE,
    planned_finish        DATE,
    planned_duration        integer,
    planned_work        integer,
    planned_cost        integer,
    actual_start        DATE,
    actual_finish        DATE,
    actual_duration        integer,
    actual_work            integer,
    actual_cost            integer,
    baseline_start        DATE,
    baseline_finish        DATE,
    baseline_duration        integer,
    baseline_work        integer,
    baseline_cost        integer,
    remaining_duration        integer,
    remaining_work        integer,
    remaining_cost        integer,
    acwp            integer,
    bcwp            integer,
    bcws            integer,
    start_variance        integer,
    finish_variance        integer,
    cost_variance        integer,
    early_start            DATE,
    early_finish        DATE,
    late_start            DATE,
    late_finish            DATE,
    total_slack            integer,
    free_slack            integer

-- Procedure new project
create function project__new (varchar, integer, integer, varchar, timestamptz,
                              integer, integer, varchar, varchar, varchar,
                              varchar, varchar, varchar, varchar, varchar,
                              varchar, boolean)
returns integer as '
    p_project_name    alias for $1;
    p_parent_id        alias for $2;
    p_item_id        alias for $3;
    p_locale        alias for $4;
    p_creation_date    alias for $5;
    p_creation_user    alias for $6;
    p_context_id    alias for $7;
    p_creation_ip    alias for $8;
    p_item_subtype    alias for $9;
    p_content_type    alias for $10;
    p_title        alias for $11;
    p_description    alias for $12;
    p_mime_type        alias for $13;
    p_nls_language    alias for $14;
    p_text        alias for $15;
    p_storage_type    alias for $16;
    p_is_live        alias for $17;

    v_item_id        integer;
    v_revision_id    integer;
    v_item_id := content_item__new (
    p_project_name,        -- name
    p_parent_id,        -- parent_id default null        ->null
    p_item_id,        -- item_id default null            ->null
    p_locale,        -- locale default null            ->null
    p_creation_date,    -- creation_date default now        ->now
    p_creation_user,    -- creation_user default null
    p_context_id,        -- context_id default null
    p_creation_ip,        -- creation_ip default null
    ''content_item'',    -- item_subtype default ''content_item''
    ''project'',        -- content_type default ''content_revision''
    p_title,        -- title default null            ->null
    p_description,        -- description default null        ->null
    p_mime_type,        -- mime_type default ''text/plain''    ->null
    p_nls_language,        -- nls_language default null        ->null
    p_text,            -- text default null            ->null
    p_storage_type        -- storage_type                ->text

    v_revision_id := content_revision__new (
    p_title,        -- title
    p_description,        -- description
    p_creation_date,    -- publish_date
    p_mime_type,        -- mime_type
    p_nls_language,        -- nls_language        ->null
    NULL,            -- data
    v_item_id,        -- item_id
    NULL,            -- revision_id
    p_creation_date,    -- creation_date
    p_creation_user,    -- creation_user
    p_creation_ip        -- creation_ip

    insert into projects (
    project_id, owner_id, project_name
    ) values (
    v_revision_id, p_creation_user, p_project_name

    if p_is_live = ''t'' then
      PERFORM content_item__set_live_revision (v_revision_id);
    end if;

    -- Change admin to manager?
    PERFORM acs_permission__grant_permission (

    return v_item_id;
' language 'plpgsql';

Should have posted it up earlier, but have been busy with other projects.  The datamodel isn't complete, which is why I haven't released anything.  But I guess some feedback would be useful before I make any further progress.


Posted by Malte Sussdorff on
Hello Nick, thanks a lot for posting your data modell. I do have some annotations though.

- You define a status_date but not a status. Is there a reason ?
- You define manager as varchar. Shouldn't the manager of a project be part of the system and therefore reference the user.
- Who is the owner of a project vs. the author, vs. the manager
- Categories should use and reference the category package
- Company should reference a seperate company table, which includes more information about this company (e.g. contact information). Good question whether we would like to replace company with sponsor or external_contact, so a company can have multiple sponsors (e.g. if you have multiple projects with one company, but different departments and project leaders on the other end).
- The hours_per_day aso. asf. are unique to a company. At least I haven't found one where one project starts on a monday and  another one on saturday, on a regular basis. But maybe I do not understand what these fields are used for.
- My gut feeling is to have a seperate timing table which has the "start, finish, duration, work (what is this), cost as well as type (planned, actual, baseline [what do we need this for]) und project_id"
- How do you define remaining work. Can't we calculate this from somewhere else ?
- I'm sure we can calculate the variances, as well as early and late start/finish.

In any case, thanks for starting this work, looking forward to see more.

Posted by Torben Brosten on
Jade, regarding your RF for status report.  I picked up a 2nd edition of "Modeling and Analysis Using Q-Gert Networks" by A. Alan b. Pritsker (c)1979 (for $10 from ). Pritsker describes the iterative development of Q-GERT through hundreds of varied projects --consistent with dotProject's requirement of application to a variety of projects.

Chapter 6 discusses integrating various statistical distributions in the Fortran IV program. The program is not listed, but the purpose and requirements of routines are described --as well as variables/fields. In line with Jade's model, he designates min and max slack-time fields as overall time duration of activity instead of (my proposal of) time difference (ie max duration less min duration) where min is the estimate value. Of course I'm just skipping through the book at this point. Perhaps he's just emphasizing the statistics calculations in this part... I have much more reading to do.

Posted by Dave Bauer on

In the project I was working on, we store all date information in calendars using the calendar package. I think you might want to look into mapping calendar items to a project.

As has been discussed before the calendar package definitely needs work.

Posted by Caroline Meeks on
This is the table definition for our client site. As promised I'll discuss all the things we would do differently if we were starting now and doing a general system.
create table projects (
    project_id    integer
                 constraint project_id_pk
                   primary key,
    project_code  varchar(20)
                  constraint project_code_nn
                    not null
                 constraint project_code_uq
    name         varchar(100)
                 constraint name_nn
                    not null,
    --A project starts off as unapproved. Must be approved before tasks are scheduled.
   status        varchar(100)
                   default 'Pending Approval',
   mfg_po_number varchar(100),
   --The sponsering (paying) entity for this project
   manufacturer_id       integer
                         constraint manufacturer_id_nn
                           not null
                         constraint manufacturer_id_fk
                           references manufacturers (manufacturer_id),
   --This restricts a project to one company.
   --Its usefull because now the company can own the calendar and the survey
   --However, if they ever want to share a project between companies it will be hard.
    company_id           integer
                         constraint company_id_nn
                          not null
                         constraint company_id_fk
                           references companies (company_id),
   team_type_id  integer
                         constraint team_type_id_nn
                           not null
                         constraint team_type_id_fk
                           references team_types (team_type_id),
   --For book keeping only. Not used right now. Use team type and shifts.
   est_man_hours         integer,
   --Crew's can't leave during a shift and might do overtime so we collect how many shifts separately.
num_shifts            integer
                         constraint num_shifts_nn
                           not null,
   -- Completion Survey that teams will respond to when they finish each task.
   -- This will be from a hard coded master survey at least for the first round.
   calendar_id           integer
                         constraint calendar_id_nn
                           not null
                         constraint calendar_id_fk
                           references calendars (calendar_id),
   photo_folder_id       integer
                         constraint photo_folder_id_nn
                           not null
                         constraint photo_folder_id_fk
                           references cr_folders (folder_id),
   comp_survey_id        integer
                         constraint comp_survey_id_nn
                           not null
                         constraint comp_survey_id_fk
                           references surveys (survey_id),
   notes_survey_response_id      integer
               constraint notes_survey_response_id_fk
                           references survey_responses (response_id),
   department_id           integer
                           constraint customer_departments_fk
                         references customer_departments (department_id),
   store_type_id          integer
                        constraint store_type_id_fk
                        references store_types (store_type_id),
   --Eventually we may need to put work hours in a look up table. For now choices are set in the ad_form.
   prototype_pa_album_id integer
                         constraint prototype_pa_album_id_fk
                         references cr_revisions (revision_id),
   work_hours           varchar(100)

Project_code and Project_name: This is like short name and pretty name, or Key and pretty name. There tends to be a key that accounting systems and such use for each project.

Status: If I was starting now I would definitely use Workflow for status NOT store it here. I hope to get funding on this project to transition to workflow. I very much believe it can provide value to my client.

mfg_po_number: This is the PO number of my client's customer. Each implementation will have random pieces of information totally specific to that site, or even that project. It would be far better to have a general way of collecting, editing and displaying them then to put fields in the data model like this. Work on making attributes more functional perhaps?

Department_id: This is a nice obscure one. It refers to a set of look-up tables that model our client's customer's internal set of departments, and sub-departments that they use for keeping track of their inventory. If Categories were available when we wrote this I think that is what we would have used. Another important point for dotProject is each project may be classified on totally different category trees for each different type of stake holder.

Manufacturer_id, Company_id: Customer_id. For this site these are the stakeholders in the project. In We represent them all as groups and each has its own table with some extra info. One issue we have already run into is that a Project needs to be associated with more then one Manufacturer, or Company. For dotProject we should probably use rels to relate projects to their stake holders. This will should be the most flexible solution and will help dotProject use the toolkit.

Team_type_id: In this case each project requires a certain type of team (2-man, 4-man, reset team, etc.). The team types are stored in a look-up table. I think if we were doing it over I'd use categories for this.

Estimated Man-hours, num-shifts: In this use case they frequently schedule assuming overtime. Work rules and the sorts of estimates needed are going to vary a lot from industry to industry. For instance if this system were to expand we might end up modeling the overtime laws in each state. We may want a more general solution then trying to put all the combinations into the data-model.

Work_hours: This is currently modeled as a look-up table of things like 5pm to 12am, 7am to 4pm etc. A bad late patch for a requirements change. Something we should think about is how to model "when is work allowed to take place". There is both the issue of working hours (only days, only nights) and the issue of work days (what holidays do you observe, is it a project or task that can ONLY be done on weekend and holidays).

Calendar_id, photo_folder_id: One of the important roles of dotProject will be to provide a framework that lets you elegantly use all of the functionality of the toolkit. In this instance we are using Calendar, Survey and Photo Album. Using one instance of each package then putting the id in the model like this is very much WRONG in my opinion. It was a fast simple solution implemented to get results quickly before dotLRN 1.0 was released. dotProject should follow the dotLRN model and extend it to use rels to relate objects such as calendars, photo albums, surveys to one or more projects and tasks.

Use of Calendar: I personally think acs_events should be used to store all time related info. I suggest considering moving the project start-time and end-time to the project's calendar. I think once we start apply dotProject to real use cases we'll see an explosion of date related info that needs to be stored. For instance for our use case we need to store Material Arrival Date. A few other common dates would be, billing dates, current .contract start and end dates, no work days, meetings, deliverables etc. We use calendar items with specific item_types to keep track of project dates. We never end up using any of the pages in the calendar package but we use the api's and modified forms of the widgets extensively. It doesn't' make sense to duplicate date handling functionality.

Survey: We used survey in two different ways. The first is each project has a list of documents that are supposed to be associated with it. For instance, building plans and material lists. These need to be named and displayed consistently for all projects and File Storage provides too open ended an interface and makes it too likely that different people would name the documents differently. Thus we created one survey with a bunch of file type questions and each project has one response to this survey. It was quick and easy and survey has nice tcl api's.

The second (and probably more appropriate) way we used survey was to create one "completion survey" for each project with each task creating one response when the task is marked complete.

Photos: An extremely important part of this project was collecting and displaying photos of completed tasks. We used one folder per project with each task creating an album. One interesting requirement is in addition to one album per task, there also must be an album of "proto-type" pics that are at the project level and show what the end result is supposed to look like. Use of rels to relate photo albums and folders to projects and/or tasks would be a much more elegant and scalable way to use the tool kit then storing all the ids in the projects table.

I will try to post our Task data model and a similar discussion soon. Please don't take these data models as a starting point, rather to use them as an example of some of the issues in a real life use case.

The things I want to emphasize:

  • Have dotProject be a tool for organizing packages and never repeat existing ACS functionality.
  • use calendar to manage date information.
  • use workflow to manage status information, including auditing when status changes and who makes the change.
  • never put a constraint to users, always use parties so there is flexibility whether it’s a user, person or group.
  • Mapping tables and look-up tables are not that scalable, expensive to maintain and requires that you have programmers for each new field you want to add, and each new filter on reports. I recommend dotProject minimizes these and work instead on improving the toolkits functionality and flexibility in areas such as rels, attributes, categories, list builder etc.

(with input from Rocael and Dave Bauer who will also be posting with more details)

Posted by Jade Rubick on
Caroline makes some very good points. Thanks for your data model, Caroline.

Here are some thoughts in response to your posting:

-- First of all, every company is going to have a list of information they will need to associate with a project. For example, our company associates recipes with each project. Some companies may associate products with projects. I think this need is going to be pretty universal.

Also, there will be other information, such as PO numbers, or customer codes, or Sales regions, etc...

This is an absolutely critical element of dotProject, I think. We have to find a flexible solution to this. For us, this is one of the main reasons we're building it ourselves instead of using something off the shelf (there are other reasons too, however).

Here are a couple of brainstorms to this idea:

- we set up a table of attributes, as you describe. Allow people to set up attributes for different types of tables, and then allow them to actually set up the values. This is pretty flexible. The attributes act as additional columns they can add information into.

- this is not mutually exclusive, but we could also have some sort of service contract for queries that are run when you look at a project page. For example, at our company, we want to see all the products associated with that project.

A way this could work is we could have a set of project_types:

create table project_type (
-- info on project type

Each project has one (or more?) project_types. Let's say one or more for the sake of flexibility. We can categorize projects into many types then.

We also create a table that tracks the service contracts:

create table project_type_service_contracts (
  project_type_id  integer constraint dfsafdsaf
                            references project_type(project_type_id),
  tcl_procedure_name  varchar(200),
  tcl_sortby                  varchar(100)

Then each project_type could have a set of associated code that would be run for it. Potentially several pieces of code.

For example, let's say we have two project types:

* Customer projects
* Research and development projects

For all customer projects, we want to display a list of relevant products.

Let's say we have a table, called customer_products. It has a column called project_id that references the relevant Project.

We set up a Tcl function called customer_product_list_by_project(project_id). It returns a list of products for that project, in an HTML table.

We insert a row into project_type_service_contract, and then whenever we look at the project page, you see the relevant entries.

Does this make sense? Does it seem useful to other people? The nice thing about it is that it's only used if necessary.

Of course, this does mean that someone who can insert rows into your table can root your computer. But I think that's probably true anyway. ?

I'll finish reading your posting, Caroline. This is just one thought I had had that I hadn't posted about much.

Posted by Jade Rubick on
About work_hours:

Yes I think this is why we need to think in terms of scheduling resources. Resources are going to be available sometimes and not others. MS Project does a good job with this, and I think we can do something similar.

Can you describe how rels work a little more? I guess I'm unfamiliar with them. Or refer to where I could learn more about them?

Caroline suggest we use acs_events to keep track of all date related activity. I'm willing to do this, I guess, but that's another piece of software I'm not familiar with. Can you describe a little more what advantages acs-events would give us?

I like the idea of completion surveys for projects. This should probably be optional, however.

Interesting thoughts about photo-albums. Makes me very curious about rels.

Good point about users vs. parties

I'm not sure I completely understood your point about mapping points and lookup tables. Where are these used? Is this something one of the data models?

Thanks for all of your points, Caroline. It's very helpful to have real-world examples to work from (and your real-world experience in creating it). I look forward to Rocael and Dave's postings too.

Posted by Jade Rubick on
On IRC, Dave shared with me a couple of suggestions for improvements:

First, he suggested using <include>able templates instead of the tcl procedures. That makes so much sense -- I wish I had thought of that.

Second: "there are two things i think that are most important. workflow, so if you need to complete a survey, workflow would make sure its done before advancing to the next status."

Third: "there is one other way to display stuff, using the CR you could have a item_id, and an associated template. different templates can be used depending on the context."

He said he'll post later with some more detailed comments.

Posted by Jade Rubick on
I've posted the newest version of the data model at:

Please do your best to rip it up, and provide as much feedback as possible. I'd love to whip this thing into shape!

Would people prefer that I post it here, so that the iterations of the code are preserved? Or is it better to keep this thread clean?

Posted by Dave Bauer on

There are times when a tcl proc that returns a multirow datasource will be more flexible, that is, is the built in templates are not formatted in the way you need. I guess, though, that the customized includable adp should just call that tcl proc.

About using acs_rels to associate arbitrary objects to a project (just another object.) The acs_rels system is very flexible and powerful. It can define relationships between two different object types. Because acs rel types are themselves object types, you can extend those object types with additional attributes. This was used in .LRN.

Setting up a user interface to require a completion survey for each project would be the tricky part. That is, letting a site builder specify what types of relationships without customr programming would be tricky. Some examples of this already exist in the acs-subsite groups UI.

Another way to hook together the various packages to manage a project would be using workflow. I haven't looked into exactly how it is done, but I hope it would be possible to associate a survey with a project, and update the status of the project when the survey was complteted. Again, all of this is possible using the existing pieces.

Definitely look at Jon Griffin's contacts and improvments to the persons data model. It will be very useful for associating people and places with projects.

I'm sorry I haven't come up with too many solutions, just more ideas. Perhaps it should be decided how flexible a solution needs to be. How closely coupled the features will need to be, and how much programming will be required to customize a solution.

Posted by Jade Rubick on
I did some research on acs-rels, and here's what I found:

I'm also working on organizing all of the ideas people have presented in this thread. It's in progress, and will change a lot especially the next few days:

I welcome feedback on these pages.


- what parts of the data model should be using the content repository?

Posted by Jade Rubick on
Other questions:

- we can't call this dotProject, because another piece of project management software is already called that. So we need a new name. Let's not spend too much thought on this:

- does everybody agree that internationalization is something we can put in version 1.1 or something? As far as I can tell, it's pretty easy to internationalize something, so let's do that later. Anything else we can postpone until the next version?

- If anybody has any free time, we could use some work on our use case scenarios:

and our Requirements:

I'm going to work some more on the roadmap ahead. I'd welcome thoughts or criticism:

Posted by Jade Rubick on
I've done a lot of work on the use case scenarios:

Posted by Jade Rubick on
I've moved the project management page from my website to the OpenACS website, where it more properly belongs:

So the above links will not work.

This way, Jeroen and others can update the page too, and we can have it not depend on just me 😊

Posted by Jade Rubick on
What should we call the project manager?
  • PMS (Project Management Super) with super pronounced like sue-pear.
  • OpenProject (because everything that's open sourced should be called Open)
  • dotPM
  • project-manager
  • PPM (Perfect Project Management)
  • PPPM (Pretty Perfect Project Management) or 3PM (it's three o'clock, do you know where your projects are?)
  • OnTime
  • OnSchedule
  • ProjectTracker
  • InSync (The project management software that sounds better than a boy band)
  • LockStep (keeps your organization's people running in lock step)
  • Rowboat (somehow I get a mental image of a bunch of people rowing together)
  • InMotion
  • DProject (for distributed project management)
  • Oaks Project (from OACS Project Management)
Your thoughts are welcome. And comments on anything else.
Posted by Jade Rubick on
I'm going to call it project-manager.

I've put the code in the /contrib directory on CVS (I eventually figured out how to do this). You can download it from CVS head.


All it does right now is allow you to create projects and view them. It's very skeletal at this point, and far from perfect.

My next step (I think) is to add workflow. Unless anybody else has any other suggestions.

I plan to work on this about two days a week until it's finished. At some point, I may be able to devote 3.5 days a week.

It's been almost two weeks since anybody else has posted on this, and I really could use some feedback on all of the documents I've put up in these last few weeks.

Posted by Nick Carroll on

I've looked at your code and it is very similar to what I've done... which was modify the Notes package.  The main difference is that I'm using the content repository instead of ACS objects directly.  I'm just having problems with creating the project hierarchy, which Ola demonstrated above with his sample code.  The indented_name isn't being indented.  Once I've worked this out I'll contribute my code to CVS as well.


Posted by Jade Rubick on
Nick, please do so. I hate for us to be duplicating each other's work. I was planning on using the content repository as well, so I look forward to looking at your code.

I'd like to suggest we merge our code together. It would be better if we determine what's good about each one, and merge them together, rather than running off in slightly different directions.

My progress report:

I've been working on the organizations package, which I think we should use to model the organizations associated with a project. I wrote a simple UI, and fixed a few bugs in the data model. It looks like a good data model -- I think Jon did a good job with it. If we build on that, plus ref-itu, telecom-number, and postal-address, we'll have that portion of our data model done for us.

I've started looking at workflow, and how to integrate it into the project-manager package. It doesn't seem to be that easy of process.

More soon.

Posted by Nick Carroll on

How would I go about merging my code with yours?

Should I just check it into /contrib for the time being?  If so would you be able to tell me how I would do this?


Posted by Jade Rubick on
There are a couple of ways we could merge the code.

If you ask for write permissions on the project-manager directory, you could download project-manager, make the improvements (adding in the content repository and your hierarchical project view pages, for example), and then commit the work yourself.

If there are any things to discuss of which way to go designwise, we can discuss it here.

I think you need to ask Don or Peter for permission to the CVS contrib/project-manager directory.

We don't need to work about upgrade scripts until we get to alpha, in my opinion.

Does that sound good?

Let's coordinate a little more on our design of this as well. I want to make sure we take the best of both of our designs, or even better, come up with designs better than both of ours 😊

Posted by Nick Carroll on
Just requested CVS write permission.  I don't know how long this will take, but I'll check your code out and make the changes now.

I'm just creating hierarchical project folders, so it is independent of your data model.  So the merge shouldn't be a problem.

The folders should contain resource items, task items, and a project description item.  These items can be added when viewing a specific project folder (view page).  I think we'll stick with your datamodel for the time being Jade.  My tables just have too many columns, and plpgsql functions don't take enough arguments (16).

That's my plan for the short term.

Posted by Jade Rubick on
That sounds good Nick. Let me know if you have any questions or I can help out in any way. I'll post here if I do any further coding, like adding in Tasks or anything like that. That way we won't step on each other's feet.

Have you taken a look at my very very primitive UI mockups? I'd love some feedback on them, and some better designs 😊

Posted by Nick Carroll on

I'm not really a UI person.  My templates are really simple at the moment.

I've checked out your code, and making the modifications now.  I'm getting rid of the acs-objects code, and replacing it with the content  repository stuff.  I'll try and check the changes into CVS over the weekend.

- Nick.

Posted by Jade Rubick on
Status update on project-manager:

Nick is working on adding use of the content repository to the project-manager. I believe he said he'll be done with that this or next week (I don't remember which).

I'm working on another project until then. Once he has added in the content repository code, I'll start working on adding in Tasks.

We would welcome some more coders, if anybody else is able to contribute. Currently, most of our work is around the data model.

Has anybody else added workflow to any packages besides the bug-tracker? I'm curious what other people's experiences have been. So far, despite Lars' excellent documentation, it looks pretty complicated. If I wade deeply into it, I'll start posting real questions.

Would it be hard to add workflow later?

Posted by Jade Rubick on
This is an idea:

Instead of porting room-reservations to OpenACS for dotWRK (which I believe nobody has done), make a more general scheduling application:

Here's what it would do:

It would allow you to schedule:


It would need some sort of service contract for you to use new "types", like users, with it.

Imagine this for an Intranet. You want people to schedule when they're available, and for how long. You set it up to automatically schedule people in for their schedules, 9-5, 5 days a week for full-timers. Then other apps, like our project manager, could query it through the API, and see how available that resource is.

This would have to be written carefully. It is very similar to the calendar app in a lot of ways. You want to be able to have almost any time of object be able to be "scheduled".

Anybody willing to write this for dotWRK?

Posted by Malte Sussdorff on
Technically I'd suggest to create a general scheduling solution for CR items or even ACS Objects. And it would be fairly basic system:

- start_date
- end_date
- status_for_this_period
- repetitive
- object_id
- approved
- ....

Every package could make us of this in their own way. A room reservation system would set the status of a room to "booked,reserved, free". The calendar could make use of it for people and the CMS could use it for displaying content.

And yes, we might take this on, end of the year 🤔.

Posted by Jade Rubick on
Malte, this is a great idea! It is similar to acs-rels, except that it is scheduling specific. Perhaps we should call it acs-schedule?

I think this is a really important item for dotWRK -- we can't compute how long a project will take to accomplish if we don't keep track of people's schedules, for example.

It looks pretty simple to code. I think we should probably make this a small package of its own. It seems like a candidate for inclusion in the core, but I guess that's not my call.

acs-events doesn't handle any of this, does it?

Posted by Nick Carroll on
Just committed the content repository mods to project-manager into CVS.

So far you can add and view a project as before.  I haven't updated the "edit" functionality yet.  I will add this back in over the next week.


Posted by Nick Carroll on
My plan now is to polish up the code that I've submitted.  As well as add the "edit" project functionality back in.  I think this is just creating a new revision of an existing project item.

The next step will be to work out how to incorporate work flow into the package, so that we can manage projects through states (proposal, open, closed).  This may take me a few more weeks.  Not sure how to use the workflow package yet.  Isn't there a new workflow package that I should be looking out for?

Another item on the "to do" list is design a better looking UI.  Should we bother with this now?  Or when there is enough functionality in place?

Posted by Jade Rubick on
Hi Nick (and all),

I'll take a look at the code you submitted, and work on it this week. It's nice to have someone else to code with. Thanks for adding in the content repository. Did you happen to take notes on what it was like to add the content repository to project-manager? It would be a useful document for others. I was going to do it here:

If you have any notes you'd like me to post there, I'd be happy to put them up for posterity.

I've started adding in workflow to project-manager. See this page for details:

It shows what I do step by step. I'm hoping to make that document be a guide for other people in the future who want to add workflow to their application, because I find the process to be pretty difficult.

I might need to add workflow to the version of project-manager that doesn't have your addition of the content repository in it, because I want this document to make sense, and have a before and after picture of what was added to make workflow work.

I'm going to post some more this week on adding workflow. It's been tough.

I think a good UI is a very important step. I have some background in UI design, so perhaps I can work on that. If you'd like to add back in the edit project functionality, that would be great.

Perhaps a next step would be to post a proposed data model for the Tasks? Would you like to work on that part, and propose something, and then we can work it out and decide who will code it? I can do it if you prefer. It's up to you. We should probably discuss the implications of different data models before we code it, though.

Posted by Nick Carroll on

I would like to code the tasks stuff, unless you would like to take that on board.  I've been keen on writing some code that generates a Gantt Chart.  The Gantt Chart could very well be an HTML table.  However I will be looking into other display methods such as SVG, Java Applet, or generating a TIFF image.  The Gantt Chart will no doubt be tied in with tasks, so I would like to get involved with this part of the project.


Posted by Jade Rubick on
Nick, I'm wading throught the addition of workflow, so if you'd like to do Tasks, please go ahead. Could you post the preliminary data model before doing too much work on it, though? It would be nice to discuss it before we commit too much to a particular data model.

The Gantt and other views will be fun to develop I think, but should probably come after we've developed some of the other portions a bit.

I looked briefly at your work on the addition of the content repository. It looks good (although I don't really know very much about using the CR yet).

I'll continue working on workflow this week, and keep you all informed.

Posted by Nick Carroll on

I will try and write up some documentation on the content repository in a theme similar to your workflow document.

In fact my supervisor wants me to concentrate on producing some documentation on where I am heading with this.  So I won't be churning out code over the next couple of weeks.  I think it would be a good opportunity for me to put down on paper the design/architecture of project-manager.  At least this will provide some food for thought.

In the mean time I will finish off the "edit project" functionality.


Posted by Jade Rubick on
I will be on vacation until the 15th, so I won't be working on project management stuff until after then.

Nick, if you do get started on the Task portion, please look at the data model on the project-manager page:

It's not perfect, but it will be a good place to start. If you don't get started on it, that's fine too. Perhaps we can regroup after I get back from vacation.

I've been doing this project-manager project in the background of other activities these last few months. About a week after I get back from vacation, I'll need to kick this into higher gear, and concentrate more fully on getting the project-manager working.

I'm hoping to have something working by late August / early September.

Posted by Jade Rubick on
I'm back from vacation now, and hoping to get an early version of project-manager out by the end of August.


1) Who has experience with Workflow? Is it just Lars and Peter? I'd really appreciate it if someone could help me navigate this a bit. I promise not be a pain, and in exchange, I'll provide some documentation on how to add workflow to a project. I'll also be there to help out others who try to add Workflow to their project!

2) Is it difficult to add Workflow to a package after the fact? Is this a mistake?

3) Peter suggested using Workflow for Tasks. That makes sense to me. Should we also use Workflow for Projects?

Nick, unless I hear otherwise from you, I'm going to proceed to add in Tasks and Workflow. I'm going to be able to devote a lot more time to this in the next 6 weeks, so hopefully things should be kickstarted a little bit.

Posted by Jade Rubick on
I've been looking at the Logger and at Bug-Tracker. It seems to me that it wouldn't be as much work if we just used the both of them, the former to log time, and the second to log Tasks.

For Logger it seems this would need to be changed:

- project should map to project-manager's Projects, instead of Logger's private projects list.
- I think an easier way of adding hours to multiple projects is necessary, at least at the company I work at.
- These changes may be possible without forking the code. Perhaps if project-manager is installed, the project-manager projects would be used instead of the private ones?

For Bug-Tracker:

- I think forking may be necessary, but we may be able to copy the bug-tracker, almost in its entirety. The reason I think forking might be necessary is that we'll want to add things like dependencies between tasks.
- The major change will be that instead of using Components or Areas, it should use Projects instead.
- I also wish that bug-tracker kept track of all the changes made to a Bug over time (Revisions). Does it not use the content repository? It seems like would be a nice addition.
- We also will need to add things like deadlines
- I think the UI will also need to be changed a bit.

That's what I'm thinking right now. Comments are welcome.

Posted by Jade Rubick on
Dave had a few suggestions (via IRC):

1. First of all, he'd like to be able to link Tasks and time logged in Logger. (jadeforrest: i definitely want a way to link time in time-logger to a bug in bugtracker)

2. He thinks maybe we can set up projects as keywords, which then can be used globally by other applications, such as logger and bug-tracker. They might be able to be used as the Project for logger, and the Component for bug-tracker.

Any thoughts on this? Here's our exchange:

[13:02] > daveb: That's the biggest problem with all these packages. They don't talk to each other.
[13:03] > daveb: so logger doesn't know anything about bugtracker, and bug-tracker doesn't know anything about project-manager..
[13:03] <daveb> jadeforrest: right. it can be done ina  general way.
[13:03] <daveb> think general-links from the knowledge management stuff.
[13:03] <daveb> or just use cr_object_rels
[13:04] <daveb> you can link a cr_item to any acs_object.
[13:04] <daveb> similarly a site-wide category package would allow using the categories to define bugtracker bug areas and project areas and time logger projects.
[13:05] > I'm only vaguely following you.
[13:06] <daveb> you don't need to store the bug_id in the time-logger, for example.
[13:06] <daveb> store the bug_id and the time-logger item_id in an acs_rel
[13:06] > You could just link them using cr_object_rels (which I guess are like acs_rels)?
[13:06] <daveb> that way you can link two different objects.
[13:06] <daveb> yes exactly.
[13:06] > Okay, I get that.
[13:07] > However, linking the bug-tracker to the project-manager does seem like it will require a lot more coding changes, right?
[13:07] <daveb> why?
[13:07] <daveb> you don't need to directly link bugtracker to project manager.
[13:07] > I have to replace the components section with project-manager's Project table.
[13:07] <daveb> just allow links to objects from bugtracker.
[13:08] <daveb> some might be project manager objects.
[13:08] <daveb> jadeforrest: no. what you _really_ want to do is replace the components and projects with categories.
[13:08] > Tell me more :)
[13:08] <daveb> then bugs or tickets can be part of a category which happens to be a project.
[13:09] <daveb> bugtracker projects and components are already cr_keywords now in the latest version.
[13:09] <daveb> so you could use that.
[13:09] <daveb> i think :)
[13:09] > Hmmm, so you're saying that we create site-wide "categories", which are equivalent to projects.
[13:09] <daveb> the new category package isn't ready yet.
[13:09] <daveb> yes.
[13:10] > I don't know that much about the CR, unfortunately. Bugtracker projects and components are cr_keywords.. what does that mean.
[13:10] <daveb> it means that they are not bugtracker specific objects.
[13:10] > Does that mean they could link to "categories" instead of whatever projects you create in bug-tracker?
[13:11] > Oh, that's cool. I thought they were local tables specific to bugtracker.
[13:11] <daveb> well cr_keywords is the existing "categories" mechanism in the CR.
[13:11] <daveb> maybe they have local tables, but they should refer back to the CR stuff.
[13:11] > Damn, the problem is the more I learn about OpenACS, the more I have to learn.
[13:11] > :)
[13:11] <daveb> Actually everyone should start with CR
[13:11] <daveb> that is where most of the cool stuff is :)
[13:12] > Hmmmm, so if you were me, you'd spend some time studying the CR first, then figure out how to link all these applications?
[13:12] <daveb> yes.
[13:12] <daveb> of course I have spent 2 years on and off studying CR :)
[13:13] > Do you think I could use bug-tracker without forking it? I do have to add things to it, like dependencies between bugs
[13:13] > (for project-manager type Tasks)
[13:13] <daveb> well, consult with the author.
[13:13] > I will.
[13:13] <daveb> maybe they would like that too :)
[13:14] > I'm going to have to chew on this a bit.
[13:18] <daveb> i would definitely attempt to not fork anything.
[13:18] > Well, it would not really be forking bug-tracker, but taking bug-tracker and using it as an example for another application built on workflow.
[13:19] <daveb> anyway bugtracker is aimed to be more general purpose.
[13:19] > True
[13:19] <daveb> but still in the end you would have two packages with similar code.
[13:19] > Yes.
[13:19] <daveb> maybe you can build a package on top of bugtracker alsom using bugtracker as a service.
[13:19] > Which would be not good if it were possible to keep them together.
[13:19] <daveb> it might not be possible.
[13:19] <daveb> but definitely look into it.
[13:20] <daveb> anyway good luck :) bbl

Posted by Jade Rubick on
Sorry for the volume of email. I want to make sure that I keep the development process transparent, and allow others to comment on what we're building, because I think the project-manager is going to be a piece of software a lot of people will want to use. It also affects so many other packages that it's important to coordinate with what everyone else is doing.

I looked at the data model for Logger, and it looks like Peter was intending to replace the private Project table in Logger with the project-manager's Project table:

"Log entries are grouped by projects. Once we have a dedicated
project management package for OpenACS this table will be superseeded by tables in that package. In order to make such a change easier in the future we are not referencing the logger_projects table directly in the logger datamodel but instead reference acs_objects."

So perhaps what I can do is when I get around to adding hours to project-manager, we can create upgrade scripts and bump up logger a version. I'll then make project-manager depend on that version. Can two packages depend on each other? Ideally, logger would also then depend on project-manager being present.

However, looking at the bug-tracker data model, it looks like "components" are hard coded as a regular table, so I don't think what Dave is suggesting will work without a lot of work.

I think what I'll do with Tasks is make them an application built on Workflow, based on bug-tracker. Please speak up if you have any better ideas.

Posted by Dave Bauer on

I was just browsing the project manager data model. I see you are storing some project data information in the projects table. I would like to convince you to use the calendar package to manage dates.

It will be much easier to show the relationship of project date based information on a calendar if you store the data in the calendar package. Generally a canlendar view is one of the views you would use to look at date-based information.

I know the calendar datamodel could use some work, but I think the benefits of being able to store an arbitrary unlimited number of dates related to a project are very important.

Posted by Dave Bauer on
I also noticed there is a mapping table to map packagte_id to the folder_id for the package.

Does this do something different than cr_folders.package_id? It seems that some packages use a table to map package_ids to a folder, but this ability is built into the content repository.

Am I missing something? (very good chance :)

Posted by Nick Carroll on
Dave, I only created that mapping table as I noticed other packages were doing the same.  If cr_folders.package_id already does this, then I will make the required change.
Posted by Andrei Popov on

This maybe too late of €0.02, but I would not think that using BT (at least in the current form) is a good idea for the PM. For one, BT does not support nesting of tickets -- with any effective project management tool you do need to be able to nest tasks -- have suntasks of tasks of subtasks of subprojects, etc...

Can't really comment much on using categories as project-holders -- maybe it is possible with the new global categories package -- have not tried/seen it yet. In this case one could (in theory) structure projects as sub-types of categories, then have BT handle individual tasks -- this would still be a limitted way of doing it, though. Projects and sub-projects can be handled this way, but not tasks and subtasks.

When I was thinking some time back about a PM approach (before dotWRK work started -- at some point I tried to port project-tracker to OACS), I was thinking about roughly the following structure:

  • Each item in PM is a task. Projects are also tasks. Have a single tasks table to hold all basic task data for all projects (descriptions, dates, reference to projects they belong to, etc.)
  • Projects are simply tasks promoted to projects type. Keep them in a separate projects table, with reference to parent_project.
  • Projects differ from tasks in ways that you can assigne pools of resources to them. These could probably be defined through acs_rels.
  • You can't also flag a project complete unless all tasks are completed under it.
  • Tasks under a given project can only be assigned to project's resources pool.
  • Project-level tasks also define/own calendars, but those may have to be also resource-specific.
  • In a very primitive sense (and that is where I've stopped -- had not had time to move any further), a data model could be as follows:
    -- knowledge-level
    create or replace function inline_0 ()
    returns integer as '
        PERFORM acs_object_type__create_type (
            ''pm_task'',                            -- object_type
            ''Project Manager Task'',               -- pretty_name
            ''Project Manager Tasks'',              -- pretty_plural
            ''acs_object'',                         -- supertype
            ''pm_tasks'',                           -- table_name
            ''task_id'',                            -- id_column
            null,                                   -- package_name
            ''f'',                                  -- abstract_p
            null,                                   -- type_extension_table
            ''pm_task__name''                       -- name_method
        PERFORM acs_object_type__create_type (
            ''pm_project'',                         -- object_type
            ''Project Manager Project'',            -- pretty_name
            ''Project Manager Projects'',           -- pretty_plural
            ''pm_task'',                            -- supertype
            ''pm_project'',                         -- table_name
            ''task_id'',                            -- id_column
            null,                                   -- package_name
            ''f'',                                  -- abstract_p
            null,                                   -- type_extension_table
            ''pm_project__name''                    -- name_method
        return 0;
    end;' language 'plpgsql';
    select inline_0 ();
    drop function inline_0 ();
    -- tasks: everything is a task, even a project itself
    create table pm_tasks (
      task_id             integer not null
                          constraint pm_tasks_fk1 refernces acs_objects,
                          constraint pm_tasks_pk primary key,
      task_name           varchar(255),
      task_description    text,
      date_start          date,
      date_end            date,
      project_id          integer not null
                          constraint pm_tasks_fk2 refernces pm_projects,
      is_project_p        boolean default 'false'
    -- projects: some tasks can be promoted to be projects
    -- (or sub-projects of existing projects).
    -- they will then get resource pools allocated to them.
    create table pm_projects (
      project_id          integer not null
                          constraint pm_projects_fk1 references pm_tasks
                          constraint pm_projects_pk primary key,
      parent_id           integer not null
                          constraint pm_projects_fk2 references pm_projeects
    -- resource pools should be created in Tcl
    -- resource assignments
    create table pm_task_rc_map (
      task_id               integer not null
                            constraint pm_task_rc_map_fk1 refernces pm_tasks,
      rc_id                 integer not null
                            constraint pm_task_rc_map_fk2 refernces parties,
                            -- a resource can be assigned to a task only once
                            constraint pm_task_rc_map_un unique(task_id,rc_id)
    -- functions
    create or replace function pm_task__name (integer -- task_id)
    returns varchar as '
                    p_task_id       alias for $1;
                    v_task_name     pm_tasks.task_name%TYPE;
                    select task_name into v_task_name
                    from pm_tasks
                    where task_id = p_task_id;
                    if not found
                            raise exception ''Task ID % does not exist in database!'', p_task_id;
                    end if;
                    return v_task_name;
            end;' language 'plpgsql';
    create or replace function pm_project__name (integer -- task_id)
    returns varchar as '
                    p_project_id       alias for $1;
                    v_project_name     pm_tasks.task_name%TYPE;
                    v_project_name := pm_task__name(p_project_id);
                    return v_project_name;
            end;' language 'plpgsql';
    create or replace function pm_task__promote2project (integer -- task_id)
    returns integer as '
                    p_task_id       alias for $1;
                    v_parent_project_id     pm_tasks.project_id%TYPE;
                    select project_id into v_parent_project_id
                    from pm_tasks where task_id = p_task_id;
                    insert into pm_projects
                    values (p_task_id,v_parent_project_id);
                    update pm_task set is_project_p = ''true''
                    where task_id = p_task_id;
                    return 0;
            end;' language 'plpgsql';
    create or replace function pm_task__demote2task (integer -- task_id)
    returns integer as '
                    p_project_id       alias for $1;
                    -- resource pools should first be de-allocated
                    -- TBD
                    -- removing an entry from projects table
                    delete from pm_projects
                    where project_id = p_task_id;
                    -- now changing the flags in tasks table
                    update pm_task set is_project_p = ''false''
                    where task_id = p_task_id;
                    return 0;
            end;' language 'plpgsql';
Posted by Andrei Popov on
Sorry for a longish (previous) post -- looks like what I've posted is sort of close to what current draft data model is anyway.

A few comments after reviewing the latter:

I'd agree that more use needs to be put onto acs_rels to handle project resource grouping.  As mentioned above, I think that a good way to do it is to have resources pool assigned to a project, yet each task should get a separate resource assignment (including multiple resources to a single task, although this may mean that a task is not granular enough).

Dependancies: just an other-task-wise dependancy is not enough -- one may have tasks that are not dependant on any other tasks, yet do have constraints (like must-finish-before, etc.).  In that sense `constraints' maybe a better word indeed.

Posted by Jade Rubick on
A couple of things:

1) Unless anyone protests loudly, Nick and I are going to require Postgres 7.3.x for project-manager. It just makes life easier. You will be able to use 7.2.x if you recompile it to support more than 16 arguments.

2) Nick is working on adding back in the edit project functionality, with the content repository.

3) I've started writing up a content repository document:  I needed to write it in order to figure out how the CR works.

4) I'm starting work on the Tasks. It will use the content repository.

5) I'd love to know how to use acs-events or the calendar package to store dates. I haven't had the time to look into it yet. Does anybody have any documentation on this? Or a good example to refer to? Anybody have any time to look into this?

6) Constraints does seem like better terminology than dependencies. Any objections?

7) I haven't done much thinking about resources yet.

8) More developers are very welcome to work on this. Or if you have feature requests, feel free to file them in the bug-tracker.

Posted by Jade Rubick on
An update:

- Added in tasks (although editing tasks is not done yet). We also might want to add more values for tasks, etc.. Tasks are created under the project they are associated with.
- Fixed bugs / added in functionality to edit projects (revisions are created, but I haven't added in the interface yet to show the different revisions)
- removed content repository folder for each project (only one folder
per instance now)
- added in a style sheet (will take this out once an openacs-wide style sheet is adopted)
- renamed files in line with (my understanding of) openacs conventions.

I've also added in documentation on the project-manager page:

(under getting the code)

that details how to set up yourself as a developer for project-manager. It is specifically for people with write access right now. Other people can email me patches or suggestions.

Nick also let me know that his thesis direction had changed, so he'll still be contributing, but not as much as he was previously. I think as this matures, more people will want to get involved in it, but you're welcome to get involved even now if you are interested, and have some time and skills to spend on this.

Posted by Ivan Labra on
I am glad to see some of the influences on this project - I am a fan of Tufte, and some integration of data concepts into a charting tool would be excellent.

Having said that, the key for a project management system is the data model.  It has to be abstracted enough so that process can be easily configured by the project manager (or at a higher organizational level) a director or VP.

I would point folks toward the Zachman framework, as a grounding concept for forming a vocabulary around process.

Furthermore, from a software development project management perspective CMM and CMMI could provide a good basis for a general taxonomy around process toolkits. An interesting example could be the RUP web product  that focus on a vertical industry methodology as a project management tool.  PMI is the place for just project management.  It could also be a good resource for vocabulary

I realize this is a little different than the common approach to PM which is to directly dive into the notion of entities like projects, tasks time entries etc or for a more horizontal approach to collaboration.

Certainly these tasks are important but I believe that a successful tool in this area  must do a few things well:

1. It must handle hierarchies
2. It must handle ephemeral relationships amongst nested objects
3. It must handle workflow (or object state) and allow for flexible configuration (perhaps creation and definition) of processes.
4. It must capture and allow for analysis, and probabilistic modeling (future planning, risk analysis)

To my first point.  Most organization and project management works in terms of an outline.  (Winer at userland has gone into outlining tools and there are quite a few that are interesting including ECCO a PIM based on outlining and Mindjet which uses MindMapping metaphor to allow for manipulation of hierarchies)

Secondly, one of the problems with most project tools is that they do not recognize that linking of objects must be easy and follow little structure.  ECCO, the best PIM I've seen does.  You can take any entry and link it to anything else.  It is loose but provides excellent context.  This establishment of object relationships should be very flexible, the way thinking is, and then the tool should allow for cleanup and after the fact organization. PM tools are really bad at this. But a great tool at this is something like Request Tracker, the open source trouble ticket system (which also has neat e-mail integration).

One of the ways RT is excellent is that you can imagine a project having 5 ticket cues. One for Idea Stage, One for reqs , one designed, one in built, one in test.  A ticket could travel amongst the queues based on some type of user defined promotion criteria.  A ticket could be split or tickets could be rolled up, and a history would allow for temporal context of the ticket life.

I think ECCO would be a great starting point for understanding functionality for a project management tool From a single user perspective. I think RT would be a great place to understand lifecycle and workflow (as well as integration with e-mail)

I have to do some thinking on the analysis part.


Posted by Jade Rubick on
Thanks for all your input, Ivan.

Do you have links to any of the products you've described?

Unfortunately, I've already started work on the project-manager, so a lot of the data model has already been completed. It is open to being changed, however.

I strongly agree with you that flexible hierarchies are extremely important. I'm trying to build this into project-manager, but I'd appreciate any insight into ways this could be improved.

Right now, I'm trying to get as much accomplished on this as possible by the end of August. So although my focus before now was on collecting information, right now, I'm focused on writing it.

However, I do want to make sure we're on the right track, and I'd welcome your help in whatever form you're able to give it.


If you or anyone else is interested in keeping abreast of what's happening with the project manager, you can get email notifications on the project-manager to-do items and bugs from the bug-tracker:

The current implementation of project-manager has a hierarchy both of projects and tasks, to arbitrary levels.

So tasks can be easily broken down into subtasks, and projects into subprojects. I aim to make it easy to move this hierarchy around, and see how it works.

The project-manager is built on the content repository, so it allows symlinks between objects (such as the tasks and projects), so potentially, a task could be part of multiple projects, for example. This may provide the interface you're describing, although I'm not familiar with the products you describe.

The trick is mostly going to be in the UI. Designing scalable interfaces for complex hierarchies, with thousands of projects and thousands of tasks is the challenge.

Posted by Ivan Labra on
Yes I realized too late you were in a bit in implementation.  Check out RT

or you can downlaod the code here:


With regards to heirarchies.  One of the options we thought about was to flaten the datamodel (not paying head to proper normalization)  keep fewer tables based mostly only to maintain core object refernce data and then parse based on business rules and rely on the namespace for managing the heirarchy.  Then extend the business rule configuration functionality to the end user.  (I think Ecco allows you to do this by using folders as containers for outline files, and then at the folder level applying attributes. I am just curious as to how this would be possible in a mutli-user web environment, especially given the limitations of a web ui.)

This may seem a bit whacky, but the idea was that a PM system and data model that is complex (i.e at task) where the business rules, and taxonomy are rigididly enforced, would be a huge barrier to adoption.

We ended up going the traditional route, for a variety of reasons, but I still believe that a system which imples a rigid business rule model will have limited success.  The real problem is not building a system that models the Project Management space (there are many that do this), it is a tool that models the process defnition/collaboration space, around a model of a project lifecycle.

What I mean is that the business practices of project managemnt can be codified, and have been.  But projects in the real world require a different kind of interaction than @task for example.  I mean do you really do resource scheduling and skill management for a project based on data inputs into a system?  I don't think so.  Would you ever not assign your number one person to a new project of super high importance if your system said she was overloaded? No.  So why would you code this into a system?  And moreover what if I did do the above tasks that way, how could a general purpose multi user PM tool support both of us?

Anyway, I realize most of the decisions in this are have been made, and I look forward to seeing beta.

Posted by Jade Rubick on
Screen shots of the interface as of today are available at:

Feedback welcome.

Help even more welcome!

If you'd like to help out, but only have a little time, you can look at the to-do list, and do one of the items. I keep the status of everything on bug-tracker, under project-manager.

Posted by Andrei Popov on

I've slightly modified the .ADP and .CSS of PM to better render on most browsers I had within my immediate reach. New screenshots are in file storage. My changes can also be found there. They aren't diffs -- sorry. Will try and make those as well in the next few days.

As a general suggestion to wider audience -- should we try at all to make sure that OACS pages pass at least -loose and -transitional validators? Current state of affairs is *much* better than it used to be, but it still soooo far from perfect (unquoted attributes, unclosed tags, varying case came to mind as the most typical problems).

Also, you'll see that I've modified default-master.adp to inclose slave into a separte <div>, as well as assign a few #id's -- changes are really minimal, but they can allow us to move from tabular design in many cases.

Posted by Jade Rubick on

I very much appreciate your improvements. I'll incorporate them into project manager either today or early next week.

I'm happy to see someone else is test-driving project-manager. Feel free to post ANY suggestions or bugs in the bug-tracker:

Please keep in mind this hasn't gone alpha yet, so with each release of project-manager, you'll need to drop the data model, and start afresh. Upgrade scripts won't be provided until it goes beta.

Even if you don't have time to code, feedback like Andrei's makes a world of difference in the quality of this product. I very much appreciate it!

Posted by Jade Rubick on
Another note:

Your changes to default-master.adp affect all other packages, so if you'd like to make those changes, I suggest posting in the TIP forum.

Posted by Andrei Popov on
Does not seem to be moving, does it?  Looked like a simple change, but....
Posted by Jade Rubick on
Posted by Randy O'Meara on
Jade, I like the look of your forms and buttons. Have you developed a different forms template?
Posted by Malte Sussdorff on
I'd love to have this thread make a new forum, but well ....

Your screenshots look good. Are you going to use workflow deadline support or are you using your own (if in doubt what I mean by workflow deadline support, reask for the code, not sure it made it to the CVS).

TGDChart & Chartdirector support package should come up soon, we started with the first (not so impressive graphics, but okay) and ended up using the latter simply due to the need for stacked barcharts (not supported by TGD) and a mouseover imagemap (to display additional data for each segment of the barchart).

Posted by Jade Rubick on
Sorry, forgot to answer Malte's question.

I'm not yet using workflow. I didn't have the time to get it in, and Lars said it was always something that could be added in later.

I agree that another forum would actually probably be useful in this case. I understand the arguments against creating separate forums, but this thread is ridiculously long!

Posted by Rocael Hernández Rizzardini on
Why you don't have a monthy thread? (and linking previous threads)
I think when dotWRK reach a lot of questions by users, and it will, will be seen the need for its own forum.
Posted by Jade Rubick on
I made a new style sheet, yes.

Malte, have you thought about using SVG? It's going to be pretty amazing what you can do with SVG. We could make dynamic applications that do everything Flash does, but interacting with the database. I'm very impressed with it.

Posted by Talli Somekh on
Jade, Malte's right. Please start a new thread. This one is too long.


Posted by Jade Rubick on
I agree:

Here's a new thread on updates to project manager:

Posted by 123 PMP on
Posted by Raza Hassan on
[spam] content removed.