5 ms·

Yup, if you need 10 million for a project, you quote 3 million and ask for more funding later on, otherwise you will never get any funding at all as they balk a

Yup, if you need 10 million for a project, you quote 3 million and ask for more funding later on, otherwise you will never get any funding at all as they balk at the true costs of research and development.

sgt101 8y ago
Where I work this gets you fired. We have a benefits tracking requirement, you put in a 3 gets you 9 case (borderline fundable - probably too small and not sufficient payback, but you might get it) and they go back and ask for another 7 over 2 years and you will leave on the ask. If you put 3 gets you 30 and then ask for another 7 you may well leave on the ask, you may get to stay for the realisation of the 30, but then you go. Probably you go on the ask because someone else will be parachuted into the project (if it's believed that the 30 really is on the table).
- buro9 8y ago
  I worked in a place (a bank) where an estimate that was more than 10% out in either direction would get you fired. Their view was that they valued accurate estimations that highly. But when I was there it was already being worked around... managers would create lots of smaller projects that delivered cross-functional behaviour to multiple projects and allowed them to externalise and hide the overages in what might appear to only be dependency lines to existing internal projects. The managers of multiple projects would collude to sponsor each others externalities so that they all had a layer of protection from being fired, obscuring what the costs were actually contributing to. The reason I was there was precisely to build a revenue recognition type system for their project management system to try and identify which projects had asked for some other project to start. But after that I worked at a UK govt department and they'd become so good at tracking who had been first to demand the creation of another project that their problem became one of legacy... no-one could sponsor even upgrading their long obsolete software or hardware, because even though it was a thing that benefited everyone, the project that demanded it was going to be the one that paid for it (literally paying for the certification, hardware, software, training, etc) which meant if you were the team that said "We can't support this on IE6" then you had to pay to replace laptops, OS, to get onto a later version. My conclusion... if we don't embrace a pragmatic reality of what things cost, if we try and manage the costs tightly... the side effects usually have unintended consequences that are worse than facing or embracing the original costs.
  - amelius 8y ago
    > My conclusion... if we don't embrace a pragmatic reality of what things cost, if we try and manage the costs tightly... the side effects usually have unintended consequences that are worse than facing or embracing the original costs. Yes, but sometimes there is competition between projects. In that case it may pay to lie about the actual cost.
    - longerthoughts 8y ago
      It might pay for the people on that project, but I think the point was that this ends up being worse for the organization. Because of the incentives at the individual level, as you pointed out, I agree that it's not realistic to expect project leads to be more pragmatic. I do, however, think organizations should be making more of an effort to realign incentives so that what's best for the project is also best for the organization. Unfortunately, solutions like the "within 10% or you're fired" model create enough pressure that people evidently just find ways to cheat the system because their greatest concern is now keeping their jobs.
  - Someone 8y ago
    ”I worked in a place (a bank) where an estimate that was more than 10% out in either direction would get you fired.” If so, I would see only two rational approaches: find another job, or hugely overestimate, and, unless things go very wrong, twiddle your thumbs for most of the time (or think of/work on a side project or study) It’s very hard to estimate even the simplest ‘projects’ within 10%. For example, try estimating how long your trip home or your next bathroom break or coffee machine visit will take, and see how often you get within 10% (if you say “5 minutes” that gets you 30 seconds either way)
    - AtlasBarfed 8y ago
      I'd overestimate and then invent work to get to 5% under budget. You can always test more.
  - sgt101 8y ago
    10% either way is very tight. I think everyone's keen to allocate capital well, but if you see a way to pull 30% out of a project and are incentivized to decline then that's not good.
- marsokod 8y ago
  One of the problem with NASA (and other companies/agencies of the sort) is that projects take a very long time, at least 10 years and usually 20 years. You cannot fire the guy who officially did the estimate at the beginning: he is not on the project anymore, most probably not in the same company, maybe retired, and usually has grown to a position much more powerful. Underestimating on the contrary leads you to not getting funding for the projects you are responsible for, and that is a nice way to not get a promotion. As in Python, it is easier to ask for forgiveness than permission.

sgt101 8y ago

Where I work this gets you fired. We have a benefits tracking requirement, you put in a 3 gets you 9 case (borderline fundable - probably too small and not sufficient payback, but you might get it) and they go back and ask for another 7 over 2 years and you will leave on the ask. If you put 3 gets you 30 and then ask for another 7 you may well leave on the ask, you may get to stay for the realisation of the 30, but then you go. Probably you go on the ask because someone else will be parachuted into the project (if it's believed that the 30 really is on the table).

buro9 8y ago
I worked in a place (a bank) where an estimate that was more than 10% out in either direction would get you fired. Their view was that they valued accurate estimations that highly. But when I was there it was already being worked around... managers would create lots of smaller projects that delivered cross-functional behaviour to multiple projects and allowed them to externalise and hide the overages in what might appear to only be dependency lines to existing internal projects. The managers of multiple projects would collude to sponsor each others externalities so that they all had a layer of protection from being fired, obscuring what the costs were actually contributing to. The reason I was there was precisely to build a revenue recognition type system for their project management system to try and identify which projects had asked for some other project to start. But after that I worked at a UK govt department and they'd become so good at tracking who had been first to demand the creation of another project that their problem became one of legacy... no-one could sponsor even upgrading their long obsolete software or hardware, because even though it was a thing that benefited everyone, the project that demanded it was going to be the one that paid for it (literally paying for the certification, hardware, software, training, etc) which meant if you were the team that said "We can't support this on IE6" then you had to pay to replace laptops, OS, to get onto a later version. My conclusion... if we don't embrace a pragmatic reality of what things cost, if we try and manage the costs tightly... the side effects usually have unintended consequences that are worse than facing or embracing the original costs.
- amelius 8y ago
  > My conclusion... if we don't embrace a pragmatic reality of what things cost, if we try and manage the costs tightly... the side effects usually have unintended consequences that are worse than facing or embracing the original costs. Yes, but sometimes there is competition between projects. In that case it may pay to lie about the actual cost.
  - longerthoughts 8y ago
    It might pay for the people on that project, but I think the point was that this ends up being worse for the organization. Because of the incentives at the individual level, as you pointed out, I agree that it's not realistic to expect project leads to be more pragmatic. I do, however, think organizations should be making more of an effort to realign incentives so that what's best for the project is also best for the organization. Unfortunately, solutions like the "within 10% or you're fired" model create enough pressure that people evidently just find ways to cheat the system because their greatest concern is now keeping their jobs.
- Someone 8y ago
  ”I worked in a place (a bank) where an estimate that was more than 10% out in either direction would get you fired.” If so, I would see only two rational approaches: find another job, or hugely overestimate, and, unless things go very wrong, twiddle your thumbs for most of the time (or think of/work on a side project or study) It’s very hard to estimate even the simplest ‘projects’ within 10%. For example, try estimating how long your trip home or your next bathroom break or coffee machine visit will take, and see how often you get within 10% (if you say “5 minutes” that gets you 30 seconds either way)
  - AtlasBarfed 8y ago
    I'd overestimate and then invent work to get to 5% under budget. You can always test more.
- sgt101 8y ago
  10% either way is very tight. I think everyone's keen to allocate capital well, but if you see a way to pull 30% out of a project and are incentivized to decline then that's not good.
marsokod 8y ago
One of the problem with NASA (and other companies/agencies of the sort) is that projects take a very long time, at least 10 years and usually 20 years. You cannot fire the guy who officially did the estimate at the beginning: he is not on the project anymore, most probably not in the same company, maybe retired, and usually has grown to a position much more powerful. Underestimating on the contrary leads you to not getting funding for the projects you are responsible for, and that is a nice way to not get a promotion. As in Python, it is easier to ask for forgiveness than permission.