Chapter 8: Planning and Tracking the Project

      1. 8.1 Have a plan
      2. 8.2 Know objectives
      3. 8.3 Get everyone on board
      4. 8.4 Choose iterative
      5. 8.5 Order features
      6. 8.6 Know when to detail
      7. 8.7 Align to external milestones
      8. 8.8 Choose a simple format
      9. 8.9 Time-box iterations
      10. 8.10 Start with short iterations
      11. 8.11 Use same size iterations
      12. 8.12 Estimate size, derive duration
      13. 8.13 Define verifiable tasks
      14. 8.14 Resist 'guesstimating' effort
      15. 8.15 Estimate collaboratively
      16. 8.16 Have 'floating' tasks
      17. 8.17 Think in hours, not days
      18. 8.18 Do not fake precision
      19. 8.19 It takes longer than you might think
      20. 8.20 Include things taken for granted
      21. 8.21 Plan sincerely
      22. 8.22 Track visibly
      23. 8.23 Refine regularly
      24. 8.24 Add buffers
      25. 8.25 Drop features when behind
      26. 8.26 Do not slack when ahead

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

Project planning and tracking is a vital part of any non-trivial project. Most students use ad hoc 'back of the napkin' 'inside your head' planning. They tend to avoid elaborate project planning or 'fake it' for the sake of appearances because of two reasons:

In reality, a typical student project can get by without much elaborate planning because of the flexibility in available time and expected deliverables. For example, they can respond to a project crisis by skipping other course work to spend more time on the project, heroics such as overnight coding sessions, or simply not delivering what was initially promised.  

However, project planning is integral to the learning experience of a project course.That is why sincere project planning is usually given extra credit. Dilligent students who want to use the project to learn the valuable skill of project planning will find the tips in this section very useful.
Why won't developers make schedules? Two reasons. One: it's a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it's not going to be right? --

8.1 Have a plan

The most important tip we can give about project planning is 'do it'.   We may not get it right the first time; but our project planning skills will improve over time, and our plans will get closer to reality. There is much to be learned about planning (and related activities like estimation and scheduling), and much to be gained from practising it during your project. Here are some:

8.2 Know objectives

What is the objective of a project plan? A project plan should help us answer at least some of the following questions:

8.3 Get everyone on board

Preferably, planning should be done as a collaborative activity. When the plan is built upon team consensus, your plan itself tends to be of better quality and others tend to follow the plan more willingly. Even if your team wants you - the team leader - to draw up the plan, do not simply allocate work to others at your discretion. Instead, present them with a draft plan and get their feedback before adopting it.

8.4 Choose iterative

Any non-trivial student project should be done in iterative fashion. The waterfall process [] may suit certain kinds of projects, for example, when a team of seasoned programmers builds a product they have prior experience in. Most certainly your project does not fall into this category.

If you are serious about having a well-defined process for your project, you can choose from many available processes such as eXtreme programming, Unified Process, SCRUM, etc. However, smaller projects can survive just fine by simply using an iterative approach to developing the product. Elaborate process-specific practices advocated by those processes may turn out to be an overkill for small, short-term projects. 

8.5 Order features

If we are following an iterative process (we should) and the product has many features, we have to figure out in which order we will implement them. While many factors influence this decision, two most important ones are the value and the risk. One strategy is to use the following order [adapted from the book Agile Estimation and Planning by Mike Cohn]: first, we implement high risk, high value features; then, low risk, high value; last, low risk, low value, leaving out high risk, low value features.

This order emphasises that 'critical' features - those that are difficult to implement (i.e. 'high risk') yet vital to the proper functioning of the product (i.e. 'high value') should be scheduled early in the project although the client/instructor does not demand it that way. This gives us enough time to recover if something goes wrong while implementing those features.

Another important factor we must consider is feature dependencies. This analysis might even discover a critical path of features in the project. A critical path is a tightly packed chain of features each one dependent on the previous one. A delay in one feature will cause a delay in the final delivery date.

8.6 Know when to detail

"It'll be done when it's done!" is not a plan [quoted from], neither is it a good attitude to have. "Design 4 weeks, implement next 6 weeks, test during the last 6 weeks" is a plan, but it is too high-level (and not a very good one either - for one thing, it follows the waterfall model). So what is the appropriate level of details for your project plan?

