1. Planning, Executing, and Managing Your Project
Most students have no idea how to begin their project. This is understandable: it is the
first time they will have had to tackle a large amount of work that is probably poorly
defined (the project descriptions provided by lecturers are rarely complete!) To get
started, it helps to know the key activities that result in a successful project. They are:
1. Problem identification
2. Requirements elicitation
3. Problem modelling
4. System analysis and specification
5. System design
6. Module implementation and system integration
7. System test and evaluation
9. Project management
1.1 Problem Identification
Problem Identification involves a lot of background work in the general area of the
problem. Normally it calls for the use of prior experience, typically experience you may
not yet have. It requires an ability to look at a domain (e.g. telecommunications or
engine control) and to identify the issue that needs to be addressed and the problem to
be solved (e.g. elimination of noise or cross-talk on a communication channel, or
engine control for temperature-dependent fuel efficiency). It also required an
understanding of the theoretical issues by which we can model the problem. So, the
first thing you need to do in your project is become an expert in the problem at hand: a
At the same time, you also need to know how to handle the tools that will enable you to
solve the problem. These might include the operating system, the programming
language, the application programming interface (API) definitions, class libraries,
toolkits, or any application-specific analysis utilities. That is, you also need to become
a solution-domain expert.
The only way to become an expert in both the problem domain and the solution
domain is to learn as much as possible about the area and to learn it as quickly and
efficiently as possible. Many people come unstuck at this first step and they launch
themselves into a frenzy of unstructured research, reading much but learning little.
Here are some tips to avoid this happening.
Collect any papers, articles, book chapters you can on the area and make a copy
for your own personal archive.
Make sure you keep a full citation index, i.e., you must record exactly where every
article you copy comes from. Typically, you need to record the title of the article,
the authors, the name of the magazine/journal/book, the volume and number of
the journal or magazine, and the page numbers. If it’s a chapter in a book and the
author of the chapter is different from the editor of the book, you need to record
both sets of names.
Not all the articles you collect will be equally relevant or important. Consequently,
it’s not efficient to give each of them the same attention. But it’s not easy to know
how relevant it is until you read it. So how do you proceed? To solve this dilemma,
you should know that there are three levels of reading:
1. Shallow Reading: you just read the article quickly to get an impression of the
general idea. Read it twice. This should take a half-an-hour to an hour.
2. Moderate Reading: Read the article in detail and understand all of the main
concepts; this will probably require you to read it several times and take a
couple of hours to assimilate.
3. Deep Reading: Here you make an in-depth study of the article. This may take
you several hours or even a couple of days. After many careful readings, you
should know as much about the topic as the author.
The way to proceed with your ‘reading in’ is to
♦ Shallow read everything and write a 5-line summary of the article
♦ If you think the article is directly relevant to your project, label it, and put it on
a list of articles to be read at the next level, i.e. Moderate Reading.
♦ Read all the labelled articles and write a 1-page summary.
♦ If the article is going to be used directly in the project, e.g. as a basis for a
hardware design or a software algorithm, then you need to add it to your list of
articles to be read at the next level, i.e. Deep Reading.
♦ Read all the Deep-Read articles and write extensive notes on them.
Note that the ‘reading in’ phase of the project can last quite a long time (there’s a lot of
reading and writing to be done) and it can overlap partially with some of the other early
tasks, such as requirement elicitation, the topic of the next section.
Finally, it is very important that you realize that, in order to fully understand anything
that you read, you must write it up in your own words. If you can’t express or speak
about a given idea, then you haven’t truly understood it in any useful way. This is so
important that it’s worth saying a third time:
Writing is an Essential Part of Understanding
This is why, in all of the above guidelines, you see recommendations to write things