Assuming similar work has been done in the past, can velocity be measured on a waterfall project? If that isn't the case, is there a more appropriate capacity management tool on a waterfall project?
According to one source:
However, most sources don't really explain that velocity is based on the idea that you can extrapolate your expectations for velocity based on historical measures of how much level-of-effort can fit within a given time-box.
In addition, the level-of-effort estimates that create velocity metrics assume a baseline task size. For example, if task B is roughly 5 times harder than the baseline task A that's worth 1 story point, task B is assigned a story point value of 5.
Story points (or other level-of-effort estimates) are not quite the same thing as the throughput and batch-size measurements used in Kanban, but there are some similarities. Throughput may be easier to retroactively calculate than velocity simply because it is less dependent on the original level-of-effort estimates for task, which may not be tracked as such in a waterfall project.
Why Velocity/Throughput is a Bad Fit for Waterfall
A typical PMI-style project often has a work breakdown structure, but those tasks are rarely decomposed into tasks of a uniform size (needed for Kanban-style throughput estimates) or time-boxed multiples of a baseline level-of-effort (needed for Scrum-style velocity estimates). That would seem to make velocity per se a poor fit for waterfall-style development.
Retrofitting a Time-Box
You may be able to retrofit velocity estimates in a waterfall project by arbitrarily assigning time-boxes. For example, you might assume that every two calendar weeks is a time-box, and see how many man-hours of completed work fit into each time box as a trailing average.
This will be a very rough estimate, and you should probably expect the estimates that you get this way to vary by at least an order of magnitude unless your WBS is extremely granular. Whether or not this sort of retconned velocity estimate is in any way useful on a waterfall project (where you're generally tracking dependencies and deviations rather than throughput or time-boxed iterations) is up to you.
Deviations from Milestones
As an informal rule of thumb, most waterfall-style projects that I've worked on have used deviations from planned milestones as their primary metric. For example, if Feature Alpha is due June 1st, one tracks whether one is on-target for the June 1st delivery date or how far progress towards Feature Alpha is behind schedule. (Hint: Milestones are rarely ahead of schedule on waterfall projects.)
Accuracy with this sort of metric relies on a feedback loop that continually assesses the start/end dates of dependent tasks, and applying any identified deviations to the projected delivery date. This is a useful technique when one is tracking by time, but not so much when one wants to track the throughput of tasks or the velocity of features delivered.
As with any methodology, your mileage may vary.
You may want to use earned value management techniques. These should give you an idea of progress to date in comparison to the baseline plan and also allow you to extrapolate future progress. As with other forms of prediction, the accuracy of the estimates will improve as you get closer to the end of your project.
The main problem that I have had with EVM in the past is trying to avoid having Accounting take it over to suit their purposes rather than suit the purposes of the project.