The only engineer at a business meeting.

[ERD50]

It is true that in most cases, and in all planning, you plan for only 2 out of three. But I do agree that sometimes it is possible to do something in a novel way that results in a much cheaper and better solution and get the project finished, because of its simplicity, faster. But it is maybe a once in a career happening. One can never make plans based on finding a novel solution to solve an old problem in a unique way, rather than incremental improvements, but it does happen.

But in my limited experience I have only seen it happen when engineers work autonomously with limited oversight or project reviews (which tends to weed out any novel approaches). It is magic when it does occur and fun to watch as the results of success where initial resistance eventually fades away to "of course this is obviously the way it should be done".

Follow up on previous post - 'once in a career'? No way, it was expected of us each and every review period. You better do all three.

Granted, they would generally all be incremental improvements, but you made them in each area (cost, quality, production rates). And it was always a TEAM effort to get all three.

-ERD50

 

[CaliforniaMan]

Follow up on previous post - 'once in a career'? No way, it was expected of us each and every review period. You better do all three.

Granted, they would generally all be incremental improvements, but you made them in each area (cost, quality, production rates). And it was always a TEAM effort to get all three.

-ERD50

I thought I might get some push back on this and considered editing it, but decided to let it stay. Actually ERD50 I don't disagree with you. The rare occurrences I was referring to are times of paradigm shift (yes I hate that overworked word also), meaning where there is a dramatic new engineering technique that upsets the old accepted approach. In my experience one example of this was a test device that cut the size and energy consumption to 10% of the original and the cost to 5% of the original device, at the same time adding new features, getting better test results, and was engineered in less time than the previous method took. It was because it was a fundamentally different approach. This is I think rare, but does happen, and is partly responsible for that great march of progress you alluded to.

Then for the next dozen years and counting, after its acceptance, the incremental part that you referred to began. Several teams worked on the improvements, continually increasing performance, adding features, decreasing cost, etc.

A fundamentally different approach or device causes the company to have to discard the old one. So it has costs, so the cost benefit has to be striking, and is in my experience discouraged. That is why I mentioned that it seems mostly to occur in a small group left alone for a while.

But I do agree with you that for most of our careers we are challenged to do all three, albeit usually (or rather hopefully) in an incremental fashion.

 

[Hermit]

...
But in my limited experience I have only seen it happen when engineers work autonomously with limited oversight or project reviews (which tends to weed out any novel approaches). It is magic when it does occur and fun to watch as the results of success where initial resistance eventually fades away to "of course this is obviously the way it should be done".

I remember on new large system developments, putting newly minted engineers in a room and telling them to come up with a design for a key problem to see if they might come up with novel approaches that would solve some of those better, faster, cheaper issues.

 

[Ed_The_Gypsy]

Are you kidding?

OK, maybe we are living in a dream world where computers, cell phones, TVs, and music players get... Cheaper, Better, Faster. But that 'dream world' is also our reality!

In my job as an engineer/manager, we were always pushed for (and measured on) cheaper (cut costs), better (improve quality), faster (increase production rates). And if we didn't deliver, they would find someone who would.

Your management let's you get by with 2 out of 3? That would have been my 'dream world'!

-ERD50

Is your point that planning and optimization can be short-cut?

Every engineer has those goals. We are much more conscientious than the people we work for. Those people most often have what can be nicely said as unrealistic expectations. In my business there is a concept called "fast-track" where design functions that used to be in necessary sequence are now done simultaneously. That is possible only in limited situations but it has been extended to all projects. Of course, there is a lot of re-work required when you do that, but now they are saying, quality means no re-work. Estimates done by conscientious engineers and technicians are cut in half. The next question is, what do you want us to leave out? In the end, it still takes exactly as long as the estimator said it would.

They want 3oo3. We have to say that we can meet their unrealistic goals because we cannot push back. But Project Management in my business only cares about on time and under-budget. They don't care if it works or not.

I do not have high regard for Project Management today. Most project engineers are no better than high-school dropouts, as well. Companies just throw people at a project, hopefully at as low a wage as we can get them to leave McDonalds for. Experience costs too much, and if you really know what you are doing you are too hard to control

In my 40 years in the business, plants that once took 18 months from letter of intent to commissioning (note: small plants and big plants take the same amount of time) can now take twice as long (and these are 'fast-track' projects!), consume more engineering hours (the new business model for engineering companies) and are more expensive than inflation can account for. They often have unnecessary start-up problems. This is what you get from Cheaper, Better, Faster.

