March 31st, 2009 | 
Author: (note: this is a long post. please click on the link above to read the entire article)
Earlier today, a colleague and I were talking on the subject of what metrics to use to determine the right size of a project. This was an interesting question because I don’t really know of any metrics to track and a few quick Google searches did not turn up anything too interesting.
Since all projects are different, I think it is fair to say there can be no formula for deriving the right size for a plan. That said, we came up with some general rules of thumb and a basic formula to follow. I’m really interested to hear what you have to say about this, so please do post your comments!
FIRST, THE FOUR RULES OF THUMB — Generally Speaking…
Rule of Thumb #1 – Tasks should not be shorter than five days. Even if someone comes in Monday and can complete the document in three hours, they have a day job and probably won’t get it done until the end of the week.
Rule of Thumb #2 – Tasks should not exceed 15 days (3 weeks). While it may indeed take three weeks to deliver on something, a Project Manager usually needs a weekly status update so it is best to break up tasks taking any longer than 15 days into smaller parts.
Rule of Thumb #3- A plan should always be managed to a point where the critical path can be derived. If the plan is so large and too detailed or if it is integrating with other projects, the level of detail to capture for any given plan should always be such that it is still relatively easy to define the entire path through the project. If this is not the case, then we really do not know the planned end date to the plan.
Rule of Thumb #4 – A single project plan will not have more than 20-30 resources. Essentially, if the project plan has more resources actively working on the project then you are probably working within a “Program”, which is compilation of projects requiring more significant planning for the divisions of labor.
AND NOW THE FORMULA…
Let’s assume for a moment that your project is 12-months (1 year) in duration. The project contains 16 total resources and some sub-contractors. We can assume that not more than 8 total people are dedicated to the project each month.
If four people can deliver about two major deliverables each month then we are probably in really good shape.
8 People @ 4 deliverables/month * 12 months = 48 Tasks
Sub-contractors usually work on a whole new set of deliverables that our internal team either can’t do or does not have the bandwidth to work on. Let’s say we have an average of 2 full-time-equivelent sub-contractors that are paid to track 10 tasks a month and produce another 2 core deliverables each month.
(10 tasks/month * 12 months = 120 tasks) + (2 deliverables/month * 12 months) = 144
Whether or not we physically integrate our project plan with other schedules, we usually have to track progress of external projects or other ‘forces’, totaling about 4 elements to watch each month.
4 external elements to track/month * 12 months = 48 Tasks
Project Managers have to manage themselves and are usually held to track progress elements defined by their sponsors, a PMO or other entities. Chances are, these additional tracking items won’t exceed 10 items/month, 5 corporate milestones and 1 project-level milestone a month.
(10 Additional items/month + 1 milestone/month = 132) + 5 corporate milestones = 135 tasks
Lastly, let’s say we are following a 5-phased methodology of Initiate, Plan, Manage, Train and Deliver. We also have a work breakdown structure under those phases that might naturally break out the underlying tasks in a simple way. We probably won’t have more than 2 different levels that cut across each given month. In terms of tools, MS Project will count those as ‘task lines’.
(2 sub-phase headings * 12 months) + 5 primary phases = 29
AND THE NUMBER IS… 404 TASKS (INCLUDING SUMMARY TASKS) FOR A 1-YEAR PROJECT!
Well, there it is! What do you think?
-Bill
Wow, you are a complete idiot. Have you ever actually managed a project?
[Reply]
Hi anonymous,
Oh yes, I’ve managed some very large projects and programs. Depending on the level of skills, resources and types of projects we run, I tend to be a minimalist. All things considered, if I have a plan that is easier to read, then I am definately going to go that route because it reduces my time trying to keep the plan up to date and increases the chances of my teams trying to understand it.
Of course there are larger more complex projects — even using my example — that more tasks and more work breakdown components are required so I would not argue that. For example, I have some government and ERP projects that are ~1200 lines and they do belong there.
So here is my opinion…
After working on projects for 20+ years, I see too many projects with work breakdown structures like “create document, review document, revise document, meet to review draft, finalize draft, submit draft for approval, complete document, meet to review completed document, submit for final approval”. That’s 9 tasks to complete a deliverable(!) Most projects have dozens or hundreds of key deliverables. Let’s say I have 50 deliverables for the year. That’s 450 tasks just for the deliverables, not any other tasks or milestones.
I humbly submit that have the things we track in a schedule is not required in the plan and it belongs in our collaborative environments. If we have SharePoint or some other web-based site to track those details, our plans should be lean and mean and focused on completion, not superfluous details that really do not belong in a critical path.
-Bill
modification was made due to my signature appearing multiple times.
[Reply]
Bill,
Your last comment is on the mark. But we need SOME way of managing what I call “checklist items” besides putting them in the project schedule. The three options are stuff them in the project schedule (and have a 5000 line schedule) track them in some other way (and wonder why you bother updating the schedule) or ignore them completely.
None of those options are particularly good.
There has to be a better way, but I’m getting tired of waiting for it.
-Jack Dahlgren
[Reply]
Some scheduling tool e.g. Primavera all for the association of a ‘to do’ list with a task. Some MS Project firms have linked Sharepoint lists with plan tasks. In either case, the functionality improves the management approach though the ‘right level of detail?’ question remains. I ask people to plan at 1 level of detail lower than I want to see the reporting.
[Reply]
I have been teaching planning and scheduling for about thirty years. This question of how far to subdivide the job always comes up. It is really the driver of “How big a schedule is big enough?” My answer is as follows:
Subdivide any given element of work until the following three criteria are met —
1) The element can be estimated (cost, labor, duration) fairly accurately,
2) Progress can be objectively assessed, and
3) Clean finish-to-start logic can be used to relate the element to predecessors and successors.
This may result in some tasks that are shorter than your five-day minimum, Bill. It often results in tasks longer than your arbitrary 15-day maximum. The third of my criteria almost guarantees the emergence of one or more critical paths. I apply whatever resources happen to be needed for the job. I can’t imagine why you’d want to put some kind of limit on the types or number of resources. The goal is to develop a realistic plan that can be used to generate a time-phased budget. Once that’s accomplished, it needs to be usable to track progress. It ain’t rocket science.
[Reply]
Hi Bob,
This is some very good insight and I appreciate the thought you put into this. You also point out a very important concept that I may not have been too clear about, which is that I don’t think the numbers I posted are designed to be hard-and-fast.
In fact, I work with some clients that rightfully have thousands of lines of tasks for a single 1-year project, with large and small durations and advanced logic.
That said, these types of projects usually have at least two roles for Project Management. One role is the Project Manager who is responsible for managing the team, reporting to senior management, collaborating with external parties and the like. The second role is that of a Project Controller who is responsible for the day-to-day upkeep of the schedule, running reports, tracking down status, refining and fine-tuning the schedule, and so on.
So I will completely agree with your point that the plan must be usable and if it becomes rocket science, I hope you are building a rocket!
[Reply]
Bob’s response is absolutely the correct one. Discreet, estimatable tasks with clear performance measurement goals metrics (Objectively viewed status)is the key during WBS planning to get to a schedule you can have confidence in. Even with that, error/defect/discrepancy and regression testing work continues to be hard to objectively plan (estimate)on new projects without historical metrics to base assumptions on. This usually leads to the creation of longer duration “bucket tasks” based on FUD (fear, uncertanty and doubt) that are hard to get program managers to reduce. Any suggestions here?
[Reply]
One mouse click often leads to another fine blog. Like yours – Thanks.
[Reply]
Very nice, I sure will be coming back more often. I bookmarked your site also, thank you. This is my loved sites : erp
[Reply]
Hi, I´m Pam, interesting post. I am a second grade teacher in Orange county. Nowadays , most people wish to save up cash on their electricity bills and one of the most common methods is through using solar energy. What can we, the regular people do to aid save up our World? The answer may sound hard, but it’s very simple. Build your own solar panel.
[Reply]
Super-Duper site! I am loving it!! Will come back again – taking you feeds also, Thanks.
[Reply]
As i extremely enjoy the things you place right here. Rather unusual and even brilliant. 1 trouble however. I’m operating Ie through Debian and even pieces from your up-to-date style articles is a modest wonky. As i notice it’s a fantastic usual put together. Still it’s a specific thing to help you maintain in the mind. As i wish going without shoes may allow and even keep the best high-quality authoring.
[Reply]
Great post.
[Reply]
Quite, all can be
[Reply]
Bill,
Back in 1994, while working on DOE IT installation project, the project manager (I lost his name) commented that he had a formula based on the $$ amount of a o project or Project-Value. So, for example, a 10 Million project should be managed using XX tasks, while a 1 Million project by 1/10 of XX tasks. Reading your formula it seems it is implicit in your assumptions “Let’s assume for a moment that your project is 12-months (1 year) in duration. The project contains 16 total resources and some sub-contractors. We can assume that not more than 8 total people are dedicated to the project each month.”
Unfortunately I lost the formula he provided otherwise I would disclose it. It would be very useful to have some guidelines for estimating “quickly” the number of tasks by Project-Value.
Any ideas?
Best regards.
[Reply]
I don’t even know how I ended up here, but I thought this post was good. I don’t know who you are but certainly you’re going to a famous blogger if you aren’t already
Cheers!
[Reply]