Engineering vs. Management
Richard Biehl
This is a system engineering class. It is NOT a project or program management class, although the two disciplines are undeniably related. Several of our assigned readings in this unit deal with the engineering life cycle. It is the life cycle — in the various forms described in the readings — that connects the two sides of the engineering-management coin. To a project manager, the life cycle determines what will be planned and controlled within the project plan in which engineering unfolds. To the systems engineer, the life cycle determines how our knowledge of our target system of interest will unfold and evolve. These two perspectives are related, but distinct. Engineers tend to emphasize maximizing what system can do, while project managers tend to emphasize constraints (usually in terms of time, money, and other resources). It is the friction between those two perspectives that can make engineering management so effective. However, that friction only adds value if both sides hold up their end of the deal.
As systems engineers, we want to keep expanding and enhancing our systems. Project managers work to keep us within the constraints. An optimum systems solutions should come out of the end of the life cycle. It is the balance between the two that ends up maximizing the value we can deliver. However, a common mistake that systems engineers make is to become overly concerned with the project management constraints. This tends to result in only documenting requirements that are believed to be ones that can be implemented within the constraints. We start trying to do our own engineering job, and part of the project manager’s job. That’s a mistake that causes us to miss a lot of requirements, or to avoid documenting requirements that look like they might be particularly difficult to achieve. The systems that result lack a lot of what our stakeholders actually need, even if their technical implementation is quite impressive. Impressive technology doesn’t satisfy requirements we chose to never write down or acknowledge.
To correct for this, we have to internalize the idea that it is NOT our job to meet ALL stakeholder requirements. Our job is to meet the highest priority requirements that we’re able to meet within the constraints imposed by project management. As long as we can assert that every requirement we meet is more important than every requirement we don’t meet, we’ve done our job effectively as engineers. If our stakeholders want more than that, then they should give project management more resources.
Discuss the implications of this distinction for your engineering. Think of a project you might have worked on in the past, or can foresee working on in the future, where you have to struggle to balance resource constraints against the range and scale of stakeholder requirements. What role in this balance have you played, or should you play, in optimizing this friction?
