“Final Projects Guide” by Dr. Shaiq A.

Haq

Final Projects Guide

1.0 Introduction
This document provides a single source that contains information about completing all the
phases of a Final Project at Air University Islamabad. However, since your Final Project
may be a highly specialized, personally created endeavor, it is impossible to cover all of
the topics that you may require. If, after reading this manual, you still find some of your
questions are unanswered, please consult with your project advisor or the course
coordinator.

2.0 Overview of Project Activities

2.1 What is a Final Project?
To qualify for a Mechatronics Engineering degree at AU (BE or MS), each student has to
complete a Final Project course of 6 credit-hrs. This Final Project course should preferably
be completed in two terms. The only difference between the BSc and MSc projects is the
level of standard according to their courses. Both types of projects are referred as Final
Project in this manual. A Final Project should demonstrate application of the skills,
methods and knowledge of computer science related to a problem which would be
representative of the type to be encountered in one's career. The MS project should
demonstrate some element of research or comparison of modern technologies in addition
to the development skills. There can be one to five students in a Project. The project's
content area should be carefully selected to complement your total educational program.

The Final Project activities generally range through user requirement analysis, research,
design, implementation and testing. These activities can involve analysis or development,
can be experimental or theoretical, and can emphasize a particular subarea of the major or
combined aspects of several subareas.

Most Final Projects will provide you with research, project design & development
experience. Generally, the Final Project is a project in which you design or develop a
mechatronics product, meet a customer’s industry related requirements, or make a
simulation model which integrates theory and practice. Since you can do nearly anything
that demonstrates mechatronics engineering skills as a Final Project, it is difficult to create
a definition that will apply to all Final Projects. Indeed, every project progresses somewhat
differently depending on the individual student's needs, the advisor's interest, the student's
motivation, team dynamics, and many other factors.

Air University, Islamabad Page 1 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

Despite the diverse nature of Final Projects, every project has to pass through the following
six phases;
1. Project Proposal Phase
2. Research & Literature Review
3. Design Phase
4. Development Phase
5. Test & Evaluation Phase
6. Reporting Results

2.2 Project Proposal Phase

During the project definition phase, you will begin to determine exactly what you will do
for your Final Project. The idea for the project might be something that you thought up on
your own, or it might be one of the project ideas that have been presented by the faculty. In
either case, you'll have some homework to do in order to turn an idea into a project.

The process of defining the project usually involves writing a project proposal. At this
stage, this proposal might be a short (2-10 page) paper where you establish the basic
definition of the project along with the project goals, projected schedules and budgets, and
the methodology you will use to satisfy the project objectives. The Project Proposal should
be submitted to the Project Supervisor before the mid of the first term of the project. A
good project proposal is always based on a good idea.

Once you have an idea about what’s involved, you can determine what skills you’re strong
in and which skills you need. MS projects are solo effort of the student, whereas, BE
projects are a team effort. BE students at this point can start selecting a team to work with
on the project. Just like a manager in industry, you should put together a team that 1) is
really motivated and excited about the project and wants to do a great job and 2)
collectively thinks they have, or can teach themselves, all of the skills they need to be
successful.

Now, you and your team can get together to identify the project goals. These goals might
require additional research into one or more areas; designing, building and testing
software/hardware; simulating designs; writing software to meet a clients needs; or
developing mathematical proofs. The more you learn, the more you’ll discover you need to
learn, but, you have to start somewhere. Start by creating a prioritized list of tasks that
must be accomplished. Next, the team can decide who will be responsible for each task in
the project. You can now make a project schedule which shows the order in which tasks
must be done (you can’t build hardware or software until it’s designed!) and who will do
each one. Along with the schedule you should develop milestones, or intermediate
objectives, that will give you a sense of accomplishment and progress. For example, if
your project requires designing a digital filter, you might decide on a milestone which says
that at the end of A-term you will show your advisor a working program that simulates a
digital filter. Nothing is more satisfying than reaching an important milestone on time (or,
better yet, early!).

