Successful Projects

Günther Blaschek
first English version: December 6, 2018
also available in German.

This document is meant as a collection of hopefully useful hints for carrying out a typical project in computer science, be that a programming project, a bachelor thesis or a master thesis. However, most of the hints are not limited to student projects, but can also be applied to “real-world projects”.

Although the focus is on programming projects and some examples are taken from the software development domain, many points can also be applied to other types of projects, such as user interface design, literature studies, experiments, measurements, etc.

Most of the topics in this document cover organization of a project: How to plan, discuss, and present projects and results.

Working on a non-trivial project is already difficult enough; we want to spend as little extra work for organizing the project as possible. All the suggestions therefore have one thing in common: They are simple. There are no sophisticated techniques and methods involved, and no special tools are required. Pencil and paper are sufficient in most cases. To maintain schedules and to-do lists, a simple text editor will do.

I'd like to emphasize that these are suggestions for “light-weight project management”. Feel free to adopt suggestions that you find reasonable for a certain project, and ignore the rest if you already have developed your own working style. Also note that big projects will require more elaborate organizational tasks, especially when you need to cooperate with others in a large team or need to comply with certain quality standards, such as ISO 9000. But for relatively small projects, where you work on your own or with a colleague, these simple recommendations will typically work. At least, they worked well in many projects that I had to do…



Before you start, develop a vision of the results. In many cases, you will start with a task description (a “specification”) that has been written by some client (such as a supervisor or professor; in general, some person who is interested in the result). This is often a good starting point, but also typically leaves some room for interpretation and refinement.

Use your imagination to “fill the gaps” in the task description. Put yourself in the shoes of people who will eventually use the result of your project, and find a few typical use cases. Ask yourself questions like:

  • Who will use the product?
  • Which problem should be solved?
  • What is the context? Where and how will the product be used?
  • Will there be interfaces with other components?
  • What are prerequisites? Which assumptions can be made?
  • Are there already similar products? What is good and bad about them? What could be improved?

Imagine the final result, as if it already existed. Draw pictures, create mockups, but don't spend too much time on them. Hand-drawn sketches are enough at this early stage.

One important result of the vision is an understanding of the “system boundaries”: What is part of the project, what is beyond the scope of the project?

In the beginning, try to find ideas for an “ultimate solution” that leaves nothing to be desired. Disregard the required effort for now; we will deal with that in the next step.

When you are satisfied, discuss your ideas with the client. In the end, it should be clear whether you have correctly understood the task and are on the right track.

As you continue working on the project, revisit your original vision from time to time. Did new ideas pop up? Did you find new aspects that extend or limit the original vision? Did you encounter obstacles that make it impossible to fulfill your dreams? You may need to revise your original vision now and then, and these changes may affect the final result and/or the schedule.


The initial vision may be “gold-plated” in the sense that it exceeds reasonable expectations. But creating a 100% perfect solution requires extraordinary effort and much more time than you have available. Every real-world project has a deadline. This is also true for student projects; if you are expected to deliver your thesis by the end of the academic year, you may only have a few months to finish the project.

It is therefore essential to reduce the requirements such that they can be implemented in reasonable time.

As a first step, try to define the “quality class” of your project. There are typically three classes:

  • Class C: Quick and dirty projects, such as proofs of concept, prototypes, experiments, auxiliary tools that will be used only a few times. Typical examples are exploratory user interface prototypes that show what an application might look like, or conversion tools that translate legacy data into a new format. The results of such projects are generally short-lived, and it is absolutely acceptable if they “just work for now”.
  • Class A: Projects that result in a high-quality product that is expected to be used in the real world for a longer time. Users expect the product to be understandable, easy to use, and of course robust. Many software products fall in this category.
  • Class A+: Extraordinary projects with extremely high quality standards. For such projects, you need to go the extra mile in order to fully implement your vision. The result should be absolutely flawless.

Many students try to produce an A+ product where an A product would be sufficient. An A+ result is required when you really want to impress someone. If it is your dream to work in a certain research institute and you get a chance to introduce yourself to the head of the institute, you certainly want to present a top product and not something that is just “good enough”. Other situations where a A+ quality is required are life-critical products (think of intensive care units and autonomous cars) and demonstrations of a new technology for which you want to raise funding (and where you must outperform other highly motivated competitors).

