5 ms·

A better way to align incentives would be to have the bids specify fixed profits and a value engineering process. You bid $10m + $1m profit. The project balo

A better way to align incentives would be to have the bids specify fixed profits and a value engineering process. You bid $10m + $1m profit. The project baloons to a $20m project, you still make $1m. The project meets it's goals with a $5m budget, you get $1m and a percentage of the shortfall. It can still be gamed, but to a much lesser degree. I worked on a 9-figure construction project and there were two full-time engineers specifically tasked with looking for ways to reduce the cost of the project, because it was essentially free money for the contractor. These two people generated millions in profit for the company. https://www.fhwa.dot.gov/construction/cqit/vecp.cfm https://www.fhwa.dot.gov/construction/cqit/vecp.cfm

bryanrasmussen 4y ago
Good, but often people reduce costs by using lower quality supplies so that isn't necessarily foolproof either.
- throwawaylinux 4y ago
  They do that anyway. The evaluation process in the contract has to deal with that.
  - bryanrasmussen 4y ago
    I don't know, it just seems to me that having two engineers devoted to find ways that you can save money, whom, presumably also get rewarded by how much they save (this could just be a nice speech by someone but I think if you saved significant amounts maybe a bonus?) would inevitably lead to some situations where they realize that the grade of cement or something similar had not been specified for something and it probably means that, barring significant seismic events in an area that has a fault that has not done anything significant for a century, the thing being built would not need any repair for 45 years instead of 65. Obviously this example is not a real world one as construction is not my area of expertise but I do think I have insights into mundane human mendacity. Then again I am also prone to cynicism.
    - throwaway2037 4y ago
      This is an interesting point. There have been a number of construction-related scandals in the last thirty years of building public housing estates in Hongkong. Either the contractor used weak cement, insufficient rebar, or didn't drive piles deep enough. The fact that they were not caught until the building was completed is terrible. It says the QA by gov't was seriously flawed. (It has since improved a lot!) I think the offset is to have a mixture of QA/checkers and gov't regulators who are onsite checking things. With huge civil engineering projects, sometimes the gov't will hire a competing civil engineering firm just to be onsite checking the work. That balance probably works.
    - efsavage 4y ago
      In the US, on large structural projects, things are generally well-specified, either by standard code, or long before the project goes to bid. The owner (usually another firm representing the government that's paying for it) and the contractor inspect and measure all the work done each day. There are undoubtedly going to be mistakes and corners cut, but that's what safety factors are for and it's hard for problems like that to be endemic without some serious corruption. On a related note to using the wrong concrete, things like this can be an opportunity to see master craftspeople in their element. We had a truck of concrete show up and the foreman rejected it with almost no hesitation. "Why the f*&($ won't you sign on off this!?" the driver yelled. "It's smells wrong", said the foreman. Nobody else noticed anything amiss, but he was the boss, so the truck went back to the plant and sure enough, they'd mixed it wrong.
- deleted 4y ago
  [deleted]
Retric 4y ago
There are a lot of games you can play to make say rent look like a cost on a contract while another entity makes a profit from that rent. Worse you still have incentives to offload costs onto a contract. For example someone finishes an unrelated contract your might as well move them to a profit + contract rather than benching them or immediately laying them off. In the end markets simply aren’t efficient without pricing information. If you can’t get someone to bid a fixed price you might as well keep in in house.
- krapht 4y ago
  Those games you play are a lot easier to deal with oversight-wise. I disagree with your conclusion. You're assuming in-house doesn't have the same perverse incentives. Also, pricing information can be impossible to discover. You often hear on HN how nobody can realistically estimate large software programs. Under that regime, what good is a firm fixed price contract? What'll happen is that the company, once it goes over-budget, will stop work and/or go bankrupt depending on the legal contract it signed. Then the client has no choice but to add more money into the pot - which suddenly sounds like a cost+ contract.
  - Retric 4y ago
    I have worked on plenty of successful fixed price software projects. The simple reality is when you fix costs quality becomes the flexible metric, but meeting the minimum project goals becomes really important. However, considering how many software projects fail, reaching the agreed upon minimum at the agreed upon price is vastly better than what generally happens. As to failing to finish a project the wonders of fixed price contracting is you can pay at completion of some milestone. Of course that means people need to pad the price even more ahead of time to assume that risk, but price becomes a really useful signal.
Closi 4y ago
All these approaches have plusses and minuses and their own risks. The risks with the approach you have described are that: a) Unless very carefully managed, you can end up with contractors being incentivised to cut corners (i.e. We make more money if we buy the cheapest doors possible, regardless of if they only last a few weeks). b) If contractors have fixed profits at their bid-price, they will have zero incentive to accept any change requests (unless they come with additional margin, in which case, overspends will magically turn into change requests).
- airstrike 4y ago
  If those doors are still built-to-spec, then shouldn't you be fine?
  - larkost 4y ago
    This assumes that every relevant detail is speced out. In many projects you don't know exactly what something is going to look like at the end of the project, so over-spec'ing is just as much a problem.
    - efsavage 4y ago
      On the types of projects I mentioned, and I assume to an even greater degree for spaceships, the details are in the spec, which is stamped by an engineer. If you're installing a curb, all of the dimensions are there, the finish on each side, how far below ground it goes, what type of gravel goes under it, the mortar you use to set it, and it will say what kind of granite is specified. If you want to change any of that, you need to get approval (and probably won't). This isn't software where you have hand-wavy goals written by people with no training and can refactor when your tests fail :)
    - airstrike 4y ago
      Every relevant detail should be speced out! The irrelevant stuff is irrelevant
      - 4y ago