Air University, Islamabad Page 2 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

Now that you’ve done your homework, you can take all the notes you’ve gathered and start
writing your proposal. Typically, this proposal will be organized as follows:

1. Title of the project; a title describing what exactly your project would be about.

2. Objectives; one or two sentences describing the aims and objectives of your project.

3. Introduction; a good concise description of what the project is and the back ground of
the problem. This section should orient the reader by explaining what the project definition
and goals are, why there is a need to address this problem, why it is a good or important
thing to do, who would benefit from this project and what your general approach will be.

4. Literature Review; a summary of what the current state-of-the-art is based on your

reading and research about the topic. Most of the references given in the References
section are cited here.

5. Methodology; in this section, you must describe as completely as possible how you
intend to accomplish the goals you presented in the introduction. Your job here is to
convince the reader that you not only know what you're talking about, you have a plan to
get there.

6. Project Schedule and Budget; this is where you present a detailed description showing
the projected completion date. Often schedules are presented in the form of a Pert or Gantt
chart. These charts clearly show the relationship between tasks and the effect of missing a
milestone on the project deadline. In industry, software engineers and managers are rated
on how well they do in terms of meeting milestones on-time and on-budget. Your schedule
should show the reader that you understand the relative sequencing of events and, to some
extent, you understand their complexity. A brief estimate of costs, other than the labor
cost, will help the advisor in assessing its practicality. If a project requires funding, you
have to convince the advisor how are you going to raise the budget. In general, University
of South Asia does not provide any assistance other than the lab resources in completing
the Final Project.

The Project Proposal should be evaluated and approved by the Research Projects
Committee of the Mechatronics Engineering Department.

2.3 Research & Literature Review

The research phase of a typical Final Project begins in the first term of the project. This is
when you will start refining the initial project proposal that you wrote to get the project
going. Based on your initial proposal, your advisor will probably have comments and
suggestions for sources of specific information that you will need. In case of a software
design & development project, this phase would consist of gathering the user requirements
and finding ways to implement those requirements in the software.

Air University, Islamabad Page 3 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

Your biggest source of information for this phase will probably be Internet, meetings with
the user, your course notes, texts, and the library. There are PCs in the lab and the library
that you can use to search for books and journal articles.

Once you've completed the research phase, you will be fairly knowledgeable about the
problem you are working on and how to solve it. You will know what others before you
have done, how well their approach worked, and how you can do better. You will fully
understand the nuances of the problem and will know the tools and techniques that are
needed to solve the problem better, faster, or less expensively than anyone else. If you've
kept careful notes along the way, you will also have a significant store of information that
will prove useful when you write your Final Project report.

Now its time to put your ideas to work!

2.4 Design Phase

The design phase of a project can take many forms, depending on the nature of your
particular project. For example, in a theoretically-oriented project, the design phase might
consist of completing the proof of a new technique for calculating the effects associated
with some physical phenomenon. In order to test this technique, you might have to develop
a program that performs the necessary calculations on a variety of examples for which
theoretical or experimental results already exist. For hardware-oriented projects, the design
phase normally involves taking the detailed specifications derived through your research
and designing and building a circuit that you expect will satisfy them.

For most of the software development projects, the design consists of two parts; Overall
System Design and the Detailed Design. In the overall system design, the focus is on
specifying various modules in the system and their interaction with each other. In the
detailed design, the focus is on explaining the internal logic of each module. The prime
issue while designing should be “can the design be easily tested” and “can it be easily
modified”. It is recommended to use a design tool like Visio or UML by Rational Rose for
the design phase.

Of course, no design effort is complete until the results are proven.

2.5 Development Phase

