If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(ZDNet)   Only 39% of IT projects are ever successful. The other 61% are the Obamacare website   (zdnet.com) divider line 53
    More: Fail  
•       •       •

1670 clicks; posted to Geek » on 26 Oct 2013 at 10:53 AM (1 year ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



53 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

First | « | 1 | 2 | » | Last | Show all
 
2013-10-26 09:31:55 AM  
I'd attribute this in large part to management. Managers are tasked with projects that have IT elements and they have no idea what their particular IT department can do, how much time and resources they have for their project, or even a full understanding of what they need.
 
2013-10-26 09:52:51 AM  
Outsourcing everyone probably didn't help.
 
2013-10-26 10:55:03 AM  
Maybe paper supply companies shouldn't make social media sites.
 
2013-10-26 10:57:01 AM  

MayoSlather: I'd attribute this in large part to management. Managers are tasked with projects that have IT elements and they have no idea what their particular IT department can do, how much time and resources they have for their project, or even a full understanding of what they need.


THIS!

I'm finishing up a project where we didn't get started coding until after the original launch date because middle management kept wanting to have scoping meetings. Finally the C suite took the project away from them and told us (tech) to just build the damn thing.
 
2013-10-26 11:04:23 AM  
The Forrester/EffectiveUI survey suggests organizational dysfunction is what keeps sending IT projects down in flames.

Ayup.
 
2013-10-26 11:13:03 AM  
This is relevant:

The Obamacare Suits/Geeks Divide

/we are gearing up to roll out a major internet service in just a couple of weeks so I'm getting a kick
 
2013-10-26 11:21:43 AM  
Seriously. I got re-org'd into the IT division, and management has an 80% success rate of coming up with acronyms for a project, not actually aligning the resources to get it done.

/they also say we need to be more "agile", yet funnel us through multiple substeps of upfront waterfall paperwork to the point that when we get to "Deliver" and discover the paperwork doesn't meet reality, then we wind up throwing a rushjob over the wall anyhow
//"reality" being how the "offshore" resources actually interpret that upfront paperwork
 
2013-10-26 11:24:19 AM  
You really can't get more unclear than "a segment of the board of directors keeps going on the news about how they want the entire project cancelled before launch"
 
2013-10-26 11:31:35 AM  
The business buys a vendor's software package without Technology's input or evaluation, discovers after purchase and deployment that it doesn't meet their expectations (e.g. the USB reader device disconnects every day, and the only remedy is a reboot), and then busts on Technology because their purchased POS software doesn't work.

/No, that's not "point of sale"
//There's a reason we have a tech project methodology; use it
 
2013-10-26 11:36:13 AM  
Define "successful."

From the viewpoint of a typical IT services company, success means "bills lots of hours."  Following methodologies and engineering for reusability are bad because they reduce the amount of hours billed to bring a project to production.  Quality is counterproductive since it reduces the number of maintenance hours needed.  Documentation should be eschewed because it makes it easier to replace your company with another and might reduce the amount of time required for change requests and bug-fixes to be implemented.
 
2013-10-26 11:43:46 AM  
Recently we got a new project management MBA type grad freshly minted out of school to run a high level initiative.  We were told he is a fast learner and should not be concerned about his lack of IT experience or the fact that his undergrad is not IT related.  Things he did not know what the letters stood for or what the technologies were: AD, SMTP, TCP/IP, UDP, UNIX, NT, Exchange, LDAP,....
 
2013-10-26 11:49:05 AM  

bagumpity: Define "successful."

From the viewpoint of a typical IT services company, success means "bills lots of hours."  Following methodologies and engineering for reusability are bad because they reduce the amount of hours billed to bring a project to production.  Quality is counterproductive since it reduces the number of maintenance hours needed.  Documentation should be eschewed because it makes it easier to replace your company with another and might reduce the amount of time required for change requests and bug-fixes to be implemented.


Usually the ones I see that operate like this are cheaper on the billable hours, pay their staff like crap, have a high turnover but good used cars like sales folks.  It may cost more up front, but pay for a company that has a stable workforce and enforces things like a proper ticketing and documentation system.  If you want cheaper rates and a reason to bag on IT folks, keep going with the company that  sends you a new tech every 3 months.
 
2013-10-26 11:52:39 AM  
I'll leave this here.
itshambles.files.wordpress.com
 
2013-10-26 12:09:00 PM  

wingnut396: Recently we got a new project management MBA type grad freshly minted out of school to run a high level initiative.  We were told he is a fast learner and should not be concerned about his lack of IT experience or the fact that his undergrad is not IT related.  Things he did not know what the letters stood for or what the technologies were: AD, SMTP, TCP/IP, UDP, UNIX, NT, Exchange, LDAP,....


I don't think it's all that rare for PMs to have no tech skills. Their role is to bust the techies' chops for not meeting their deadlines, and get their own chops busted by the management when the project timeline slips.
 
2013-10-26 12:32:32 PM  

pdieten: wingnut396: Recently we got a new project management MBA type grad freshly minted out of school to run a high level initiative.  We were told he is a fast learner and should not be concerned about his lack of IT experience or the fact that his undergrad is not IT related.  Things he did not know what the letters stood for or what the technologies were: AD, SMTP, TCP/IP, UDP, UNIX, NT, Exchange, LDAP,....

I don't think it's all that rare for PMs to have no tech skills. Their role is to bust the techies' chops for not meeting their deadlines, and get their own chops busted by the management when the project timeline slips.


Yes its common that a project manager hasn't got any background on the projects they are supposed to be masterminding, doesn't make it any less silly every time you encounter one of these useless twats out in the wild.  Unless they transitioned into the role from within IT's management I have no patience for that type of PM.
 
2013-10-26 12:49:55 PM  

BumpInTheNight: Yes its common that a project manager hasn't got any background on the projects they are supposed to be masterminding, doesn't make it any less silly every time you encounter one of these useless twats out in the wild.  Unless they transitioned into the role from within IT's management I have no patience for that type of PM.


You don't want PMs with technical skills.  Then they start to make decisions on things they shouldn't be making.  I cannot remember how many times a project veered off course due to a "helpful" PM thought he/she knew better than the architect or engineer leading the project.

/i'm personally running a year long project right now because it was almost driven into the ground by a PM who thought she had technical chops
//we fired her ass
///the new PMs are competent and non-technical
 
2013-10-26 12:57:44 PM  

gingerjet: This is relevant:

The Obamacare Suits/Geeks Divide

/we are gearing up to roll out a major internet service in just a couple of weeks so I'm getting a kick


They can have my copy of the Mythical Man Month.

/What do you mean we can't hire 9 women to birth a baby in a month?
 
2013-10-26 01:33:57 PM  

wingnut396: bagumpity: Define "successful."

From the viewpoint of a typical IT services company, success means "bills lots of hours."  Following methodologies and engineering for reusability are bad because they reduce the amount of hours billed to bring a project to production.  Quality is counterproductive since it reduces the number of maintenance hours needed.  Documentation should be eschewed because it makes it easier to replace your company with another and might reduce the amount of time required for change requests and bug-fixes to be implemented.

Usually the ones I see that operate like this are cheaper on the billable hours, pay their staff like crap, have a high turnover but good used cars like sales folks.  It may cost more up front, but pay for a company that has a stable workforce and enforces things like a proper ticketing and documentation system.  If you want cheaper rates and a reason to bag on IT folks, keep going with the company that  sends you a new tech every 3 months.


Reminds me of my Boobies-internship IT job. The company offered managed networking and telecommunication services for many small to medium businesses in the area. It was easy to see why projects were doomed to fail right off the bat.

The first reason was that the sales department was running the show. There was very little consultation, if any, with the IT department before selling the customer on a project. This would lead to promises being made that were technically infeasible, incompatible hardware being ordered and wildly unrealistic customer expectations regarding timetable and quality of services.

As if this wasn't bad enough, there was a striking lack of technical prowess on the IT team. out of about 10 technicians, only three even understood the fundementals of networking (i.e. what  is the OSI model, what are sub-nets,  how do devices communicate on layer 2 vs layer 3 etc.) The rest of the techs had done some cookie cutter courses on how to configure PBX from a GUI with no understadning of the underlying principals.

Needless to say, the pay was below industry average (though it was better than my internship stipend). Any skilled workers that came into the place left quickly (from what I heard anyway). I only lasted 7 months before I had to GTFO. Unsurprisingly, the incompetent techs stick around long term.

/csb
 
2013-10-26 01:37:54 PM  
Some easy steps to make some things go easier. 1) No software purchases will be done without technical review.
2) No purchase commitments will be made on a damn golf course.
3) the project lead developer should have a full grasp of the problem being solved before the first line of code is written (here's a hint, you are looking to fix a process not technology)
4) Prioritize needs before wants when looking at requirements.
5) if you want professional results, fund at a professional level.
6) Deadlines created in a vacuum of challenges are deadlines that will be missed. Either set your deadlines with full knowledge of the obstacles or start your project with enough lead time allow for three unknown.
7) The developers do noy get to go on vocation until at least one week after the launch is successful if they want to wait till after launch to take time off.
8) At all levels, if you don't have time to document, you don't have time for a project.
9) If a junior developer or mid level one with a track record on deadlines says it will take X hours, plan on 2X hours.