magicalhippo 4y ago
> I worked on a 9-figure construction project and there were two full-time engineers specifically tasked with looking for ways to reduce the cost of the project, because it was essentially free money for the contractor. Semi-related story: Way back I was a trainee for a company, which won a contract to upgrade the the branch servers for some other company, about 500 of them. The on-site process involved copying over files from the old Unix server to a new NT4 server running Citrix, split maildir and home directory and set proper user-level permissions on each users home and mail directory. The whole rollout was going on for just a few months, so we had tons of folks doing this in parallel at each site. During the first site I saw the manual our project team had created, and it specified us doing the copying and permission setting using Windows Explorer. To change the ACL that meant scrolling down to find the right abbreviated user name matching the directory name... fun when there was hundred employees at a branch. I figured there had to be a better way, and started writing some batch scripts. After about a day I had automated the whole process, including sending a mail to our phones (the phone company had a service turning number@phone-company.com into an SMS). So I just launched the script, went for a 1-2 hour lunch until the phone beeped. Then I just had to go over the logs and verify there were no errors, and job done. Back at base, I shared the scripts with my coworkers, which obviously loved not having to do the tedious process as specified. It was only after the end of the project that I learned that the contract included a fixed rate of 3-5 days per site for one or two techs, depending on size. After all, changing all those permissions manually took a lot of time. After I wrote the scripts nobody used more than half a day... Did I get any extra compensation for that? Of course not, and I was too young and shy to ask. Oh well, lesson learned.
- myself248 4y ago
  Similar here: Fresh out of high school, I worked for a telecom contractor, installing large cross-connect machines. (Think 20-30 racks of equipment, a few thousand DS3s worth of capacity, which in the late 1990s was a lot.) We'd do the physical install and some very basic continuity testing, then hand over the keys to the vendor's own tech who would "turn up" the machine, thoroughly testing it and making it ready for service, before finally handing it to the customer who would provision their actual traffic on it. The turn-up procedure was documented in the manual and technically anyone could do it, it was just customary to have the vendor do it. And they charged handsomely for it, flying out a tech who would spend 2-3 weeks on site running through the procedure. It was quite a lot of manual work, adding and deleting connections throughout the whole range, and plugging a T-Berd tester into the patchbay to verify transmission of every single circuit. The tech was quite busy during those weeks. My company decided (at a level way above me) that we were gonna try to get into this line of work. As the pimply-faced youth with some computer experience, I got tapped for it, and paired with a graybeard who had done something similar back in the 80s and had a sense of the lay of the land. The logic was that our first few jobs might not make us any money, but we'd get better, and anyway just saving the airfare would be a win. The manual specified typing all the commands directly into the machine's (TL1) prompt, but I wanted to avoid typos, so I typed everything into Wordpad first and then pasted it into the prompt. Which meant I was creating a log of all the necessary commands, and I could search-and-replace various parts to advance through the range of valid circuits. Less typing, more pasting. By the end of our second day, we were screaming through the testing (still doing everything by the book, just typing an effective 500wpm and making zero typos) way faster than the vendor's tech ever did. Running back and forth with patch cords and T-Berds was the principal limit. By the end of the first week, I had written a QBASIC program to obviate the search-and-replace, and just spit out bespoke commands for any given range, or for a whole machine at once if you wanted to feed it the whole config. The output was a many-thousand-line text file which you would then drip-feed to the machine while doing the needful with patch cords and your trusty T-berd. As long as nothing went wrong, it was literally just one long file-send with pauses for jogging across the office. And as our installers were very good, things rarely went wrong. (I did find out that the machine's input buffer was only a few hundred characters, thank goodness the terminal software had an inter-line paste delay!) Our very first job came in at less than half the time we'd bid, and it only improved from there. After our third job, I believe, I went solo. I bought a pair of WPC11 cards and parked one laptop at the machine's console port, carried the other with me to the patchbay, and eliminated the running-back-and-forth time too. Wizardry! Laziness! Profit! I proceeded to reverse-engineer quite a lot of that machine, finding undocumented debug interfaces that saved tons of time when things did go wrong, so we could avoid the blind combinatorics specified in the manual, and instead directly zero in on the errant signal. When things went smoothly, I was 3-5x faster than the vendor's own tech. When things went wrong, I was 10x faster. Extra money? Nah. But I was having the time of my life.