The purpose of the development phase is to ensure that your design meets the
specifications you derived. Usually, you will have certain expectations for your results that
are a result of the research you did. Now is the time to verify these expectations. Often,
you'll find one or more deviations from the specifications. When this happens, you'll have
to determine if the original specification is somehow in error, or if there was an error that
occurred during the design phase. Indeed, by the time you successfully complete the
evaluation phase it's quite likely that you will have done additional research, updated your
design, and re-evaluated your results one or more times.

Air University, Islamabad Page 4 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

It is very important to choose the right development tools. Select the languages and tools
and skill-set that are currently in demand. The use of modern tools seems difficult in the
beginning because of the lack of proper guidance but their pays off in the long run.

Once you accomplish the development phase, test it rigorously and then you really have
something to shout about.

2.6 Reporting Results

In IT environment, shouting about your results usually takes the form of reporting your
findings to your colleagues, customers, and possibly the IT industry through presentations
and through written reports. Although few beginning IT professionals realize it, the best
way to communicate to your boss how well you are doing is to make good presentations
and to write excellent reports. To teach you about this process all the Final Projects
conclude with a substantial written report and an oral presentation.

The Final Project Report documents the entire project. In this report, you will present the
project, the research you did, the details of your design, and the results of your evaluation.
It would be difficult to overstate the importance of a quality report and, even though it is
the last thing you will turn in related to the project, you should start writing it when the
project begins. Because of the diverse nature of each project it is almost impossible to
suggest a report pattern that would fit all projects, however, the general format of a typical
software development project report is given below;

Title Page
Acknowledgements
Abstract
Table of Contents
List of Figures
Chapter 1: Introduction
Chapter 2: Literature Review (theoretical background of the subject)
Chapter 3: Suggested Design
Chapter 4: Features of the Software
Chapter 5: Test & Evaluation Reports
Chapter 6: Discussion & Analysis of Results
Chapter 7: Conclusions
Recommendations for Further Work
References
Appendices

Modify the above pattern of report according to the nature of your project. For details
Section 3.0 is referred that contains information describing the style of the report.

The Final Project Oral Presentation is similar to the written report, but is presented in a
more abbreviated format. Details on the oral presentation are contained in Section 4.0. In
brief, the oral presentation will briefly introduce the project, describe the major innovations

Air University, Islamabad Page 5 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

that made the project succeed, present an evaluation or demonstration of the project, and
then will conclude by assessing the project status and prospects.

Air University, Islamabad Page 6 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

3.0 Written Report Guidelines

3.1 Introduction
This section is intended to provide guidelines for preparing the written Final Project report
which is submitted at the conclusion of the project. For MS Reasearch Project a sample of
thesis is given in Appendix-II. Most of these guidelines are based on common sense. As
with everyone else, an engineer's primary means of communication is through oral and
written means. It would be difficult to overstate the importance of a quality report. The
report is an important element in the evaluation of the project by your examiners. In
addition, the project report is the vehicle by which the results of your work are
disseminated. It must be structured correctly and written precisely if it is going to be of any
use to the intended audience. There is no excuse for misspelled words, incomplete
sentences or poor punctuation in a report.

Your advisor's job is to make sure that your report is technically correct. Everything else is
your responsibility. You should not expect your advisor to spend his or her time correcting
your English. If the writing is poor, don't be surprised if your advisor refuses to read it. If
your advisor must help you with your English, don't be surprised if your grade reflects this
fact. By this point in your career you should be competent in written communication.

Even though handing in the report is the last thing before being officially done with the
project, the writing should not be left until all of the work has been completed. The “write
as you go” method of report generation often saves time and headaches in the end. By
writing the report in installments, you will avoid omitting an important finding before the
final report is printed. Remember that the ideas, the findings of the project and the
conclusions put forth are the primary purpose for the report.

To fulfill the requirements of a computer science degree, one hard bound copy duly signed
by the Project Supervisor must be submitted in the projects office before the final exam.

3.2 Format and Style Issues

