Forum OpenACS Development: Re: dotWRK: Project Manager

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, www.achievo.org).

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.