CISE Senior Project - Time Management and Presentation Skills
This Web page discusses time management issues for your project, and outlines some do's and don'ts for giving a presentation.
Time Management is the art and practice of scheduling and using the time available to you for Senior Project, so that you can:
- Complete your project on time, to meet specification;
- Build a working prototype (hardware, software, or both);
- Complete and submit your final report to your advisor, at least a week before your final presentation; and
- Plan and deliver all your presentations successfully.
Let's examine how to achieve these goals. First, you need to have a plan, which you should have devised as a requirement prior to the first meeting. This is called the Senior Project Plan, and outlines your effort in a taskwise fashion.
There are several ways to plan your project. The one most favored in business and industry uses a device called a Gantt chart to plot your activities as a function of time. A sample Gantt chart is shown below, in ASCII characters, for a project having four tasks, and four months to complete those tasks.
Task Month of Study No. 1 2 3 4 -------+-------+-------+-------+--------+ 1 |XXXXXXXXXXXXX | | | -------+-------+-------+-------+--------+ 2 | XXXXXXXXXXXXX | | -------+-------+-------+-------+--------+ 3 | | XXXX | XXX | -------+-------+-------+-------+--------+ 4 | | | XXXXXXXXXXXXX | -------+-------+-------+-------+--------+In the preceding chart, Task 1 is performed throughout Month #1 and most of Month #2, and overlaps with Task 2 in the latter part of Month #1 and for most of Month #2. Similar comments can be made about Tasks 2, 3, and 4.
Note that this Gantt chart is structured such that only two tasks are active at any given time. This is called load balancing, and you can think of it like scheduling tasks on a computer. As an example from operating systems practice, if you have a computer that can perform only two instructions in a given time slot (two-fold parallelism), then you don't want to schedule 20 tasks in any one time slot. The algorithm that schedules tasks for the processor(s) will likely expend much I/O effort swapping tasks in and out of the CPU(s), and little work will get done. This behavior is called thrashing, and is unproductive.
Humans tend to function similarly, especially those of us who like our work - we tend to pile up many tasks without regard to their size or requirements, then try to do too many tasks at once. Similar to the thrashing processor in the preceding example, we tend to expend a lot of effort trying to keep the tasks in order, and comparably less effort getting useful work done. That's why we try to schedule just two or three tasks for one person to perform at a given time.
In practice, most people can do one or two things well at any given time. It's always nice to have a task to fall back on if your primary task gets difficult, or if you need to take a rest from the main thrust of your work. Some people can function well when they have three things to do, but few people perform efficiently with more than three tasks "on their plate" (so to speak). You can think of this like a juggling paradigm - juggling one object is boring, while juglling two is more interesting. Juggling three objects is a challenge, and there are few people who can juggle four or more objects at a time - human perceptual and cognitive systems just don't support the associated mental and physical requirements.
Action Item #1 To help reduce thrashing, the first thing to do is block out your effort by
- Decomposing project tasks into subtasks;
- Scheduling the subtasks so that you have one or two (but no more than three) active at any given time;
- Determining ependencies between tasks or subtasks, as discussed previously, and scheduling the dependent ones later in the effort; as well as
- Allowing about twice as much time as you think you will need for each subtask (to accomodate Murphy's Law).
Let's briefly talk about decomposition. For example, if you have a software development effort, you might have tasks such as (1) Design, (2) Coding, (3) Testing, and (4) Documentation. Your software project could have, for example, communication, math, and report-writing modules. So, you might want to decompose Tasks 1 and 2 (design and coding) into subtasks (1.1) Design communications module, (1.2) Design math module, and (1.3) Design report-writing module, and similarly for coding.
When you schedule these subtasks, you want to respect the dependencies between them. For example, you would not want to code the communications module before it had been designed, and you could not test the communications module before it had been coded. A well-accepted means of representing dependencies is a Pert chart, which uses directed arcs to show how tasks depend on each other. A combination Pert and Gantt chart is shown below, for a three-task project elaborated to the subtask level.
Figure 1. Combined Pert and Gantt charts for a project with three tasks.For example, in Figure 1, there is a dependency chain between Subtasks 1.1, 2.1, and 3.1. That is, Subtask 3.1 cannot be started until Subtask 2.1 is completed, and Subtask 2.1 cannot be started until Subtask 1.1 is completed. In contrast, Subtask 2.3 can be started when Subtask 1.3 is half-completed (in time), since the base of the Pert-chart arrow that connects Subtask 1.3 to Subtask 2.3 is located midway along the timeline of Subtask 1.3.
Self-Exercise: Find all the dependency chains in Figure 1.
Once you have your subtasks arranged, you need to balance your effort. For example, at the outset of the project whose schedule is diagrammed in Figure 1, there is only one task being performed. During Months 10-11, there are four concurrent tasks scheduled.
Self-Exercise: Redraw Figure 1 so that there are either one or two subtasks being performed concurrently. Respect dependencies between tasks and subtasks.
Action Item #2: Once you have determined what schedule you want to pursue, then you need to apply yourself and get `the work done. Of course, this is the hardest part - anyone can draw pretty Gantt or Pert charts, but few people can follow them closely. As stated above, when planning you should allow plenty of time to deal with the effects of Murphy's Law. Also be sure to pace yourself. The latter means not allowing work to pile up, then walking away from it, but getting a more-or-less regular amount of work done each day. Building these orderly work habits now will pay off immensely when you get into business, industry, academia, or government. Meanwhile, your less disciplined colleagues will be thrashing at their workload, while you can be plowing along, getting useful work done at a more-or-less regular, predicable rate.
Now that you have a basic idea of how to schedule your work, let's talk about presenting your results.
Technical Presentation Skills serve several purposes, which include:
- Conveying information about your work;
- Presenting an image of you as a person and as a scientist, engineer, or manager; as well as
- Inducing a mindset in your audience that is conducive to support of your work.
Let us examine each of the above objectives, as follows.
1) Presenting Information About Your Work is a necessary component of technical endeavor. Without communicating your thoughts and research/development results to others, you cannot do much beyond creating interesting and (possibly) useful software or hardware gizmos. Most of these widgets will not see the light of day, and as a result you will not be appreciated within the organization that employs you. This means the rather dreary prospect (for most people) of no promotion and little or no job security. Science and engineering organizations are replete with intelligent people who can't communicate very well, and thus end up on the "bottom of the heap" spending their lives as low-paid drudges. For an intelligent, creative person, such jobs tend to be boring at the least and intolerably stultifying in the typical case.
To promote your work, you must be your own salesman. Others will usually not do this for you, especially in an increasingly competetive global business environment. Promotion of your work is typically realized in three ways:
- Routine informal communication in the office, with colleagues;
- Written communications, ranging from software documentation, technical notes or memoranda, technical reports, user and technical manuals, to research papers, book chapters, or books; and
- Oral presentations at a conference, or poster presentations supported by an oral explanation.
In the latter category, we focus on oral presentations, which should show (a) the utility and novelty of your ideas or results, (b) how your ideas or results could (or can) be applied to problems of practical interest to your employer or customer, and (c) the plan you propose, are implementing, or have implemented, to achieve your objectives or results.
2) Presenting an Image of You as a person, scientist, engineer, or manager cannot be emphasized enough as a tool for promoting your work. The reason for this is quite simple: most people, whether technical or non-technical, do not necessarily relate well to new ideas or results at first glance. In other words, humans have little tolerance for change.
For example, if you are proposing work-saving software, your co-workers (and, perhaps, your boss) may be immediately most concerned about how this development might impact their job security. If you come across as a hard, demanding, or threatening person, their natural instincts toward suspicion will likely be reinforced, and your ideas might find little or no support. On the other hand, if you present your ideas in a simple, honest and nonthreatening way, then your audience (including technical people) will be more willing to see beyond the humanistic issues and try to understand and appreciate the technical points of your presentation.
This is especially true in organizations where you might be interacting with a "professional manager" - a person who has little or no current knowledge of technical trends, but is in the position of managing or influencing others about your work. Such people exist and tend to populate large organizations. Because of a lack of current technical knowledge, they may feel somewhat uneasy in a scientific or engineering discussion. Entering your presentation with such feelings tends to prejudice their judgement against you, and you must therefore work all the harder to present your ideas or results in a way that gains their trust and support. Since their technical background may be shaky or nonexistent, you need to present the following:
A colloquial ("plain-English") overview of your work that is not tinged with negative emotion or excessive positive emotion. This part of your presentation should show that you have (in the manager's estimation) a sufficient and positive grasp of the subject matter, have thought through the associated problem(s), and have developed one or more workable (proposed or implemented) solutions. It is usually advisable to address the context of your work in a few sentences, i.e., how your effort fits into your organization's goals, ongoing programs, and (if applicable) into a larger economic or social context.
Concept: Note that these are almost entirely humanistic considerations, which is consistent with the presentation objectives that we are discussing in this section.
A colloquial overview of prior work from the literature, with supporting but not excessive technical detail. This indicates to the manager(s) (and, possibly, your colleagues not skilled in your area of presentation) that your work is based upon prior achievement. In the manager's estimation, this is a sign that you are not "off the wall" and a potential risk to his/her program(s). In contrast, technical people tend more to interpret a literature overview as a sign of honesty and thoroughness.
Concept: As in the previous item, both perspectives are steeped in humanistic considerations.
Your approach to solving the problem(s) you posed in Item 1, above. This must be simple enough for a nontechnical manager to understand, but complex enough to hold the attention of technically oriented managers or colleagues. Of key importance is risk assessment, where you present estimates of how risky your approach will be. This gives the nontechnical listener an idea that you have not only thought out the approach in technical terms, but have considered some of the organizational implications of your proposed or implemented approach.
Concept: While this may seem trivial, such issues are of key importance to managers, because their reputations (and, hence, their compensation) usually depends on the success or failure of the programs they manage.
An overview of results helps establish the credibility of your work in others' minds. Most humans are "from Missouri" - they have to be shown that something is workable. The reason for this is that humans are creatures of economy. Thus, it is usually preferable (i.e., easier) to watch a demonstration that to work out theory or engineering designs in one's head as a presenter says something like "...it's really obvious how this works..."
Concept: The importance in humanistic terms of a simple, supporting demonstration cannot be overstated. To a manager, this is yet another feature that shows some dependability on your part - a value prized by most humans.
A brief discussion of lessons learned as well as planned future work again helps establish credibility. Keep the discussion simple and focused on what you learned in the project. Also try to mention two or three practical aspects of the study that you would like to investigate.
Concept: In humanistic terms, this can reinforce the managerial perception that you are a forward-thinking but realistic individual that could become (or are) an asset to the organization.
Thus, the objective of presenting an image of you (hopefully, a true account of your behavior) has as its goal the induction of humanistic perceptions in managers as well as technical colleagues. In leading-edge Western cultures, the virtues you want to portray are: honesty and forthrightness without being brash, confidence in yourself, your work, and your colleagues, and a sense of caring about your work in relationship to larger contexts such as your company or organization, society in general, etc.
In more traditional cultures, the high-priority criteria can be different, i.e., obedience, respect for authority, diligence, technical ability, and adaptability or conformance to the prevailing organizational or social context. Sometimes, these "traditional cultural values" are embraced by Western managers and thus should not be thought of as being absent in Western organizational contexts.
3) Inducing a Mindset in Your Audience that is Conducive to Support of Your Work - At this point, you might be asking yourself if this isn't the topic we just addressed. In fact, we just talked about presenting a positive, convincing image of you as a person. In the following few paragraphs, we are going to discuss concepts of how to present your work in a more positive and convincing way, but from a perspective that might be more intuitively attractive to your audience.
Presenting a technical subject to an audience that consists in part of people who might support your work is a well-known task of a scientist, engineer, or manager. In a sense, you are trying to "sell" others on your idea(s), some of which might be supported by one or more preliminary results. As in item 2, above, you should:
Win the confidence of your listeners by presenting your work in a simple, honest, and believable way;
Present your ideas in a way that supports the aims and goals of your employer or supporting organization (real or potential); and
Provide supporting literature, theory, and (if possible) preliminary results or simulations.
Additionally, there are other humanistically-related considerations, including appearance, diction, and clarity, which we discuss as follows.
Personal Appearance is a very important component of a technical presentation. Technically-oriented people might not mind if you appear in ragged jeans, scruffy t-shirt, etc., but management folk tend to see this as an indication of possibly being a slovenly person. Those who do not understand your work, or who might feel threatened by it, will likely have their potentially negative feelings reinforced by an appearance that does not meet their idea of minimum acceptable standards.
Thus, the following guidelines for personal appearance are suggested:
Business casual - For the men, trousers, collared shirt or turtleneck, closed dress shoes or casual shoes (with stockings). Athletic shoes should not necessarily be worn for business casual. For women, the same or with optional skirt or dress and optional open-toed shoes, stockings not necessarily required.
Business formal - For the men, dark suit, shirt and tie, closed dress shoes or casual shoes (with stockings). Athletic shoes are never worn with business formal attire. For women, a trouser suit or skirted suit with blouse or open shirt, easy on the jewelry, also closed- or open-toed shoes with stockings.
Hair and nails should be neatly trimmed. Believe it or not, there are still some managers who judge a person's work by the cut of their hair or condition of their fingernails. For men, if you are wearing long hair, pull it back into a bun or ponytail, and make sure your hair has been recently washed. If you have short hair, make sure it is combed. For women, neatly done hair and a nicely tailored suit convey a sense of refinement and, in a formal situation, can impress managers with an image of strength and elegance.
Important DON'TS - Don't wear strong cologne or perfume, as this can irritate members of your audience who have allergies. Don't wear light-colored clothing for business formal, as this tends to convey a more casual appearance. Don't wear ill-fitting clothes - have someone knowledgeable in fashion or personal image check out your attire (while you are wearing it) before you give your presentation.
Appearance of your viewgraphs is also important - avoid cluttered slides with small print, large numbers of equations per slide, or graphics that are loaded with fine detail. This especially alienates managerial types who are trying to figure out what you are talking about, and tend to feel put down by a morass of technical detail that they cannot see or understand. If you have to present large amounts of detail, spread it out over multiple viewgraphs and use an introductory (outline-format) slide to describe what you are going to show in the next few viewgraphs. This is a courtesy to your audience, to orient them to the organization and nature of your talk. In most presentation scenarios, outline-type introductions will help management better understand what they are supposed to be seeing in your presentation, and will also give them a sense of being catered to in a positive but non-servile way.
Bulleted or numbered items should be five or less per viewgraph. For unknown reasons, humans don't seem to like more than five or fewer than three items per viewgraph. Also, make the text large enough for people in the back of the room to read without squinting. This may mean a few more viewgraphs, but it is preferable to losing your audience with itty-bitty details they can't see. Even technical people get impatient with that technique, and some managers can be positively infuriated by it.
Good Diction (i.e., clear, understandable language) is a must when presenting to any audience. If you are not a native speaker of the language in which you are presenting, then rehearse your presentation before one or more such native speakers. Ask them for criticism on volume, pronunciation, spacing between words and phrases, and pitch. Since linguistic expression is highly culture-specific, we will discuss only American Standard English, as follows:
Volume - Speak loudly enough to be heard clearly in the back row, but do not shout. If the room acoustics subdue your speech and you are giving a long talk or a talk that is very important, then ask audience members who indicate they can't hear you to fill the empty seats near the front of the room. If there are no empty seats, then you obviously cannot do this.
Pronunciation - Be sure to pronounce your words (especially technical terms) clearly and correctly. Do not "chop up" your syllables, but speak each word as a set of continuous phonemes. For example, "specifically" is correctly pronounced as spesifikly, not as speh-si-fi-kuh-ly (as in a spelling bee). Also be careful of regionalisms, such as ax instead of ask, or pacific instead of specific.
Regarding regionalisms, I once attended a technical discussion in Portland (Oregon) where the pre-lunch speaker was a "local boy". He got through his presentation alright, but then said, "Hokay, timefer lunch. Pungle up." The locals knew what he meant (pay for your own lunch), but the out-of-town folk were left clueless. The humanistic implications of such gaffes usually don't sink in until the embarrassed (clueless) recipients have to ask for an explanation...
Pauses - Nothing is more irritating than to listen to a technical presenter whip through a set of viewgraphs at lightspeed, babbling forth tons of jargon in a fast, clipped, monotone voice. If you present this way, especially at critial times of day (early or late in the morning or afternoon), you will most likely lose your audience. Instead, put pauses between your words, phrases, and sentences, just like spaces in text. For example, we don't pronounce "today I am going to talk about..." as a blob of sound such as t'dayigonnatawkabout.
Hint: Examples of good diction and spacing between words can be found on the BBC evening news, which aires on PBS in Gainesville (WUFT-TV). Nobody expects you to talk with a British accent, however. Note that the BBC newsreaders are much more careful with their use of language than their American counterparts. It sometimes helps to listen with your eyes closed and try to determine how the spoken phrases are structured and articulated.
Pitch - Americans often have lower-pitched voices than Europeans, particularly in the case of women. Most Americans do not like to be exposed to a prolonged high-pitched voice (considered shrill for women and inappropriate for men). Practice speaking in a low to moderate pitch, and avoid overly aspirated labial consonants (e.g., lisping on sh, th, and terminal s sounds). To refresh your voice and avoid fatigue, have a glass of warm (not cold or hot) water available to drink from. Pause between sections of your talk to take a sip of water, which will help reduce dehydration and fatigue of the vocal and respiratory tracts that is a frequent result of public speaking.
Stance - When you stand in front of an audience to speak, you should keep your feet slightly separated (i.e., no further apart than your shoulders for men, and three to six inches apart for women). Stand steadily, do not shift from foot to foot or jiggle around. If you want to move to another position to emphasize a different topic, then do so in a deliberate way. Use limited (non-distracting) gestures and be careful of cultural implications of gesture in a multi-cultural audience. For example, do not hold your hands together below your belt, as that could be read as a need to go to the bathroom. Do not stuff your hands in your pockets, as that is a dead giveaway for nervousness. Also, do not make chopping gestures with your hands - your gestures should be gentle and fluid, to indicate comfort and control.
As mentioned previously, your presentation should be clearly organized, with outline viewgraphs to orient your listeners, as discussed above. Each slide or viewgraph should be uncluttered and should convey salient information about the concept which the viewgraph describes. Finally, clarity of speech with an acceptable level of pitch, volume, and articulation will help convince your audience that (a) you know what you are talking about, because you can relate it to their level of understanding, and (b) you know how to relate to them as individuals. The latter achievement comes directly from the humanistic issues we discussed in previous sections. Finally, you are expected to give clear answers to one or two questions from the audience, in the same vein as your presentation.
Best wishes for success in your midterm and final presentations!