The format and style of the report are the first things that the reader will see. Attention paid
to the details of report format and structure will complement the written content. These
issues are dealt with by Turabian[1]. Strunk and White[2] do an excellent job of
illustrating and then describing ways around common writing problems.

Your Final Project Report must be typed. This document was prepared with Microsoft
Word. Word® which is one of many different tools that are available. These tools relieve
the user of most formatting and typesetting concerns and generally provide facilities for
tabulating data and drawing figures. While typing your report on computer do not forget
to keep regular backup copies of your written reports.

Air University, Islamabad Page 7 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

3.2.1 Report Format

Any technical report can be broken down into three main components, including:

1. The front matter.

2. The body.
3. Reference material.

The physical formatting of each page should be according to the library standards. A good
rule of thumb is to allow one inch on the top, bottom and the unbound side. A margin of at
least one and a half inches should be allowed on the side of the page which goes into the
binding. The font and the headings style can be the same as used in this guide.

3.2.1.1 Front Matter; the front matter consists of,

a. The title page.

b. An abstract. This is a short, stand alone description of the project which should
convey the problem, the approach, the solution, the results and the conclusions. An
abstract is often the first thing to be read and will determine whether the reader
decides to go further. The abstract should contain the maximum amount of specific
information. For a Final Project Report, the abstract should be limited to about 200
words (or one page).
c. Acknowledgments. These are optional.
d. A table of contents. This is a list of page numbers indicating where to find each
section in the report. Major and minor section divisions should be listed in the table
of contents.
e. A list of figures. This is a list of each figure, its caption and its page number.
f. A list of tables. This is patterned after the list of figures.

3.2.1.2 Introduction; the introduction should explain the project to the reader, should
describe any relevant research that has been done by others, and should detail what you did
that is novel. By the end of the introduction, the reader should know what your objectives
are, what you did, why you did it, how you did it better, and should be introduced to the
vocabulary necessary to understand the rest of the report. It is important that the
introduction flow logically, starting with a general overview and ending with a description
of the flow of the report. Details of your design should generally be left out of the
introduction. Rather, you should concentrate on communicating the basic concepts.

3.2.1.3 Report Body; the body of the report is where you start getting into the details. Be
conscious of keeping a logical organization. Most projects evolve along a winding path,
encountering several wrong paths on the way towards finding the correct one. Don't follow
the same path in the report! Once the project is complete, you'll know what sequence of
steps you should have followed. The body should flow according to the same path you
wish you had followed. The report body should be constructed of well defined divisions
such as chapters, sections and subsections. Each division should be numbered, with each

Air University, Islamabad Page 8 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

section numbered to reflect the chapter. Each subsection should reflect the section. It is not
a bad idea to end each chapter with a summary of that chapter.

In addition to the details of the design process, the body of the report usually includes
information about the economics of the project, theoretical background, description of the
techniques used in the project, an analysis of the project results, and other information.

3.2.1.4 Conclusions; a typical report concludes with an assessment of the project as a

whole. Were all project objectives accomplished? If not, why not? Are there ways to do
even better? It may be useful to describe areas in the project where performance was
marginal or inconsistent.

3.2.1.5 Recommendations for Further Work; Research is an ongoing activity. Rest

assured there will be your juniors who would like to carry on your work and try to improve
it further. This is the section where you write what you think should be done by your
successors in this area of work.

3.2.1.6 References & Appendices; the reference material consists of the material you
referenced in the body of the report. If you point the reader to any books, technical papers,
reports or manufacturer's information for more details regarding something you discuss,
then your reference material would include a list of technical references. The style of these
references is discussed in Section 3.2.2.3 below. Other appropriate reference material
would be included through the use of appendices. Material appropriate for inclusion in
appendices includes experimental data, computer programs, detailed schematics, device
data sheets and anything else which adds to report completeness but which is not
appropriate for inclusion in the report body. Copies of readily available material should not
be included in the appendices; reference to the material is sufficient.