"You don't want PMs with technical skills. Then they start to make decisions on things they shouldn't be making. I cannot remember how many times a project veered off course due to a "helpful" PM thought he/she knew better than the architect or engineer leading the project."
I have to politely disagree; non-technical Pm's do the same thing, they just assume that if it's easy to do something in excel it's easy everywhere.

"Their role is to bust the techies' chops for not meeting their deadlines, and get their own chops busted by the management when the project timeline slips."
That mentality huge part of the problem. A pm can do that if needed, but their largest role is facilitation, making sure everyone had and gets what they need to get the job done.

Sorry about the quotes, I'm doing this from my phone.
 
2013-10-26 01:38:37 PM  

manbart: Reminds me of my Boobies-internship IT job


goddammit.

Boobies-internship
 
2013-10-26 01:40:12 PM  

manbart: manbart: Reminds me of my Boobies-internship IT job

goddammit.

Boobies-internship


Where might I sign up to have my very own boobies-interns?  I don't think I'll really care what they do, I'll take a half dozen.
 
2013-10-26 01:40:40 PM  

manbart: manbart: Reminds me of my Boobies-internship IT job

goddammit.

Boobies-internship


I hate that filter, it could at least show on preview... the first job I had after my internship...
 
2013-10-26 01:42:01 PM  
"Boobies-internship" double filter powned. Ha!
 
