Yes and no.

Example:
If you calculate a project with four developers and one (purely managerial) project lead, you basically add 25% overhead to the effort. If you then double the number of developers to reduce the duration to 50%, the overhead percentage might increase or decrease depending on the people involved. There are non-linear effects due to communication and “noise”/cooperation between project participants.

So, the equation “duration = effort / full-time-equivalents” is only a very rough estimate. Additionally, you have to take into account public holidays, vacancies, illness, competing projects, resource priorities, etc. to derive the calender duration from the estimated effort.

A related question/discussion is here.

“Effort” is measured in man-hours (or man-days, man-weeks, man-months, or even man-years). “Duration” is measured in hours, days, weeks, months, or years.

You start by estimating the effort required to complete the project. There are lots and lots of ways to estimate, some better than others, none perfect. (Strong hint: Linear estimators (“ten lines per man per day”) do not scale up well.)

Once you have an effort estimate, you have to estimate the duration. This is closely related to constructing a draft (strawman) schedule, and inherently involves decisions on how many people you will put on the project. To a certain extent, headcount can be traded for schedule, but bear in mind that there is still a minimum duration for some things: it is just plain impossible, today, to make a baby in one month by putting nine women on the job. The better estimating methodologies will give you an “optimum” duration and headcount, given an effort estimate, and give you guidance on adjusting the effort estimate if you need a duration significantly longer or shorter than the optimum. (Generally, both cases yield higher efforts, and hence higher cost.)

For some duration estimates, you may have to take into account that you need specialists for some tasks, and they don’t grow on trees. If you have three Kalman filters that have to be set up and tuned, and only one Kalman filter expert, you are not going to be able to do those three tasks in parallel.

Recommended reading: “Software Engineering Economics”, by Barry Boehm, and “Controlling Software Projects”, by Tom DeMarco. These are the bibles of software estimation. If you want to read other books, fine, but read these two FIRST.

One more thing: No matter what estimating methodology you use, even if it is “engineering judgment”, recognize that you ignore the resulting estimate at your peril. LOTS of companies have learned this the hard way, and lots more will. Some have learned it many times over (or, more accurately, refused to learn it, many times over).