]
]Project planning is a frustrating activity. Since things rarely go according to the plan, it seems like a big waste of energy to draw up a plan. Still, project planning is integral to the learning experience of a project course. We may not get it right the first time; but our estimation skills will improve over time, and our plans will get closer to reality.
By looking at your project plan, one should be able to answer at least the
following questions:
The long term plan (we can call this the master plan) could be abstract and less detailed, while the short term plan (typically, this is the iteration plan) should be more concrete and more detailed.
If a simple table or a spreadsheet is able to achieve all the above objectives easily, there is no need for fancy Gantt charts. See here for a sample project plan, maintained as a simple MSWord document.
Each iteration should start by drawing up a detailed plan for that particular iteration. For increased sincerity, send a copy of the plan to the supervisor at this stage itself.
You can also maintain the project plan as a GoogleDoc, and give access to the supervisor. In this case, it is easy for the team members to update the doc as and when required. For example, a team member can mark a task as "done", as soon as it is done. GoogleDocs also keep track of the past versions of the document, and show who did which change. You can also consider more specialized project tracking tools.
Do a post-mortem analysis at the end of an iteration. What did not go according to the plan, and why? Change the master plan as necessary.
Do not simply allocate tasks to team members; Get you team mate's consent. Whenever possible, let them choose what to do, and let them come up with the initial effort estimates for their own tasks (these initial estimates can be further adjusted based on the team's consensus).
"Complete the parser" is a verifiable task. Either the parser is complete, or it is not. "Add more functionality to the parser" is not a verifiable task. Always allocate verifiable tasks to team members. How else will you decide when the task is done?
Things like unit testing, adding comments, and routine refactorings are usually considered integral parts of coding. Do not show them as separate activities in the project plan.
Identify floating tasks for idle team members (those who have completed their tasks, and waiting for others to finish) to do. Doing a floating task should be counted towards that member's contribution.
According to Ed Yourdon's book Death March
If you are inexperienced in estimation, multiply your initial estimates by a factor of 1.5 to 2.0 (depending on how unsure you are of your estimates) before using the figures for early project scheduling. You can adjust this factor in the subsequent rounds of scheduling, based on your experience from the previous iterations.
)
During iteration planning, you will be asked questions such as "how long do you need to do task X?" and "do you think you can finish task Y and Z by Friday?". To answer, you need to estimate the time required for each task. While you may not have a lot of past data/experience to help in estimating, and while you are not usually required to use sophisticated estimation techniques, do resist the temptation to give the first number that pops into your head. Take some time to consider the following factors:
Unlike industry practitioners, your commitment to the project is not full-time (because you are taking other courses at the same time). This means the number of hours you can dedicate to the project is different from one day to another. Therefore, think in man hours, not man days, when you estimate the time required for a task.
E.g., If you think a task will take 5 hours, and the time you can devote for the project is Monday - 2 hrs, Tuesday - 0 hrs, Wednesday 4 hrs, you should ask for time until the end of Wednesday to finish the task.
Since the time a task will take depends on the person who does it, we use can use "normalized" hours to calculate the contribution one makes by doing a certain task.
For each task, estimate the effort in terms of normalized hours. At the end of the iteration, record the actual effort (normalized), which could be different from the previously estimated effort (if a task turned out to be genuinely easier/tougher than expected, or only part of the task was completed).
The actual effort can then be used to calculate the contribution from each member. Here's a sample calculation.
| Name | Task | Estimated effort (hrs) | Actual effort (hrs) | Total | % |
| Jean | implement foo() | 5 | 5 | 12 | 60% |
| implement bar() | 5 | 7 | |||
| Farouk | find a testing tool | 5 | 8 | 8 | 40% |
| implement goo() | 5 | - (postponed) |
Note that Jean took more than 5 hours to implement foo() because she is new to C#. However, we only count it as 5 hours, since that is time it should have taken.
Align your iterations (wisely) with the external milestones (i.e., those imposed by the course instructor or the external client). For example, if your iteration ends 1 day before the external milestone, you have a buffer of 1 day to pit against last minute delays.
Some teams allocate one member to "do the project plan". This member creates a nice project plan and submits it, while others never get to see it, let alone follow it. Instead, each team member should have an intimate knowledge of the project plan, at least the part that applies to him/her. One should always be able to answer the following question: "According to the project plan, what should you be doing today?"
It is not enough to know the plan, you should also try to follow the plan.
When what you actually did does not match with the plan, it means the plan needs adjusting. But remember, you don't adjust the past plan to match what you did up to now, but you adjust the future part of the plan to match what you now think you can do (as opposed to what you originally thought).
Do not assume that everything will go according to the plan. Insert buffers to strategic locations of the task chain. If task B depends on the completion of task A, try not to schedule task A immediately before task B. Scheduling task A little earlier creates a buffer between A and B. That way, a delay in A is less likely to affect B.
Note that buffers should be explicitly shown in the plan. Inflating all estimates by 10% is not as same as adding buffers.
A floating deadline (i.e., "let's finish our tasks and email each when we are done") is a sure recipe to slowdown the project. Estimate how long the tasks will take, and fix a deadline based on the estimates. Deadlines are a way to get a commitment from all, and push the project tasks up the list of priorities ("I have to finish this by Friday, or the team will let me have it!"). Of course if you find yourself finishing the work before the deadline, set a shorter deadline next time.
Start with 1-week iterations. If things go according to the plan, you can think of longer iterations; if they don't, try to make the iteration shorter.
If you can gather all team members together for a couple of hours, consider starting with a mini-iteration that lasts only a couple of hours.
Having fixed times set aside for meetings (e.g., Monday 12-2pm) from the beginning of the project avoids the hassle of trying to find common time slots for each individual meeting. No team member can claim to be busy during such pre-allocated meeting times; it's his/her responsibility to keep that time slot free.
Don't forget to include meeting times in the project plan, and in contribution calculations.
Consider the following scenario: A team claims to have implemented all the features of the product, but did not have enough time to hook up the functionality with the GUI, and therefore, had no way of demonstrating the product. They offered to take the evaluator through the code to prove their claims, an offer the evaluator politely declines. The team receives a very low grade, although they supposedly fell only a small step short of the complete product. They could have got a much higher grade if they omitted some features and used that time to hook up the remaining features to the GUI.
If you realize that you are not going to make the deadline, and if late submissions are disallowed or heavily penalized (they should be!), you should not carry on with the current plan as if nothing is wrong. Choose wisely what you will include in the product, and what you will have to omit. Do not blindly reallocate time from one task/feature to another (e.g., from documentation to coding) - the decision should depend on the amount of credit you stand to gain from each. Do not skimp on testing no matter what - it is better to have 90% of the features 100% tested (i.e., a good product that lacks some features) than 100% of the features 90% tested (i.e., a lousy product. period).
Some features are "must have", while some are "nice to have" (e.g., adding a nice image to the splash screen). Make sure you push former to the early stages of the schedule, and leave the latter to later stages.
The reality is that typical student project can get by without much elaborate planning. Most students use ad hoc "back of the napkin" "inside your head" planning. However, a project course intends to teach you good project planning. That's why sincere project planning is usually given extra credit.
Normalized time is the time an average team member is expected to take to complete the task. We use normalized hours to measure the actual amount of work involved, independently from how a fast a person can do it. A slow team member might take 10 hours to do a 5-hour task, but it should still be counted as a 5-hours task. The term "normalized time" is not a standard term - it is something we coined.
Floating tasks are those tasks that are not in the critical path of the project plan. They have flexible timing requirement. E.g., "looking for a good format for the user manual" can be done any time, as long as it's done before starting to write the user manual.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.8, 3rd Sept 2008, Copyrights: Damith C. Rajapakse |---