Then I got the call from my team lead. We needed to come up with a new estimate. Why? Well he said some managers will see the 300 hour number, put 3 developers on the project, and schedule it to complete in 300 calendar hours. Oh no. That will not work.
You see, all the work cannot be done in parallel. Somebody needs to figure out the FindWindow replacement for Windows 7. Then that technology will be applied to the places in the applications that use FindWindow. There is a critical path which must be worked serially. Assuming everything can be done in parallel will result in a nasty schedule surprise.
My team lead told me to determine the criical path, then multiply those hours by the number of developers we think will be assigned. That will save us from anybody thinking they can divide the total hours by the number of developers to figure out how long the effort will take.
This feels wrong. Shouldn't we teach critical path analysis to whoever is doing the schedule? That way we don't have to do these estimate hacks? Apparently that task is harder than it seems. We got some managers who are looking to slash the schedule. Their angle is to slice and dice the work up amongst multiple developers to decrease time to delivery. They apparently do not want to know about the critical path. Go figure.
