System Software
|
Home General Staff Contact Partners Alumni Research Areas Projects Papers Books Reports Awards Teaching Lectures Exams B.Theses M.Theses PhD Theses Go Abroad Misc Talks Library Gallery Links Search Webmaster |
Successful Projects
Günther Blaschek 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… ContentsVisionBefore 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:
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. FocusThe 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:
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”. ScheduleOnce 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:
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 listThe 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. DecisionsWhereas 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):
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. MeetingsDuring 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:
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. PresentationsNow 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:
DemosIn 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:
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). DocumentationYour 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 backWhen 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:
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.
|