The magic trick there is ‘achieved all’- sometimes, when you try to measure it, you will be wrong. A requirement will disappear under a rug somewhere. If you’re wrong after you try to measure though, you would still be wrong if you didn’t.

Measuring constructive criticism is very difficult or impossible until after the fact. Consider it: if the user provided no criticism/feedback whatsoever, does that mean that your design was perfect, or that you didn’t get something you needed? How do you measure that at that stage?

As for rigid, ahh… see, I agree with you there, but I also disagree. Part of the reason to measure is to identify the target, not to become rigid. There’s an old maxim that says ‘the most flexible point in a system controls the system’. A project manager’s job, and in turn, the project manager’s tools- the PMO structure and processes- must be the most flexible point in the system if they are to control the system. You must be able flex when something about the project has to be bent. If not, you’ll waste time on process overhead that you could actually spend on solving the project problems. One has to be careful not to forget that your own PM time counts against project costs too. After all, if you weren’t working on this, you’d be useful on something else of value to the company.

Figuring out the right places to insert ‘flex’ in your processes for your particular company is, in my opinion, where art and experience meet the science in project management. I’ll try to write some on my theories on this in the near future.

These are some of the core matrix that are ‘soft’ in nature and are a very much needed for measurement. Yet, no where in the PMI / PMBok or are any other methodologies that clearly documented how and where these ‘soft’ underlying variables can be captured. IMHO, these are the most critical points in the project life cycle.

The rest is pretty easy and quantifiable under a rigid folio with good PMO structure and processes.