2013-10-26 01:43:59 PM  

gingerjet: You don't want PMs with technical skills. Then they start to make decisions on things they shouldn't be making. I cannot remember how many times a project veered off course due to a "helpful" PM thought he/she knew better than the architect or engineer leading the project.


I partially agree.  It's not that you don't want a PM with technical skills (though your observations of how that might be an impediment are valid), it's more that you don't need one.  A good PM should be a good PM regardless of what the project is.  If the project is planting a crop and harvesting for the season or setting up a new BTB website or whatever.  What the project is should be immaterial.  The PM shouldn't be in the minutia.
 
2013-10-26 01:46:49 PM  
"They can have my copy of the Mythical Man Month"

I love that book. I've specialized in going into rogue development shops that are floundering after a couple years of moderate success. That is my first expense. The manager gets to read it while I'm assessing the environment. They tend to hate it.
/but some learn from it.
 
2013-10-26 01:51:08 PM  
Many people in IT are uneducated idiots, who were socially awkward enough to spend their youth alone on a computer.

This is changing, but the old guard are now in the senior management roles. Once they die, you still have to contend with the onslaught of Indian scabs, lined with useless degrees and certifications.
 
2013-10-26 01:59:48 PM  
fst_creeper:
"Their role is to bust the techies' chops for not meeting their deadlines, and get their own chops busted by the management when the project timeline slips."
That mentality huge part of the problem. A pm can do that if needed, but their largest role is facilitation, making sure everyone had and gets what they need to get the job done.


I know what you're saying, though to a certain extent it's really the management's job to provide resources. The PM should be running interference between the techs and management to ensure those resources are indeed available when they're needed. Because when they're not, then the schedule goes to hell. But still, that's probably what you're saying anyway. You make excellent points.
 