Most projects do not fall in class A+ but only in class A. Don't misunderstand “only class A” as a synonym for “low quality”. The result will still be something that you can be proud of. The point is that the requirements are more realistic, which means that that they can be finished within a reasonable time frame and with adequate costs.

Class A projects result in products that are as good as possible, as far as time and budget permits, whereas class A+ projects are perfect, no matter how much it costs. In other words, class A products are both good and economic, and class A+ products are excellent but very expensive.

The background for the decision between A and A+ is the Pareto principle. It basically says that a class A solution (which covers about 80% of the ultimate solution) can be achieved in 20% of the time. This means that the inclusion of the remaining 20% (to create a gold-plated A+ solution) requires a fivefold effort, compared to a class A solution. For this reason, commercial products typically belong to class A, since most users would not pay five times the price for ultimate perfection.

You don't need to decide between A and A+ once and for all at the very beginning. It is possible to mix parts of a projects in different quality. For example, a PhD project will typically contain a few A+ parts, which shine in full glory and demonstrate the expertise of the PhD candidate. But there will also be parts that demonstrate the usability in class A quality and maybe even quite a few class C parts for testing, simple showcases, evaluation, etc.

Another possibility to reduce the total effort is to remove features that are not essential. A good way to deal with parts of different importance is to prioritize the list of requirements and then tackle them in order of decreasing priorities. Even simpler, I'd recommend that you classify the features as either “need to have” or “nice to have”. Of course, it is important to agree on the prioritization with the client. Then start with the “needed” parts and complete them as early as possible (in class A quality). If you have some time left, pick a few “nice” features and implement them as well. If you run out of time, it may also be necessary to omit a few less critical features that had originally been classified as “need to have”.


Once you have put together a prioritized list of tasks, bring them into a sequence. Of course, all “need to have” items should come first on the list, followed by the “nice to have” items. Dependencies require a certain order, so you will need to start with the foundation.

When no dependencies exist between several tasks, you could basically work on them in any order. When deciding which task to process next, consider the following criteria:

  • Shortest first: It can be satisfying to quickly shorten the list by completing easy tasks first. Find simple tasks that are independent of other activities, so that they are not affected by other tasks and do not influence other tasks.
  • Hardest first: Starting with more challenging tasks can yield insights, which helps to avoid misunderstandings and wrong decisions in downstream steps.
  • Longest first: Completing time-consuming parts first helps to meet the deadline, as it is easier to add a few small tasks at the end. If an important longer tasks remains at the end, you risk failure.
  • Outside-in: When one task creates an overall structure or skeleton, it is a good idea to start with this one. The result is often a product that already (sort of) works, but has some holes that need to be filled. Then fill the missing parts, one by one.
  • Visible first: If a certain tasks produces a visible result (such as a user interface, web page, or presentation), finishing that first is motivating and gives you an intermediate result that you can use for future testing, presentations, and discussions.
  • Beauty last: Create a simple appearance at the beginning and concentrate on the function. When it works as expected, still resist the temptation to make it more beautiful. Keep notes of items that need to be polished at the end.

The next step is to estimate how long the completion of the individual tasks will take. If this is your first project, you will find this difficult. To improve your estimates over time, create a table with all your planned activities and add two columns for estimated and actual duration.

As you work on the project, you will often find that your initial estimates were too optimistic. To avoid breaking the entire schedule when some parts take longer than expected, it is highly recommended to add some extra time, especially when you do not yet have solid experience with project planning. Over time, your estimates will get more and more precise, but this requires that you compare your estimates with the actual efforts after completion of a project.

Once you have the estimates for all tasks, sum up the estimated durations, and you get an idea how many of the tasks you will be able to complete before the deadline. Can you finish all the “need to have” tasks? Will you be able to add a few of the “nice to have” tasks? It is also a good idea to define predetermined breaking points. Be prepared for failure to meet the deadline, and carefully monitor your own progress in order to detect problems as early as possible. When you expect that you may not be able to meet the deadline, you need to decide where you can sacrifice aspects of the project. If you are lucky, you can finish all the important parts by dropping some of the “nice to have” tasks. But it is also possible that you need to reduce functionality or quality of certain parts, or even drop some parts altogether. Of course, such reductions need to be agreed upon with your client or supervisor. Depending on the importance of the project, you may also be able to negotiate an extension of the deadline.

