Meaghan CoonProgram / Project Manager| Velocity Project Management, LLCTempe, AZ, United States
Does anyone use the square root of the total tasks to determine the number of projects there should be in a portfolio? I cannot locate any information on this as a methodology. One of my clients (who is not a project manager) is advising that I should do this to set up his company's projects so that the work is distributed evenly across each project, but I cannot find any supporting information.
As we all know, the work varies by project and does not get distributed evenly in real life. He wants 10 tasks per project (!!). I would love to hear input on this topic. Thank you! Saving Changes...
That type of heuristic makes absolutely no sense to me. I see no physical reason (capacity, complexity, etc.) why that kind of exponential relationship would exist between tasks and projects unless there is some unique thing I don't know about the projects in your domain.
If you have 100 tasks, that could be one project and not a particularly complex one. Why arbitrarily break it up into 10 equally sized projects? If you had 2 projects each would have 2 tasks. That is clearly not the level of fidelity needed to track anything as complex as a typical project. One single deliverable on a project could involve a series of 10 tasks (and often many more). As tasks are added and completed, you would need to constantly re-balance and thus replan the entire portfolio already in work due to unrelated changes.
Tasks shouldn't be equally distributed across projects. They should be identified by breaking down the project deliverables into the activities required to produce them at the desired level of detail enabling effective management. Saving Changes...
The number of tasks in a project is a relative quantity and depends on multiple factors like complexity, type of processes, nature of the work, etc. Certainly, this factor can't be absolute or a result of a square root calculation. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
What your client is asking for is a rule of thumb used in software projects but to create a rough estimate for project duration. For example, if after the first estimation you get that the project will take 100 man/month then you have to transform it into 10 man/month and publish it as the duration. Related to programs, this rule is applied to the largest sub project and that will give you the program duration. always talking about a rough estimate. My recommendation is using Cone of Uncertainty as a complement to get a range and public the range according to the stage you are in the estimation. Saving Changes...
Given the incomprehensible manner in which some leadership teams populate their project portfolios, this approach which is akin to a monkey throwing a dart at a dartboard to pick a number is just as workable :-)
However, as the others have indicated, there's no basis for such a parametric estimate...
Kiron Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Meaghan,
sounds like a rule of thumb to have a quick sanity check on a portfolio. Though I never saw it before. It is similar to looking at a WBS and saying less than 6 rows deep and less than 8 1st level work packages.
A rational could be that - as example - you have 100 tasks in a portfolio, putting them all into 1 project would create a complex project and not use portfolio management benefits. Similar to putting each task into 1 project, would not use project management but put all burden on portfolio management. So between these 2 extremes, the square root indeed is the optimal balanced solution. 10 projects with 10 tasks each in average. Saving Changes...