Discussion on:

How to complete a schedule for a project

I agree, and take the project timelines I develop very seriously. But I'm currently being asked (by the project sponsor) to fit in about 10% more deliverable to my existing project without impacting the timeline. Because I do take the published timeline seriously, and I've already asked for a 10% timeline increase and been told no, I'd like to know if anyone else out there has generally still been able to be successful in their project with that amount of increase and no additional increase in resources or time?

I think that this is a good example of why software developers don't think much of the project management business. (See the article and discussion on http://www.codeproject.com/useritems/SDLC_HELL.asp)
At no point is it mentioned to everyone that until we know what exactly it is that we want - and finding that out is part of the process - can we ask those who can make it happen how long it might take. At that point, developers will give out their wildass guesses. A great developer will be better with their guess because they will be correct more often with their architecture choices at the beginning.
I don't think that anyone in the business wants to admit that unless this is *just like* the project we've done before with a particular team, we won't have anything more than a really broad idea of how long a process will take.
Agile doesn't say that exactly but it tells you that it will give you a little bit at a time and tell you how long to get that little bit. It avoids the question of how much will it cost to get this certain amount of benefit when that is too hard to tell. That's not really helpful but at least it isn't quackery.

While Project A and B might not be identical, there ought to be some historic data in the develoment team based on complexity that allows for better than WAGs. Even without developer input, I'm building a plan right now where I know the vendor comitted effort (in the signed off SOW) for Task 1. Until I get a commitment from the vendor for Task 2 and Task 3, I'm estimating their effort based on the comparative complexity of Task 2 and 3.

I think it would be a mistake to look for a template. Better to look for the discrete pieces of other projects, or even comparable bits of the same project, and use those to assembly the initial plan.

You can do the same for some tasks in which the stakeholders have made early phase commitments. I can give a reasonable estimate of later tasks we haven't reviewed jointly yet based on what they have committed to in the early phases.

I've had many years of construction PM where the constructor ends up at the end of the cycle and has to meet the deadline. Everyone is indecisive in making choices or designing elements and then we all rush to build it. Typically we know what we are building, how much it will be and when it is needed by, hence - HEY PRESTO! we have the work constants and number of hours we need to work to complete. There is a flaw in this method - we only get 24 hours a day and 7 days a week! ;?)

Since moving a number of years ago into IT Support, Implementation and then PM I have discovered clear parallels with execution and realised that SW is a different ball game. Even when the product is clearly defined and we have experienced developers involved, things can be a very different story from one project to the next.

After 26 years managing projects, I have determined that accurate work / effort estimation is very difficult for most people. Project managers and Development Leads tend to be conservative and build-in "fat" for contingencies; while programmers / developers tend to under-estimate the effort needed to complete tasks and deliverables. During early planning, they also tend to understate the calculation for time to solve issues and problems. Being aware of this may help PM's oversee the planning phase.