Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
I'm sure a lot of you have been in similar situations(if you've worked for large companies in a relatively IT oriented job).
A new project comes along. It's far too much work for the normal team to take on, so the answer is consultants. Hire a bunch of "experts" to help get the new system or whatever off the ground, then afterwards, things will become the responsibility of the normal team. Consultants are here just to get the ball rolling and provide their "expertise" in the design stage(since we all know it's easier to build something right the first time than fix it alter)
Except that never seems to work!
My career is focused on a consolidation system used by global companies. I've developed a hatred for consultants because it seems that every time a consultant comes along, you get one of 3 possibilities.
1) That consultant is happy to build something that meets the needs... of this second. Everything's hard coded, nothing is sustainable, maintaining it is a nightmare.
2) That consultant can't be relied on to do anything beyond EXACTLY what you tell them to do. If you tell them to pick up a stapler, they need to know EXACTLY how high. Lift it 3.2"? 5.7"? They need exact specifics or they can't lift in at all. By the time you've gotten through telling them EXACTLY what to do, you could have done the job yourself in in 1/10th the time, or automated it in 1/2 the time.
3) They are obsessed with documentation. They don't care if it works, they just care if it's documented in a process, with about 20 forms behind it. This type of consultant would happily sit abord the titanic saying that everything's working perfectly as the ship sinks... because the process documentation indicated that "In the event of an iceberg collision, everyone dies" and that's what happened, so Success!
Have I just had unbelievably horrible luck, or is this the norm for the consulting world?
My father did consulting (computer programmer) near they end of his work years, after working many decades in scientific institutes/National Labs. He was shocked at the caliber of work of employees at many of the companies he went to as a consultant. In fact, he had some of YOUR complaints, but directed at the employees!
He noticed that everything was short term goal driven by the employees.... everyone had project end dates/goals that had to be met. It didn't matter if things actually worked, or if the data was wrong, or if the program written was unbearably slow and full of bugs, or even what the next step of the project would be. The goal/date had to be met so reviews would be positive, promotions would be gotten, and raises given.
These were massive National corporations. Like AT&T, All-State Insurance etc..
My Dad was an amazing programmer, who would sometimes finish projects in a day that others at the companies would say they needed months to complete. He hated working in those companies, and quickly realized the work ethic and work pride he knew from academia just didn't exist in the corporate world. And wow.... did he see people get paid a ton of money (compared with academia!) for crappy work... Life just doesn't jive.
My father did consulting (computer programmer) near they end of his work years, after working many decades in scientific institutes/National Labs. He was shocked at the caliber of work of employees at many of the companies he went to as a consultant. In fact, he had some of YOUR complaints, but directed at the employees!
He noticed that everything was short term goal driven by the employees.... everyone had project end dates/goals that had to be met. It didn't matter if things actually worked, or if the data was wrong, or if the program written was unbearably slow and full of bugs, or even what the next step of the project would be. The goal/date had to be met so reviews would be positive, promotions would be gotten, and raises given.
These were massive National corporations. Like AT&T, All-State Insurance etc..
My Dad was an amazing programmer, who would sometimes finish projects in a day that others at the companies would say they needed months to complete. He hated working in those companies, and quickly realized the work ethic and work pride he knew from academia just didn't exist in the corporate world. And wow.... did he see people get paid a ton of money (compared with academia!) for crappy work... Life just doesn't jive.
Have to say, it sounds like it would have been nice to work with your dad. Maybe I'm viewing this an a "consultant" problem when it's really just a "most employees" problem.
Doesn't solve it... it actually just shows that it might not be consultant driven and I think that's even more depressing...
That's not consultant specific. Those are all common with in-house staff. Those issues seem to be more common with publicly traded companies, because they need to meet their deadlines now. I like working for smaller privately owned companies, if they have strong IT management that can push for more resources.
Management pushes good employees to cut corners, so they get their bonus for the project finishing. They don't care, because the AVP will leave in 2 years to be a VP at the competitor. This project will be all over his resume as saving the company millions, when there lots of mistakes that cost more than it saved.
The big companies are notorious on excessive documentation for the SDLC and to cover themselves for IT compliance. They still manage to screw it up, because of poor testing on the back end. You may need to fill a 2-3 page document and multiple approvals to get one line of code change.
As for developers that need to know exact requirements from the line of business, I see that everywhere. They just do it for CYA purposes. They blame the line of business on bad requirements, when the project fails. Who cares if the data is corrupted, because there are no primary keys on the main tables? The business units don't even know what a primary key is.
I'm sure a lot of you have been in similar situations(if you've worked for large companies in a relatively IT oriented job).
A new project comes along. It's far too much work for the normal team to take on, so the answer is consultants. Hire a bunch of "experts" to help get the new system or whatever off the ground, then afterwards, things will become the responsibility of the normal team. Consultants are here just to get the ball rolling and provide their "expertise" in the design stage(since we all know it's easier to build something right the first time than fix it alter)
Except that never seems to work!
My career is focused on a consolidation system used by global companies. I've developed a hatred for consultants because it seems that every time a consultant comes along, you get one of 3 possibilities.
1) That consultant is happy to build something that meets the needs... of this second. Everything's hard coded, nothing is sustainable, maintaining it is a nightmare.
2) That consultant can't be relied on to do anything beyond EXACTLY what you tell them to do. If you tell them to pick up a stapler, they need to know EXACTLY how high. Lift it 3.2"? 5.7"? They need exact specifics or they can't lift in at all. By the time you've gotten through telling them EXACTLY what to do, you could have done the job yourself in in 1/10th the time, or automated it in 1/2 the time.
3) They are obsessed with documentation. They don't care if it works, they just care if it's documented in a process, with about 20 forms behind it. This type of consultant would happily sit abord the titanic saying that everything's working perfectly as the ship sinks... because the process documentation indicated that "In the event of an iceberg collision, everyone dies" and that's what happened, so Success!
Have I just had unbelievably horrible luck, or is this the norm for the consulting world?
I've had similar experiences to yours, mainly with India-based consulting firms hired by US companies. They are terrible.
I've been a developer for 10 years and have been in I.T. almost 18 years. I am one of those developers who CAN code without a specification or requirements, but I strongly prefer having them for several reasons:
1.) I can't code to a guess.
2.) If there is no spec or no requirements, how do we know if we have the right answer? Since I do database development, correct results are THE most important aspect of my work.
3.) If specs/reqs don't exist, how is QA supposed to formulate test plans/cases?
4.) If specs/reqs don't exist, how do you determine the exit/signoff criteria for UAT?
5.) If specs/reqs don't exist, re-work and post-release defects rise exponentially.
6.) Without specs/reqs, there is no protection whatsoever from scope creep.
7.) Since I do mainly ETL here, the underlying business logic is frequently a mystery to me. It is impossible for ETL developers in this company to be SMEs in every single module of our code. Our source database has (literally) thousands of tables. Thousands. Some of those tables sport hundreds of columns. There's no way for us to know all of it. We rely on SMEs to assist with, and in some cases provide, the business logic that interprets what constitutes a specific data point. Without specs/reqs, this knowledge is passed around in e-mail threads that get long and annoying. Things get missed.
Please register to post and access all features of our very popular forum. It is free and quick. Over $68,000 in prizes has already been given out to active posters on our forum. Additional giveaways are planned.
Detailed information about all U.S. cities, counties, and zip codes on our site: City-data.com.
Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
