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?
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.
protected by David Espina Jul 28 '15 at 20:40
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?