First, there is a limit to how detailed it can be. The element of uncertainty common to all software projects and our own lack of expertise in similar projects prevent us from knowing in advance every detail of how we will do the project.

Second, we may not want to detail out certain things upfront even if we could. For example, we may not want to be specific about which function we will be implementing on Monday of the 11th week from today. Instead, we might stop at specifying which set of features we will be implementing during weeks 8-12.

In general, we prefer to define major milestones in the high-level plan (we can call this the master plan) using features rather than components, functions, or tasks. This emphasises our focus on delivering values to the customer and not merely 'doing some project work'. Here is an outline of such a plan :

iteration 1 [weeks 1-2] V0.0 : skeleton architecture, feature 1.
iteration 2 [weeks 2-3] V0.1 : feature 2, feature 3.
iteration 3 [weeks 3-4] V0.9 : feature 4.
iterations 4-7 [2 months] V1.0: features 5,6,7 and 2 additional features from the 'nice to have' list.

This plan tells us which features we will deliver from each iteration.  At the end of each iteration, we plan our next iteration in more detail (we can call this the iteration plan). Here, we will break down each feature in that iteration into fine-grain tasks, estimate the effort required, and schedule them appropriately.

8.7 Align to external milestones

Align your iterations appropriately with external milestones imposed by the course instructor or the external client. For example, if your iteration ends one day before the external milestone, you have a buffer of one day to pit against any last minute delays.

8.8 Choose a simple format

If we can use a simple table or a spreadsheet to document the project plan and still achieve all the objectives easily, there is no need for fancy templates, diagrams, and charts. See here [] for a sample project plan, maintained as a simple MSWord document.

8.9 Time-box iterations

