Forum OpenACS Development: Preliminary vision statement open for discussion

All,

I've tried to come up with a summarization of all the things said 'n done around dotWRK during the past weeks and put it in the form of a prelim. vision statement.

Please have a read and comment.

Also, there is an updated people list on the project page.

Rgds,
Jeroen

Whether that is a separate package, dotLRN related stuff back-ported into oacs or something else is of course open for discussion.

In case there's any doubt: I'm not trying to force the *result* in any particular direction, I'm trying to force the *process* in a particular direction.

And so far a lot of people seem to have slightly different ideas when they hear 'dotWRK' - we need to resolve that first before we jump into solutions for yet vaguely defined problems. This thread is meant to get everybody explicitly on the same page.

As soon as there are some more posts I'll do another summarization attempt.

Can I interprete that as 'taking the general bits out of dotLRN and put them into a package on their own'?

In that case I couldn't agree more. Question then becomes what bits should be taken out and how to be repackaged?

Logical things could be:
- the portal stuff (already a separate package)
- generalized version of 'community' (i.e. departements are communities, project-teams are communities, ...)
- ???

This is exactly my question - what functionality should go in the 'umbrella' packages and what will eventually be dotWRK.

• portal pages
• a standard way to 'portletize' oacs applications
• solid generic group management
• a generalized version of the 'community'-thing in dotLRN
• perhaps role-based access control
• a way to define 'portal templates'
• i8n support? (perhaps more oacs's task?)

OpenACS already provides a solid generic group management facility - please study the groups and relational segments datamodels and supporting code. dotLRN provides a good working model for how a vertical application can use these tools. The problem in OpenACS per se is that there's not a practical UI for making use of these facilities in our subsite package. Lars Pind has the design of a new UI on his plate. My personal thinking has been to map role-based access control onto the group/relseg datamodel - the datamodel supports more sophistication than this but I think for a standard subsite package, role-based access control is something that's fairly easy to define a good UI for and is something that users will find fairly easy to understand. Packages or vertical apps needing more than this probably won't map to a generalizable solution that will make sense anyway, IMO, but since the datamodel is so general custom group management code is easy to to write.

The current OpenACS acs-subsite admin UI actually lets you do this (well, in 4.6.2 you'll be able to do this, since some of the bugs/quirks in the code have been fixed), it's just incomprehensible, that's all.

My recommendation is that the dotWRK folk concentrate on applications for the time being. Since the portal system simply maps templates to portlets, it's often possible to share template chunks between your portlet and non-portlet pages that provide views of data. So if you get the application right, generating portlets will be very simple in general. Maybe a day per portlet, something like that.

And on the application side I'd recommend concentrating first on the datamodel for the various pieces. How do we want to represent the various resources within an organization and how do we want to tie them together? I think the calendar package is a great example of what happens when too much effort is expended on writing code that provides pretty displays and far too little effort is spent on designing the datamodel.

Let's not repeat that mistake!

There's a lot of application code that needs writing before dotWRK can become a reality. By the time a dotWRK group makes significant progress in this direction I think you'll find that the issues in the bullet-list that heads my post will be solved in the general toolkit.

Of course, dotWRK will undoubtably want to layer custom UI on top of standard portal management and group management facilities that already exist, but that's a different issue ...

From my point of view, all these core facilities fall under the dotWRK hat from a "use case" and "push" perspective: We need it for dotWRK, therefore Jeroen and others can help clarify the requirements, use cases, and people who need dotWRK will be well positioned to develop this.

That doesn't meant that the code should live in some dotWRK package, or that it should be specific to dotWRK in any way.

/Lars

Malte, I envision building a program (ie. large scaled project) cost estimating, scheduling, charting, and coordinating capabilities (call it "dotSystem") into OpenACS for manufacturing/development cycles, operations management, and building construction starting with top-down metasystems modeling and methodology. You're right that these are long term goals.

Adding a statistics package will be a critical component. [I was going to suggest adding a statistics package for dotWRK on a previous post but really think it should wait until dotLRN is folded back into OpenACS with the dotWRK goals currently outlined --to save duplication of efforts. Also, I wanted to refer to the postgres statistics package that a couple of OpenACSers are playing with... but can't find the forum reference about it right now.]

On another point, there seems to be a behavioral pattern within the OpenACS community to  wait until funding before starting on such a long-term endeavor. Doesn't this assume that MBAs etc. will seek such a solution from OpenACS, or that OpenACSers will be able to sell it to them before making it?

I have great confidence in this community. Still, isn't the MBA culture much different than opensource's gift culture? I think the efforts needed to sell (compete) would be enormous. [Yes, there are MBAs who do not follow the MBA cultural values as implied and generalized here, and who would choose OpenACS. One of my best friends is one. I don't mean to offend anyone, just be matter of fact about the cultural values in general for purposes of discussion.]

One MBA rule implicitly states that paying for development work is generally much more risky than paying heaps for an existing (therefore predictable) solution --ie. the Oracles and SAP's will "win" on these terms for all large projects because they already have solutions.

Yet, I believe these terms ignore the potential of the open source culture to create effective solutions for meeting the demands for dotSystem capability outside of the enterprise business environment (as well as in it).

As long as long-term goals do not impinge on short-term, similarly aligned objectives, I see no reason to wait.

Our company is interested in a lot of these applications. Scheduling is one that we've discussed recently, for example, and we'll probably use anything that works for us that we as a group build. I'll probably focus initially on project management and task management (tickets).

I don't really see anything preventing us from starting to build these applications now. We just need to coordinate how we'll work together to get it done, and make sure the parts work well together, no?

Still, Lars may have a point imho when he says "all these core facilities fall under the dotWRK hat from a "use case" and "push" perspective". While defining the requirements for the various applications I guess the dependencies to (currently) dotLRN related stuff will become clear. By that time we can signal this to the relevant group (Don - do you represent the 'relevant group' in this case?)

So the new question-of-the-day seems to be - what applications, in what order and who's gonna do what?

For sanity sake - let's start with 'what applications'?

In the doc I posted I'd already listed a couple of apps that seemed to be wanted, based on the various forum posts.

Giving the 'people' list another look shows that project mgmt. type of stuff is firmly on the number one spot.

In this category I think of applications like:
    * project repository (i.e. CR for projects)
    * project scheduling & reporting
    * collaborative todo-list/task tracking
    * resource management
    * timekeeping (linked with scheduling and task-tracking)
    * holiday booking (idem)
    * expenses (idem, budgets)
    * calendaring
    * messaging (chat, im, mail)
    * wiki (i.e. general purpose information sharing)
    * document storage
Some things may already be available - I guess.

I wouldn't mind working on wiki (currently playing with dave's code) <off-topic> - on the wiki topic, what is is your [Jade] opinion? I saw in the wiki-thread that you were in doubt whether to adopt Dave's code or the extend some other wiki package? </off-topic>

Anyway, From a logical point of view, if we like Nick's 'project repository idea' (do we?) it would be most sensible to implement that one first before project scheduling and task-lists (in fact - if you define a project to be a collection of tasks and people tied together by a schedule, then a collaborative task list is just a project without a strict schedule, isn't it?)

But I'm losing focus: lets first see what applications we want.

BTW - I think there're actually more dependencies:

Project scheduling requires:
  -- timekeeping ('already used' time can impact the schedule, especially if it is more than planned :(
  -- task/todolist (and phasing - lets not forget that! Very important for projects)
  -- resource allocation
  -- holiday booking

If you add it all up then the workorder would likely look like this:
1) project rep (indeed the most fundamental)
2) resource manager
3) scheduling
4) phased/categorized task/todolist (a normal tasklist simply has one phase)
5) timekeeping, holidaybooking, expenses
6) project scheduling
7) project reporting

