Leadership optimize

Technical Project Management and "The Shadow" of IT


"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?

7 comments
jodyharris5016
jodyharris5016

It has been my experience as an IT professional and now as a project Manager that the only reality that can be counted on is IT. I have been multilingual since the beginning of my IT career, speaking both business and IT. The IT department as a whole is the solid foundation that business is built on. The IT people though sometimes lost in these clouds you speak of are creating the walls that hold all of the business processes. I agree with you on the difficulty the TMP faces but from my point of view it lies with the business side having difficulty realizing that the scope of a project has limits and that it cannot change willy nilly to meet a new idea that they just thought. IT lives in reality and deals with finite limits. Business sometimes chases butterflies and fairy dust.

mdonovan
mdonovan

I see your point, but you're taking it just a little too far. IT is and always should be subservent to the business purpose and function. The business purpose and function is the only reality that should be pursued. Though these days a big part, IT is a part of that purpose. I think that what you might be saying is, "business leaders don't know what the hell they're doing". And, while (sadly) this point is often true, it only reflects poor leadership. Because there might be bad business leadership doesn't mean that IT should assume the role of directing the business (with the exceptions of solely web-based businesses, but even then business purpose should guide the business). Again, with some exceptions, IT should never be the foundation on which the business is build nor should IT create walls for the business. The business needs to respond to market and having IT process that have become *the rule* by which business decisions are made is a bad (bad) idea. I'm not saying that this doesn't happen. It does. In fact, your very point that "IT is the only reliable reality" reinforces this false precept. And, it's still a bad idea. Most businesses can help themselves through clarity (from it's leaders), simple process and 5 letters: V-G-S-T-P. Vision > Goals > Strategies > Tactics and Projects-- these 5 things should be the foundation of most worthwhile business undertakings. Business leaders can use these concepts to clearly define their business purpose and direction. And, really, it's not very hard to do. It takes some "guts", which is where quality business leadership comes into the frame. When this map is established, everyone involved (from the senior managers to line programmers) knows what's what. If an IT Project doesn't support a defined Strategy, then it shouldn't be pursued. Period. This creates clarity. Clarity is and always should be the ultimate goal for a business leader.

Wayne M.
Wayne M.

It is the idea of a fixed scope project that often derails IT in meeting business needs. By using a program model, we have the freedom to adjust as business needs change and not be the brake always saying, "No, what about last week?"

Labrat636
Labrat636

Tactics and projects that support the business strategy. But just the technical stuff please - although I also have to manage a couple of employees - everything I do is geared toward installing, maintaining, supporting, and administering the technical systems and infrastructure that support the business strategy. In my case, our strategy is changing with the market to reflect the trendy move to VoIP and converged technologies - I must support that shift in strategy.

mdonovan
mdonovan

Interesting thing about your post is that most of the technical resources I have interacted with were thirsty for this type of clarity. Sounds like you have it...so "good on" your company. Surprisingly, many IT support teams simply aren't provided this type of strategic direction.

Labrat636
Labrat636

Is that what you're smoking in your "shadow IT" relm? Technical Project Managers are responsible for all of the technical aspects of an enterprise project. They usually report to the Project Manager. If the project is to create a call center, the TPM will handle all the technical details and requirements of providing information and communication, and maybe even power, to the call center desktops. Other project sub-managers handle things like staffing, training, logistical supply, furniture, office design, decorating, etc. in support of the enterprise project.

lpresson
lpresson

Articles like this are a waste of my time, if you have nothing to write ; don't post a document with an interesting title.