Back to the basics - Project Tasks part 3.0: How? Identifying Tasks

link to part 2: http://itprojectguide.blogspot.com/2007/09/back-to-basics-project-tasks-part-2-why.html

It's a target rich environment out there. Once you have your project charter and scope (to be discussed elsewhere), one of the next steps, and one most associated with project management, is creating your plan. There are various methods/approaches for this:

• WBS - work breakdown structure - http://en.wikipedia.org/wiki/Work_breakdown_structure
• User Stories - associated with most Agile methods - http://en.wikipedia.org/wiki/User_stories
• JAD - Joint Application Development - http://en.wikipedia.org/wiki/Jad
• UML - Unified Modeling Language - http://en.wikipedia.org/wiki/Unified_Modeling_Language
• Six Sigma - http://en.wikipedia.org/wiki/Six_sigma

YES - I know the above list is not all specific to task identification, but the list is about methodologies that at least discuss task identification.....I think the two approaches most used are working with a group to identify tasks for a project and working alone.....and then hopefully getting input and feedback on the tasks identified. The method I've found most effective in capturing tasks is brainstorming (in a group or alone) and building a WBS (work breakdown structure) on a white board. (You can use some mind mapping tools - http://www.nova-mind.com/ is my favorite), but don't let the tool get in the way of the process. WBS, User Stories, etc. - it's all about the results - identifying as best as you can the tasks required to complete a project. Things to consider during the process:

• don't get pulled into the details - not yet - keep it high level for at least the first pass
• base the size of the task (duration/effort required) on the risk level assoc. with each, group culture, etc. This requires a high level of intuition which over time will improve. I've always used 2 week increments as a base - get the tasks to a level that will take about 2 weeks to complete each one - this is based on a 6+ month project duration. My feeling is that 2 weeks can be recovered if worst case the task does not completed at all and it's big enough to track (tracking to many tasks is as bad as tracking no tasks).
• make sure everyone has at least a high level agreement to what the task is, use common terminology and use short/sweet/simple task names to identify them
• make sure each task is associated with a hard deliverable - something like 'think about the design' without a deliverable has no meaning or value and will not really happen
• think about, but not to deeply, the people performing the tasks.....don't get pulled into the details
• make sure you have logistical tasks identified - not ordering servers, workstations, hiring people, etc. will drive the project in the direction of failure as quickly as any other missed task.
• DON'T get caught up in the tools yet, not the project tools, development tools, testing tools...don't let preconceived 'notions' restrict this thinking process - if you never put yourself in a box you'll never have to think outside of one
• time box the task identification process - you'll never identify them all and, like taking a test, the more you go back the more mistakes and less overall value will be added. Make the task identification process an iterative one, revisited throughout the project.