In my work experience as a systems engineer we constantly face the same 'formula'...except that we typically define it somewhat differently:
Cost, Schedule, Technical_content
Rather than redhotpenguin's
Cost, Schedule, Quality
Both formulations work and both have many of the same challenges. If you substitute Technical_content in place of Quality in redhotpenguin's post, the post would speak to my situation, too. In fact, as I think about it, I think that Technical_content and Quality are closely enough related that the two are, in many ways, just two sides of the same coin...maybe that's why redhotpenguin's writing so closely reflects my own thoughts.
I have been puzzling over a variation on redhotpenguin's dilema, which is:
If we imagine that the triumverate of Cost, Schedule and Technical_content were an abstract equation of the form: a*Cost x b*Schedule = c*Technical_content where the '*' is a normal multiplyer, but 'x' is an abstract notion of 'combines with'...though it could, also, be a normal mathematical multiplier if we choose the a,b, and c correctly and have a quantified version of the three variables Cost, Schedule and Technical_content.
The question that we've been faced with is: how could we 'change the results' so that for the same Technical_content and Schedule, we get lower Cost?
It seems that, in my experience, many folks don't see that to change the cost (for example) but keep the Schedule and Technical_content the same, you have to change the model...i.e., by, so to speak, changing the coefficients: a,b,c.
What makes the model? From my perspective, the model is the impact of all the policies, practices, processes, procedures, engineering & business accumen, etc. of an organization or other undertaking. To change the relationship of Cost, Schedule, and Technical_content, the model has to change...and that means the organization or undertaking has to change.
In my experience, I regularly come up against management, customers, or stakeholders that demand (sometimes they even attempt to edict) that "Technical_content and Schedule will not be sacraficed, but we're going to deliver at 50% the cost." It never happens...unless the model is changed...and that means organizational changes.
In a previous thread on Testing (The dangers of perfection, and why you should stick with good enough) I presented an argument for 'doing more thinking and less heaping on of non-value-added testing' which is part of trying to change our organization...i.e., changing the 'model'. So far, it has worked and worked very well. It seems that as one redefines one's organizational processes, procedures, strategies, (including testing strategies...and as redhotpenguin states, quality strategies) then the model (i.e., its coefficients) can change.
But once the model is instantiated the relationship between the variables is fixed...unless and until the organization or undertaking is, again, changed
Whether one uses the variables of redhotpenguin (i.e., Cost, Schedule, Quality) or the ones we've been working with (i.e., Cost, Schedule, Technical_content), the issues which redhotpenguin brings up and discusses are still the same...and form a nexus of engineering challenges.
Thanks, redhotpenguin...love this node. It strikes very, very 'close to home' for me.
<In reply to Re: The dangers of perfection, and why you should stick with good enough
by ack
in thread The dangers of perfection, and why you should stick with good enough
by redhotpenguin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |