In medium size project were you are interfacing with functional Project Managers, and you are the PM for the entire project.
How much details do you want in your WBS?
Do you break it and keep it high level but deep enough to know what's going on?
Or do you go all the way in, to the point you know each team members tasks, even if they are 16 hours task?
I really recommend using a WBS only for what you want to summarize and report on. In many many cases you only need a few (3?) levels in a WBS to capture things like budget centers or functional departments. I've been part of attempts to define 9 levels in a WBS where level 9 had the categories "design, implementation, testing, documentation, rework, etc." The feeling was that at some point after the project was done, you could simply add all the Design items up to get a "cost to design" the product. These never worked. Their usefulness tended to be related to the size of the projects (bigger projects would like this more, smaller projects can get the same thing without it). But bigger projects tend to re-organize and re-baseline, so you start getting weird things like "don't count Baseline 6 in the totals" which invalidates the 9 levels pretty quickly and only creates work for people to keep everything updated.
To solve your problem of "keeping on top of the sub-projects" I always ask for milestones from their schedule. So, one sub-project might have "transmission prototype available" that I want to know about. So, I ask to report on that milestone. As the "transmission prototype" slips in and out with the schedule, I can see it in the milestone. I'd usually ask for a few milestones each month for each sub-project, and I would feel no hesitation in looking into the project plan/details whenever I was feeling bored.
Of course, I've learned in my old age that the best way to approach a medium sized project is to work like heck to decompose it into small projects that can be "done done" and built upon iteratively/incrementally.
hth
There is no right answer to the WBS decomposition. What worked for one PM on a similar engagement could be disastrous for another on the next engagement.
You decompose your WBS to the level at which you can manage the project. This is one of those thing where you know you have right when you see it. You also need to listen to your intuition on this. All of us approach management in a different way. One size does not fit all.
There are trade-offs. Too high a level, the administrative burden to manage it is less in terms of cost. However, you lose insight into what is going on in the work and to understand where variances are accruing and why. This lack of insight increases your risk of successful ability to mitigate those variances. It decreases your ability to able to re-plan the sequencing of work if you have to correct for a schedule variance. And if your WBS is deliverable-oriented, you have less ability to control scope creep with a higher level WBS.
Too low a level, all of those risks above are decreased or go away but your costs to manage will sky rocket. You will spend more effort on analyzing the WBS and schedule than managing the overall effort. For each project and for each manager, there is a balance between these two points. You have find that for yourself.
When I hear of a project manager managing project managers -- the "project manager manager" -- it makes me think more along the lines of program management than project management. While the skills are very similar, it sounds like you're in a position where you need to focus on higher level concepts, similar to a program manager.
Program management exists because businesses realized that sometimes a driving force was necessary in order to drive separate yet complimentary projects towards the same high level goal.
Program managers are less concerned with the details of the individual tasks and are more focused on the strategic goal. As a result, their project portfolios will contain very high level information about each project.
What's more, there is a phenomenon that exists where increases in the amount of available information is inversely proportional to the ability to actually process that information. In other words, the more tasks that you try to keep track of, the more poorly you'll do at keeping up with the progress of those tasks. After all, that's why you have project managers working with you, so that they can worry about the details while you worry about the big picture.
Focus on the big picture, trust your project managers, and measure the success of the project portfolio from a high level, and you'll find that you're better able to focus on your responsibilities of aligning the goals of each individual project with the goals of the entire program.
It really depends on the length of the project. For reporting purposes, I have seen the rule of thumb that the lowest level WBS items should span no more than 10% of the project's estimated length. And also seen that no item should span more than your reporting period ( time between status reports ).
As mentioned above you need to weigh the administrative burden as well. Leave the 'inch pebble' tracking up to the project managers, or the people who are actually doing the work. Let them roll it up in their status reporting.
In your case, as you are tracking multiple projects you should really be focused on deliverables and not discrete tasks. But again, it is entirely up to you how you want to track things.
One thing to note, the WBS should be a tool for your teams to decompose their work. Let them get as granular as they want if it helps them figure out what needs to be done. Then simply roll it up to the appropriate level for status reporting.
