Comments
4 Outsourcing Mistakes Companies Still Make
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 3 / 3
TerryB
100%
0%
TerryB,
User Rank: Ninja
8/25/2014 | 1:28:13 PM
Re: Outsourcers
That's a pretty blanket statement on "coders". There are quite a few of us out here who do the whole package. And funny thing, we tend not to outsource. It's only when you get a bunch of "architects" who can't produce a working product that a company starts looking outside itself. I'm assuming you work for a big company, where teams are so big no one can take a project from the user's mouth to have working code that does what it supposed to.

That is certainly no knock on you, not my intention here to insult you. I'm sure you are correct in all you said. But when you go from a complex communication path internally (architects to coders) it makes it pretty easy for mgmt to move the coding outside. And then you have added a bunch of coders who care about THEIR company and job, not yours. So the CYA factor during communication goes way up, that is your increase in lead time.

The core premise of Agile methodology is flat structure. If the guy getting requirements from users is same guy writing code, you can iterate to what users want pretty quickly. When dealing with large internal teams using waterfall, or outsourcers, what you talk about is a fact of life.

Again, not trying to insult you, but outsourcing probably works best when people like you don't exist. Let the outsourcer handle it (design thru code) and hold them responsible for working systems. If you have the expertise to define the application that thoroughly like you do, just write the code internally so you are in control. And accountable.
jjobe323
100%
0%
jjobe323,
User Rank: Apprentice
8/25/2014 | 12:47:20 PM
Outsourcers
Ms. Laurianne, when we deliver documents which EXPLICITLY define data/database design standards & expectations from the request for quote to final acceptance -- the entire lifecycle of the project -- & have built a validation tool to ensure those standards are met, the problem then lies COMPLETELY with the outsource vendor.  In effect, the vendor is telling US what standards s/he is going to comply with & which we may not-so-politely stuff in our ears -- regardless, the vendor expects to be paid for an unfinished, non-compliant deliverable.  We refuse to accept the product, the vendor begins whining, & the real fun begins.

My point:  In the couple of years my company has been outsourcing application development projects, it has been the outsource vendor as the source of 90% of insufficient communication, conflict, & tension.  The implementation time required to get the outsource project functional has increased from 6 to 10 hours to 2 to 6 weeks -- a good bit of the added time showing the vendor where IF our standards had been complied with in the first place, the issues encountered would never occurred.  The vendors know LONG before implementation -- because we provide the findings reports from our validation tool -- their deliverable is out of compliance; there's no last minute 'gotcha!'.

They don't want to comply with data/database design standards because the coding tools they use are constructed for optimized CODE.  From that code, a database is, basically, reverse-engineered.  They're coders -- that's what they do & they're good at it.  I remember back in the Dark Ages when coders did everything from gather the requirements to write the programs to design the databases to implement the whole kit-&-kaboodle.  I remember because I was one. 

Coders are a lot like race horses:  They're blindered so they can only see what's directly ahead of them.  That's what makes a good coder.  See problem, fix problem, next problem.

Architects have to see the entire race track -- taking the analogy further.  As a matter of fact, we also have to see the stands, offices, parking lots, etc.  We HAVE to keep a handle on how the "everything" fits together.  Design standards enable us to do that more effectively & efficiently.

The other 10% of all project issues usually belongs to users changing their minds after development has begun.  But that is an entirely different herd of ponies.
PedroGonzales
100%
0%
PedroGonzales,
User Rank: Ninja
8/25/2014 | 12:46:13 PM
Re: On the subject of control freaks . . .
I agree.  If a company isn't clear with the outsource companies about its own goals and objectives they won't able to solve their problem. I noticed that too that relying on a single factor(cost) it narrow the view by not taking into account the other factor which can impact while working with an outsource company as you have point it out.
Laurianne
50%
50%
Laurianne,
User Rank: Author
8/25/2014 | 11:58:56 AM
Outsourcers
"If you're not dealing with your own conflicts between IT and the business, outsourcing will not fix them." This is an important point that Michelle raises. If anything, the tensions can get worse when business expectations are not met and IT shifts the blame to the outsourcer.
Lorna Garey
100%
0%
Lorna Garey,
User Rank: Author
8/25/2014 | 11:57:52 AM
Pricing
Shane, In terms of item #2, cost vs. quality. Is the answer to price per job vs. per hour? Say, $5,000 for [complete job] with additions only if the customer expands the scope. That way if the outsourcer takes longer than it estimated, that doesn't hit IT's budget.
Somedude8
100%
0%
Somedude8,
User Rank: Ninja
8/25/2014 | 11:23:08 AM
Re: On the subject of control freaks . . .
Sounds like there are some strange ideas floating around that you are trying to resist. Stand your ground, because you are 100% right!

Standards and sensible design are super important for the database. If the database is screwy, anything built on it will be screwy too. IMO, database design is the place where you get the best and brightest you have and let them do it right, not something to be sent out of the shop to the lowest bidder.
Ariella
100%
0%
Ariella,
User Rank: Ninja
8/25/2014 | 11:14:25 AM
Re: On the subject of control freaks . . .
All observations are spot on, though I particularly like, "Don't think the outsourcer will do all the thinking for you."
jjobe323
100%
0%
jjobe323,
User Rank: Apprentice
8/25/2014 | 10:23:46 AM
On the subject of control freaks . . .
. . . we've been accused both repeatedly & vehemently.  Not in relation to managing the project, but in data & database design standards we REQUIRE for these deliverables.

Amazing that coders have no issues -- either verbally or in practice -- incorporating CODING standards into the final deliverable, but data/database design standards are just too onerous & time-wasting.  Definitions!?  We don't need to stinkin' definitions documented for the project. 

Whether the disconnect results from a communication problem, a philosophical difference in design/construction methodologies, or a money-manhour issue for the outsource developer, getting the job "done" includes documentation & compliance with pre-determined company standards.  Otherwise, you shouldn't be paid . . . period.
<<   <   Page 3 / 3


Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 7, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program!
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.