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.
Earned value metrics is the end of the story. In other words Earned Value looks back at the result and ensures the value earned(profitability) and that is the end. But Velocity's main purpose is to provide data for upcoming work. So to bring this to waterfall, developer needs to manually do it. Remember SCRUM is a framework and velocity is brilliantly calculated by the framework(not by a PMP certificated Manager or a Scrum Master). Since in waterfall there is no framework backing, we need to do it ourselves. So the best option will be the developer creating a estimation history database and put in junks of data in the form of web pages, or hours, etc. There could be more parameters like the experience of the developer , work location, development framework used etc. Which ever the developer thinks affects estimation. And then pull the info from database. Try to get this as early as possible and perfect it as we move on. This is a standard practice in product development companies even before Scrum came into existence. Mainly because Product development companies uses standard company wide process and development frameworks. This way the equivalent of velocity can be calculated in non agile /waterfall projects.