5 ms·

The reason that software projects deliver so poorly in the corporate world is that senior executives and investors understand them so poorly that a large amount

by zakum1 8y ago

The reason that software projects deliver so poorly in the corporate world is that senior executives and investors understand them so poorly that a large amount of recognition and attention goes to those who can "bullshit" rather than fix the problem. This is particularly toxic, because often the senior executives and investors also have an interest in hiding the failure (avoiding personal accountability and avoiding write-downs on investment). It is very hard to see how a culture of true reflection and learning can emerge in this environment.

pmlnr 8y ago
That's not the problem; looking at it as a cost center is. It all boils down to not enough growth.
- sgt101 8y ago
  It's seen as a cost centre because no one can manage it in any other way. The consultants have found one way to provide some results sometimes, but aren't motivated or able to do better.
  - dredmorbius 8y ago
    What might alternatives be? How about treating it as capital with a risk-return element, say?
    - sgt101 8y ago
      omg in my dreams: then it would be an asset on the balance sheet and it would be a shareholder value increasing move to improve it. CIO becomes = CFO.
- deleted 8y ago
  [deleted]
amelius 8y ago
I think the biggest problem is getting the requirements right (as much as possible) prior to the actual coding. Many managers seem to think that they can easily change the requirements in the middle of the project.
- XorNot 8y ago
  Requirements, infrastructure components, platform systems and promises from external vendors that "it'll totally be ready by the time you launch". This is all things I've seen in the last month (yeah I'm not joining any more greenfield projects within organizations - if you think you're going to rebuild it from scratch and fix all the problems, you have no idea what went wrong in the first place).
- pvarangot 8y ago
  Yeah but behind your "as much as possible" statement hides the whole softwar engineering profession. Getting the requirements right sometimes can paralize a team, making it loose "capabilities" or momentum or even having attrition impact. There's no single PM methodology solution to avoid having the deal with the tradeoffs associated with the agile vs. waterfall dichotomy. Behind any popular or profitable succesfull software project there are sometimes as much "PMing" practices as there are coders.
- groestl 8y ago
  It might be even the idea that (without an effort that matches or exceeds the implementation itself), you can "get the requirements right", i.e. that there is a point in time where the requirements are complete, fully understood and thoroughly specified.
  - brazzledazzle 8y ago
    Given the enormous scope of some of these projects I wonder if a prototype phase would help. Humans seem to have a hard time with conceptualizing and a slow, barely/non working and unscalable prototype might be worth the added cost/time. If it’s part of the requirement gathering process with explicit expectations set that it’s a prototype would it facilitate better requirements input? Naturally you’d have some people making assumptions about its fitness as a final product or MVP but (if a UI is involved) giant bright warning banners plastered all over might help with that.
dredmorbius 8y ago
A form of Gresham's Law, whose generalised form is that equivalent current-cycle benefits outweigh non-apparent long term net advantage (benefit less cost). Or even more generally: a complexity constraint. Risk is a nonapparent long-form cost, and unless specifically manifested (insurance, regulations, fines), will be ignored. The results of a scholarly search for "a gresham's law of" are illuminating, spanning divorce, neighbourhoods, academic admissions, environmental regulations, incorporation, shipping, management, court citations, television programming, politics, and more. https://scholar.google.com/scholar?q="a%20gresham%27s%20law%20of"&btnG=Search&as_sdt=800000000001&as_sdtp=on https://scholar.google.com/scholar?q="a%20gresham%27s%20law%...

by zakum1 8y ago

pmlnr 8y ago

That's not the problem; looking at it as a cost center is. It all boils down to not enough growth.

sgt101 8y ago
It's seen as a cost centre because no one can manage it in any other way. The consultants have found one way to provide some results sometimes, but aren't motivated or able to do better.
- dredmorbius 8y ago
  What might alternatives be? How about treating it as capital with a risk-return element, say?
  - sgt101 8y ago
    omg in my dreams: then it would be an asset on the balance sheet and it would be a shareholder value increasing move to improve it. CIO becomes = CFO.
deleted 8y ago
[deleted]

amelius 8y ago

I think the biggest problem is getting the requirements right (as much as possible) prior to the actual coding. Many managers seem to think that they can easily change the requirements in the middle of the project.

XorNot 8y ago
Requirements, infrastructure components, platform systems and promises from external vendors that "it'll totally be ready by the time you launch". This is all things I've seen in the last month (yeah I'm not joining any more greenfield projects within organizations - if you think you're going to rebuild it from scratch and fix all the problems, you have no idea what went wrong in the first place).
pvarangot 8y ago
Yeah but behind your "as much as possible" statement hides the whole softwar engineering profession. Getting the requirements right sometimes can paralize a team, making it loose "capabilities" or momentum or even having attrition impact. There's no single PM methodology solution to avoid having the deal with the tradeoffs associated with the agile vs. waterfall dichotomy. Behind any popular or profitable succesfull software project there are sometimes as much "PMing" practices as there are coders.
groestl 8y ago
It might be even the idea that (without an effort that matches or exceeds the implementation itself), you can "get the requirements right", i.e. that there is a point in time where the requirements are complete, fully understood and thoroughly specified.
- brazzledazzle 8y ago
  Given the enormous scope of some of these projects I wonder if a prototype phase would help. Humans seem to have a hard time with conceptualizing and a slow, barely/non working and unscalable prototype might be worth the added cost/time. If it’s part of the requirement gathering process with explicit expectations set that it’s a prototype would it facilitate better requirements input? Naturally you’d have some people making assumptions about its fitness as a final product or MVP but (if a UI is involved) giant bright warning banners plastered all over might help with that.

dredmorbius 8y ago

A form of Gresham's Law, whose generalised form is that equivalent current-cycle benefits outweigh non-apparent long term net advantage (benefit less cost). Or even more generally: a complexity constraint. Risk is a nonapparent long-form cost, and unless specifically manifested (insurance, regulations, fines), will be ignored. The results of a scholarly search for "a gresham's law of" are illuminating, spanning divorce, neighbourhoods, academic admissions, environmental regulations, incorporation, shipping, management, court citations, television programming, politics, and more. https://scholar.google.com/scholar?q="a%20gresham%27s%20law%20of"&btnG=Search&as_sdt=800000000001&as_sdtp=on https://scholar.google.com/scholar?q="a%20gresham%27s%20law%...