stuart@gargoyle.UChicago.UUCP (Stuart A. Kurtz) (04/29/85)
A (serious) criticism of MacProject: MacProject is not capable of preventing assignment of a resource to multiple projects concurrently. This is surprising, particularly as MacProject recognizes two different reimbursal strategies: so called multiple and single. Single reimbursal resources bill only for time spent on the job, independent of how many jobs are being performed concurrently; while multiple reimbursal resources bill for each task independently. The clear intent is that multiple reimbursal scheduling is intended for pooled resources, e.g., trucks, engineers (generic), secretarial help. For these resources, additional capacity can be achieved (at additional cost) by hiring more of whatever resource is required. Single reimbursal is clearly intended for dealing with specific individuals. This is all well and good, but MacProject will happily assign the same individual to two or more tasks simultaneously, and thereby realize an apparent cost reduction! This is unreasonable. Even more unreasonable, such "overuse" is not automatically reported, one needs to examine the full resource allocation window (normally invisible) to see that such a difficulty exists. Now of course, one can obtain single use (a.k.a. "mutual exclusion") in such cases by adding precedence constraints, but this seems completely out of spirit with the program: first, it requires the user to sequentially overspecify the problem; and second (far worse), if one does this, it is then the users responsibility to remove such constraints to obtain full generality if situations change. If this program did indeed permit mutual exclusion (can anyone thing of a reasonable single-use resource for which one does not want mutual exclusion?) it would admit many more applications. Some possibilities: designing a course, arranging the order of presentation of a logical argument (e.g., a mathematical paper), or even more reliable and flexible handling of the tasks for which MacProject is ostensibly designed. Stu <sak> ::= stuart | kurtz <address> ::= ihnp4!gargoyle!<sak> | <sak>@uchicago.csnet
mash@mips.UUCP (John Mashey) (05/01/85)
> A (serious) criticism of MacProject: > MacProject is not capable of preventing assignment of a resource to > multiple projects concurrently. This is surprising, particularly as > MacProject recognizes two different reimbursal strategies: so called > multiple and single. .... > If this program did indeed permit mutual exclusion (can anyone thing > of a reasonable single-use resource for which one does not want > mutual exclusion?) it would admit many more applications. ... > <sak> ::= stuart | kurtz I think this is a flaw also, but I'd prefer to have resources tagged as "exclusive" or not, and be able to get a resource-loading report [ although the existing resource report does give a quick idea here]. I think that many of the people I've worked with are "reasonable single-use resource for which one does not want mutual exclusion". I find that many normal activities are most simply modeled by using the elapsed time, knowing that one will only work on that activity on a part-time basis. [Ideally, one might be able to enter both elapsed & fraction worked, like some other systems, but that might complexify it more than its worth]. Actually, what I miss most is a convenient ability to hierarchically compose charts, i.e., so each person can keep more detailed charts, but get overall dates and times included in master charts. However, I still find MacProject to be a good thing: the downfall of many powerful project management systems has been the difficulty of getting people to use them. Even with its occasional irritations, MacProject has not seemed to have this problem. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!glacier!mips!mash ARPA: mips!mash@SU-Glacier.ARPA DDD: 415-960-1200 USPS: MIPS, 1330 Charleston Rd, Mtn View, CA 94043