The buzz around “project management” these days is about the various flavors of “agile” development being applied to, or advocated for, IT projects and other software engineering.

“Conventional” project management is passed off as old hat.

But IT projects are a little different from conventional product development, because IT projects are almost never “productized”. IT is internal or hosted software, not something to be delivered intact as a documented, self-contained product, which is to be supported at multiple levels by non-engineers. It is software made available for use, and updated frequently, maybe daily, much as an individual worker might create and modify a spreadsheet for his own use. There are no warranties or instruction manuals, no supply chains, no factories.

Conventional products need a different kind of investment, because they must be taken from their engineers and sent out into an unforgiving world to stand on their own.

Such engineering projects succeed when someone is tasked, or takes the initiative, to see how all the moving pieces fit together, takes the time to learn what is needed to be successful and what are the pitfalls, is alert to spot problems early, and quickly grasps the impact of changes or delays. You have to be technical without being a techie, and political without being a politician. It is not a job for everyone.

A project manager once told me, “It’s an impossible job. You can’t fire anyone, so they don’t have to listen to you.”

But it’s not impossible. You can get commitments without direct authority, so long as the organization supports the goals of the program. But you may have to tread carefully. You can’t look at any aspect of the project, from dependencies among internal disciplines to customer expectations, as “none of your business”. And without tact and diplomacy, there is the risk that someone will get protective or defensive, and the flow of information dries up, progress becomes opaque, and risks skyrocket.

Yet if you are not assertive enough to make your point and get what you need, you will be sidelined, out of the loop.

Of course, “Project Management” has become its own academic discipline, with its own lexicon of jargon and certifications, which may be needed to navigate really big public or private organizations and communicate with a bureaucracy.

But jargon and tools aside, the underpinnings of successful product development, particularly anything that involves hardware, remain very much what they’ve always been.