When your task list with all the durations is complete, insert milestones at critical points in your schedule. These milestones help to monitor the progress of your project. They are also great opportunities to coordinate the progress with the client or supervisor (see the section on Meetings below).

To-do list

The schedule is already a coarse to-do list with just the big blocks. To keep track of things to be done, it is highly recommended to break down the tasks into smaller activities. Before you start with the first task, identify steps that need to be done and briefly describe them with a few keywords. Initially, the order is not important; just concentrate on what needs to be done, as far as you can tell in advance. For example, you might split the task “user interface design” into activities like “layout design”, “icon design”, “UI prototype”, “usability testing”, “implementation” and “polishing”. Then bring the activities in a reasonable order, based on what you want to do next.

As you start with the first activity, you may want to split it into even smaller steps. Tackling a to-do list is an iterative refinement process. The more tasks you finish, the more you know about future items on your to-do list. For example, if you decide to start with “layout design”, you will probably split that into subtasks for individual windows and then again bring those subtasks into a reasonable order. This eventually results in a list of to-do items with different granularity. Items to be done in the near future should be concrete (so that you already know how to do them) and relatively small, ideally such that they can be completed in less than a day. Items that will be completed in the distant future may still be rather vague.

Obviously, the to-do list is not static, but will be constantly revised and refined as you make progress. But you don’t need any sophisticated tools to maintain your to-do list. A simple text editor will do. Just create a list with three sections, TO-DO, NOTES and DONE. Start with the TO-DO section and describe each item with a few words in a separate line.

Use the NOTES section for open questions, ideas, potential problems, solutions, etc. Consider this part as a scratchpad for things that pop up during the project, where you want to make sure that you do not forget them.

It is recommended to always keep the to-do list up-to-date. You could, for example, print the current to-do list and put it on your desk, so that you always have an overview of the next activities. Cross out completed items with a pen and add new items to the NOTES section as they arise.

At the end of the day, update the to-do list: Clear the DONE section from the previous day, move newly completed items to the DONE section and update the NOTES. Review the items in the now reduced TO-DO section, split large items into smaller activities, and put the top items into the order in which you want to handle them. Finally print a new copy for the next day.

An advantage of this procedure is that it automatically produces a journal of your activities. Just add the date to the to-do list and archive all the printed and manually edited pages. This becomes a valuable source of information for documentation of the project. If you also add information about the actual duration to the DONE section, this eventually helps you to improve your estimates for future projects.

When multiple people are involved in a project, you may want to keep the organizational overhead small by maintaining the to-do list in larger time intervals. For example, organize a weekly meeting of all team members, where the to-do list is discussed and updated. This is also a perfect opportunity to distribute the work among team members. Just add names of the responsible team members to activities, and send the new week plan to every team member. Of course, it is then important that all team members keep notes about their progress, which can then be incorporated in the to-do list during the next team meeting.


Whereas the coarse tasks on the schedule will just describe what needs to be done, the fine-grained activities on the to-do list also require knowledge about how the tasks can be fulfilled.

The best solution will not always be clear in advance. You will therefore often be forced to make decisions based on assumptions. Collect as many arguments as possible, and try to find a few possible solutions. If you do not yet have enough knowledge to make a well-founded decision, you basically have three ways to deal with such a question (listed by increasing effort):

  • Postpone the decision. In some cases, it helps to note the problem and leave it on the to-do list for now. Continue working on other activities, which hopefully help you to gain more insight.
  • Create a prototype. If you are not sure whether a certain idea works, create a quick-and-dirty implementation that helps you to find out. Experiments with the prototype can then help you in your decision. It may even be necessary to create multiple prototypes, one for each possible approach.
  • Guess. As a last resort, just make an educated guess. In complex cases, it is often best to make an intuitive decision. But be prepared that your chosen solution might fail, so you need to go back to a well-defined snapshot and start again from there with a different approach.