A floating deadline (i.e. "Let's finish our tasks and email each when we are done") is a sure way to slow down the project. Estimate how long the iteration 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 their priority list ("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.

8.10 Start with short iterations

Start with one-week iterations. If things go according to the plan, you can try longer iterations; if they do not, make the next iteration even 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.

8.11 Use same size iterations

Once you have found an iteration size that fits you, try to stick to it. Try to schedule milestones on the same day of the week. Doing so helps your team to 'get into a rhythm' and makes subsequent iterations easier to plan. This especially makes sense since most of your work from other courses also follows a similar pattern.

Parkinson's law: Work expands to fill the time available.  

8.12 Estimate size, derive duration

Answering question such as "How long do you need to do task X?" in fact requires answering two questions: "How much effort will it take?" and "How long will it take you do that amount of work?". The first question is primarily about estimating the size of a task. The answer to the second question depends on the person who does it and when it will be done.

... my mantra of estimation and planning: estimate size, derive duration [adapted from the book Agile Estimation and Planning by Mike Cohn]

8.13 Define verifiable tasks

When you need to define tasks, make sure they are verifiable. 'Complete the parser' is a verifiable task. Either the parser is complete, or it is not. 'Add more functionality to the parser' or 'Finish 50% of the parser' are not verifiable. Always plan an iteration using verifiable tasks. How else will you decide when the task is done?

8.14 Resist 'guesstimating' effort

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:

In rare cases when you have absolutely no idea of the size of a task, you may want to try out a similar task at a MUCH smaller scale before venturing an estimate. Such a tryout is called a spike solution. While this delays the planning process a bit, it is much better than planning based on guesstimates.

8.15 Estimate collaboratively

We can estimate the task size as a team or as a sub-group of teammates related to the task. You can ask the person who is likely to do the task for an estimate. Then, others can add their opinion, especially if they think the task is being over/underestimated by a big margin. 

If you feel that some team members are padding estimates to evade work, here is a bit more elaborate and fun way to estimate task size (this approach is called  planning poker []):

8.16 Have 'floating' tasks

Floating tasks are the tasks not in the critical path. Their completion time is generally flexible. E.g. 'looking for a good format for the user manual' can be done any time, as long as it is done before starting the user manual. Identify floating task for idle team members (those who have completed their tasks, and waiting for others to finish) to do.

8.17 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 spend on the project is different from one day to another. Therefore, estimate task duration using person hours, not person days.
E.g. If you think a task has a size of five hours, and the time you can devote for the project is Monday - two hours, Tuesday - zero hours, Wednesday four hours, you should ask for time until the end of Wednesday to finish the task.

8.18 Do not fake precision

Let's face it: estimates can never be 100% accurate. The larger the task is, the less precise the estimate will be. First, break larger tasks into smaller ones. Second, do not give seemingly precise values to largely uncertain estimates. Using scales such as 1,2,3,5,8 (Fibonacci series) or 1,2,4,8 reflects that when the task is bigger, our estimates are less precise [adapted from the book Agile Estimation and Planning by Mike Cohn]. For example, using the first scale means when a task is bigger than five hours, we put it into the eight hours bucket instead of choosing between six, seven, and eight hours.

8.19 It takes longer than you might think

According to Ed Yourdon's book Death March, one reason for project failure is the na´ve 'we can do it over the weekend' optimism. An overconfident student might think he can develop any system over a weekend, and things such as documentation, error-handling, and testing are so 'minor' that they do not need much time.

We should keep accurate measures of the time we spend on each task, compare it with our initial estimates, and adjust our future estimates accordingly. Do not be surprised if you found your estimates were less than half of the actual time you took.

The process is called estimation, not exactimation.
-- Phillip Armour (as quoted in the book Software Estimation by Steve McConnell)

8.20 Include things taken for granted

Things like unit testing, adding comments, and routine refactorings are usually considered integral parts of coding and, therefore, should not generally be shown as separate activities in the project plan.  However, it is better for student teams to include them as separate activities [adapted from the book Agile Estimation and Planning by Mike Cohn], at least until they become a habit. This practice will help us to consciously allocate time for these important activities that may be overlooked otherwise. Also, remember to allocate time for fixing bugs (found in features delivered in previous iterations).

Do not forget to include meeting times in the project plan, too. However, we should not include things that do not add value to the project (e.g. answering emails). 

No battle plan survives contact with the enemy. -- Helmuth von Moltke

8.21 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. 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. Always refer to the plan when choosing what to do next.

Even the best planning is not so omniscient as to get it right the first time. -- Fred Brooks

8.22 Track visibly

Each iteration should start by drawing up a detailed plan for that particular iteration. For increased visibility, you can send a copy of the plan to the supervisor at this stage itself.

You can also maintain the project plan as a GoogleDoc (or some other online format), and give access to the supervisor. In this case, it is easy for the team members to update the document as and when required. For example, a team member can mark a task as 'done', as soon as it is done. GoogleDocs also keeps track of the past versions of the document, and shows who made which change. You can also consider more specialised project tracking tools mentioned in Chapter 9.

8.23 Refine regularly

Planning is not over until the project is over. 'Revise plan' should appear frequently in the project plan. It is also advisable to put someone in charge of this aspect.

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.

When there is a mismatch between what you actually did and what the plan says, it means the plan needs adjusting. But remember, you should not adjust the past plan to match what you did up to now, but you should adjust the future part of the plan to match what you now think you can do (as opposed to what you originally thought).

Evaluators know that a project plan never revised at least once is most likely a fake.

8.24 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 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 the same as adding buffers.

8.25 Drop features when behind

Consider the following true story: 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 those features. They offer to take the evaluator through the code to prove their claims, an offer he 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 had omitted some features and used that time to hook up the remaining features to the GUI.
The moral of the story: When short of time, you have to sacrifice some features so that at least the other features survive. If you realise you are behind schedule, and if late submissions are heavily penalised (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 re-allocate time from one task 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).

Similarly, when you cannot make the iteration deadline (an internal deadline set by the team), drop/postpone features rather than extend the deadline. Changing deadlines disrupt the rhythm of your team.

8.26 Do not slack when ahead

If you are ahead of the schedule, do not 'take it easy' until the plan catches up with you, and do not use the extra time for 'gold plating' (i.e. adding unnecessary adornments to the product). It simply means the plan was wrong, fortunately, in a good way. Do what you would do if you were behind schedule; consider the current status, revise the schedule accordingly, and carry on.


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]

Sharing this book helps too!


---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---

free statistics free hit counter javascript