How to successfully deliver your final year project

Completing a project successfully is mostly a matter of planning and technique. That doesn’t mean that you don’t have to do any work, but rather that a good plan will make the whole process much simpler and easier

Companies use plans routinely to improve their business practices. They do this because plans are extremely effective at ensuring that time use is maximised and therefore they get better value for money. A figure often quoted is 30%. That is 30% of time wasting can be avoided by using a plan. Saving this amount of time during the production of your final year project is a goal worth pursuing.

Most projects follow a general pattern of activities. This pattern is often called the project lifecycle. One of the models most commonly used is shown in Figure 1.

The first part of the lifecycle is the requirements phase. This phase, for a final year project, will be the time when you are trying to understand what it is you need to do in order to successfully deliver your final year project. Towards the end of the phase you should have developed a clear appreciation of the task ahead of you and you will now start to move into the design phase.

During the design phase it is highly likely that you will need to keep returning to the requirements in order to refine them. This is shown by the overlapping bars in Figure 1 between the requirements phase and the design phase. When you are happy that you understand the requirements you will start to exit the design phase. Despite the continuing design iteration you should now feel that you are starting to know what you are required to do.

The development phase of the project is the time when the major amount of work is undertaken. This might be experimentation or in-depth research. Whatever the work, it is likely to take the longest amount of time and absorb most of your energy. However, you should not lose sight of the need to prepare to enter the final testing stages of your project output. After all if you don’t release a final report then you won’t pass.

To test the project you might involve friends and other students from your faculty. It is also likely that you’ll now start to work more closely with your supervisor in order to complete the dissertation that normally accompanies the close of a project. When you find yourself doing this then you should recognise that you are moving into the final phases of your project.

Understanding that your project will follow this pattern makes it easier to plan for success. You will also feel less stressed and you can be confident that not only are you following a pattern familiar to many students before you, but that many companies also follow this pattern.

Building your final year project plan

Although understanding the pattern is important it will not give you the surety that you need for success. Instead, you need to translate the pattern into a more detailed project plan. The simplest way to build a plan for your project plan is by blocking up the general task pattern onto a grid. This is illustrated in Figure 2.

The chart presents an overview or macro plan of the whole project. Each task shows its relation to the other project tasks, its duration and when it is scheduled to start. Along the bottom of the chart runs a timeline (from left to right) and on the vertical left hand axis is a list of tasks.

The first task at the left hand axis is the requirements phase task. This task along with the design phase task is scheduled to take about 2 months to complete. The plan then allows 3 months of development work and 1 month of testing. Finally, 2 weeks are left at the end for the production of the final deliverable, often the project dissertation.

Although this is a good starting point, obviously the plan needs to be adjusted to fit with your own project. To do this you first need to work on the detail for the requirements phase task. You need to determine what you think you are going to do to complete the project requirements. Once you think you know what this work is then you need to work out how long the work will take. Building a simple list of tasks enables you to work this out. You should do this by filling in a table similar to the table shown in Figure 3.

The table shows a list of tasks that need to be completed and it also includes estimates for how long these tasks will take. The estimates are given in three categories for each task: Best Case (BC), Most Likely Case (MLC) and Worst Case (WC). Normally a company would apply a mathematical model to these three estimates to obtain a single value. This model would weight each estimate depending on probability of success. Although you could adopt a similar technique it is probably not needed. Instead, simply use the estimates as a method to make you think through how long it will take to complete a given task.

Once you have the plan in detail for the requirements phase tasks, it is important that you validate the plan. Often people undertaking projects forget that much of the work they are about to do has been undertaken before by others and that by simply looking at what happened they can learn quickly where they might have gotten estimates wrong. So, to really improve your chances of producing an accurate plan it is wise to undertake some simple validation research. Validation research falls into two broad categories: desk research and interview research. Desk research involves using books and the Internet to find relevant information. Interviews simply involve asking people who have undertaken similar work before.

If this idea of research seems excessive for a final year project then it is worthwhile remembering that companies do it for almost every project they carry out. One of the most commonly asked questions is, ‘What happened last time we did this?’. Historical data mining is big business for companies because it avoids them wasting precious time that could be spent doing other things.

If you’ve followed the process so far you should now be in possession of a basic plan of action. The next obvious thing to do is to move onto planning the design phase. However, you don’t need to do this. Providing you are reasonably happy with the blocked out time for the design phase you can hold off planning it until some of the requirements phase is completed. Holding off planning like this is a common technique used by professional project mangers. They recognise that before the requirements are understood it is very difficult to guess at any other project activities. Experience shows them that actually all that happens is that they waste time planning activities that will ultimately need replanned. However, this doesn’t mean that you don’t need to plan the design phase. Instead, it simply means delaying the planning until you reach a suitable point in the requirements phase. This point should be reasonably obvious but if in doubt start the planning when you are two thirds of the way through the requirements phase. Similarly, towards the end of the design phase you must plan the development phase in detail and, as it completes, plan the test phase.

Finally, you need to remember that as time goes by you need to iterate your plan. Put simply, your plan must become a living document. It is not something to do once to keep a tutor happy. It is important that you review your progress against it every time you work on your project. If you do then things should go well. Although planning can’t guarantee you a good mark, it can make getting there easier and surer. You can be confident of finishing and be confident of doing the right things along the way.

Good luck!

Alan Orr is a Chartered Engineer who has worked as a project manager with Blue Chip companies such as British Airways, Samsung, Nokia and Aerospatiale. He is now the Director of Engineering at Picsel Technologies Ltd.

OTHER INTERNET RESOURCES:

From the IET