For many software development projects, the report should contain a user manual. This
manual should be a stand-alone section and included as an appendix which is referred to in
the body of the report.

3.2.2 Report Style

Virtually every technical report uses figures, tables, equations and references to aid with
clarity, succinctness and completeness. This section addresses how these items should be
included in the report.

3.2.2.1 Figures and Tables

A figure is located as close as practical to, and preferably after, the first place it is
referenced, but it should not split up paragraphs. The figure is accompanied by a number
and caption, both of which go below the figure. Use the number when you refer to a
specific figure. Figures should be numbered consecutively within each major division of
the report. That is, if your report is broken down into chapters, number each figure

Air University, Islamabad Page 9 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

consecutively within that chapter. Each figure number should reflect the major division.
For example, the first figure in Chapter 2 would be referred to as "Figure 2.1."

Figures should not be drawn freehand. Drawing packages such as Corel Draw are available
on the Department PCs to create proper figures. Similarly, a variety of tools are available
for creating Graphs. Each figure given in the report must be referenced in the body of text.
For figures taken from any other source, reference the source in the caption.

A table is just like a figure with two exceptions.

First, the number and caption go above the table. Second, when referring to a specific table
the word table is capitalized and never abbreviated. Figures and tables should be numbered
separately but with the same numbering convention.

3.2.2.2 Abbreviations and Acronyms

Define abbreviations and acronyms the first time they are used. Acronyms that will be
recognized by any IT student do not have to be defined.

3.2.2.3 References and Bibliography

References are used to direct the reader where to go for more explicit information about a
topic. You do not need to include a direct quote from the source in order to justify your
reference. For example, the following text is an example of how you might use a reference.

Thus, the basic requirement of a GPS integrity monitoring system is to

alert the user if their reported position is outside of the accuracy
requirements for the current phase of flight. Furthermore, the user
must be alerted in a timely fashion so that an alternate source of
navigation information can be used. Table 1 lists the typical integrity
monitoring requirements for various phases of flight[3].

The number of the reference is enclosed in the square brackets. In the list of references at
the end of the report, we would find

[3] Haq, S A, "Minimum Operational Performance Specification for Airborne

Supplemental Navigation Using Global Positioning System (GPS)," RTCA Document
RTCA/DO-208, July 1999.

It is important that references be complete. There is nothing more frustrating and time
consuming than tracking down an incomplete reference. A typical reference should
provide; names of the authors, title of the paper, full title of the journal, year of publication
and the volume number, first and last page numbers.

For a book, the author, book title, publisher and year of publication should be stated, along
with the chapters or pages you refer.

Air University, Islamabad Page 10 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

3.3 Summary

This document has provided a brief overview of what is expected in a BE Final Project
report. Most of these guidelines have dealt with the mechanical features of the document.
While these are easier to take care of than the actual report content, their importance
cannot be overstressed. Following these guidelines will result in a report which has the
essential components of a professional quality report. A sample of MS Research Thesis is
given in Appendix-II.

3.4 References

1. L. Turabian, A Manual for Writers of Term Papers, Theses, and Dissertations, The
University of Chicago Press, 1973.
2. Strunk and White, The Elements of Style, 3rd ed., Macmillan Publishing Company,
1979.

Air University, Islamabad Page 11 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

4.0 Oral Presentation Guidelines

4.1 Introduction
This section is intended to provide some general guidelines for the content and style of oral
presentations of Final Project. The ability to give effective oral presentations is one of the
most important skills a technical professional can possess; no matter how good your work
is, if you cannot effectively communicate its results and significance in both written and
oral formats, you and your work will not be fully appreciated. Fortunately, the seminar of
the Final Project provides an opportunity for you to gain experience giving an oral
technical presentation. This presentation is a requirement for computer science degree at
University of South Asia.

4.2 Designing Your Presentation

A presentation must be carefully tailored to the specific format, audience, presentation
media, and level of formality associated with the presentation forum. In this section, the
appropriate form and content for a Final Project presentation will be discussed.