bryanrasmussen 4y ago

Good, but often people reduce costs by using lower quality supplies so that isn't necessarily foolproof either.

throwawaylinux 4y ago
They do that anyway. The evaluation process in the contract has to deal with that.
- bryanrasmussen 4y ago
  I don't know, it just seems to me that having two engineers devoted to find ways that you can save money, whom, presumably also get rewarded by how much they save (this could just be a nice speech by someone but I think if you saved significant amounts maybe a bonus?) would inevitably lead to some situations where they realize that the grade of cement or something similar had not been specified for something and it probably means that, barring significant seismic events in an area that has a fault that has not done anything significant for a century, the thing being built would not need any repair for 45 years instead of 65. Obviously this example is not a real world one as construction is not my area of expertise but I do think I have insights into mundane human mendacity. Then again I am also prone to cynicism.
  - throwaway2037 4y ago
    This is an interesting point. There have been a number of construction-related scandals in the last thirty years of building public housing estates in Hongkong. Either the contractor used weak cement, insufficient rebar, or didn't drive piles deep enough. The fact that they were not caught until the building was completed is terrible. It says the QA by gov't was seriously flawed. (It has since improved a lot!) I think the offset is to have a mixture of QA/checkers and gov't regulators who are onsite checking things. With huge civil engineering projects, sometimes the gov't will hire a competing civil engineering firm just to be onsite checking the work. That balance probably works.
  - efsavage 4y ago
    In the US, on large structural projects, things are generally well-specified, either by standard code, or long before the project goes to bid. The owner (usually another firm representing the government that's paying for it) and the contractor inspect and measure all the work done each day. There are undoubtedly going to be mistakes and corners cut, but that's what safety factors are for and it's hard for problems like that to be endemic without some serious corruption. On a related note to using the wrong concrete, things like this can be an opportunity to see master craftspeople in their element. We had a truck of concrete show up and the foreman rejected it with almost no hesitation. "Why the f*&($ won't you sign on off this!?" the driver yelled. "It's smells wrong", said the foreman. Nobody else noticed anything amiss, but he was the boss, so the truck went back to the plant and sure enough, they'd mixed it wrong.
deleted 4y ago
[deleted]

Retric 4y ago

There are a lot of games you can play to make say rent look like a cost on a contract while another entity makes a profit from that rent. Worse you still have incentives to offload costs onto a contract. For example someone finishes an unrelated contract your might as well move them to a profit + contract rather than benching them or immediately laying them off. In the end markets simply aren’t efficient without pricing information. If you can’t get someone to bid a fixed price you might as well keep in in house.

krapht 4y ago
Those games you play are a lot easier to deal with oversight-wise. I disagree with your conclusion. You're assuming in-house doesn't have the same perverse incentives. Also, pricing information can be impossible to discover. You often hear on HN how nobody can realistically estimate large software programs. Under that regime, what good is a firm fixed price contract? What'll happen is that the company, once it goes over-budget, will stop work and/or go bankrupt depending on the legal contract it signed. Then the client has no choice but to add more money into the pot - which suddenly sounds like a cost+ contract.
- Retric 4y ago
  I have worked on plenty of successful fixed price software projects. The simple reality is when you fix costs quality becomes the flexible metric, but meeting the minimum project goals becomes really important. However, considering how many software projects fail, reaching the agreed upon minimum at the agreed upon price is vastly better than what generally happens. As to failing to finish a project the wonders of fixed price contracting is you can pay at completion of some milestone. Of course that means people need to pad the price even more ahead of time to assume that risk, but price becomes a really useful signal.

Closi 4y ago

All these approaches have plusses and minuses and their own risks. The risks with the approach you have described are that: a) Unless very carefully managed, you can end up with contractors being incentivised to cut corners (i.e. We make more money if we buy the cheapest doors possible, regardless of if they only last a few weeks). b) If contractors have fixed profits at their bid-price, they will have zero incentive to accept any change requests (unless they come with additional margin, in which case, overspends will magically turn into change requests).