In either way, it is important that you also document your decision. Describe the arguments, the pros and cons of different approaches, and why you eventually decided in favor of a certain approach. When you actually used your gut feeling to make an intuitive decision based on your personal taste, do not pretend that you made a thorough analysis. Note in your documentation that you had to make a decision on the basis of insufficient information, and that you chose an approach without being sure that this would be the best solution. However, you should carefully observe the consequences and document whether this finally turned out to be a good decision or not. Often, the quality of a solution can only be evaluated in hindsight, when the project has already come to an end. But such information may be valuable for others who are facing similar questions in other projects (or for yourself in the next project).

It is important to reserve enough time for uncertainties. Do not assume that all decisions will be straightforward and easy to make in no time. This is one of the reasons why it is recommended to add some extra time to the items in your schedule.


During your project, you will need to discuss the progress, results and planned approaches with others. This can be team meetings, scheduled meetings with your client or supervisor at certain milestones, or emergency meetings to make urgent decisions.

Keep in mind that meetings always have a purpose. Even when your supervisor asks for a progress report, you should carefully prepare for the meeting to make sure that you benefit from the meeting. It is a good idea to start with a list of expectations: Under which circumstances would you consider an upcoming meeting as “successful” from your personal point of view? Ideally, you leave the meeting with more knowledge than before, and uncertainties have been resolved. To achieve this goal, it helps to go into the meeting with a list of questions, such as:

  • Does the current solution already cover all the important functions?
  • Of two possible approaches, which one should be pursued?
  • Is this task still important, or can it be discarded?

If this is a formal meeting, make sure your important questions are added to the agenda.

During the meeting, note all the important decisions, and finally incorporate the new knowledge into your to-do list.


Now and then, you will need to present results of or plans for your project. Today, typical presentations are made with PowerPoint, Keynote, or similar software. However, giving a good presentation requires careful planning. Here are a few recommendations:

  • Make sure that you have an appropriate number of slides for the available time. A good estimate is two to three minutes per slide. This means that a 20 minutes presentation should not contain more than 7 to 10 slides.
  • Avoid summary and introductory slides. You don’t need to spend valuable time to tell the audience what you are going to tell the audience. A table of contents at the beginning usually is a waste of time. As soon as you move on to the actual topic, no-one in the audience will keep the overview in mind, so you can as well skip the overview and come to the point immediately.
  • Start with some motivation: Why did you start the project in the first place, what was the problem, which improvements of the state of the art does your project address? Give the audience an idea of the expected benefits.
  • Use pictures and diagrams, avoid text slides with lists of bullet points. In particular, do not create slides that also serve as cheat sheets for yourself (so that you read the text that the audience could read from the screen as well). Use illustrations and describe what they mean.
  • In diagrams, make sure that the meaning is clear. Use labels for the x and y axis. For diagrams that indicate quality, include information about whether lower or higher is better.
  • Use examples to explain complex aspects. Ideally, use simplified real-world scenarios to illustrate problems and how your approach works.
  • Every slide should have a slide number. This is helpful when questions are asked at the end. People from the audience can then ask you to show slide 5 again.
  • Make sure that text is readable. In particular, use high contrast between foreground and background colors and avoid small font sizes. A good rule of thumb is to use a font size of at least 24 points.
  • If your presentation contains colorful slides, make sure that the pictures are clearly visible. When you design the slides on the computer screen, be prepared that colors may look completely different on a projection screen. In particular, the resolution and color contrast will be much lower, so small and subtle details may get lost. Try your slides with a projector, if possible with the actual projector that is installed in the room where you will give the presentation.
  • Do a dry run of your presentation, ideally in a setup that is similar to the situation in which you will give the presentation. During such a rehearsal, give the whole presentation from start to end. When you make a mistake, don’t interrupt and repeat a part, but rather move on as if you were talking to a real audience, then repeat the whole presentation again. If the presentation took longer than expected, do not try to speak faster, but remove content that is not quite as important.