And the current calendar datamodel sucks for this.

So a root dependency would seem to be "rewrite the calendar datamodel so it is easy to map arbitrary content to calendars".

There have been threads about this elsewhere but it doesn't hurt to make the need for this for dotWRK explicit in your list of dependencies.

Calendar is basically some GUI on top of acs-events using datetime for some widgets. You can certainly do all you need with events, but of course it would be better to rethink calendar. There was another thread I started a month or so ago about changes needed to make it work. I can't find it now though.

Search is very important.

So we really want a unified search package, that can use OpenFTS on postgresql and Intermedia on Oracle. This allows package authors to provide content via service contract and not worry about what database is being used.

Along with this, we need to add package specific, package type specific, and object type specific searches.

The search should probably also allow searching in categories through integration with a general category system.

These are all OpenACS specific items that will greatly enhance any site, but are definitely important for a dotWRK project.

(I'm not implying he's wrong about technical comments, he's just the first to bring up - dare I use the word? - marketing points)

It would be really great to get a logo put together soon, and to use it on the project pages in order to differentiate them from the generic openacs.org part of the site, such has already been done for dotLRN.

Anyway, with respect to competetive analysis, we could start here http://www.adtmag.com/article.asp?id=7349 and here http://www.adtmag.com/article.asp?id=7350. Although may be a little OT - see below for simpler examples.

Then, more than anything else, KISS!!! From the packages mentioned in articles I've worked with Primavera and MS-Project. Both are feature-loaden, but for most projects at least 50% is rarely if ever used and even doing simple things can be difficult.

PM tools are administrative tools, mainly to help you rembember what you otherwise would've forgotten, help you to reduce the mesh in your head, to confirm your gut-feel and to communicate that gut-feel to others. But that's just my view.

I'd say let first get the basics right:
- proper work breakdown structure
- simple scheduling of tasks within the wbs
- a risk/issue register
- proper support for interdependent projects (i.e. ability to have projects containing subprojects)
- links between timekeeping, holidayplanner & plan
- may be a GANTT or PERT chart
- sensible resourcemanagement, linked to timekeeping and wbs/schedule.
- some collaborating tools (e.g. shared filestorage, wiki, forum, ...)

That way you cover the basics pretty well, and more sophisticated things can always be added later as an add-on package. Especially if we go for the 'project repository approach'.

But why not post it as a question in alt.projectmgm and/or alt.comp.projectmanagement. Expect a lot of flaming/off-topic remarks (like 'why would you do that' and 'pm is not about the tools', etc.), but we might get some sense out of it.

Another source of information are of course related projects such as (note - I did not put those links here as 'this is how we should do it', most are actually terrible, just a peek at the competition):
http://www.achievo.org/ (I've used this before, and it's actually very usefull, bit limited though and not that easily enhanced)
http://www.dotproject.net/demo.php
http://www.ace-solution.com/demo.php
http://www.epiware.com/
http://udpviper.com/html/project.php?project=ipm
http://mrproject.codefactory.se/ (desktop (X) app, very simple but effective for simple projects)

A couple of them are open-source, so we might consider looking at how they work as well.

One thing our company will likely need is the abiliity to associate structured data with each project. For example, details on the product (if the project is product related), and who in the graphics department is working on it, etc..

It's probably a little early to be making comments like this, however.

Sorry if the below sounds a bit like a rant - it's not meant that way :)

""" In short... no we are not. """
I agree, but for different reasons.

"""MS Project is an application used by PMs to schedule, plan and monitor a project. """

And that is indeed the job of the PM, although I'd say replace 'monitor' with 'control'.

""" But is it the right tool to be used by all members of a project team?"""

No - and they're not supposed to. The tools in the kit that are for 'them' are things like documentrepository, (collaborative) todo/task-lists, timekeeping, perhaps chat/forum/wiki.

The wbs, scheduler and nice views are for the pm to maintain. They may see them of course, but should not touch them.

""" The project tools that we want to develop for dotWRK should allow project team members to update their "actual" progress. This will allow the PM to compare the differences between "estimated" duration and "actual" duration, """

That won't happen. Only way you can get project members to report accurately is to link it with the timekeeping system and link the timekeeping system with their payroll. And even then :(

""" and if the project is not on track, then the PM can take the appropriate course of action to get the project back on track. With this sort of project reporting (from team members) at a micro level, the PM is able to estimate Earned Value more accurately as well. """

How many projects did you lead where 'reporting at a micro-lvel' actually worked? In my experience pm is 80% communication. If you /need/ the tools to tell you what went wrong, you should not've been the pm in the first place imo.

For that particular reason it's important to keep projectteam size within you max. span of control - typically not more than 10-15 people (for an experienced pm that is). If it gets bigger, divide in subteams and manage the subteams/subprojects, not the people or the whole project. And at that stage you get a project that consists of interdependent subprojects, where the teamleaders maintain their own schedule, which you incorporate in the main one.

""" This kind of feature will make the dotWRK PM tools quite powerful, as the progress of a project becomes more transparent. """

A clear plan of approach, good reporting, having a well maintained risk register make them transparant. Micro-level updated GANT-charts don't.

Then why do I agree with "we're not replacing ms-project":
- indeed because of the collaboration-angle
- and it's too bloated. Having a good foundation on top of which we can build more advanced stuff later (i.e. when there's actually demand for the advanced stuff) is far more valuable imo then the everything-but-the-kitchen-sink approach.

