04-10-2012, 12:56 PM
Engineering Productivity:
Engineering Productivity Unpublished 2008.doc (Size: 897.54 KB / Downloads: 23)
Abstract.
There are often too few qualified engineers. I am mostly referring to product design engineers Ð software engineers and systems engineers. One reason we have too few is that we misuse their time so badly Ð we waste at least 50% of it. But when we can longer desire or afford to solve the problem by hiring or off-shoring to get more warm -bodies, we need to consider getting more productivity from the engineers we already have. There is one great advantage from that tactic Ð they already have plenty of experience in our company! There are several tactics to improve productivity. They can take many years to come to full effect, but a steady long term improvement, and dramatic short term improvement, should be possible. The key idea in this paper is that we can define our own productivity quantitatively Ð and manage the improvement
of it quite systematically. Your own definition of productivity demands several simultaneous dimensions of productivity. The definition of productivity also requires substantial tailoring to
your organization, and to its current environment. I am going to assert that the best short term measure of engineering productivity is agreed value (requirements) delivered; and the best long
term measure of engineering productivity is stakeholder benefits actually delivered .
Some strategies to increase engineering productivity
Measuring Value as a strategy
It is all too common, in the many international industries I am personally witness to, that many of the acknowledged critical factors that determine value are not expressed in quantified terms. This seems to be a problem for both management and engineering cultures. We are taught a selection of metrics, for accounting and engineering, but we are not taught that all critical factors must be dealt with quantitatively, even if we have to invent suitable metrics. Senior managers and engineers are not taught, and they do not know how to quantify the very factors they have just acknowledged are critical to the project at hand. They use words, but not numbers. Technical Goals: Òrock-solid robustnessÓ, Ò to dramatically scale back the time frequently needed after the last data is acquired to time align, depth correct, splice, merge,
recompute and/or do whatever else is needed to generate the desired products by semi automating and/or performing these activities as the data comes inÓ, Òto make the software much easier to understand and use than has been the case for previous softwareÓ, Òto provide a much more productive software development environment than was previously the case.Ó, Òsoftware development difficulty should scaleÓ, Òwill provide a richer equipment model that better fits modern hardware configurationsÓ, ÒMinimal down-timeÓ, Òmajor improvements in
data quality over current practices wherein the job planning process is much more haphazard.