In addition to slide presentations, you may want to give live demos of your product. There are basically two types of demos: a) flexible demo and b) fully planned demo. A flexible demo simulates real-world usage, where you can immediately react on questions from the audience and quickly show how your product can adapt to ad-hoc situations. But most demos are planned in advance. The advantage of a planned demo is that you can prepare everything to the last detail, including text to enter, and you can carefully avoid parts that are not yet working properly. Here are a few recommendations for such a demo:

  • Create a script with detailed notes when you want to show what. It is helpful to create a table with two columns, where the first column describes what you do (click here, select that…) and the second column contains the spoken text.
  • Prepare the program and auxiliary information, so you don’t need to launch processes, resize windows and make other time-consuming adjustments during the actual presentation.
  • If your presentation involves much text entry, you may want to prepare “canned text”. For example, you could use third-party tools that enter text for you. This helps to avoid mistakes caused by typing errors. If you have only a few text fragments, you can also prepare a text document and copy/paste text between applications.
  • As with a presentation, use dry runs to make sure that everything works as expected when you follow the script. Also measure the time, to make sure your presentation fits into the available time slot. If possible, do such dry runs in the room where you will give the demo, on the actual setup (computer, projector, network, etc.). If your demo starts with a certain initial configuration that is modified by the demonstration, don’t forget to revert the situation to the correct state after each dry run.
  • Be prepared that the projector may have a different resolution and make sure the program can handle the different screen size and text is large enough.
  • If your presentation depends on external resources (for example, servers), make sure that the configuration will work during the presentation. Check that the network is available and that all required servers are up and running at the time of the presentation. To void dependencies, you may want to create your own ad-hoc network or run services locally on the computer that you use for the presentation.
  • When giving the presentation, try to slow down. Move the mouse slowly, so that movements can be followed easily. Do not rapidly click here and there to show how fast everything is. Rather explain what you are doing and synchronize your activities with the spoken text.

Instead of a live demo, you may want to use screen-recording software to create a screencast of a sample session and then show a movie of the session. This has the advantage that you can avoid nasty surprises, you can prepare a demo of an exact duration, and you can demonstrate features that would not be possible in the presentation room because some special equipment is not available. But, as with a live demonstration, you should take extra care that the resolution of the recorded movie works with the resolution of the projector (otherwise it might get scaled down or distorted).


Your project will also need some documentation. This could be your master thesis or the system and project documentation that is to be delivered to the client.

Ideally, the documentation should be written in parallel to the actual project. When you do this at the end of the day, the important details will still be fresh in your memory. However, this has the disadvantage that you may write too much in vain when it turns out that a certain approach did not work.

Writing all the documentation at the end has the advantage that you can look back and have an overview of your project, but you will very likely forget a few important details.

A good compromise is to collect daily notes when you update your to-do list at the end of a day. These notes do not need to be excessive. A short paragraph is usually sufficient. Just write down what you achieved, which to-do items you could check off, which problems were solved (and how), which new problems turned up, and what you plan to do next.

While you are at it, it is a good idea to note how long you worked on the individual tasks.

Such notes are an invaluable source of information when you create the final documentation. It takes just a few minutes per day, and you will often be able to directly integrate some of your notes in the documentation.

Note that the final documentation also takes some time. This must be considered when you set up the schedule for your project.

Look back

When you have finished a project, this is a great opportunity to review what you have done. Here are few questions that you should ask yourself:

  • What worked well, where did I encounter unexpected problems?
  • Was it possible to implement the initial design (such as the architecture), or was it necessary to revise the initial design? What were the mistakes, and how could they be avoided in future projects?
  • How well do the actual efforts match the estimated efforts? Which tasks took much longer than planned? How should that be considered in future projects?
  • Did the used tools, libraries, languages, platforms, etc., prove successful? Would I use them again and recommend them to others? Or would I rather used alternatives, now that I know better?
  • If I had a chance to start the project again, but with the knowledge that I have acquired during the project, would I do it in the same way again?

Looking back is important for gaining experience. Over time, you will improve your estimates, your schedules, your planning, your designs, and your management skills. With more experience, it will become easier to make reasonable decisions even with insufficient information. In short, future projects will work out better and better.