5 ms·

Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPE

by dpweb 9y ago

Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. But after selling the deal, their workers have to solve a difficult engineering and organizational management problem simultaneously (the project). They use contractors (devs) which proves they are not an engineering but sales culture. So, you need to bridge the two worlds. That's the PMs. These are the most incompetent members of the team. The devs very often are very smart. Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things. Reasons for failure: 1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem. 2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed.

dctoedt 9y ago
> Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. An EDS executive's alleged overpromising, in landing a big contract to build a CRM system for British Sky Broadcasting, ended up costing EDS big bucks: USD $460 million, or more than four times the value of the original contract [0]. [0] http://www.oncontracts.com/eds-british-sky-overpromising/ http://www.oncontracts.com/eds-british-sky-overpromising/ (self-cite)
- rahimnathwani 9y ago
  "After the decision was handed down, Sky announced that it expected the damage award to be at least £200 million. Had it not been for the misrepresentation claims, the pure-contract damages presumably would have been capped at £30 million. The difference works out to about US$270 million." Seems like a math error.
lovich 9y ago
I agree with some of your points but I don't think that deconstructioning the pieces of the project is a panacea. What frequently occurs when that happens is that you get distributed work along with distributed responsibility. Then whenever anything goes wrong or needs to change, there is no one who can make it happen. You get team A who needs team B to make a new api, but they won't do it till they get a new device because their kpis don't improve for any work they do for team A, so HR needs to be involved the do hiring but they need to talk to accounting to approve the budget and on and on and on. If you've ever seen Rick and Morty, the episode where aliens have accidentally pulled another character in and the leader is trying to find out why, when every department blames another and he says "oh, so it's nobodies fault" is a perfect example of most large projects
- dpweb 9y ago
  Not a panacea, but if you imagine - every effort is begun with a built in base probability of failure (battle won or lost before it's fought kind of thing) - that a smaller effort reduces likelihood of failure cause you have less unknown variables. Breaking things up, not necessarily with the teams, but with time. Milestones, separate the projects over time. Also, the shorter deadlines I've found help keep focused. Longer than a couple months - things can languish.
paulie_a 9y ago
This cannot be stressed enough, IBM is basically the opening scene of the movie "boiler room"
wahern 9y ago
Early in my career I had a brief stint as an engineer at a consulting company in the ERP industry. Our projects always had at least one functional consultant whose expertise was _using_ the ERP systems and understanding how they integrated with other systems and procedures. This was a different position than PM, who was often an employee of the client company who drew the short straw. The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable. The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate. The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.
- AndyNemmity 9y ago
  Yeah, our projects were generally A functional consultant on our team who is great. Connected to their functional consultant who was wildly differing in skill level, from expert to can barely use a computer. Technical Consultants, which involved 1 Senior who knew everything about one segment of topics. Another Senior who knew everything about a different segment of topics. A junior to learn things. And the PM which was also the sales lead looking for more work. 1 of those Seniors needed to be able to have social skills and diplomacy, the other didn't. You could hide the 2nd through preplanning. The junior just needed to know to keep his mouth shut. Then you'd have a variety of other seniors who you could call in on a particular topic, but you'd try not to use, as they are on projects. And in our case, we had a GM who was more functional than all of us, almost as technical as all of us, and the best in front of customers. He could be brought in to deal with any special scenarios, and to gut check our plans. So we were really, ridiculously successful with that model. Basically, really well paid, SMEs, no cruft except a younger guy to learn on the job. Such a good structure.
derefr 9y ago
> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. I do understand what you meant here, and it's mostly right. But there are also obvious exceptions. You can often make a sale by promising more than your competitors. If your competitors' bids are calibrated by what's actually possible, and yours isn't, then you'll win the bid... and then, years later, be unable to deliver what was specified, and have to renegotiate. But hey, you won the bid! I guess that, if the market doesn't keep track of these renegotiations and failures-to-deliver, this is the optimum strategy over the short- and even medium-term. But it gets your company known to devs as a company that chews up and spits out talent. Devs that get stuck on projects trying to do the (literally) impossible, slogging forward each day with the knowledge that all of this is going to be ripped out when the deadlines pass and the renegotiation hits, don't tend to recommend to their friends the companies where they had to do that. So, over the long-term, this is a recipe for a talent shortage. But, like you said, there's always contractors: fresh pools of devs who never signed up to work for something like IBM, headed by either unscrupulous or just plain naive management willing to take on such jobs with literally-impossible specs.
kev009 9y ago
I disagree, IBM is a multifaceted company. These kinds of projects fall under what used to be called IBM Global Services https://en.wikipedia.org/wiki/IBM_Global_Services https://en.wikipedia.org/wiki/IBM_Global_Services. It could be compared somewhat to EDS (HP), Accenture, Perot Systems (Dell) etc. I've never heard of over-delivery from any of these kinds of outsourcing arrangements, they always seem so obviously destined for boondoggle. IBM proper, the one that makes mainframes and POWER and DB2 and a ton of operating systems and storage etc is very much a technology company. Some of their best products have the worst sales and marketing efforts. I'm working directly with the senior leadership of the POWER group right now and there are no salesmen in sight.. the technology will either sell itself or not. When we met in person the first time the GM told me "we can build any kind of computer you want" - meaning microarchitecture changes, SERDES configuration, new board layout, sheet metal, OS, application tweaks. Not a lot of companies can do that. There is hubris, less technology, and lack of technical value at FANG or most startups or whatever your benchmark is in comparison. IBM Research is one of the only remaining great industrial research organizations https://en.wikipedia.org/wiki/IBM_Research https://en.wikipedia.org/wiki/IBM_Research. Their results speak for themselves.
- eeks 9y ago
  I was looking for a proper answer to that parent comment. I could not have come with a better one.
- stochastic_monk 9y ago
  I’m surprised the Stratix FPGA platform isn’t getting more marketing. Half a TiB/s memory bandwidth [0] (white paper) when GPU’s memory transfer is the bulk of the overhead could help Intel make up for lost gains in SIMD application marketshare. [0]: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01264-stratix10mx-devices-solve-memory-bandwidth-challenge.pdf https://www.altera.com/content/dam/altera-www/global/en_US/p...
  - kev009 9y ago
    Maybe misparented comment? HP has GenZ, IBM is going to move from DDR or DDR buffers to CAPI attached RAM -- expect to see HBM2 attached to CPUs in 2019. I'd be happy to discuss that kind of thing in email.
kevinSuttle 9y ago
If only people knew how often employees of companies like this scrambled to build something in a mad panic because some exec made a promise to a client about software that wasn’t even designed yet.
jlarocco 9y ago
> Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. Companies as large as IBM don't have a single unified culture. The sales groups are sales oriented, and the engineering groups are engineering/ tech oriented. Most of the time the two aren't in the same building, and often not even the same city. > Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things. > Reasons for failure: > 1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem. 2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed. It seems like you're stretching to blame PMs, and I don't think it's deserved. The sales guy's job isn't just to sell the biggest deal - it's to sell the biggest deal that the company can actually execute and deliver. And it's no secret that there at least as many incompetent devs as there are smart, amazing devs. There's a reason "fizzbuzz" is a weed out question. Likewise, there are good and bad PMs. Without all of the information it's impossible to place blame on a single group of employees.
wallace_f 9y ago
Why are the sales guys necessarily competent in seeing that a project adds value? They only need to sell it.
hinkley 9y ago
I have been on the bad side of IBM Global Services both times I’ve encountered them and was warned off by someone with existing beef. They will build the most complicated thing that could possibly solve the problem. And then you can’t get rid of them because holy shit nobody else wants to deal with their code. If Rube Goldberg and H P Lovecraft had a child it would weep in despair knowing that in all its life it would never create something as sinister and complex as the stuff IGS makes before breakfast. They were trying to charge $80k a year for a proxy server to handle XML RPC. For a system that was basically ftp with code signing. Our team took care of the code signing, soup to nuts. To this day I don’t know what they were doing with all that money for a tiny part of the system. Except try to take over. They didn’t expect the wall of competence they encountered.
noonespecial 9y ago
That seems a little over-analyzed. Sales is seen as a profit center, engineering is seen as a cost center. This is no different than a good salesman selling some shipping contracts and then the company failing to deliver because some penny pinching nit-wit "saved" some money by skipping oil changes and tire maintenance causing the trucks to break down before the job was done. Its just on a bigger scale.
tobtoh 9y ago
> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. Seems very flawed logic. Anyone can make a sale if you promise everything, charge a low price (that can't sustain your organisation/solution), and have no responsibility for actually being able to deliver within the timeframe they promised. I fail to see how that shows the sales person is competent.
- Arnt 9y ago
  Pretend you're a customer. Would you buy from someone who promises everything at a price that cannot sustain his organisation and accepts no responsibility?
  - godzillabrennus 9y ago
    Have you met your local politician who is trying to make decisions on things they don't understand?
    - Arnt 9y ago
      I'm an expat. My politicians aren't local. The two I've spoken to were also both knowledgeable and intelligent, so your rhetoric is glib but a little lacking in factual accuracy.
  - Spooky23 9y ago
    Pretend you are a CIO with an average job tenure of 18-24 months. Do you give the CEO the right, expensive and difficult answer? Or assign accountability to a third party, bug out and leave the mess to the next guy? In most companies with mediocre the latter is the answer.
- raarts 9y ago
  Still, I can confirm from personal experience this is how the world works for many people. Been in multiple companies that went bankrupt because the sales people showed this behavior.
white-flame 9y ago
The project sizes are fine. The team sizes are too large. There's too much empire building and career-minded politicking going on in companies of this size, which gets in the way of actually working on the product. Managers increase scope to increase their budget, then do busy make-work to justify the budget so they can get more next round. The engineers need to look busy even though things aren't defined, and optimize to internal-facing metrics as opposed to product-oriented productivity. Anybody who steps back and mentions that progress isn't being made towards actually getting the customer a working product is reprimanded as undermining the unquestionably accepted established processes (which usually aren't working anyway). The actual deliverable gets lost in the shuffle, as the lumbering hulk of the company and career paths within it overshadow the customer.
- ezconnect 9y ago
  This is the correct answer. I saw it first hand how PM and engineers don't care about the product, they just care about their careers and company internal metrics.
godzillabrennus 9y ago
A friend of mine has had an illustrious career in I.T. with many successes in the last decade. Right before he struck out on his own to build his brand he was unhappy with his then job and decided to work with a recruiter to find a new role. The recruiter got him a job with a large bank going through a transition from a major platform from a third party that had been long neglected. The platform was on what we will call version 5 of the software while everyone else was running what we will call version 9 of the software. My friend was hired as a technical project manager. He worked there for less than a month before he struck out on his own and got to realize his full potential. In that brief period of time he learned the following: * The bank had not started to put together the requirements for the new software to be integrated. * The software vendor had no upgrade path from the very old version to the new version. * The bank needed the migration done in under ninety days or they would start getting fined millions of dollars by regulators. * The project had already committed to spending $3M / month on a five year commitment with a hosting partner but they didn't have any developers working with them yet. What I took away is that when big companies do stupid things they are big stupid things. I'm not surprised that government being as big as it is would also do stupid things on a larger scale.
flarg 9y ago
I wholly disagree with your criticism of the middle. The original article points to the cause of failure which was dismissal of SMEs prior to deployment. Almost all projects of this size are doomed to complexity overload but that is surmountable, but loss of Product Owners and SMEs is not.
- jessaustin 9y ago
  It wasn't sales who decided not to have a SME on the project. They already got paid; why would they worry about personnel? That is a classic middle management decision.

by dpweb 9y ago

dctoedt 9y ago

rahimnathwani 9y ago
"After the decision was handed down, Sky announced that it expected the damage award to be at least £200 million. Had it not been for the misrepresentation claims, the pure-contract damages presumably would have been capped at £30 million. The difference works out to about US$270 million." Seems like a math error.

lovich 9y ago

I agree with some of your points but I don't think that deconstructioning the pieces of the project is a panacea. What frequently occurs when that happens is that you get distributed work along with distributed responsibility. Then whenever anything goes wrong or needs to change, there is no one who can make it happen. You get team A who needs team B to make a new api, but they won't do it till they get a new device because their kpis don't improve for any work they do for team A, so HR needs to be involved the do hiring but they need to talk to accounting to approve the budget and on and on and on. If you've ever seen Rick and Morty, the episode where aliens have accidentally pulled another character in and the leader is trying to find out why, when every department blames another and he says "oh, so it's nobodies fault" is a perfect example of most large projects

dpweb 9y ago
Not a panacea, but if you imagine - every effort is begun with a built in base probability of failure (battle won or lost before it's fought kind of thing) - that a smaller effort reduces likelihood of failure cause you have less unknown variables. Breaking things up, not necessarily with the teams, but with time. Milestones, separate the projects over time. Also, the shorter deadlines I've found help keep focused. Longer than a couple months - things can languish.

paulie_a 9y ago

This cannot be stressed enough, IBM is basically the opening scene of the movie "boiler room"

wahern 9y ago

Early in my career I had a brief stint as an engineer at a consulting company in the ERP industry. Our projects always had at least one functional consultant whose expertise was _using_ the ERP systems and understanding how they integrated with other systems and procedures. This was a different position than PM, who was often an employee of the client company who drew the short straw. The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable. The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate. The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.

AndyNemmity 9y ago
Yeah, our projects were generally A functional consultant on our team who is great. Connected to their functional consultant who was wildly differing in skill level, from expert to can barely use a computer. Technical Consultants, which involved 1 Senior who knew everything about one segment of topics. Another Senior who knew everything about a different segment of topics. A junior to learn things. And the PM which was also the sales lead looking for more work. 1 of those Seniors needed to be able to have social skills and diplomacy, the other didn't. You could hide the 2nd through preplanning. The junior just needed to know to keep his mouth shut. Then you'd have a variety of other seniors who you could call in on a particular topic, but you'd try not to use, as they are on projects. And in our case, we had a GM who was more functional than all of us, almost as technical as all of us, and the best in front of customers. He could be brought in to deal with any special scenarios, and to gut check our plans. So we were really, ridiculously successful with that model. Basically, really well paid, SMEs, no cruft except a younger guy to learn on the job. Such a good structure.

derefr 9y ago

> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. I do understand what you meant here, and it's mostly right. But there are also obvious exceptions. You can often make a sale by promising more than your competitors. If your competitors' bids are calibrated by what's actually possible, and yours isn't, then you'll win the bid... and then, years later, be unable to deliver what was specified, and have to renegotiate. But hey, you won the bid! I guess that, if the market doesn't keep track of these renegotiations and failures-to-deliver, this is the optimum strategy over the short- and even medium-term. But it gets your company known to devs as a company that chews up and spits out talent. Devs that get stuck on projects trying to do the (literally) impossible, slogging forward each day with the knowledge that all of this is going to be ripped out when the deadlines pass and the renegotiation hits, don't tend to recommend to their friends the companies where they had to do that. So, over the long-term, this is a recipe for a talent shortage. But, like you said, there's always contractors: fresh pools of devs who never signed up to work for something like IBM, headed by either unscrupulous or just plain naive management willing to take on such jobs with literally-impossible specs.

kev009 9y ago

I disagree, IBM is a multifaceted company. These kinds of projects fall under what used to be called IBM Global Services https://en.wikipedia.org/wiki/IBM_Global_Services https://en.wikipedia.org/wiki/IBM_Global_Services. It could be compared somewhat to EDS (HP), Accenture, Perot Systems (Dell) etc. I've never heard of over-delivery from any of these kinds of outsourcing arrangements, they always seem so obviously destined for boondoggle. IBM proper, the one that makes mainframes and POWER and DB2 and a ton of operating systems and storage etc is very much a technology company. Some of their best products have the worst sales and marketing efforts. I'm working directly with the senior leadership of the POWER group right now and there are no salesmen in sight.. the technology will either sell itself or not. When we met in person the first time the GM told me "we can build any kind of computer you want" - meaning microarchitecture changes, SERDES configuration, new board layout, sheet metal, OS, application tweaks. Not a lot of companies can do that. There is hubris, less technology, and lack of technical value at FANG or most startups or whatever your benchmark is in comparison. IBM Research is one of the only remaining great industrial research organizations https://en.wikipedia.org/wiki/IBM_Research https://en.wikipedia.org/wiki/IBM_Research. Their results speak for themselves.

eeks 9y ago
I was looking for a proper answer to that parent comment. I could not have come with a better one.
stochastic_monk 9y ago
I’m surprised the Stratix FPGA platform isn’t getting more marketing. Half a TiB/s memory bandwidth [0] (white paper) when GPU’s memory transfer is the bulk of the overhead could help Intel make up for lost gains in SIMD application marketshare. [0]: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01264-stratix10mx-devices-solve-memory-bandwidth-challenge.pdf https://www.altera.com/content/dam/altera-www/global/en_US/p...
- kev009 9y ago
  Maybe misparented comment? HP has GenZ, IBM is going to move from DDR or DDR buffers to CAPI attached RAM -- expect to see HBM2 attached to CPUs in 2019. I'd be happy to discuss that kind of thing in email.

kevinSuttle 9y ago

If only people knew how often employees of companies like this scrambled to build something in a mad panic because some exec made a promise to a client about software that wasn’t even designed yet.

jlarocco 9y ago

> Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. Companies as large as IBM don't have a single unified culture. The sales groups are sales oriented, and the engineering groups are engineering/ tech oriented. Most of the time the two aren't in the same building, and often not even the same city. > Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things. > Reasons for failure: > 1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem. 2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed. It seems like you're stretching to blame PMs, and I don't think it's deserved. The sales guy's job isn't just to sell the biggest deal - it's to sell the biggest deal that the company can actually execute and deliver. And it's no secret that there at least as many incompetent devs as there are smart, amazing devs. There's a reason "fizzbuzz" is a weed out question. Likewise, there are good and bad PMs. Without all of the information it's impossible to place blame on a single group of employees.

wallace_f 9y ago

Why are the sales guys necessarily competent in seeing that a project adds value? They only need to sell it.

hinkley 9y ago

I have been on the bad side of IBM Global Services both times I’ve encountered them and was warned off by someone with existing beef. They will build the most complicated thing that could possibly solve the problem. And then you can’t get rid of them because holy shit nobody else wants to deal with their code. If Rube Goldberg and H P Lovecraft had a child it would weep in despair knowing that in all its life it would never create something as sinister and complex as the stuff IGS makes before breakfast. They were trying to charge $80k a year for a proxy server to handle XML RPC. For a system that was basically ftp with code signing. Our team took care of the code signing, soup to nuts. To this day I don’t know what they were doing with all that money for a tiny part of the system. Except try to take over. They didn’t expect the wall of competence they encountered.

noonespecial 9y ago

That seems a little over-analyzed. Sales is seen as a profit center, engineering is seen as a cost center. This is no different than a good salesman selling some shipping contracts and then the company failing to deliver because some penny pinching nit-wit "saved" some money by skipping oil changes and tire maintenance causing the trucks to break down before the job was done. Its just on a bigger scale.

tobtoh 9y ago

> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. Seems very flawed logic. Anyone can make a sale if you promise everything, charge a low price (that can't sustain your organisation/solution), and have no responsibility for actually being able to deliver within the timeframe they promised. I fail to see how that shows the sales person is competent.

Arnt 9y ago
Pretend you're a customer. Would you buy from someone who promises everything at a price that cannot sustain his organisation and accepts no responsibility?
- godzillabrennus 9y ago
  Have you met your local politician who is trying to make decisions on things they don't understand?
  - Arnt 9y ago
    I'm an expat. My politicians aren't local. The two I've spoken to were also both knowledgeable and intelligent, so your rhetoric is glib but a little lacking in factual accuracy.
- Spooky23 9y ago
  Pretend you are a CIO with an average job tenure of 18-24 months. Do you give the CEO the right, expensive and difficult answer? Or assign accountability to a third party, bug out and leave the mess to the next guy? In most companies with mediocre the latter is the answer.
raarts 9y ago
Still, I can confirm from personal experience this is how the world works for many people. Been in multiple companies that went bankrupt because the sales people showed this behavior.

white-flame 9y ago

The project sizes are fine. The team sizes are too large. There's too much empire building and career-minded politicking going on in companies of this size, which gets in the way of actually working on the product. Managers increase scope to increase their budget, then do busy make-work to justify the budget so they can get more next round. The engineers need to look busy even though things aren't defined, and optimize to internal-facing metrics as opposed to product-oriented productivity. Anybody who steps back and mentions that progress isn't being made towards actually getting the customer a working product is reprimanded as undermining the unquestionably accepted established processes (which usually aren't working anyway). The actual deliverable gets lost in the shuffle, as the lumbering hulk of the company and career paths within it overshadow the customer.

ezconnect 9y ago
This is the correct answer. I saw it first hand how PM and engineers don't care about the product, they just care about their careers and company internal metrics.

godzillabrennus 9y ago

A friend of mine has had an illustrious career in I.T. with many successes in the last decade. Right before he struck out on his own to build his brand he was unhappy with his then job and decided to work with a recruiter to find a new role. The recruiter got him a job with a large bank going through a transition from a major platform from a third party that had been long neglected. The platform was on what we will call version 5 of the software while everyone else was running what we will call version 9 of the software. My friend was hired as a technical project manager. He worked there for less than a month before he struck out on his own and got to realize his full potential. In that brief period of time he learned the following: * The bank had not started to put together the requirements for the new software to be integrated. * The software vendor had no upgrade path from the very old version to the new version. * The bank needed the migration done in under ninety days or they would start getting fined millions of dollars by regulators. * The project had already committed to spending $3M / month on a five year commitment with a hosting partner but they didn't have any developers working with them yet. What I took away is that when big companies do stupid things they are big stupid things. I'm not surprised that government being as big as it is would also do stupid things on a larger scale.

flarg 9y ago

I wholly disagree with your criticism of the middle. The original article points to the cause of failure which was dismissal of SMEs prior to deployment. Almost all projects of this size are doomed to complexity overload but that is surmountable, but loss of Product Owners and SMEs is not.

jessaustin 9y ago
It wasn't sales who decided not to have a SME on the project. They already got paid; why would they worry about personnel? That is a classic middle management decision.