We need to define our tasks and milestones.

Task Definition Inputs

There are many sources of information to help us determine the required tasks for our project:

  • The WBS and Project Scope Statement are used to ensure that all information about the project scope is included.
  • Constraints and assumptions should be considered. There may be tasks that can be defined to perform early in the project to validate assumptions.
  • Historical information can be valuable in helping to identify tasks, estimates, and resources from previous similar projects. Lessons learned should be reviewed to see if there was scope missed on previous projects or if there is other applicable information that may be helpful.
  • Organizations may use templates as a starting point in task definition. We may use templates containing tasks, durations, links, resources, and other details.
 
 
 
Task Definition Details

Tasks must be broken down to a level where they can be estimated, assigned, and tracked. There are several recommended rules of thumb that can be used, including:

 

 
  • 8/80 rule – Define tasks so that no task is fewer than 8 hours or greater than 80 hours.
  • Less than 2 update cycles – Keep tasks at a duration that is no more than 2 update periods. Using this, no tasks should be in progress for more than 2 status meetings. Typically, organizations have a standard update cycle of one week, which would mean a maximum of 10 working days. Your update cycle may be different.

If tasks are not broken down into enough detail, you lose visibility to the early stages of a problem occurring. It is common for a task to be reported right on schedule all the way up until just before it is supposed to be finished. If you have a task that is two months in length, you are likely not to know that the task is not progressing as planned, until close to the end of the two months. Team members usually believe they can make up any progress that they are behind, so will report on track. By decomposing the task into multiple smaller tasks, you can identify variances earlier.

However, if tasks are broken down into too much detail, you can end up with so much data that you spend your time managing the data instead of the project. Don’t let your tasks become a checklist.

The people performing the work should be involved in defining the tasks. For each task, some basic information must be understood and documented:

  • What is the output for the task? – What is the deliverable – what are we doing and how will we know when it is done?
  • How long will it take? – An estimate in duration (span time in working days) and/or work (effort hours) is needed. This should be estimated by the work performers.

There are a number of ways that estimates may be provided, e.g. task will take 5 days total to complete and a total of 10 hours of effort, or task will take 40 hours of effort and I will be working on it 50% of my time.

If you are doing task management only, and will not be assigning resources to your project, Duration estimates are needed.

  • What inputs does the task require? – For each task you must identify all of the inputs to the task. Initiating inputs are needed to start the task. Progress inputs are needed at a certain point during the task to continue making progress.
  • Who is responsible? – There should be someone assigned responsibility for each task.

Milestones are created in the same way as tasks, but with a Duration of 0 days. Milestones can be used for linking and reporting. They allow us to measure progress in our project.

**Best Practices:

  • Task names should begin with an action word – a verb.
  • Task names should be detailed, unique, and standalone. If you are looking at a subset of the tasks, this will allow you to understand exactly what the task represents and where it falls in the schedule structure.
  • Include a Start milestone at the beginning of the project and a Completion milestone at the end.
  • Include a milestone at the end of each major summary task group (WBS deliverable). These are useful in reporting and for linking.

_________________________________________________________________________

Materials are based on the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) 7th Edition, Project Management Institute, Inc., 2021

PMBOK is a registered mark of the Project Management Institute, Inc.