When leading a project, what are some suggestions for documenting all tasks required? Who should be involved with the PM to come up with the list?

4 Answers 4


The name for this document is the Work Breakdown Structure (WBS). The WBS (and the WBS dictionary) document all the work that is required for the project. There are ample resources to help you develop a high quality WBS. I'm not associated with the firm, but my favorite guidance is from Sensei Project Solutions; if you write to them and ask, they have a set of filters for Microsoft Project and associated guidance that will significantly improve the quality of the WBS.

The Project Team should develop the WBS - I have some fairly strong opinions about that. The people doing the work are best able to plan the work.


Initial project documentation should be hierarchical in nature

For example, start with a Project Vision statement - this is a 10,000 foot view description and this statement declares the purpose of the project, who it serves, and why it is important.

The PM should be working with the client/Product Owner to define this

If you already have a team in place, they should be included in these top level vision discussions regarding the purpose of the project and potential ways that it could be implemented.

Define the users and their roles within the application

Understand your users upfront, and map out the features they would need to use your application. Do this with the Product Owner and as many experts from your team as possible. Create persona's if it makes sense to do so -

Create user stories that map out the 'minimally-marketable-feature' set

of your application, e.g., the core features and functionality necessary for the application to serve its users and function in production. This is known as 'Story Mapping'. Have the team estimate these features which will give your client an idea on time, e.g., 3-6 months, 6-9, 9-12 etc.

Include as many experts from your team as possible

Nothing worth doing is worth doing alone, include as much expertise as you can during all stages of the project -


I think Jon's answer covers a lot of what's necessary in an Agile environment. I'd like to add that if you're using a tool like JIRA or similar, you can use sub-tasks to specifically describe what's involved in each user story and assign them. Many different software suites offer similar functionality, and it makes it easy to track tasks and who should be completing them.

In an Agile environment, a self-managing and cross-functional team should determine who among them will be completing each piece of the work. It's also important to consider pairing and swarming on tasks, which can make your team far more effective.


Tasks are just a sub product of the scope management area. You actually have to start documenting your high level scope in a project charter and get it signed by the sponsor. Than later you create (together with subject matter experts) a WBS (Work breakdown structure). You start with a single box, which is the project name and then you progressively divide it either by solution phases, solution elements or whatever logic you and your team agree to. Tasks are then the last items in your WBS and they must be clearly described and have a time frame of min 8 a max 80 hours duration.

Small advice: Don't mix up duration with effort. Duration is how long it takes to be completed whereas effort is the man power involved in doing the work.

WBS Chart Pro is a good tool to document it. It has also integration to MS Project.

Not the answer you're looking for? Browse other questions tagged or ask your own question.