Expand my Community achievements bar.

Ideal Project Size

Avatar

Level 4
What is a typical project size in your instance in terms of number of tasks? Also, do you typically permit a Workfront project to span multiple departments or do you create separate "sub" projects for each department that contributes to the overall project / program? Thanks! Daniel Cooley Kenall
17 Replies

Avatar

Level 10
We typically range from 200-1,000 tasks in a project depending on the project. The average appears to be around 388 tasks (using our current top 9 projects). We don't do a lot of sub projects. We currently have an Office 365 Program which has 2 projects at the moment. We haven't really termed them as sub-projects, but I suppose technically you could call them that. Regarding Departments, we started as only IT using Workfront for projects etc. And the rest of the company is on Workfront for the ability for Helpdesk (we use WF for our Helpdesk). But a couple of other departments have started to inquire and start using it for their work management. Some just track their work. Some are creating little projects. I just trained one of their members and let them do their thing. As far as spanning departments we're kind of compartmentalized but if I need someone from the business side or another division to work on a task I can easily assign it to them because everyone in our company has a WF account (of at least a Reviewer level) (to allow them to open Helpdesks). Let me know if I've answered everything. Thanks. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 4
Wow, up 1,000 tasks. We don't go over 350 hardly ever and our large projects usually around 250. How do you manage the development and maintenance of those large projects (task names, descriptions, durations, planned hours, predecessors, etc)? How many projects would a single PM manage? Daniel Cooley Kenall

Avatar

Level 10
Hi – I like our projects to stay under 200-250 tasks. My experience is that anything over that becomes unwieldy and out of date quickly. I would rather people break up their deliverables into separate project plans than to aggregate them all together. 1000 tasks is too much, too difficult to find things, and become inaccurate because of the difficulty in maintaining them. Eric

Avatar

Level 1
Our Professional Services team uses Workfront to manage customer deliverable projects, using a standard project plan template of around 40 tasks. The template used to be 120 tasks, in order to help new-hires on the team to remember everything they needed to do, but the experienced PM's didn't like that level of granularity. So what we did was create some custom forms which serve as checklists on certain tasks. These effectively act as sub-tasks, but without cluttering up the Gantt chart or requiring task assignment. Each sub-task had 3 options: Done, Not Done, and Not Applicable, with Not Done being the default. This way, experienced PMs could simply close off tasks when they were complete while new PMs could go through the checklists if they needed to. We even went so far as to create an external process that updated the %-complete on the tasks based on the status of each item on a checklist, but that was probably overkill. :) Mike Fox eXplorance

Avatar

Level 2
As our company's in-house creative agency, we rarely have projects more than 50 tasks, with most of them being in the 20-30 range. It's a fine line of being too granular and not being detailed enough, but we've found a good system using templates that allow the PM to customize it per request and cut out any unnecessary tasks for that particular request. Malisa Lieser Tennant

Avatar

Level 10
Yeah we run full blown IT projects that can last up to 1-2 years (for example Windows 10 and OneDrive installations). So we tend to have more tasks. The PM rule of thumb I was taught on granularity was "No task longer than 40 hours. No task less than 1 hour". Less than 1 hour gets too granular. Greater than 40 gets increasingly harder to manage and track properly. And bringing it down to 40 helps you really focus your estimates. Of course there are exceptions to this rule. It's just a rule. When first starting a project (with no requirements yet) you may say a coding task will take 2 months. But then when you have requirements you break that down into smaller tasks (ideally of 40 hours or less). And of course you'll then have a better estimate. Vic Alejandro, PMP, CSM | Senior IT Project Manager Denver Water | t: 303-628-7262 | c: 303-319-6473 Http://www.denverwater.org Sent via mobile phone

Avatar

Level 4
Jumping in here.... I am the world's laziest PM :) I do not want to maintain a huge number of task, but I want the job done... ... My rule is a few tasks as possible.... Entered by me! I allow my teams the flexibility to enter more detail, if that's what floats their boat, but I will hold them accountable for maintaining those tasks... ...Also, we are an agile operation, so fewer tasks is better, otherwise assigning work to sprints becomes a real chore. The tasks are there to be a discussion point every scrum, to show progress (burndown), and to record hours worked (especially by vendors). This bare-bones approach allows me the time to be working directly with my stakeholders, SMEs and customers rather than maintaining tasks just for maintaining tasks' sake :) Thank you Phil (wearer of Workfront socks...) Phil

