Guildelines for Detailed Planning

Business and society operates on commitments. For your commitments to be more than just empty statements, you must base those commitments on a plan of action. Creating plans is activity that can be learned. It takes practice to become good at planning.

Sage advice: because the business can only operate on commitments, commitments will be made. If you don't create a plan of action, then the commitments will be made without your input, but you will still be held responsible for making them. It is in your best interest to be actively involved in planning and tracking your work so you can make real commitments that you can keep.

Guidelines

Start With The End In Mind

Start with the end in mind is a statement made popular by Stephen R. Covey's book, "The 7 Habits of Highly Effective People." This applies to software development very well. Think through your objectives for the project, and figure out what are the deliverables that you have to produce to be done.

Identify your work products: The Deliverables

Think through and answers the following questions:

1. What is the end result of your work?
2. What is your "value add" on the project?
3. What is your contribution to the project's success?
4. In what order do you have to create your work products?

The answers to the above questions will clarify to you what you have to do on the project.

Identify the milestones

It is a mistaken assumption that because you don't produce "running code" as a result of what you do, therefore your deliverable is not that important, and therefore it doesn't have to be planned and delivered according to a committed schedule. This thinking is dangerous. Your deliverable, the work product that you produce is an input to some other person's process, and if you are unable to create your deliverable, then the person counting on your output will not be able to produce their deliverable. Your work product might be a: presentation, white paper, design diagram, UI sketch, etc. Whatever it is, as long it is an input to somebody else's process (or to your own process a few days down the road), you need to ensure that it is delivered on the agreed upon schedule and with the agreed upon quality.

Unless you are working on a simple and quick deliverable, say one deliverable that takes 8 to 10 hours to create, do not try to make the deliverable in one shot: "Divide and conquer." Take your work product, and figure out what are the intermediate stages in which it has to go through to be created. Identify what could be its constituent parts, and in what order should you create those constituent parts. Then figure out the tasks you have to do to make those parts and then to assemble your work product.

Identify the work

A task list is nothing more than the work that you know that you have to do to get a set of deliverables done.

What will you do first? What will you do next?

Let's suppose that it is Monday morning, the first day of the new project. You arrive to the office early to get ready for the new project. What will you do first? Write these few things that come to your mind down on your task list. Write down your first few tasks as you would do them on the first day of the project. You would have to think about what will you do anyway, wouldn't you? So, write them down. Then think about the next milestone. How are you going to achieve that? What will you have to do? You will do ... ... And then what? Write that down, too. Your goal should be to write down everything that you have to do to make the project work.

Write tasks based on what you will know when you get to start the task not what you know now

At some point as you write down your tasks you encounter the familiar feeling: "Yeah, but I do not know what will I do after getting to xyz." What are you supposed to know at the time when you get to that point? You sure will have learned some new stuff. If you wouldn't be planning on learning anything, then you would have to use your existing knowledge and that means that you should be able to use all the knowledge that you have now.

What do you expect to learn as you work through the tasks of the project? Based on what you expect to learn, now, as you are writing the tasks, you can assume that when you will get to that point in your project, you will have learned what you planned to learn, or you have replanned the project, because you realized that you are not able to learn what you need to.

Of course, the assumptions that you make should go on your Personal Assumptions List. This may also be a new thing for you, so keep the assumptions list in writing. Remember: the problem with assumptions is not that we make them--after all we make them all the time--but rather the problem is that we make them and we never realize when an assumption "changes sign," or goes from true to false. Every time when you notice that an assumption is going south, then you need to update your plan, since part of your plan is no longer true.

When you think of a new task, write it down

This may sound obvious, but it is not. It is much better to have captured more tasks and then throw some out, than far fewer then you need. The insight about how to do something might come to you when you least expect it. Write it down! Don't count on the "great" insight to come again and again. Update your task list early and often!

The task list must represent at all times your best understanding of what needs to be done to complete the project. While it is important that you keep a history of the task as you started out with, it is even more important to always know what comes next and what is left to do to get the work done.

If you catch yourself that you are working on something that is not on your task list, then add the task to your list. The task list serves two purposes: it show what you expect to do, and--through the time log--it shows what you actually did.

Log time against a task that you planned to do

Logging time is considered by many folks--especially software folks--one of the most difficult things to do. Logging time is easier if--whenever you ask yourself the question "What do I have to do?"--you turn to your task list and start working on your next open task.

Twice a day, at mid-day, and at the end of the day, check your time log and ask the following questions from yourself:

1. Did I do what I planned to do?
2. How much time did I log?
3. Is there a good reason for having logged only this much time? What is the reason?

Understand the reason for the variation

By itself the data that you get about your planning and tracking process is very good. But it is even better to look at the variation of your data from day-to-day and from week-to-week. Seek to understand the reason for the variation. If there is no variation, but you are not happy with the results, then look into how you could make some changes that would cause a positive improvement in your data.

To sum it all up: At first planning is hard. With practice you can get pretty good at it. Your corporate life will be better when you will become known as a person who can make and meet commitments.