On resource optimization...

How many people does it take to develop a specific software module in a mid- or large-size organization? On the face of it, it seems to be a simple question. You size the project in terms of man-hours, divide by 8, divide by the number of working days you have to complete a project, and voila: you have your people count... right? Not really... as there are quite a few additional considerations to take into account.

1. How many changes do you expect on your project? In sizable organizations, project scope fluctuates... and saying no to every change control does not foster a positive relationship with your business partners. Since the amount of change is driven by both the individual(s) who initiate your requirements as well as by the inherent nature of the domain, use historical examples to determine what capacity buffer you should plan for during your project. Ramp up these resources at key points in the lifecycle, such as toward the end of your requirements-analysis phase. This allows the majority of your team to focus on mainstream design, while others can evaluate new requirements and incorporate them into the project.
2. How skilled is your technical team? In many companies who use outsourcing today, skill in a specific system or domain can vary each year, as the outsourcer rotates people among portfolios. Even if technical skillset is solid (and don't be surprised if this is a "big if"), your developers must understand the system architecture, environmental tools, and the like. Otherwise, plan for a good amount of ramp-up at the beginning of each project phase and assume productivity will be lower per capita. Consequently, add a "new team member" contingency to your project... which will translate into either additional staff, longer timeline, overtime, or a mixture.
3. Flu season? People have been known to get sick once or twice during a project. This risk increases if you're executing during periods of known flu seasons or other types of periodic illness. If your dates can't slip, allow for some contingency due to illness.
4. Have you done this type of project before? Projects come in all shapes and sizes. If you've done this type of development before, consult your historical records for variances between your projected and actual effort... and build yet another contingency in your project. If this is your first time with this type of animal, either consult colleagues who tamed this beast before or allow for some healthy contingency.
5. On how many other groups do you depend? Large-system development in sizable organizations typically involves other groups... both internal and external to the company. Each group's changes either be "business as usual" or can represent a significant effort for said group. Increased effort increases their (and your) risk, especially if not all managers run a tight ship like you do. Hence, increase your contingency for every integration point outside of your direct control. Unfortunately, this contingency will impact your schedule more than anything else... so make sure you have the people necessary to troubleshoot, bug-fix and implement workarounds when the time comes.

The purpose of planning for the right amount of people is to enable successful delivery of the project with quality and within agreed-upon timelines... without needing to beg for mercy (in the form of additional time or cost) from business owners. There will always be risks that you either cannot predict or are so infrequent as to not be likely. For example, if the business champion for your project suddenly wins the lottery and a new champion will take her place, the impact to timeline this creates definitely warrants a project checkpoint and an independent go/no-go decision. Unless you're already into heavy coding and you've already forgotten the business partner's name, you need to have a candid conversation with your business champion.

Setting the stage...

Why do some writers employ pseudonyms? On one hand, it gives one the anonymity necessary to publish views without fear of heckling from friends and close associates. It allows freedom to experiment with ideas without later being tied to statements no longer part of one's worldview. On the other hand, should one have a profound influence through one's writing, the world may never truly know the author. Though I've often considered the question of anonyms, I never envisioned myself using one someday. Alas, the tactical benefit is, for the present time, the clear winner. Hence, I shall pen these musings as one Walter Bradford Jones.

That said, here is a riddle. The SHA1 digest of my first, middle (full), and last name (all letters lowercase and including spaces) as computed in PHP Version 5.2.0RC6-dev is 28c2323c86c1ac810e4504e80efa8e61e581d4ff . Who am I?