But we are meeting a demand. It is the customer who demands these things. They got rid of their engineering departments long ago and now have only MBAs to talk to.

We can work smarter but we are being required by management to work stupider. That's OK. They get paid for selling man-hours and I get paid by the hour and sometimes I can make a difference.

Your industry may be different than mine.

 

[aja8888]

Let's build a crude oil pipeline spanning a dozen states and two countries "cheaper, better, faster'......

(even getting FERC approvals is mid boggling. Project delays, etc can hit you from several different fronts and be totally unknown.)

I know, let's blame the engineers on this one.

 

[ERD50]

Is your point that planning and optimization can be short-cut?
...

Your industry may be different than mine.

Everything can be improved and optimized, including planning. If you do it right, it isn't taking 'shortcuts', it is streamlining and improving the process. Eliminating non-value added (is that one for the 'buzzword' thread?) steps, using computers and data to improve the decision process, etc. Making it better, faster, cheaper.

Our lives are filled with examples from many different industries where we get better, faster, cheaper products. It isn't rare at all.

I think the difference in our views on this are not about the industry we are/were in. I think it's that you are talking about a specific situation with your management (and regulatory situation?), versus the broad brush generalization that you can only have 2 out of three (Better, Faster, Cheaper). I stand by my statement that good engineers will routinely provide all three - and yes, that can be difficult/impossible without management support.

-ERD50

 

[MRG]

I'd always thought the 'faster, cheaper, better' quote was attributed to Gene Amdahl, when he left IBM to start Amdahl. Thought it was in context of what his organization's goals were. Of course I'm frequently mistaken.

The saying in software was 'time, functionality, and quality' one will be sacrificed. With all else equal.

I agree we can do some projects faster, cheaper, better with more efficient ways of working. These efficiency gains generally come from better tools, processes, and creative thinking. Don't know I've seen one occur because of a SR. management mandate, tomorrow won't be faster, cheaper, better if nothing else changes. Just my sometimes humble opinion.
MRG
Edit: fixed important typo

 

[aja8888]

Faster, cheaper, woops!

Apparently, Sr. Management wasn't on top of the engineers who rolled out the 10/1/13 version of the ACA website. Good thing those folks weren't building a bridge or a pipeline.

 

[M Paquette]

Apparently, Sr. Management wasn't on top of the engineers who rolled out the 10/1/13 version of the ACA website. Good thing those folks weren't building a bridge or a pipeline.

LOL!

That there was a fine example of applying the waterfall model to manage development of a highly interactive system with a number of unresolved requirements and design of back-end components while the front end had requirements and design locked into the contract.

Waterfall model works great when building an office building on a known site. It's not so great for a software system, particularly one to be layered atop other systems with differing requirements and design, and especially one where the folks running the project are changing requirements while it's under implementation!

This sort of project screams for something utterly alien to a typical government bidding process, the use of an agile development strategy of some form. Dynamic Systems Development or spiral model development would be a better fit.

In this particular case, a great example would be HealthSherpa.com, a site initially done by three coders to get a quick and dirty prototype (initial iteration) up and running that demonstrated the basic shopping functions needed. Note that additional iterations would be needed to get the various back end functions (authentication, income verification, subsidy eligibility and calculation, application guidance, and delivery of electronic applications to insurers.)

The point being that incremental development and rollout is arguably the right way to go for large software projects that may have flexible requirements, but such a process is utterly alien to many large non-engineering organizations, particularly those loaded down with powerful management figures that want results instantly, have hidden agendas, and no understanding of engineering. Sort of like most of the folks in that video...

 

[Ed_The_Gypsy]

At our recent company town-hall meeting, there was a question from the floor about what we could do to speed up getting equipment and contracted things through customs. Supply Chain Management stood up and told us that we would have to order equipment earlier. (Real answer: get permission to bribe Customs which is normal here.)

I know! Let's order the equipment before the project starts! And since we already have it, we won't need as much design time!

I have seen this happen. In very rare cases, this will work. Generally, you are going to order the wrong stuff and the project schedule and budget will be hooped because you will still have to order to right stuff.

Some of the companies I have seen are wasting their investor's money like you wouldn't believe.