2013-10-26 02:05:09 PM  
Well, I believe that's a little better than a brick and mortar new business venture. So they've got that going for them.
 
2013-10-26 02:05:28 PM  
I used to do in-house programming for several departments, basically building UIs to the back-end database, some of which I created. My biggest obstacle was managers and directors who thought they knew how things actually got done in their domain. Hint: they didn't.

My most successful projects started with a white board and a room of end users (if the manager allowed). I'd draw a box on the white board and ask, what input/dropdown list/check box goes where, what does it do, does it automatically fill in other boxes, where do these fit on the screen, what things are editable, what buttons go where and what do they do, etc.

Once I knew what the end user specs were, as opposed to the manager's specs were. I could develop the database and the UI.
 
2013-10-26 02:12:38 PM  
MayoSlather: Managers are tasked with projects

"Tasked with projects?"

That's managerial speak, you're not fooling anyone.

// assigned projects, given projects, etc.
 
2013-10-26 02:15:55 PM  
pdieten: I don't think it's all that rare for PMs to have no tech skills.

What's a PM?

// sadly, only partially kidding

// System Analysts end up doing the work of PMs on most projects.
 
2013-10-26 02:26:46 PM  

gingerjet: BumpInTheNight: Yes its common that a project manager hasn't got any background on the projects they are supposed to be masterminding, doesn't make it any less silly every time you encounter one of these useless twats out in the wild.  Unless they transitioned into the role from within IT's management I have no patience for that type of PM.

You don't want PMs with technical skills.  Then they start to make decisions on things they shouldn't be making.  I cannot remember how many times a project veered off course due to a "helpful" PM thought he/she knew better than the architect or engineer leading the project.

/i'm personally running a year long project right now because it was almost driven into the ground by a PM who thought she had technical chops
//we fired her ass
///the new PMs are competent and non-technical


That's nice and all and I've worked fine with PMs that could not do the actual technical work.  No problem.

The problem here is that the PM doesn't even speak the language.  Its hard to allocate and provision resources when they don't know what the project entails. Its like saying its okay to hire a general contractor to build your house and then they ask what what slab, plumbing and wiring is.
 
2013-10-26 02:38:31 PM  
And 100% of non-IT projects are successful?
 
2013-10-26 03:04:27 PM  

MayoSlather: I'd attribute this in large part to management. Managers are tasked with projects that have IT elements and they have no idea what their particular IT department can do, how much time and resources they have for their project, or even a full understanding of what they need.


After 17 years in IT I hate to admit this, but a good project manager is worth their weight in gold.  They write a good project plan, avoid scope creep, keep the project on track and things are delivered.  They keep the IT managers that know nothing about IT out of messing with a running project.


 
2013-10-26 03:09:07 PM  

MayoSlather: I'd attribute this in large part to management. Managers are tasked with projects that have IT elements and they have no idea what their particular IT department can do, how much time and resources they have for their project, or even a full understanding of what they need.


Mugato: Outsourcing everyone probably didn't help.


Aaaand we're done here.
 
2013-10-26 03:21:46 PM  

Nemo's Brother: Many people in IT are uneducated idiots, who were socially awkward enough to spend their youth alone on a computer.

This is changing, but the old guard are now in the senior management roles. Once they die, you still have to contend with the onslaught of Indian scabs, lined with useless degrees and certifications.


Many people are uneducated idiots, who are socially self-entitled to a point where they think they should be able to feel superior to the sorts of people who are passionate about things they don't understand like, by way of example, computers.

This is changing, but the old guard are now in senior management roles. Once they retire or die, you will still have to contend with their pampered spawn who are just as self entitled, armed with useless MBA's that learn nothing from history and are convinced that their own inexperienced dreams are just as valid as the advice given to them by the technical people with years of experience.

/idiots exist at all levels, but management rewards them.
// it takes a village to raise an idiot.
 
2013-10-26 03:37:44 PM  

Mugato: Outsourcing everyone probably didn't help.


