This is here for historical purposes.

First of all, let's make up an example company that will use all the functionality we expect.

Instead of making up names, let's just refer to the titles of the people at this company:

• Project manager
• Worker #1
• Worker #2
• Salesperson
• Client
• Distributor
• CEO
• COO

The Project Manager hears from the Salesperson that the Client has agreed to purchase a product from the company. This sets off a bunch of work within the company, and getting this product out the door is a new project.

So the product manager sits down and enters in the details about the project. She enters in the deadline for the project, and which salesperson is the contact with the client. The client is also added to the project, so that they can watch the progress of the project, but in a more limited fashion.

After entering in information about the project, the project manager starts breaking down the work to be done. She may do this in two ways:

• She lists all the tasks that need to be accomplished.
• She then starts assigning who is to do each item (by assigning either an individual or a group to do the task)
• She then enters information like deadlines and dependencies.

or

• She enters each task, along with its dependencies, deadlines, and who is assigned to do the task.

As she is entering the Tasks, the software informs her of how scheduled the people assigned to the Tasks are, so that she doesn't overschedule anybody.

After she looks through the tasks, she then approves the project to go live. All the people associated with the project get email informing them that the project has been created. They also receive email for the Tasks they've been assigned to. The email informs them of how important this item is, and how much slack time is presently expected for this item. The email also gives them a link to the portion of the Intranet which shows their Task list.

The next day, Worker #1 comes in to work, and pull up a list of Tasks. Several of the items are flagged as more important because they have very little slack time before they will start impacting the project deadlines they are in. One of them has no slack time, but it is not that important of a project, so it is shown as less important.

Worker #1 clicks on that (less important) Task, and brings up the Task view page. This page shows information about the Task, such as when it needs to be accomplished by, how much time the project manager estimates it will take to accomplish, and so on. Worker #1 laughs at the time estimate, and changes it to something more realistic. This could send off an email to the project manager, but in this case, it doesn't affect the deadline very much, so no email is sent off. If it affected any other tasks or the deadline of the project, an email would be sent out to the project manager, and any other people whose tasks were dependent on this task.

Worker #1 returns to the main task page and sees that there are two other high priority tasks for the day. He works most of the day, and finishes the first item. He goes closes that Task, and the project manager gets an email (optionally) which informs her that the task is done, and any details that Worker #1 happened to type in. He also spends three hours on the second task, and enters in the time (or the percentage it is complete).

The project manager and the sales person are talking about the project at the end of the day, and the project manager pulls up the project to see how things are going. Only the problem spots are really highlighted, the rest is proceeding according to plan, so it isn't highlighted in any particular way.

The client checks his email the next day, and logs in to the Extranet for the site to see how the project is going. He has very limited access to the project, and is not able to see any comments that the team members have left. He is only able to see a broad outline of the tasks and details of the project. He sees one spot in red, and calls the project manager about it. The delay is because Worker #2 just added in his vacation schedule, and it shows that it will push back his tasks by a day. The project manager arranges to have some less-important work postponed, and assigns Worker #3 to the job.

Alternatively, Worker #2 may see how taking the vacation will affect the schedule, and go talk with the project manager before even asking for the time off.

---

Caroline Meeks:

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.

Jade's use case

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.

Torben Brosten's use 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.

Jade:

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.