HOME – Previous section of this example
Next section of this example -->
College Life: definitions
The student's basic problem: within constraints that I cannot control, how much of my time do I allocate to which activities?
Having decided that this situation can be represented as a system, the new goal is to define the situation in terms that will let me build a model that describes it.
After gathering the data and making a few tries at describing the situation, the result looked like this:
where
Where I am: The goal is to provide the student with a way of thinking about how to allocate time, but this picture doesn't seem to provide any obvious answer. I can't just say "make a schedule" ... because the problem is how to make a schedule. On the other hand I've collected the basic data. I know what the situation looks like in general.
What I do next: Before I can build a solid model, I need to pause and get myself organized. The most important thing to do is to define all of the terms that I am going to use in the model. That way no one ... not me nor the people who I am trying to help ... will be confused about the final result. I have the data, and I have a general sense of what the data means. So next step is to make some definitions and begin to organize the data in ways that might help solve the problem.
Definitions
One way of thinking about the situation is to see it as an event scheduling process. I used that term to make it seem important, because I think it is ... what I really want to do is give the student a method for scheduing events.
In order to schedule events there have to be certain frameworks: times or time slots ... something that tells us when the various events can happen. The events themselves need to be defined ... most importantly, each event has to start and end at a particular time. And there will need to be relationship rules for scheduling. For example, one obvious rule is that two events cannot happen at the same time.
So here is a first try at creating a set of definitions:
Timeslot: a time of day. In this case I'll make each timeslot be one hour long. And, since timeslots never overlap, I can make a timeslot framework for each day of the week. Assuming that the student starts the scheduled day at 8 a.m. and ends the scheduled day at 10 p.m., the timeslot frame would look like what you see in the graphic.
I emphasize scheduled day as a reminder that the model only takes care of the times that the student wants to allocate. The period from 11 p.m. to 8 a.m. is unscheduled and can be used for anything. (Sleep would probably be good, but at college you never know.)
Event: Something that happens.
Timed Event: an event that must be scheduled. Timed events will be put into timeslots.
There are things that the student knows will happen, but that won't or can't be scheduled. These Untimed Events will not be put into the model ... they will be in the environment. For example, suppose the student works as a bartender, and suppose that when a total of $100 in tip money builds up, he or she always makes a trip to the bank. This event will definitely happen, but there is no way to know exactly when it will happen. So it cannot go into the schedule.
Unpredictable events are totally unexpected. They will be taken care of as they occur. They may force the student to change what he or she is doing at the moment, but they won't permanently change the schedule. For example, a spontaneous party might break out to celebrate the school's winning a sporting event. This might cause the student to skip a sheduled event ... but the schedule itself wouldn't change.
Here is another example. Suppose that the student has a class scheduled at 9 a.m. every Wednesday. Now suppose that on this one particular Wednesday, the student oversleeps and wakes up at 9:30 a.m. This unpredictable event, overslept, wins out and the timed event, class, loses. The student misses class this one time, but that does not change the schedule.
I have to accept the fact that unscheduled events happen, but I do not have to include them in the schedule because that's not what I'm trying to do. My goal is to deal with the events that the student can schedule.
Overlap: This is a relationship. Two events are not allowed to overlap one another. Only one event can be put into a timeslot.
Priority: This is also a relationship. In collecting the data I noticed that some events have to happen at certain times ... the student has no choice. Other events can happen in any free timeslot ... the student has total choice. And some events have to be negotiated. I'm going to call this set of relationships "priority".
To start out I'm going to name the priorities "red", "yellow" and "pink". There's no particular reason for this ... these are the colors I chose earlier when I was drawing up the first picture. Red events cannot be changed. They are not controlled by the student. Yellow events are totally controlled by the studen. Pink events are not controlled by the student, but the student has some ability to choose among different events or to negotiate their times.
Source: Events that have the red priority require input from the environment. Some pink events require input. I need to include the sources because the student needs to know who to talk to to get the time of a red event or to negotiate the time of a pink event.
OK - Stop and Think
Huh? What? It was going so well ... why stop?
For one thing it looks too easy. From your point of view I'm just moving along, cranking out these definitions like there was nothing to it. But it's been much harder than that. I've spent about five hours over the last three days thinking about this problem and coming up with different ways of defining it. I can't show you that work, but it happened and it matters. You don't usually get these things right on the first try.
For example, why are there three kinds of events? Why not four or seven? And what about the pink ones ... some of them had source connections in the environment (like work) and some didn't (like classes). Does that matter? Maybe pink should be split into two categories.
Well ... there are three kinds of events because three is a small number and I want to keep this simple. Maybe pink should be split into two, but I don't have to decide that now. I am going to update these definitions several times as I build the model and there's no need to try for perfection at step one. I might even have to throw the whole thing away and start over. So all I want to do now is come up with something that makes sense and has a chance of working out.
For another thing, you should notice that I am using this color to indicate definitions. I'm doing that because I want to make the definitions stand out. Every designer develops his or her own set of tools. If you don't like colors, you can use something else ... but you will find that you need some way of organizing your work.
For another thing, what about homework? Doesn't the student do homework and shouldn't that be part of the schedule? Well ... it didn't show up in my data. Maybe this student does homework at random free moments and doesn't schedule it. More likely, the student just forgot to mention it. Again, the model will go through a series of updates ... I'll catch the homework later.
But that shows you a basic problem of systems thinking. If you don't put it in the model, it never shows up in the solution. The purpose of doing all of the criticism and reviews and updates is partly to make you think about what might be missing. (And also about what might be extra and can be cut out.) I keep saying this, but it deserves the emphasis: it's not about the model ... it's about all the thinking that the model makes you go through.
What's Next?
This seems to be a reasonable starting set of definitons. Now I need to use them to build a model and test the model to see if it works.
Next section of this example -->