Yeah, but it saved money.
I'm not trying to be too much of a dick here, but the fact is, American companies didn't just try offshoring because they thought it would save them money.
Companies outsource because their IT projects fail anyway. Make shiat work. No one will care about cost, if your shiat works. But it doesn't. That's the real problem; 10% of programmers do 90% of the work, and that's the problem that needs to be solved. That's why we give four yeur degrees in CS, why we've split the writing of while loops out from actual intellectual endeavors like math and EE. But right now, the situation is, we still don't know how to make shiatty programmers good. At least when CS was tied with math, you could bank on hiring someone smart enough to know how to count how many subgroups can fit on the head of a pin, but now, all you get is someone who can write a while loop like the most bad-ass of seven year olds.
 There's a management problem involved, but management is a problem everywhere, not just in IT. The fact that IT projects have such amazing failure rates has to be traced to the fact that 10% of IT workers know what they're doing, and the rest of them just know how to speak Klingon.
 
2013-10-26 04:09:04 PM  

HighlanderRPI: gingerjet: This is relevant:

The Obamacare Suits/Geeks Divide

/we are gearing up to roll out a major internet service in just a couple of weeks so I'm getting a kick

They can have my copy of the Mythical Man Month.


Should be required reading for anyone in technology.   I buy it in bulk and hand it out to anyone on a project I get a bad feeling about.

Management isn't the problem, generally.   They're just part of the problem.   The other part of the problem is technical people that don't really get they're in a business, and really just want to play with the latest and greatest whizbang technology fad that just came out.     The conversation usually goes like this.

"We need to lower our IT costs."   

"We can do that if we just throw out our existing infrastructure and migrate it all to this other thing, because it's free!"

"How much will that cost."

"Nothing.  It's free!"

* time passes *

"We need to hire four more people to port the old system to the new one because if we don't it will be 18 months before we reach feature parity."

And on it goes.
 
2013-10-26 04:11:11 PM  
I love threads like this. 40+ years in, still never saw PM/Manager/Senior level programmer ("I'm a code God") worth a damn. And no, 10% of the code monkeys don't do 90% of the work in a balanced environment. Worked for too many Fortune500 companies, the feds & 4 state governments. It never changes.
 
2013-10-26 04:30:30 PM  

Rent Party: HighlanderRPI: gingerjet: This is relevant:

The Obamacare Suits/Geeks Divide

/we are gearing up to roll out a major internet service in just a couple of weeks so I'm getting a kick

They can have my copy of the Mythical Man Month.

Should be required reading for anyone in technology.   I buy it in bulk and hand it out to anyone on a project I get a bad feeling about.

Management isn't the problem, generally.   They're just part of the problem.   The other part of the problem is technical people that don't really get they're in a business, and really just want to play with the latest and greatest whizbang technology fad that just came out.     The conversation usually goes like this.

"We need to lower our IT costs."   

"We can do that if we just throw out our existing infrastructure and migrate it all to this other thing, because it's free!"

"How much will that cost."

"Nothing.  It's free!"

* time passes *

"We need to hire four more people to port the old system to the new one because if we don't it will be 18 months before we reach feature parity."

And on it goes.


Eh, it takes two.

Just as often management wants to throw some new, buzzword infested value adding software into the system that will magically make everything conform to the latest buzzwords traits and magic Gartner quadrants.  Of course they have denied the past 5 years of infrastructure upgrades, because after all,upgrades are just IT wanting to 'play' with the latest dodaddles.   Just so happens that the guys selling them the magic buzzword beans neglected to tell them you need to have an up to date infrastructure to handle their software properly.  So IT is left manically cobbling together all kinds of crap to get it to work. Cobbles that invariable make updating the infrastructure at some later date an even larger pain in the ass... and more costly.
 
2013-10-26 05:01:22 PM  

rumpelstiltskin: Yeah, but it saved money.


I'm not even in software development anymore, thankfully but I used to be and I still have a lot of friends in the field and all they say it is that the outsourced people can't code and can't document what they do code and it's biting all the companies in the ass.
 
2013-10-26 05:27:39 PM  

gingerjet: BumpInTheNight: Yes its common that a project manager hasn't got any background on the projects they are supposed to be masterminding, doesn't make it any less silly every time you encounter one of these useless twats out in the wild.  Unless they transitioned into the role from within IT's management I have no patience for that type of PM.