Avatar

Level 10
Most of them are probably in the 300 range. But we have some projects that span a year or so. So they'll be closer to 900. We have two Templates we created in WF (one Waterfall, one Agile) that the PM's use as a starting point. In the Template, we have the Milestone Tasks & Approvals already set and links to documents in tasks that would require a document. For example, the Task to Create a Project Charter has a link to our Project Charter Template. Predecessors are set as well. Then the PM would modify it to suit their project (add, change, and delete tasks). Update the estimates (Duration and Planned Hours). They should be adding details about the task in the Description (but they don't always do that J ). As a rule of thumb that I learned on Task Names, all Tasks start with a verb. It was a neat trick I picked up somewhere. It helps with clarity. For example, I used to have a task that simply said "Requirements". Well what does that entail? Am I gathering requirements? Writing them? Drafting them? Finalizing them? Obtaining sign off? When you add the verb it makes it more clear and it usually becomes obvious that you need more than one task. In this example, I would want to gather reqs with the business user, write them, re-verify them with the user(s), and obtain sign off. So one task can become four. Some may say just include them all in one task. But that gets hard to manage and track where you're at (especially on larger efforts). And putting them in one task would usually be underestimated. When it's broken down, you get better estimates. Number projects per PM depends on the size of the project. We have one very large project, so that PM gets only one project. But in general, most PM's have 2-4 projects. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 10
It's all personal preference, and style right? This is art part J I've seen the bare bones approach (with less tasks) also go horribly wrong (nobody knew what was included in a task). One thing I forgot to mention on managing these "unwieldy" J projects. We built a Weekly Status Dashboard that sits on each project. It contains reports that provide: Tasks Completed Last Week Tasks Scheduled for this week Open Issues Issues Updated this Week Risks And Change Requests Then the PM can review these items in the weekly status meetings. Helps maintain the focus. It works well for us. Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 4
Hi Vic, Thanks for the clarification. That helps. I sounds like you have that dashboard setup as a custom tab on every project. Is that right? Daniel Daniel Cooley Kenall

Avatar

Level 10
Yes, correct. I think I even put it in a Layout Template so it just appears as a tab in their project (so they don't have to know how to go find it etc.). Vic Alejandro, PMP, CSM | IT | Sr. IT Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

Avatar

Level 2
We have templates that start projects with a minimal 10 tasks. then the last task is if the project is approved to go to production, we add Phase 2 template with 10 more tasks. We also create child projects connected to the original. Lots of really nifty dashboards and project views, etc. Including milestones. Keeping it simple has been the best method. Linda Wanitschek Intel Corporation

Avatar

Level 10
We have recently discovered that for larger projects, the Plan Hours calculation shows different results in different places. (yikes!) Example, the Project Details say 3,112 hours. But the new Project> Utilization Report, shows the total PH for the project at 9.8 hours less (even when you include/count the unallocated hours). The Resource Estimate report (using scheduled hours) is 157.8 hours off. Not good! We are working with WF Tech Support on trying to see what is going on.

Katherine Haven, PMP VP, Director, Business Technologies - PMO FCB

Avatar

Level 8
Katherine, we have a similar case open except it's on Actual Hours. The project overview page says one number, but when you go to the hours tab it is different. It is not on every project, so it's been tricky trying to figure out why it's happening. Recalculate Timeline/Finance seems to fix it...but it shouldn't be mis-matched in the first place. Is anyone else seeing this problem? Adina Pierce Cisco

Avatar

Level 10
Hi: Ugh, been there, I'm sympathetic. It is my opinion that some places they show the sum of labor hours on tasks. Other places they add in the planned hours of issues. Other places they take the hours charged to tasks, issues, and hours charged to the project (usually from tasks that were deleted). I started making a matrix to show the hours by type and it wasn't ambiguous anymore. I should go back and find that matrix. J

Avatar

Level 10
Recalculate Timeline doesn't resolve this for us. Eric - thanks, I'd love to see that matrix if you find it! Katherine Haven, PMP VP, Director, Business Technologies - PMO FCB

Avatar

Level 5
Linda- can you tell me how you create a child project? what links it to the parent project? tks Karen Karen Rutz Harvard Alumni Affairs and Development