Why we need a plan and a process

“I understand your requiremets, I will do my utmost to meet it, but until I make a plan, I cannot responsibly commit to a date”

Watts Humphrey

For any task, before you agree to a commitment, analyze the work and make a plan to complete that work. You need a personal plan to guide the work and should be able to answer the following questions

  1. What do I do next? (the tasks should be sequenced, and ready to begin, you must know what to do)
  2. When will I finish? ( That is, finished with the next task and the project.)
  3. How will I know I’m done? (What does done look like?)

To accomplish this we begin with a defined process. A good product doesn’t happen by accident. To get consistent results, you implicitly or explicitly follow a process.

How do you know when you will finish? For each product, estimate the overall size and effort. Estimate your availability. You can estimate the effort and schedule based on results from similar products or similar size, using the same development tools, in the same technical domain. Tools like PROBE are very helpful. If possible use your own historical data. If you don’t have personal data, make a best guess using planning guidelines, if you don’t have guidelines, use engineering judgement.

For any given product, there will be entry criteria, exit criteria, and steps along the way. These are captured in a script. The script is at just enough detail to guide the work and should. The Exit criteria should describe what done looks like. You are done after you complete all steps and satisfy the exit criteria.

Every product should have a process that you use to build it. Each step becomes a task. The tasks should be sized so that you can complete 2-4 per week. You must frequently bring tasks to closure to track progress accurately.

How should you sequence the work? For a single product, the order of tasks is determined by the process. If you have multiple products, sequence them in a way that makes sense with respect to your development strategy.

Your management may want a specific date. do your best to satisfy those needs, but the plan must be sensible and enactable. As a developer is is your responsibility to commit only to what you reasonably can do. You must make a credible, defensible plan. You do no one favors by making a commitment you cannot keep.


About Bill Nichols

PhD in Physics from Carnegie Mellon University I'm a software team coach and instructor with the TSP Team at the Software Engineering Institute
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s