What I meant by "reporting at a micro-level" is having developers report their effort spent on a task upon completion.  I was coming from a software project management angle, as I have worked for a company developing software project management tools.  Some of our clients were defence contractors that were trying to achieve a higher CMM level, and therefore had mature software processes in place.  Maybe I was thinking too far ahead, or beyond the scope of what we want for now.

Regards,
Nick.

I wasn't referring to "micro-level updated GANT-charts", I was referring to improving earned value estimates with micro-level reporting.  I'm not sure if earned value analysis (budgeted cost of work performed) is commonly used in Europe, but its heavily used by US and Australian departments of defence in software projects.

I agree that we need to develop a good foundation.  Perhaps more general PM tools are required, and not ones focused on a specific domain such as software project management.

Regards,
Nick.

Sometimes authors can provide quick experiential substitutes for surveys when they summarize norms (and limits).

Here are some comments from Eric Verzuh, author of "The Fast Forward MBA in Project Management: the portable mba series" published by John Wiley and Sons 1999, page 281 to 285 quoted and summarized below:

"No matter which kind of project information system a company might choose, there are a number of considerations that will influence the effectiveness of the system and the effort to install it.  Here are some guidelines for developing.. [one].

"Start with reporting requirements... the information requirements for the system must be clear.    The basic questions that drive the entire system are:"