airstrike 4y ago
If those doors are still built-to-spec, then shouldn't you be fine?
- larkost 4y ago
  This assumes that every relevant detail is speced out. In many projects you don't know exactly what something is going to look like at the end of the project, so over-spec'ing is just as much a problem.
  - efsavage 4y ago
    On the types of projects I mentioned, and I assume to an even greater degree for spaceships, the details are in the spec, which is stamped by an engineer. If you're installing a curb, all of the dimensions are there, the finish on each side, how far below ground it goes, what type of gravel goes under it, the mortar you use to set it, and it will say what kind of granite is specified. If you want to change any of that, you need to get approval (and probably won't). This isn't software where you have hand-wavy goals written by people with no training and can refactor when your tests fail :)
  - airstrike 4y ago
    Every relevant detail should be speced out! The irrelevant stuff is irrelevant
    - 4y ago

magicalhippo 4y ago

> I worked on a 9-figure construction project and there were two full-time engineers specifically tasked with looking for ways to reduce the cost of the project, because it was essentially free money for the contractor. Semi-related story: Way back I was a trainee for a company, which won a contract to upgrade the the branch servers for some other company, about 500 of them. The on-site process involved copying over files from the old Unix server to a new NT4 server running Citrix, split maildir and home directory and set proper user-level permissions on each users home and mail directory. The whole rollout was going on for just a few months, so we had tons of folks doing this in parallel at each site. During the first site I saw the manual our project team had created, and it specified us doing the copying and permission setting using Windows Explorer. To change the ACL that meant scrolling down to find the right abbreviated user name matching the directory name... fun when there was hundred employees at a branch. I figured there had to be a better way, and started writing some batch scripts. After about a day I had automated the whole process, including sending a mail to our phones (the phone company had a service turning number@phone-company.com into an SMS). So I just launched the script, went for a 1-2 hour lunch until the phone beeped. Then I just had to go over the logs and verify there were no errors, and job done. Back at base, I shared the scripts with my coworkers, which obviously loved not having to do the tedious process as specified. It was only after the end of the project that I learned that the contract included a fixed rate of 3-5 days per site for one or two techs, depending on size. After all, changing all those permissions manually took a lot of time. After I wrote the scripts nobody used more than half a day... Did I get any extra compensation for that? Of course not, and I was too young and shy to ask. Oh well, lesson learned.

myself248 4y ago
Similar here: Fresh out of high school, I worked for a telecom contractor, installing large cross-connect machines. (Think 20-30 racks of equipment, a few thousand DS3s worth of capacity, which in the late 1990s was a lot.) We'd do the physical install and some very basic continuity testing, then hand over the keys to the vendor's own tech who would "turn up" the machine, thoroughly testing it and making it ready for service, before finally handing it to the customer who would provision their actual traffic on it. The turn-up procedure was documented in the manual and technically anyone could do it, it was just customary to have the vendor do it. And they charged handsomely for it, flying out a tech who would spend 2-3 weeks on site running through the procedure. It was quite a lot of manual work, adding and deleting connections throughout the whole range, and plugging a T-Berd tester into the patchbay to verify transmission of every single circuit. The tech was quite busy during those weeks. My company decided (at a level way above me) that we were gonna try to get into this line of work. As the pimply-faced youth with some computer experience, I got tapped for it, and paired with a graybeard who had done something similar back in the 80s and had a sense of the lay of the land. The logic was that our first few jobs might not make us any money, but we'd get better, and anyway just saving the airfare would be a win. The manual specified typing all the commands directly into the machine's (TL1) prompt, but I wanted to avoid typos, so I typed everything into Wordpad first and then pasted it into the prompt. Which meant I was creating a log of all the necessary commands, and I could search-and-replace various parts to advance through the range of valid circuits. Less typing, more pasting. By the end of our second day, we were screaming through the testing (still doing everything by the book, just typing an effective 500wpm and making zero typos) way faster than the vendor's tech ever did. Running back and forth with patch cords and T-Berds was the principal limit. By the end of the first week, I had written a QBASIC program to obviate the search-and-replace, and just spit out bespoke commands for any given range, or for a whole machine at once if you wanted to feed it the whole config. The output was a many-thousand-line text file which you would then drip-feed to the machine while doing the needful with patch cords and your trusty T-berd. As long as nothing went wrong, it was literally just one long file-send with pauses for jogging across the office. And as our installers were very good, things rarely went wrong. (I did find out that the machine's input buffer was only a few hundred characters, thank goodness the terminal software had an inter-line paste delay!) Our very first job came in at less than half the time we'd bid, and it only improved from there. After our third job, I believe, I went solo. I bought a pair of WPC11 cards and parked one laptop at the machine's console port, carried the other with me to the patchbay, and eliminated the running-back-and-forth time too. Wizardry! Laziness! Profit! I proceeded to reverse-engineer quite a lot of that machine, finding undocumented debug interfaces that saved tons of time when things did go wrong, so we could avoid the blind combinatorics specified in the manual, and instead directly zero in on the errant signal. When things went smoothly, I was 3-5x faster than the vendor's own tech. When things went wrong, I was 10x faster. Extra money? Nah. But I was having the time of my life.