You don't want PMs with technical skills.  Then they start to make decisions on things they shouldn't be making.  I cannot remember how many times a project veered off course due to a "helpful" PM thought he/she knew better than the architect or engineer leading the project.

/i'm personally running a year long project right now because it was almost driven into the ground by a PM who thought she had technical chops
//we fired her ass
///the new PMs are competent and non-technical


They should have at least a basic understanding of what they are working on so they will know what is feasible and what type of provisioning and scheduling is realistic.
 
2013-10-26 05:35:31 PM  

Handsome B. Wonderful: And 100% of non-IT projects are successful?


Big ticket civil engineering projects (building, road, bridge, etc. construction) tend to have a high on-time success rate and little need for post-rollout fixes, because such projects and their complexity have been well understood for a long time.

Things like the problems with Boston's "big ditch" really are rare exceptions.
 
2013-10-26 06:24:16 PM  

fst_creeper: 7) The developers do noy get to go on vocation until at least one week after the launch is successful if they want to wait till after launch to take time off.


Enjoy your H1Bs. Cancelling someone's vacation that's been on the calendar for six months due to things outside of their control is a good way to ensure they'll leave your company, probably in the middle of a project. Spouses and kids aren't going to be understanding about having their vacation ruined because a PM screwed around the first half of the project and then didn't have the backbone to push back on requirement changes late in the project. Developers are too much in demand to put up with such behavior. The only ones who will are those who you're better off without.
 
2013-10-26 07:29:25 PM  
Speaking of buzzwords, when did "best fit" and "best practice" become current IT terminology? Perhaps a PM with rudimentary ITIL on his/her resume. And they get hired by the oh so knowledgable HR department. Farking hilarious when the PM was fired and the middle manager had to take over...(and made things even worse). This'll happen when you have managers/PMs that have spotty 4 month tenures on their resume. All because of industry buzzwords. Management by magazine.
 
2013-10-26 08:40:33 PM  

EngineerAU: fst_creeper: 7) The developers do noy get to go on vocation until at least one week after the launch is successful if they want to wait till after launch to take time off.

Enjoy your H1Bs. Cancelling someone's vacation that's been on the calendar for six months due to things outside of their control is a good way to ensure they'll leave your company, probably in the middle of a project. Spouses and kids aren't going to be understanding about having their vacation ruined because a PM screwed around the first half of the project and then didn't have the backbone to push back on requirement changes late in the project. Developers are too much in demand to put up with such behavior. The only ones who will are those who you're better off without.


It's not been an issue yet. I'm not talking about canceling vacation planned 6 months ago.
The situation I'm taking about is a developer turning in a 4 month effort and immediately trying to go off the grid for the next two weeks. Typically it's senior dev's who think their shiat doesn't stink. When confronted with a lead developer who plays by the same rules, they grumble a bit and then get on with it. Funny thing, they also trend to be more careful in their work. They might even discover a meeting on their calendar off site with a customer that happens to cancel but we "forget" to update their calendar. I take care of my developers if they take care of me.
 
2013-10-26 10:17:23 PM  
There are millions of ways to screw up a development project and only a handful of ways to be successful.  It takes experience all around the team.  Also the team needs to keep the sales people from messing everything up.
 
2013-10-26 10:17:40 PM  

pdieten: wingnut396: Recently we got a new project management MBA type grad freshly minted out of school to run a high level initiative.  We were told he is a fast learner and should not be concerned about his lack of IT experience or the fact that his undergrad is not IT related.  Things he did not know what the letters stood for or what the technologies were: AD, SMTP, TCP/IP, UDP, UNIX, NT, Exchange, LDAP,....

I don't think it's all that rare for PMs to have no tech skills. Their role is to bust the techies' chops for not meeting their deadlines, and get their own chops busted by the management when the project timeline slips.


But they still need to have at least a modicrum of understanding of technology or be willing to learn about it outside of the project meetings.

manbart: Reminds me of my Boobies-internship IT job. The company offered managed networking and telecommunication services for many small to medium businesses in the area. It was easy to see why projects were doomed to fail right off the bat.

The first reason was that the sales department was running the show. There was very little consultation, if any, with the IT department before selling the customer on a project. This would lead to promises being made that were technically infeasible, incompatible hardware being ordered and wildly unrealistic customer expectations regarding timetable and quality of services.

