“Who knows what darkness lurks in the hearts of computers? The TPM knows!” This line, paraphrased from pulp hero The Shadow, is not just a bit of melodrama. Well, okay, yes it is. But it is also a brutal, unfortunate truth about our work as technical project managers. Despite centralized corporate policies, complex system diagrams, and a surge in business analyst employment the only people who really know how the system works is the people who use it.
Note that I did not say “how the system functions.” Most users could not explain to you in any coherent way how your interface engine translates transactions between a legacy operations system and your newfangled data-warehouse-thingy. They can tell you how long it takes to intake an order though the myriad of communications channels, how much effort it takes to put real information into that beloved report, or where to find the real skinny on what looks like total nonsense from the outside.
A technical project manager learns how to bridge the gap between the impenetrable cloud which falls over men’s minds when they start talking technical jargon and the sometimes even less sensible world of business activity. Some TPMs do this by force of personality. Others rely on trading favors. Many take on a hard-line pragmatic approach, in which they officially ignore one thing which violates department protocols so long as they get concessions in other areas.
The TPM learns a great deal about the “Shadow IT” system created by these negotiations. He knows who did what, when, where, why, and how in order to keep things running. He knows where the system is held together with good wishes and duct tape; and where it might not run at all without the concerted effort of a dozen little Access databases.
Touching this knowledge can carry a heavy political price. The corporate office is never entirely sure who the TPM servers; they may pay his bills but his work means he must occasionally defy their orders to meet the customers needs. At the same time the user community should never forget that the TPM works for the corporate office; his responsibility is the deployment of approved systems whether they work or not.
The question, then, becomes this: Does the weed of project management bear bitter fruit?