That's OK. I have worked on many projects that were cancelled and some that should have been. I get paid by the hour. By the way, I get paid to troubleshoot plants with problems. It pays good and somebody appreciates my work. And I do not go to meetings or deal with idiots.

 

[bUU]

But it is the engineer's job to push the envelope on all three. That's what progress is all about.

Rather, progress is about pushing the envelope on two of the three, using a surplus of the third to pay for pushing the envelope on the other two.

If you want to build something better and faster, then progress in that regard will cost more money.

If you want to build something better and less expensive, then progress in that regard will take more time.

If you want to build something faster and less expensive, then progress in that regard will be derivable from compromising on quality.

But I do agree that sometimes it is possible to do something in a novel way that results in a much cheaper and better solution and get the project finished, because of its simplicity, faster.

That's only if you start with the novel way already determined. The path to identifying such a novelty is long and hard, and it costs both money and time wasted on false starts.

But it is maybe a once in a career happening. One can never make plans based on finding a novel solution to solve an old problem in a unique way, rather than incremental improvements, but it does happen.

And in a typical environment such as that depicted in the video, the business types who hyper-extend the period of time necessary to realize that achievement (through firing engineer after engineer who cannot do the impossible) think, in the end, that the last engineer magically came up with the novel solution as if it was nothing, rather than acknowledging that the engineer was just lucky enough to be the one hired after all the hard work had already been done, like the tenth person trying to open a tightly sealed jar of jam.

I spent a career assessing the operations of company after company, 100 or so companies every year. None of them listed "sorcerer" in any of their job descriptions.

 

[2B]

I know! Let's order the equipment before the project starts! And since we already have it, we won't need as much design time!

Been there -- done that.

I was on a project that was in a remote location. There were three large separators needed based on the conceptual design. Three large separators were ordered before detailed design even began based on the largest separators that could be successfully shipped to the site. Unfortunately, little thought was put into the pressure and temperature ratings of the vessel or the number of nozzles required/desired by various safety reviews. The entire design was done around the low pressure rating of these vessels and the project required additional pumps and relief systems that could have been eliminated with only a slightly higher design pressure.

 

[HFWR]

Our lives are filled with examples from many different industries where we get better, faster, cheaper products.

-ERD50

This is much more a testament to engineering than to management...

 

[aja8888]

I spent a career assessing the operations of company after company, 100 or so companies every year. None of them listed "sorcerer" in any of their job descriptions.

This statement kind of sums it up quite nicely!

 

[robnplunder]

I once worked for a project manager who made up schedules to make his bosses happy and them dumped them on us.

At my megacorp, all schedules are top down. Ditto for budget. They make it worse by forcing us to do bottom-up schedule, and budget planning exercises. The exercises, invariably, become one to "guess" the top down number and fit stuff in to meet it. Hilarious but absolutely "making love" true.

 

[ls99]

Oh, budgets!

While not an engineer, I often had to work up projects within a given budget. Most of the time all was well and projects were approved by powers that be. One event did not go well.

Was given around $360k budget for some winterization mods to transit fleet. By the assisatant manger. Worked up the the plan, submitted it. A wewk later the chief honcho came back from a European fact finding tour. Got called into his office and was informed that budget is only 180k. Rework the plan.

Turns out a few days later there was an impromptu meeting/bitch session called by the outfit's president, who was present in person. Me not happy by the sudden vaporization of $$$ stuck my hand up. The man called on me. I concisely explained the funding problem and asked: So what happanend to $180k. Our manager who was also pesent appeared the have a sudden large load in his trousers with a rather pained expression.

Two weeks later he was no longer employed with us. No one ever explained where the money went, and the whole project diasappeared.

 

[NW-Bound]

The last 10 years of my working life was as a contractor besides doing some freelance work. What bugged me the most was when I was given a task when others before me had thoroughly messed up, and spent most of the money.

For example, a development job may start out with an allocation of 1,000 man-hours. If that was given to me from start, I would be able to do a nice job for them with no problems. However, they wasted 700 or 800 hrs without producing anything, then called me in expecting me to do the whole thing over with the remaining hours. Hell no! I have declined assignments with that kind of project management, and rather took time off to travel than to become their fall guy. This BS was also a factor in my deciding to ER for real.

 

[ERD50]

Originally Posted by ERD50 View Post
But it is the engineer's job to push the envelope on all three. That's what progress is all about.

