Trust but Verify, in Underperforming Project Team Members
I certainly must concur with most of this article; I too have worked as contractor project manager where you parachute into a difficult project. I have frequently thought about why companies bring in outside PMs, especially on large critical projects. I gues they may not have in-house PM capabilities, but why not develop them as in-house people will have orgainzational and political knowledge an outside PM must take time to master. Maybe it's easy to blame an outside PM if a doomed project fails. But, I was bothered by the "Trust but Verify" guidance. The Gipper, former president Reagan, used this in the Cold War context in dealing with the Soviet Union. Recently my boss used that on me when he repeatedly did not believe me when I reported information on an 'as-is' assessment. My source was a high ranking end user SME who had actually built the rogue systems in question. I refused to go back to this executive and ask the same question he had already answered multiple times. In this relationship, the SME and I had established a professionall level of trust. My boss set up a in person meeting with the SME, who then demonstrated on the desktop PC the rogue system he had developed, because the IT shop. my boss's boss, had refused to help the executive.
Verification is a standard process step(s) in mature systems engineering and should be done in routine way in all things. That's why we have PDR, CRDs, milestones, reviews, control gates, etc. These are not being done because of some 'trust' factor, but because as humans developing complex systems, we discipline ourselves, bosses too, in subjecting our work to critical review and ongoing assessment, thest check, verify, cycle. It has nothing to do with trust, and to introduce this cold war advesarial relationship term into a team is just another example of inmature, shaddy management practice.