As if this wasn't bad enough, there was a striking lack of technical prowess on the IT team. out of about 10 technicians, only three even understood the fundementals of networking (i.e. what  is the OSI model, what are sub-nets,  how do devices communicate on layer 2 vs layer 3 etc.) The rest of the techs had done some cookie cutter courses on how to configure PBX from a GUI with no understadning of the underlying principals.

Needless to say, the pay was below industry average (though it was better than my internship stipend). Any skilled workers that came into the place left quickly (from what I heard anyway). I only lasted 7 months before I had to GTFO. Unsurprisingly, the incompetent techs stick around long term.


Two years ago, my (as of Friday) former employer hired a company like this to implement a virtual desktop platform.  The first engineer we were assigned was there long enough to install the hardware before leaving.  The only remaining "qualified" engineer was stretched so thin that we were lucky to get him once a week.  He only lasted a few months before moving on.  I ended up having to do most of the implementation work myself.  The project plan, as I recall, was only a few pages long and contained a few details about the design.  There was no design or as-built documentation for the work they did, and I had to reverse engineer most of that when we wanted to fix the mistakes they made (or, for that matter, any design justifications that outlined why they made certain decisions).  The system that they built was designed to suck as much money out of the organization (a church) as possible on an ongoing basis with inadequate and expensive managed services.

On top of that, there was a push from someone within our department to not only continue doing business with them but to give more business to them even though the CFO of my former organization didn't like them.

Not that I was any better.  I never had time to maintain proper documentation as the sole infrastructure person in a 850-seat environment, but I at least tried to label everything inside the systems and maintained some documentation of the stuff I had to reverse engineer.  At least the preparation I'm doing for some VMware certifications is giving me a bit of respect for proper documentation throughout the entire systems design process.

The funniest part of this is that the consulting company that put this in is the one that is going to be replacing me, and no one asked me to stay a little longer to train them.

/csb
//I know what was going on.  I'm not that naive.
 
2013-10-26 10:48:16 PM  

fst_creeper: EngineerAU: fst_creeper: 7) The developers do noy get to go on vocation until at least one week after the launch is successful if they want to wait till after launch to take time off.

Enjoy your H1Bs. Cancelling someone's vacation that's been on the calendar for six months due to things outside of their control is a good way to ensure they'll leave your company, probably in the middle of a project. Spouses and kids aren't going to be understanding about having their vacation ruined because a PM screwed around the first half of the project and then didn't have the backbone to push back on requirement changes late in the project. Developers are too much in demand to put up with such behavior. The only ones who will are those who you're better off without.

It's not been an issue yet. I'm not talking about canceling vacation planned 6 months ago.
The situation I'm taking about is a developer turning in a 4 month effort and immediately trying to go off the grid for the next two weeks. Typically it's senior dev's who think their shiat doesn't stink. When confronted with a lead developer who plays by the same rules, they grumble a bit and then get on with it. Funny thing, they also trend to be more careful in their work. They might even discover a meeting on their calendar off site with a customer that happens to cancel but we "forget" to update their calendar. I take care of my developers if they take care of me.


It's not just devs doing this on a project - I've seen sign-off people on the business side go off-grid mid project, often putting in massive efforts to get the scope changed but not to then articulate/re-sign-off what it all means. Again it's IT's fault.

/ not a dev
// dba, so I see all the times where someone takes leave and how much crap they leave for other people.
/// really sick of cleaning up other people's messes...
 
2013-10-27 12:57:36 AM  
I'm not sure why they are blowing this out of proportion.  The normal rate of project failure in business is close to that number if not higher.  Where I work, I would say closer to 80% of projects fail, about 50% never getting past the initial developement and another 30% failing long before they accomplish anything.  In business, everything is in a continual state of flux, sometimes a project that is relevant today simply has no place tomorrow.  It's all in how you massage the statistics that gives you these skewed results.
 
Displayed 50 of 53 comments

First | « | 1 | 2 | » | Last | Show all

View Voting Results: Smartest and Funniest


This thread is closed to new comments.

Continue Farking
Submit a Link »






Report