"Who needs information?"

"What information do they need?.. what decisions or actions will be based on the information?"

"When do they need it?"

"Where will the information come from? does it exist anywhere now or does it need to be created?"  there is a need for consistent standards for entering data at the detail level (pg283)  [It seems that an ability to assign to any instance (financial, calendar, resource, content) with at least one WBS reference (which designates responsibility and authority roles etc.]

suggests "top-down design of a work breakdown structure"

Customization is a given part of any off-the-shelf system

"if your organization runs many small and medium-size projects, you'll want to use the simpler applications at the project level. These lower-end applications may not have enough power to pull data together from all the projects, however; you will need to choose one of the high-end applications to handle that chore"  [I think this implies ability to dump data to spreadsheets or external DBs for starters]

a pm system only works if it gets used consistently and completely --ie users don't bypass it, suggesting that the system needs to be user centric and user friendly.

"The true potential of a consistent approach to pm is realized only when the discipline is extended to the organizational level and used to choose, monitor, and cancel projects. The ability to link projects to the operational and strategic goals of an organization has far-reaching implications for the effective use of resources, particularly people."

"Like good pm, portfolio management delivers the best results when it is based on facts and data. The project information system empowers the portfolio management process by providing the facts that drive decisions".

"The Spectrum of Project Office Models... The two factors that govern a project office role are responsibilities and authority (full, partial, none).  [Hmm. this granularity should adapt well to the user-group permissions in dotLRN (as I understand them)]

--end quotes

I think these comments suggest some rudimentary customizable resource/info sharing packages that where hinted at previously.  Since OpenACS' strengh focuses on collaborative work, I don't know that it would be wise to model after non-colaborative pm-based software solutions, given that pm systems work best when the entire project team participates. These packages need to be user-centric while providing the pmgr with the necessary operating info also.

It's really a pity - I've seen the dotWrk pages only a few days ago. Even Dirk Gomez didn't know about them. So I think I have duplicated some efforts...

I'm working on a similar project since June 2003. I started as a project management system for a local translation agency (http://www.sls-international.com/ - someone needs _high_quality_ translation into Spanish? 😊. Briefly checking for alternative system, I decided to go ahead with the old ACS 3.4.8 Intranet that is in productive use at Competitiveness (http://www.competitiveness.com/) with a few enhancements. So I spent the summer customizing the system and building a reasonable business solution.

Telling a few friends about the project and showing them the new GUI, they encouraged me to widen the scope and to actually design a "Project Resource Planning" platform, providing support for several vertical modules (Hi Malte!). So http://www.project-open.org/ popped up into existence.

Recently things got even a little more encouraging. I managed to convince a student from Universitat Politecnica de Catalunya to write his final thesis about building a translation marketplace module for Project/Translation and La Salle University approved a Knowledge-Management workgroup, staffed with 4-5 final thesis students. They are going to use Project/Open as their development base.

So the idea is starting to convert itself into real systems. I'm planning to publish some press releases as soon as I've got a reasonable demo system online.

The drawbacks of the system are its ACS 4.5.8 base, its lack of multilingual support and the restriction to Oracle. And I had to customize the platform quite a bit, in order to get a new fine-grained permission system working  (http://www.project-open.com/whitepapers/).

Code is currently not available publicly, because Project/Translation contains customer owned code. The current "Project/Advertizing" project with Opus 5 (http://www.opus5.info/, currently my first priority) will lead to a modularized system and the release of a "core" module and an "advertizing" specific extension module. I hope to finish this reorganization around 11/2003.

A lot of things are still open to discuss or clarify:

- Is Project/Open going to be a separate project, just using the ACS/OACS platform, or is it going to be integrated into OACS?

- How to design the relationship between dotWrk and P/O?

- How to deal with conflicts between the open-source idea and commercial interests? What does the history of ArsDigita and the current state of the OACS system teach us? How to integrate "business guys" into "the community"?

- Is OACS going to take over some of the P/O concepts, such as the fine-grain permission model and the configurable views?

- ... and many more.

Anyway, I think the follow-up discussions should take place in another thread, not to trash the great contibutions above...

Bests,
Frank

mailto:fraber@fraber.de, http://www.fraber.de/

=> Please don't reply to this message

I've created another thread, called "Announcing Project/Open" in ACS Development. I think it would be a great idea to continue the discussion there.

Actually, I created two threads (fuck, I think I'm getting old...). I've marked one of the threads as invalid. It would be great if somebody with admin permissions could delete it to avoid confusion.

Dave, I'm still developing with ACS 3.4.8 and I have to admit that I'm not familiar with the current OACS permission model. My permissions forms a matrix between user profiles (managers, project managers, employees, accountants, freelancers, clients, ...) and permission to modify business object such as view_freelancers, edit_freelancers, add_freelancers. Check it out yourself (http://www.project-open.com/whitepapers/ and "Permission Model"). And let's continue the discussion in the other thread, ok?

Bests,
Frank

mailto:fraber@fraber.de, http://www.fraber.de/