Rather, progress is about pushing the envelope on two of the three, using a surplus of the third to pay for pushing the envelope on the other two.

If you want to build something better and faster, then progress in that regard will cost more money.

If you want to build something better and less expensive, then progress in that regard will take more time.

I'm going to continue to disagree with this. I think you are looking at specific cases, rather than the general case. In the general case, it is the engineer's job to attempt all three simultaneously.

In the specific case, one or two might well take priority, and sometimes it's fine if it costs more if the customer really wants 'faster & better', etc.

Originally Posted by CaliforniaMan View Post
But I do agree that sometimes it is possible to do something in a novel way that results in a much cheaper and better solution and get the project finished, because of its simplicity, faster.

If you want to build something faster and less expensive, then progress in that regard will be derivable from compromising on quality.

Now that's simply not true. Many products have become faster and cheaper and yet have higher quality. I'm not sure what's driving your thinking here at all.

That's only if you start with the novel way already determined. The path to identifying such a novelty is long and hard, and it costs both money and time wasted on false starts.

Sometimes, but not always.

In the process of taking on a new project, one of the things you do is review what was done in the past, as you think of ways to fit in the new requirements. Sometimes, you just see a better way of doing something, something the previous engineers didn't think of, or maybe they could not have envisioned without first taking this step (here you are 'standing on the shoulders of giants'). Hindsight is 20-20, and you often have more hindsight with a new project

And sometimes there are just newer components and techniques available, and these are cheaper, better, faster. So you use them. Often, the newer components are easier to use and design with, so even the design process is sped up.

>> Following comment [-]almost[/-] completely tongue-in-cheek:

Some of the naysayers here have me thinking maybe I was a much better engineer than I thought I was!

Or maybe my bosses were better at [-]beating[/-] inspiring us to achieve our best!
​

Originally Posted by ERD50 View Post
Our lives are filled with examples from many different industries where we get better, faster, cheaper products.

-ERD50

This is much more a testament to engineering than to management...

Probably, but I was just trying to point out that it's a lot easier to make real progress if management is providing support.

Heck, I recall a program that a bunch of us got pulled into, and I really thought there was just no way we could make the date they set out. But my peers were in the same boat, so I figured just be a good soldier, play along, and as long as I'm not later than anyone else, I'll survive. Turns out that some top management really went all out to knock down barriers and provide support, and we made the date - much to my surprise.

I got a tee-shirt.

-ERD50

 

[Koolau]

Okay, back to the original "meeting" for just a moment. I have sat in such a meeting (where, in effect, I played the part of the engineer - though I am not one.) Half a dozen folks including my boss were there with me. The gist was that a "program" was to be started and I was to dream it up and run it. I pointed out that other than the authority to do it, I had zero (and I do mean absolutely zero) resources (no money, no people, no training, no equipment, no space, no buy-in from internal customers, no precedent, etc. etc. on and on.) The folks more or less ignored me and continued to discuss how important is was to the company to have such a program immediately. Most of these folks WERE engineers, so they knew the task was impossible. Finally, my boss committed me to the project (with time line) and everyone slapped everyone else on the back and walked out. Here's the thing. They had completed THEIR task. They had assigned someone to the project and I was "it". If it didn't happen, didn't work, didn't last, didn't meet internal or governmental requirements, it was MY problem. Not theirs. So, since I couldn't win, why spend any of my time on it. I ignored it, and the programe was never audited nor even mentioned again. What a way to run a company.

 

[robnplunder]

BTW, the acting was great on the video.

 

[bUU]

I'm going to continue to disagree with this. I think you are looking at specific cases, rather than the general case.

Rather, I'm looking at the general case, with the acknowledgement that every so often lightning strikes and the laws can be violated.

In the general case, it is the engineer's job to attempt all three simultaneously.

It is always the engineer's job to manage the trade-off between the three.

Now that's simply not true. Many products have become faster and cheaper and yet have higher quality.

Speed, in the engineer's time-cost-quality trichotomy is always talking about how long it takes to realize the product. The characteristic of the product, regarding the product's speed, is covered by the quality side of the trichotomy. The achievement of a new level of speed of the product, which is what you were mentioning, as an aspect of quality, was accomplished at great expense of upfront time and money.

 

[ERD50]

BTW, the acting was great on the video.

Now that I agree with! The engineer actor did a great job of showing that mode where you are thinking 'are you a freaking idiot?' while calmly keeping a poker face and saying 'Let me try to explain it this way.'