4.2.1 Format

The format for the Final Project presentations is very brief; typically 20 to 25 minutes per
project plus 10 to 15 minutes for questions & answers session is budgeted. Presentations
taking more than thirty minutes may have a negative marking. The brevity of this format
may please you at first, but it is one of the most difficult things about the format. Simply
put, there is not nearly enough time for you to give a detailed description of your project.
Instead, you must focus on an overview that gives the audience a general appreciation for:

• what you did,

• why it's worth doing,
• how you did it, and
• how well it worked.

More specifically, an outline of your talk should be not unlike the outline of a written
report, with:

• An introduction which describes the problem and motivates its solution;

• A brief background section describing such things as special theory or devices you
used, or previous work done on the same problem by others;
• Your approach, giving a broad overview of your solution to the problem,
preferably at the macroscopic level;
• The results of your work, including a demonstration of the software you
developed; and

Air University, Islamabad Page 12 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

• A conclusion, perhaps touching upon improvements or future work that could be

done.

It is considered extremely unprofessional to exceed the allocated time for a presentation.

(On the other hand, finishing early doesn't really send a very good message, either; that
shouldn't be a problem for these brief presentations, though.) You should focus on the "big
picture" at the expense of technical details that you might feel are important. There simply
isn't enough time to talk about everything you've done (if there is, then you haven't done
much). You will find that tailoring your talk to the right length and level of detail might
require several tries.

4.2.2 Audience

The audience for MCS Final Project presentations generally consists of one external
examiner, one internal examiner, your project supervisor, faculty and students and, plus
assorted family and friends. The level to which you should gear your talk is that of a
competent computer science graduate student, i.e., assume that the listener understands
basic computer science concepts. The talk should be accessible to the students without
boring the faculty to tears.

4.2.3 Presentation Media

All the Final Project presentations should be prepared for a multimedia projector.
Generally students use PowerPoint or a similar package for preparing their multimedia
slides. Every major point in your presentation should be represented in some form on a
slide.

Here are some guidelines for preparing slides for Final Project presentation:

• All slides should be easily readable from anywhere in the hall, so large font
(minimum 16 point) should be used to generate them.
• Use MS PowerPoint or any other presentation graphics package to prepare your
presentation slides.
• Do not overload your slides! It is better to keep them simple and use a few extra
than to cram them full of information.
• On the other hand, each slide should contain more than just a few words. Try to
achieve a balance.
• It is said that a picture is worth a thousand words; so promote the use of images and
views in your presentation.
• Data, such as tables, graphs, etc., should be particularly clear, uncluttered, well-
labeled, and easy to understand.
• Don't change a slide unless you're going to give the audience enough time to look
at it. If you're rushing through them, you have too many.

Air University, Islamabad Page 13 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

• On the other hand, if a slide is up too long, it is either too detailed or irrelevant to
what is being said. A good balance is usually achieved by a rate between 0.5 and 1
slide/minute.
• A block diagram describing your system or procedure is usually a good way to
describe the project. Make sure that any block diagrams are kept simple by
combining subsystems into systems, etc., until the diagram is easily
understandable.
• You might want to have a felt-tip marker with you in case you need to write on
small white board during the presentation to clarify or emphasize something.

Remember that your slides can't have the whole story-that's what you're there for. They
should, rather, focus the attention of the audience to key points and provide a basic
understanding of how any pieces of the project fit together.

4.2.4 Level of Formality

The word that best describes the impression that you should try to give the audience is
"professional". This applies to your appearance, manner of speech, and visual aids. You
should dress as if you are going on a job interview. Preferred language is English. Speak in
clear and complete sentences, avoiding slang and obscure technical jargon.

4.3 Presentation Style

Once you have determined the content of your talk and visual aids, you must pull it
together into a presentation. This will require practice-it is easy to find yourself tongue-tied
the first time that you attempt to describe or explain something, even if you understand it
well. Here are some pointers for preparing the presentation.

• Introduce yourselves, give the title of your project, and indicate who the advisor is.
This information should be presented on a title slide.
• Don't jump into the details of your project until you have given the audience
enough introductory and background information to understand what your project
is all about.
• Most of the software development projects start with introduction of the problem,
user requirements, design phase, development phase showing the software screens
and the results in the form of actual demonstration of the software.
• If possible, try not to read from your slides. It is better to use them as cue cards
with brief phrases or lists serving to remind you of the topics you wish to discuss. If
you find that you absolutely have to read from the slides, at least try to ad lib a bit
of introduction, insight, and/or summary.
• Practice, practice, practice. The first run might be just among the project partners,
or in front of some close friends. Then, recruit some HIIT students to listen and
give you feedback and questions. Ask them to be brutally honest. After a few tries,
you should have the length of the presentation down to within a few minutes. Now
you are ready to give the presentation for your advisor, who may suggest that you

Air University, Islamabad Page 14 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

change the whole thing. Do so, for this person will be grading you! Then go back to
the beginning of this paragraph and start over.
• Don't go too fast. This is a common problem for nervous presenters. People would
rather be a little bored than completely lost; remember that most of your audience
may have never even thought about your project before. Make sure that important
ideas have time to sink in; give enough time to look at any figures, equations, etc.
that may appear in your slides.
• For multiperson presentations, transitions should be smooth. Lead into the
following section ("Now that the problem has been defined, Ali will describe our
approach..."); tie into the previous section ("As we have explained the software
operation, let me describe the quality assurance plan...").
• Try to make your conclusion as upbeat as possible while still being honest. Even a
project which does not produce a working system can have educational merit. Be
sure to acknowledge anyone who has contributed significantly to the project other
than the project team and advisor. Welcome questions.
• Look at the audience! A person speaking from behind a pile of notes is incredibly
boring.

4.4 Handling Questions

The best way to handle questions from the audience is to be prepared. Elicit questions from
the practice audiences. Try to anticipate anything that might confuse or intrigue people. Be
aware of anything you have done which is unconventional or impractical, and be ready to
discuss why. Your advisor may be of some help here.

It is a good idea, if you can anticipate certain questions, to prepare "backup slides" for
answering them. For example, there may be screen views, data, circuit diagrams, or
whatever that were too detailed for the main body of your presentation, but would serve to
answer a tough question quickly and painlessly.

Don't try to snub anyone; if you don't know the answer to a question, say so. Perhaps
someone in the audience can provide an answer; ask for a little help if you need it.

4.5 Logistics
All the presentations will be in Seminar Room. Each presentation will be assigned a
specific time slot. You should attend the entire session; don't just come in for your
presentation. One reason is that any canceled presentations will change the time of yours;
another is courtesy to the other presenters. Be sure to contact your advisor or the examiner
immediately if you cannot give your presentation at the assigned time.

A multimedia projector, an overhead projector and a P-4 compatible computer with

Windows operating system will be available for your use in the presentation hall; you are
responsible for any other equipment or software you might need for a demonstration. You
should load and practice your presentation well before the presentation time. Contact the

Air University, Islamabad Page 15 of 16

“Final Projects Guide” by Dr. Shaiq A. Haq

maintenance in-charge of the seminar room for this purpose. If you plan to do a hardware
demonstration, be sure to arrange your apparatus so that it is easily moved into place for
your presentation and out of the way when you are done without causing disruption to the
proceedings.

4.6 Summary
Effective presentation skills come with practice; as your career progresses, you will gain
more confidence in expressing your ideas to others. The Final Project presentation is not
meant to be a traumatic experience, but rather a chance to exhibit the skills and share the
results of your work with others. Be sure to take full advantage of this opportunity by
preparing a high-quality presentation.

Good Luck!

Air University, Islamabad Page 16 of 16