Tips for planning and Tracking the Project

I have always found that plans are useless, but planning is indispensable.
--Dwight Eisenhower [ source]

Overview

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.

Tips for documenting the plan

Know the objectives

By looking at your project plan, one should be able to answer at least the following questions:

know how much details to give

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.

Choose a simple Format

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.

Tips for tracking the project progress

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.

Tips for creating the WBS (Work Breakdown Structure)

Get everyone on board

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).

Define concrete (verifiable) tasks

"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?

some things go without saying

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. 

Have "floating" tasks for "idle" times

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.

Effort estimation tips

Project work takes more time than you might think

According to Ed Yourdon's book Death March, one reason for project failure is the naive "we can do it over the weekend" optimism of the youth. An overconfident programmer (in our case, a student) might think he/she can develop any system over a weekend, and things such as documentation, error-handling, and testing are so "minor" that do not need much time.

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.

do not "guesstimate"

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:

Think in hours, not days

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.

Include effort statistics

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.

Tips for project scheduling/tracking

Align the plan with external milestones

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.

Plan sincerely

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?"

Follow sincerely

It is not enough to know the plan, you should also try to follow the plan.

adjust accordingly

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).

Add buffers

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.

Fix the deadline

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.

Weaker the team, smaller the iteration

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.

Set aside meeting times

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.

If you cannot make the deadline...

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).

Schedule critical things early

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.

Grading tips

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.

Further resources


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.

Giving feedback

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 |---

free statistics free hit counter javascript