Forum OpenACS Development: Re: dotWRK: Project Manager

Collapse
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.

Collapse
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? 
</blockquote>

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:

Actors:

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

Projects:

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.
http://www.edwardtufte.com/744545307/bboard/q-and-a-fetch-msg?msg_id=000076&topic_id=1&topic=Ask%20E%2eT%2e

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.
http://www.columbia.edu/~jm2217/

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:
http://www.doc.mmu.ac.uk/online/SAD/T04/projman.htm

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)

Users

  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

Requirements:

- 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?