The fact that you are taking an upper division computer science course, means that you have successfully completed thousands of assignments and (at least) dozens of significant projects. This attests to your intelligence, skill, dedication, and resourcefulness: the characteristics that get us through 1-100 hour tasks. You are about to start confronting larger tasks ... senior projects, clinic, graduate research, or in the software development industry. The complexities and risks associated with a project grow geometrically with its size. As you move into larger projects, you will discover that individual ability becomes a weaker predictor of success, and that methodology becomes more critical.
This course is about the issues and approaches, methodologies, tools, and techniques for successfully pursuing large software projects. This paper is a brief introduction to project management 1A. You might be tempted to say (or at least to hope) that project management is the responsibility of career managers, and it will be years (if ever) before you have to confront those problems. Were it only so! If you go into industry, and you are very lucky, you will have the opportunity to work for skilled and well seasoned managers. Unfortunately a few other things will happen first:
To be successful in such situations will require you to possess a basic understanding of project management. Conversely, having such skills will do much to ensure your success ... even if you never move into management. This following chapters will discuss the basics of:
Based on our experiences with team projects at school, it might seem natural to infer that we assign projects to multi-person teams because:
This chapter discusses why we assign projects to teams, and how teams can effectively partition that work among their members. It is hoped that an understanding of these considerations will enable you to form more teams and accomplish your tasks more effectively.
From a managerial perspective, it is often much easier to assign a task to an individual. Teams, made up of individuals with differing goals and experiences, introduce overheads and problems that seldom come up for individuals. Why then would we go to the trouble of creating a team to solve a problem?
There are overheads associated with tasking and monitoring team activities, and coordinating complementary efforts. If we could break the one large tasks into several independent tasks, it might well be more efficient to parcel each of the smaller sub-tasks out to a different individual. Smaller tasks tend to be performed more efficiently and encounter fewer problems.
Unfortunately, it is often impossible to sub-divide larger tasks into independent sub-tasks. If there are significant interdependencies among the sub-components, it will be necessary to coordinate the efforts of the people who are responsible for them.
Any project is likely to benefit from a synthesis of multiple perspectives. If a project involves specialized modeling, human factors analysis, domain specific knowledge, complex user interfaces, distributed applications and specialized tools it may actually require a significant number of people to assemble the required combination of skills and experience.
Prototyping and producing correct code involve different skills. Developing requirements and test cases involve different attitudes. A person who has spent several weeks working on a piece of code is probably convinced of its correctness, and would be a poor choice for a reviewer.
Whether a project involves distinct roles, or it is simply a matter of needing another pair of eyes, many tasks will be performed much better by multiple people ... even if a single person possesses all of the required skills.
Individuals can easily become blocked, frustrated, or confused. When a group of people is working together on a project, help is usually close at hand, and such problems are usually discovered and resolved quickly. A lone individual might spend hours (or even months) bumping their head against a wall before someone else noticed and stepped in to help them.
If a project will involve the use of a new tool or technique, we might assign people to the project, for the purpose of letting them gain experience with that tool or technique. This might be for the purpose of training new people, exposing experienced engineers to new technology, or purely to help and/or observe in an experiment. In cases like this, we would assign people to the project as much for their own education as for the contributions they might make towards the project's goals.
Teams are formed for reasons. If those goals are to be satisfied, the team must be created with the right people, and organized around the desired goals. As is true in most areas, the first step towards success is clarity about your goals.
The initial partitioning of work for school projects seems to be based on two primary goals:
While these constants will always be with us, there are a few additional considerations that can be incorporated into a more purposeful partitioning of the work that is more likely to achieve the goals that initially motivated the formation of the team.
In the interests of efficiency, each person should have approximately the same amount of work to do. If person A finishes long before person B, then shifting work to person A would reduce the time required to accomplish the task. This may sound a lot like "fairness", as in giving each person an equal amount of work ... but this is not the case. Assuming that all team members are putting in the same number of hours, the shortest time to completion is achieved by giving more work to the most productive people.
If all tasks were independent of one-another, it would be a simple linear programming problem to assign the work to people in a way that would minimize the total time to completion. It is, however, rare for all of a team's tasks to be independent. If task A depends on B and C, and C depends on D and E, it may not make sense to assign someone to task A until tasks D and E are done. Reasonable assignments must consider, not only the total amount of work to be done, but the interdependencies among the tasks ... parallelizing everything possible, and minimizing the time that one person spends waiting for another. If a single task is a prerequisite for many others, it may make sense to have everyone start out working on that one task, to get it finished so that it becomes possible to work on all of the other tasks. Attempting to schedule work without an understanding of the interdependencies between tasks is a formula for disaster. Where the dependency networks are complex, automated project management tools become indispensible.
For some tasks (like research) that involve many independent activities, it is possible to add extra people and complete the task sooner. For other tasks, assigning extra people can reduce efficiency and, potentially, even increase the time required to do the job:
Tasks will, in most cases, be done both more quickly and more correctly by a person who is most skilled at the activities in question. In many cases work assignments will indeed be dictated by skills. If, however, there are also educational goals to be satisfied, we may consciously decide to make assignments that do not correspond to peoples' strengths:
Many tasks require cooperation between multiple individuals ... either for synergy (e.g. Pair Programming) or in complementary roles (e.g. coding and test case development). In these cases multiple people will be assigned to a single task (or set of closely related tasks). In these cases, it is important that people clearly understand their respective goals, roles and responsibilities. The issue here is not that there is any right or wrong way to structure such collaborations, because (for the most part) there isn't. Rather it is a matter of ensuring that all parties understand the plan in which they will be cooperating.
In some cases, all of the people who support a particular effort will be dedicated to the sub-group that is responsible for that effort. In other cases, there may be "matrixed" resources, not assigned to a particular group, but available to help any group that needs them. Such shared resources can easily become bottlenecks, when multiple sub-groups need their help at the same time. These conflicts can be greatly reduced if the support resources can be scheduled for specific tasks, or can promise each sub-group a fraction of their time (e.g. 10 hours per week).
There are a few activities that are better performed by a whole team rather than being assigned to a few individuals:
Most work plans involve work to be done by all of the members of the team, and their review of those plans is critical to ensuring that every has "bought in" to his portion of the plan. Even when the plans do not involve assignments for all members of the team, it is good for all members of the team to understand what the overall plan is, so that they can better understand their role in it.
Brain-storming is the process of coming up with ideas, and is equally valuable for initial product concepts, and solutions to troublesome problems. Brain-storming sessions benefit from a wide range of input, and it is important that all members of a team have the opportunity to provide that input.
When the team is about to publish a major work product, it is a good idea to review it with the team. Since this represents the output of the entire time, the whole team should have the opportunity to review and improve it. This also gives everyone the opportunity to better appreciate what they have had a hand in creating.
If the work to be done is a simple matter of sitting down for a few hours to work on it, a schedule is nothing more than a time the team agrees to meet and do the work. If you aren't sure how long it will take (because you haven't done this sort of thing before), you should block out an overflow session. How much contingency time you need to block out depends on how well (or poorly) you understand the task. This is probably about as much scheduling as most of you have (thus far) been forced to do. Larger projects tend to have much more complex scheduling requirements:
Exactly how much schedule you need depends on how complex the project is. There are no simple rules to tell you how much project planning you have to do ... but it is pretty easy to tell whether or not your schedule is adequate to the project: Go through the review and validation process described (below) in section 3.4.
To schedule a large project, it is necessary to break it down into smaller pieces (individual tasks and sub-tasks). For each task, you should describe:
Just how small should a task be? This is a hard question to answer in the abstract:
Another question about work breakdowns is how specifically the task needs to be defined. The answer is, "sufficiently specific to avoid problems resulting from likely misunderstandings". There are two different types of specificity here:
Producers of work products must clearly understand what is required of them, and consumers must know what to expect. Ambiguity in these requirements usually results in waste, whether performing unnecessary work, or fixing inadequate work.
This type of detail is not required froma project planning perspective. If, however, the assigned people are not well familiar with the task, such a sub-breakdown can be invaluable in guiding them through the process.
One good test of how well defined your sub-tasks are is how easy it is for you to estimate how long it will take. If you can give an answer to within an hour, or even to within 25%, your tasks are probably pretty well defined. If there are powers of two in your estimate (e.g. 3-6 hours) your understanding of the task is suspect. If there are powers of ten in your estimate (e.g. 2-20 hours) you clearly do not yet understand the task. There are two general approaches to dealing with this problem:
As you are estimating how long it will take to perform each task, it is also a good idea to note insights you have in the process:
In most cases, and especially with school projects, people have many responsibilities, and will not be dedicating full time to any one project. A project schedule does not usually call out a three hour block of time for a three hour task. It is more common to specify a period of a few days, within which that task must be accomplished, and a delivery date by which it will be completed. There is no simple formula for the relationship between the estimate and the scheduled work period:
Given a number of days that has been set aside for the accomplishment of each task, and the interdependencies of the tasks, it becomes possible to lay out a schedule. With a one-digit number of tasks, this can reasonably be done on a white-board or a piece of paper. With a dozen or two tasks, it might be easier to lay them out on 3x5 cards. With larger numbers of tasks, you will almost surely want to use a project planning tool (e.g. Microsoft Project or Open Workbench).
Schedule the first task to start immediately, and then schedule the next task to start as soon as that finishes, etc. This tells us the soonest possible completion date.
Schedule the last task to end on the due date, and then schedule the previous task to complete just before that one starts, etc. This tells us the latest possible starting date.
Schedule the first task to start immediately, and the last task to end slightly before the due date, and spread the remaining tasks evenly throughout the alotted interval. This gives us the most slack (to accomodate slippage) for each task.
If you want to get even more sophisticated, don't distribute the extra time evenly, but rather in proportion to perceived risk ... giving more slack to the scarier tasks.
In some cases a basic schedule, laid out in these ways, will work fine. In many cases, it seems impossible to accomplish all of the tasks in the available time. There are a few options:
The output of this process is a schedule, a complete list of tasks, where each has:
Putting together a schedule that addresses all of the various needs can be a daunting task, and there is a very natural sigh of relief when you finish it. Unfortunately you aren't done yet. You have to review and validate the schedule with the rest of the team:
Once there is a validated and accepted schedule, it is up to the individual task owners to perform their tasks by the stated completion dates. How individuals juggle their commitments is a much simpler time management problem. Most of you probably already have good time management skills, so the following is presented as a basic review of key principles.
Prioritize your activities:
We tend to put off tasks that are unpleasant, complex, or uninteresting. We can overcome these obstacles by:
A schedule is a plan for the future, but you will often hear it said that "a schedule is a living document" (i.e. it changes over time). Robert Burns (in a greatly underrated 19th century treatise on project management) put it more poetically:
We must observe when each task is completed and compare these completion dates with the schedule. Any slippage is a warning that something is wrong. If the problem is recognized and dealt with before it results in further slippage, the consequences are usually negligible. If, however, a late task is allowed to become later, and starts delaying subsequent tasks, the situation may quickly devolve into one where the delivery date is no longer achievable.
More effective management often follows from finer grained monitoring. If a single task is expected to take multiple days, there may be value in checking the progress at multiple points along the way. If we wait three days until we find out that the task is going to be late, we may find that we have lost six days (the three we have already lost, and the three it will take to make up the missed work). If, however, we discover after the first day that no progress has been made, we can institute recovery measures sooner, with much less time lost.
Another key principle in project management is "no surprises". It is common for someone who is falling behind to try to keep this fact a secret (in the belief that they will be able to make-up the missing work tomorrow, and to avoid embarrassment). It usually turns out, however, that the factors that prevented progress today will still be there tomorrow ... and that the embarrassment of letting it be known that you need help is negligible in comparison with the consequences of causing the whole project to be laten.
Regular and candid status reporting inevitably leads to a smoother running project.
When a problem delays the completion of a task, we need to do at least two things to correct the situation:
A tight schedule, with no room for slippage is brittle in the face of problems. This is the problem with delaying tasks until the last minute. A schedule that starts tasks as soon as possible (and is likely to finish early) is more robust, and allows time to deal with problems and still make an on-time delivery.
For at least 2 million years, hominids have formed teams, and planned strategies for accomplishing critical tasks. Why? Because it increases our chances of success. A well functioning team of ordinary people can reliably achieve results that are beyond the capabilities of the best individuals. As projects get larger, a good plan will beat heroic efforts every time. Organizing a plan and a team to effectively attack a problem is work. It is worth it!
It is tempting to think that these activities are primarily the concerns of managers. Actually they are the concerns of people who are serious about conquering difficult problems. It is not coincidental, however, that people who demonstrate these abilities often find themselves quickly promoted greater responsibilities.