in reply to OT: The mythical man month - have we learned nothing?

Following up on dragonchild, the best way you can demonstrate this up front is with a detailed project plan. The advanced project manager types use software to designate tasks with explicit dependencies on each other. Then, they schedule the project and it shows the parallel and sequential tasks. If all you have remaining are sequential tasks, more people won't help. If you have a bunch of parallel tasks, bodies might help.

You still run into the issues mentioned above bringing a new person up to speed, but with parallel tasks there is at least the possibility that they can help move things along. If you have a bunch of components dependent on each other, it really won't matter and your project plan can prove it.

If they insist, the next step is to re-design things to remove hard dependencies. But if I remember, Brooks notes that mocking up interfaces to allow people to work in parallel can create some nasty integration problems at the end when people arrive at different points.

  • Comment on Re: OT: The mythical man month - have we learned nothing?

Replies are listed 'Best First'.
Re^2: OT: The mythical man month - have we learned nothing?
by g0n (Priest) on Feb 21, 2006 at 11:57 UTC
    Leading on from that, if your project manager is familiar with the Prince2 PM methodology, you can relatively easily demonstrate the problem in their own terms, using 'Product Breakdown Structure' and 'Product Flow' diagrams.

    The PBS splits the overall project 'product' into individual components, which in turn are split into subcomponents etc. The product flow diagram shows the chain of dependencies of products - what has to be built before the next product.

    If you can diagram software components in the same way as the (probably) less rigorously defined 'products' that the project plan contains, it might be easier for him/her to understand what you're getting at.

    You can also explain with a PBS that once you break down the products to a certain point, it's impossible for two or more people to work simultaneously on the same product - two people simultaneously writing the same subroutine?

    Another product based planning concept that's handy for this is the 'integration product' - that's a product where "one or more activities, such as assembly or testing, will need to be applied to that product after its sub-products have been produced" ('Managing successful projects with Prince2' - OGC), so for instance once all the subcomponents of a block of code have been written, someone has to compile them all together and test them.

    --------------------------------------------------------------

    "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
    John Brunner, "The Shockwave Rider".

    Can you spare 2 minutes to help with my research? If so, please click here

[reply]

In Section Meditations