Originally Posted by ERD50 View Post
I'm going to continue to disagree with this. I think you are looking at specific cases, rather than the general case.

Rather, I'm looking at the general case, with the acknowledgement that every so often lightning strikes and the laws can be violated.

Well, this is just circular. We just disagree, and I certainly do not understand your view. It sounds like an excuse for sub-standard engineering effort to me!

It is always the engineer's job to manage the trade-off between the three.

Absolutely - and that is not mutually exclusive to all three progressing at the same time. Yes, apply the trade offs to maximize the net gain for the most important areas. There just is no reason that one has to stay the same or get worse to have progress in the other areas.

Speed, in the engineer's time-cost-quality trichotomy is always talking about how long it takes to realize the product.

Is it? Always? You seem to talk in absolutes when they are convenient for you. I'm not sure if this discussion about 'Faster, Better, Cheaper' applies solely to the engineering effort, or to the end product of that engineering effort, or both.

Not that it matters. I gave examples where an engineer might have an opportunity to do all three, one obvious one is when a new component becomes available (take the case where a single chip now integrates several chips and support components, at lower cost and higher quality), and now the engineer's job is easier, faster, and also cheaper - and that often applies to the product as well.


Let me guess - you are going to add in the development costs of that chip? Nope, this engineer didn't invest their time in that, and that previous R&D cost is amortized into the ongoing cost of the chip (which is cheaper than the previous technology). So it is a win-win-win on all counts.

This isn't a lightening strike event. It happens routinely.

Heck, I recall when PCB's were laid out by hand with black tape and razor blades on mylar. PCB design by computer is... faster, better, cheaper. The examples go on and on.

The characteristic of the product, regarding the product's speed, is covered by the quality side of the trichotomy. The achievement of a new level of speed of the product, which is what you were mentioning, as an aspect of quality, was accomplished at great expense of upfront time and money.

Sometimes, not always.

-ERD50

 

[growing_older]

So, not only do these kinds of miscommunication happen so much in working situations that we all recognize them in a silly video about drawing red lines, but even after retirement, ex-management and ex-engineering cannot agree on what the issues are.

 

[daylatedollarshort]

important is was to the company to have such a program immediately. Most of these folks WERE engineers, so they knew the task was impossible. Finally, my boss committed me to the project (with time line) and everyone slapped everyone else on the back and walked out. Here's the thing. They had completed THEIR task. They had assigned someone to the project and I was "it". If it didn't happen, didn't work, didn't last, didn't meet internal or governmental requirements, it was MY problem. Not theirs. So, since I couldn't win, why spend any of my time on it. I ignored it, and the programe was never audited nor even mentioned again. What a way to run a company.

One of the things I enjoyed about becoming self employed was that I knew some of the management people I had worked with at my previous megacorp, like the ones in the video, would never succeed in a million years working by themselves. Dumping difficult or even impossible assignment off on another person or group is a skill some managers seem to have perfected to an art form, but when you are working by yourself there is no one else to dump the work on, and spending all day developing processes or mission statements isn't going to pay the mortgage.

 

[bUU]

Well, this is just circular. We just disagree, and I certainly do not understand your view. It sounds like an excuse for sub-standard engineering effort to me!

Your comments sound like an excuse for sub-standard management effort to me. Baseless prejudicial comments aside, my comments reflect my first-hand experience with the product realization operations of over a hundred companies. I appreciate those who like to showcase their own personal views of their own personal performance in some unrealistic way, and would do it myself whenever I can rely on the rigor of analysis of such claims to be non-existent. However, when actually managing a project, realistic expectations are those that lead to success far more often.

Absolutely - and that is not mutually exclusive to all three progressing at the same time.

I would be happy for you to provide proof that this is a routine part of the engineering discipline, aside from your own personal, Herculean accomplishment.

Is it? Always?

Yes - always - whenever that trichotomy is the object of discussion. I would be happy to have you provide definitive examples of substantive discussions where cost and quality are the same as what everyone else in this thread has been discussing while speed is "the speed at which the product itself operates" instead of the speed of the product realization process. I'd especially like to see at least one example of such a general discussion where the product that is the result of the realization process is something that doesn't have a speed characteristic, as is the case reasonably often.

You seem to talk in absolutes when they are convenient for you.

I think you're projecting. Let's move on.