Back to the basics - Project Tasks part 3.1: How? Gathering the Details

link to part 3.0: http://itprojectguide.blogspot.com/2007/10/back-to-basics-project-tasks-part-30.html

Ok, so now you have your first (perhaps) second pass at gathering your task list (part 3.0) - now it's time to dig into the details of each task. Part 1 of this series provided the attributes to be collected (http://itprojectguide.blogspot.com/2007/09/back-to-basics-project-tasks-part-1.html)

Prior to meeting with anyone, take a first pass at defining each task's description, this provides the scope of what each task IS, it should contain as specific information as possible WITHOUT adding to much detail as to confuse the delivery (if you're adding a lot in the description chances are you're identifying that the task is actually two or more tasks and need to be separated out). In addition to the description make sure to provide the deliverable - a fuzzy deliverable description provides for fuzzy deliveries.

The most important step in this part of the process is getting the involved people - INVOLVED. Without the people involved in doing the actual work, at best, you'll take a wild guess at effort, missing tasks, etc. Make sure to listen more then anything else - good people will provide good information and identifying the potential resource issues now will GREATLY REDUCE overall project risks (it's all about the people). Get their input to the tasks, are there any missing ones? Get their input on effort AND duration (know the difference and ensure you understand which one they are talking about). Prod them to understand what needs to be done prior to the given task - do you have any missing tasks (the number two high risk to any project is unidentified work/tasks).

The end result of this process is the gather of more detailed information for each task, identification of any prior unidentified tasks and MORE IMPORTANTLY:

• understanding of the people involved in the project
• their buy in to the project (if people provide the info, the potential of them delivering is much higher)
• a true time line (you have a starting date, predecessors and durations - string them out and you see the complete time line - pass 1)
• if you listened you'll also have a good set of risks that need to be mitigated

Congratulation's - the easy part is mostly over - you know have a base set of tasks for your project, now it's only a matter of getting the time line to fit into the sponsor's expectations, taking a few more passes to better define and just getting the work done...........