« Everybody loves Raymond | Main | Survey - Tell me what you like »

Object Oriented Scheduling - Part I

I mentioned in a previous post that traditional CPM scheduling is rather primitive. It has only two major objects, tasks and dependencies. You might suggest that resources are also worthy of considering, but actually in software like Microsoft Project it can be argued that they are a bit of an afterthought. My contention is that tasks and even the schedule itself is but one facet of a project, but before we get to building a better model for that let's look at how the current model can be improved. One way to do this is to improve the behavior of the tasks themselves. We can do this by adding additional properties or parameters which will change the way the tasks behave under different conditions.

The first and one of the more obvious properties of a task is the elasticity. We know that some tasks are quite fixed in duration while others are more flexible. Indeed, it is common to desire a task which will stretch automatically for the length of a project or a certain phase of a project. This sort of task is often called a "hammock task" and the method for creating one in Project is rather convoluted. Between the two extremes there are a range of flexibility in the durations of tasks. This may be due to the availability of resources upon demand (brought in to keep a task on schedule if necessary) or perhaps a lower priority or maybe the task results in something "nice to have" rather than something required.

Current scheduling software can not distinguish between the black of the fixed duration and the white of the hammock task, and as a result minor shifts in a flexible task impact the schedule projection to the same extent as a task with a hard duration. We can work around this by adding lag to the dependencies or other tricks, but ultimately we have to exercise judgement in determining if any slip is "real".

To get around this and to maintain a more stable model, consider adding a property to a task which determines its flexibility. Here I model the property as a spring.


Springs have a constant "k" which describes their flexibility. We could simply add a k property to tasks. A higher k would indicate a very stiff task and a low or 0 k would indicate that a task was quite flexible. Using the values of k and a measure of how much schedule pressure there is, we could obtain a more realistic model of how the work will actually be performed. Calculation of a network made of springs is more complex than the traditional critical path, but it should be nearly trivial for a modern computer. Why don't we start doing this now?

There are several more properties and methods I'll be describing in the coming days. Your comments are always welcome.


Comments (5)

Jack -- Can't seem to wrap my head around the need for such a task, other than as a buffer in a critical chain schedule. Anything can be streched to fit time allowed (Parkinson's Law), but I can't see the value of planning/projecting it in this way. Can you provide an example of the sort of actual work task that would fit this hammock characteristic?


Hammock tasks are often used for things commonly considered "overhead". Supervision on a construction site is a common use. Administrative functions often fall into this category as well. One of the issues in building a schedule is whether or not you should include such tasks. Some people will model them, others will not. Depends on how important it is to you and if you are tracking costs and resources on these tasks. If not, then they have little value.

The fact that they are optional points out that the current models of "projects" are insufficient. My contention - at least I think it is what I am trying to contend - is that a "project" is a subset of work performed. I think we need to recognize that and consider work in a larger context with "projects" as a subset. Financial systems include all the debits and expenses. You can't just count some of the income and ignore some of the debts without getting into a situation where you don't know what is what.

I think that work is of the same nature. It is the basic building block. Project schedules are just one thing that you can do with work. Limiting the planning/analysis/tracking functions to just "projects" as defined by PMI is a bit shortsighted. It would be easy to extend the same functions to cover things which do not fall into the classic project definition. Further, the limited world of tasks and dependencies is too narrow to model much of what goes on. If we expand or change them, we are likely to have a better model.

Yeah - OK - Overhead...

I've generally lived in the world of product/service development and implementation projects for which detailed/allocated cost tracking is of so much less importance than time to completion that I haven't had to spend a lot of time concerned with the cost tracking issue.

I do, however resonate with the last paragraph in your comment response, Jack, as my current work is in a small organization in which "the project" of implementation used to end with a fairly clean handoff to "production" of a program of managing the outcome for a period of time. However, recent growth and product mix changes have resulted in a blending of the resources involved in the project also being involved in the ongoing production. This has fuzzied up the resource/capacity planning a bit and has gotten me leaning toward thinking about the idea of the entire implementation/program being defined as a "project."


The last paragraph is the key. I'm getting less and less certain that "Project Management" is such a special case. Why is it set apart the way it is? Certainly some work is on what is defined as projects, but why have a different field of "managing" them?

Sig Rosenthal:

Great IDEA! Now, how to use it.

For years I have wanted to do the following in MSProject:

1. Schedule meetings for the duration of a project. These are usually weekly, and chew up resources.

2. Most of my projects are long enough (6 mos - 3 yrs) that I cannot accurately predict their duration.

3. Therefore, I would like the weekly meetings to be a "hammock" between the start and end of the project. Unfortunately, everytime the total project time changes (increase or decrease), I have to manually adjust the hammock. e.g. If the project shortens, the existance of the "meetings" tasks keeps the total project time line from shortening. If it lengthens, I have to add more meetings.

I can see how "elasticity" would solve the problem for a single task. I haven't figured out how to use it to change the number of occurences of a recurring task.

Post a comment

(Comments are moderated to fight SPAM and will be published after I have a chance to approve them. Thanks for waiting.)


The previous article is Everybody loves Raymond.

The next article is Survey - Tell me what you like.

Current articles are in the main index page and you can find a complete list of articles in the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.34