Predictability and objective historical information

Over the last two weeks I have been involved at the process of interviewing project managers for an coming project.

A few positive things are striking me:

1. Eloquence. All the guys I have talked to seems to have a facility at talking. This is not a skill you can filter from their résumés. You expect this from a PM but I was expecting some to be weaker on this front.
   
2. Deep understanding of what they did. Although their experiences were high level project management (not technical) they would all be able to describe in a fair amount of details the projects they worked on. That's good.
   

However, a few not as positive things are striking me too:

1. Predictability. Let's face it, software projects are slipping for many reasons. However as a project manager you want to reach a point at which you will know with a rather high level of certainty when you will be completed. Periodically pushing back the delivery date is a bad thing both internaly and externaly. None of the guys have brought this up. It feel like this is even not a word they know about. It's like if this is external to them, don't shoot the messenger kind of attitude. I think this is wrong.
   
2. Historical Information. When talking about estimation, re-forecasting and schedule slippage one would hope that historical information is valued as a way to improve predictability. Apparently not.
   
3. Subjective info is king. Last but not least, it would seem that very few metrics are being used by the people I have talked to. This surprises me, they all had some form of PM certifications. What if the people that brings you back the info are bad at estimating? This one beats me.
   

Obviously, maybe the questions I have asked were misinterpreted, but I am telling you I did all I could to get them to tell me about predictability, historical and objective information.

The lesson here to me is that we will have to train this new project manager to consider looking at the past to improve predictability.

After all, this is rather simple thing to do. Take your velocity/productivity/burnrate (call it however you want) and apply this to the remaining work to do. Chances are that the estimation mistake you made so far are existing in the up coming work too.

With this approach, at least, you have an objective basis for the project change (feature, time, $$) you will have, like it or not, to ask for.